Sit in the support queue for an hour

Everything in this part of the book has a scheduling problem. Finding the person who hurts takes a week of asking around. Watching someone work needs their calendar and yours. Getting a named user to answer questions requires that somebody introduce you.

Support has none of that. The queue is already full, it is full of people describing problems in their own words, and you can be reading it in four minutes without asking anyone’s permission.

It is the only user research a developer can start this afternoon, and it is the one almost nobody does.

Companies that take this seriously make it compulsory

This is not a hack. Two companies known for shipping good software have written it into how they onboard people.

Automattic puts every single new hire, whatever their role, through a support rotation. Their employee field guide is direct about it: “For most Automatticians, onboarding begins with a two-week support rotation.” The guide even scripts the objection, “but I’m not a Happiness Engineer,” and answers it: the rotation “brings you close to our users and gives you a taste of their needs and frustrations.”

37signals runs a company ritual they call Everyone on Support, on the same reasoning.

Two weeks is more than I am asking of you. I am asking for an hour.

The move

Read one hour of your product’s support queue, and write down what people were trying to do rather than what went wrong.

What you are listening for

Not bugs. Support already handles bugs, and they are better at it than you.

The words they use. Marta’s team says cost centre. Your database column is org_unit_id and your UI says Department. Three names for one thing, and only one of them is the one your users have.

What they tried first. The wrong click before the right one is a design finding, and it arrives free, over and over, in ticket after ticket.

Questions that should not be possible. How do I see what this was before I changed it? is not a support question. It is a missing feature, filed as confusion, because the user assumes the capability exists and they are failing to find it.

Repetition across different words. The same underlying gap arrives four times an hour, described four different ways, which is exactly why nobody upstream ever recognises it as one thing.

ONE HOUR, TUESDAY AFTERNOON            WHAT IT WAS ACTUALLY ABOUT

 "how do I change the cost centre   x4  they cannot find it. it exists,
  for someone who's left?"                two clicks from a page they
                                          have no reason to open

 "the export is missing the         x2  our CSV writes the id.
  department column"                      they need the name

 "can you re-run the September      x1  the DO NOT DELETE tab again.
  file for me?"                           nothing in the product can
                                          answer "what was it before?"

 "is the system down?"              x3  a nine-second page load

  seven of ten tickets. not one is a bug.
  three of them are the same missing concept in three costumes.

That third row is the same thing Marta’s spreadsheet was compensating for, arriving through a completely different door. When a gap shows up in the workaround and in the queue, you are no longer guessing.

Why this matters more now

DORA’s research names user-centric focus as one of the small set of capabilities that decide whether adopting AI helps a team or hurts it. It also identifies the inverse as an antipattern: team structures that systematically disconnect developers from the people using the software leave them without the context to build anything valuable, and, in the AI era specifically, without the context needed to judge whether what the model produced is any good.

That second half is the part worth holding onto. Reviewing generated code for correctness is a solvable problem with tooling. Reviewing it for whether it does the right thing requires knowing what the right thing is, and no amount of tooling supplies that. An hour in the queue does.

What it costs

Support is a biased sample and you must not forget it. You are reading from people who hit a problem and had the energy to report it. The users who silently gave up, or built a spreadsheet instead, are absent by construction. Treat the queue as a source of problem shapes, never as a measure of how common anything is.

It is emotionally heavier than you expect. An hour of people being frustrated with something you built is not a neutral hour, and reading it defensively is the failure mode. If you find yourself mentally arguing with a ticket, that is the signal to note the ticket and move on.

And you will want to fix things immediately. Resist it for the hour. The first fix that occurs to you is almost always for the ticket in front of you rather than for the pattern, and the pattern is what you came for.

Try this week

Get read access to the support queue. In most companies this is a Slack message to whoever runs support, and the answer is yes, because nobody has ever asked.

Then block one hour, read tickets in the order they arrived, and keep a tally with two columns: what they were trying to do, and how many times it came up.

At the end, take the row with the highest count and go and look at whether your roadmap has anything to say about it. Usually it does not, and now you have ten quotes in users’ own words about something nobody has planned.

That is a better piece of evidence than most feature requests arrive with, and it cost you a Tuesday afternoon.