You've had the conversation. You showed up as a human, you made it safe for the customer to be honest, and you stayed quiet long enough to hear the real thing. Now you're back at your desk with pages of notes, and something the customer said has lit you up. You can already see the feature. You want to start building.
This is the most expensive moment in the job, and almost everyone gets it wrong. There's a step between the conversation and the solution, and skipping it is how teams energetically build the wrong thing. Before you design anything, you have to define, in plain and honest terms, what problem you're actually solving. Not what you're going to build. What's broken in the customer's life that you're trying to fix.
That sounds obvious. In practice it's astonishingly rare.
What "working backwards" means
At Amazon, where I spent more than a decade, this discipline is called Working Backwards, and the name is the whole idea. You start from the customer and their problem and work backwards to the solution, rather than starting with a solution and working forwards to find someone who wants it.
I use it as my example because I've seen it work again and again, not because it's the only good process. If your company already has a discovery method, use it. What matters is that you honestly answer questions like the five below before you build, and that the answers come from real customers rather than your own imagination.
But first, two traps that catch almost everyone on the way in.
Trap one: customers hand you solutions
Customers rarely describe their problem. They describe the fix they've already imagined: "Add a filter." "Give me a mobile app." "Fix search." These arrive sounding like instructions, and the temptation is to write them down as a to-do list.
Don't. A feature request is a clue, not a marching order. It's the customer guessing at a solution, and their guess is shaped by what they can imagine, which is usually a small tweak to what already exists.
A school librarian I'll call Shelly once asked me to "just fix search." If I'd taken that as an instruction, I'd have briefed a team to make search faster, ticked the box, and still lost her students. The real problem sat underneath the request: students typed questions the way they'd ask a person, got nothing back, felt stupid, and left for Google. Define the problem that way and the solution space cracks open. Maybe the answer is natural-language search. Maybe it's something nobody in the room could have named yet.
Build for the request and you might ship exactly what they asked for and still miss. Build for the problem and you have a chance to delight them in a way they couldn't have described.
Trap two: your shiny idea is a solution too
The second trap is harder, because it's yours. Every team walks in with an idea it loves, and every idea is quietly looking for a problem to justify it. Attachment makes you hard of hearing.
Sometimes the shiny idea belongs to the most powerful people in the room. I once ran a two-day workshop where three influential leaders arrived certain we'd end up building their pet project, a content repository that had already been floated to leadership. We put it in front of the customers at the table. Every one of them said a version of the same thing: nice idea, but I'd never use it.
At the break, the three leaders called it a failure. It wasn't. It was the workshop working. Finding out in two days that an idea is dead, before months of buy-in, engineering time, a launch, and a sales team trying to sell something customers had already rejected to our faces, is the cheapest possible way to learn it.
Hold your idea loosely. It's a hypothesis, not a plan.
The five questions
Here is the front door to Working Backwards: five questions that force you to define the problem before you fall in love with an answer.
1. Who is the customer?
Not a broad segment like "K-12 school districts," and not necessarily a single individual either. Usually it's a persona: a specific, recognizable type of customer, ideally embodied by a real person you've actually spoken to. Shelly was a real librarian, and she also represented a whole persona of middle school librarians. Grounding the persona in a real person keeps it from drifting into abstraction. Vague customers produce vague products.
2. What is the customer's problem or opportunity?
Write it in the customer's terms, not yours. Not "search relevance is suboptimal," but "students feel stupid and leave for Google." If you can't state the problem in a way the customer would recognize as their own, you haven't understood it yet. A simple format helps:
Today [customer persona] has to [problem] when [situation].
Then follow it with a real customer quote to bring the problem home.
3. How do you know the customer needs this?
This is the honesty question. What is your evidence? If the answer is "I assume" or "sales mentioned it," you're guessing, and you need to go back and talk to real customers. If the answer is "three librarians told me this in their own words, and it lines up with our usage data and last quarter's survey," you're standing on solid ground.
4. What is the most important customer benefit?
One benefit, not a list of ten. If you fixed this, what single thing gets better for the customer? Forcing yourself to pick one shows you what actually matters, and it pays off later when you have to make trade-offs about what goes into the first version.
5. What does the customer experience look like?
Walk through how the customer discovers, uses, and benefits from the solution, from their point of view, step by step. If you can't picture it in real detail, you don't understand their world well enough yet.
The question that keeps you honest
Of the five, the third is the one that separates real product management from confident guessing. It has only one good answer: evidence from real people, in their own words. When someone challenges your definition of the problem, and someone always will, you don't defend it with your title or your conviction. You point to what a real customer said.
But a quote can't carry the case alone. Three customers saying the same thing is powerful only if they're representative, and one vivid sentence from an outlier can lead you confidently in the wrong direction. Pair the quote with the rest of your evidence: surveys, usage data, market research, win-loss notes. The data proves the problem is real and widespread. The quote makes it land.
A quote on its own gets dismissed as an anecdote. Data on its own rarely moves anyone to act. Together, they're almost impossible to ignore.
And if you work through the five questions and question three comes up empty, that isn't failure. It's the process doing its job, telling you the truth before you spend six months and a budget finding out the hard way. Don't fill the gap with a confident guess. Go back and talk to people.
From questions to a document
Once you can answer all five, Working Backwards turns them into a short document: a press release written from the future, as if the product already existed, plus an FAQ that tackles the hard questions head on. It names the customer's problem, states the benefit in plain language, and carries a real customer quote right there on the page. That document becomes the north star that keeps engineering, marketing, sales, and design building for the same person, including in all the meetings you'll never attend.
Where AI helps, and where it doesn't
AI is genuinely useful here. Once you have notes and verbatim quotes, a model is very good at organizing that raw material into a first draft of the five answers, and at spotting when your "problem statement" is really a solution in disguise.
It will also lead you off a cliff if you let it. Ask a model to answer the five questions without real evidence and it will, fluently and completely, and every answer will be an invention that feels like insight. So give it your evidence and a firm guardrail. A prompt like this works:
Here are my notes and verbatim quotes from five customer conversations. Draft answers to these five questions: who is the customer, what is their problem, what is the single most important benefit, how do we know what they need, and what does their experience look like. For every answer, cite the specific quote or note it came from. If there isn't evidence in what I gave you for a particular answer, write "no evidence yet" rather than filling it in.
The model can structure your evidence. It can't be your evidence. If it ever writes a customer problem you can't trace back to a real person, delete it and go back to your notes.
Two things to try this week
- Write the problem in one sentence, in the customer's words, before you write anything about the solution. Use the "Today" format, or this one: "[A specific customer] can't [do something that matters] because [reason], and it costs them [something real]." If you can't fill in the blanks from real conversations, you've just found out what to do next.
- Interrogate your favorite feature. Take the idea you're most excited to build and ask it question three: how do I actually know a real customer wants this, enough to change their behavior? If you can point to a real person and their words, build with confidence. If you can't, that's your next conversation.
