Product discovery interviews: decide what to build next

If your discovery interview shows a mock-up, it is a sales call

Here is how a rigged discovery interview runs. Someone has a favourite idea, a prototype is ready, and the "research" is a polite tour followed by "would you use this?" Everyone says yes. The idea ships. Nobody opens it.

Interviews can help you decide what to build next, but only if you aim them at the right target. The target is not your idea. It is the assumptions that must be true for your idea to be worth building. Test those by asking people what they did last week and how they cope today, never what they think of your feature.

This guide gives you three things to copy:

1. An assumption map that turns a feature list into questions worth asking.
2. An interview guide built around past behaviour and current workarounds.
3. A decision rubric to use after the interviews, so the loudest voice does not decide.

It works for customers, users, your own team, partners, or the people who will use an internal tool. If you are still choosing what kind of study to run, start with which customer research study you should run.

Turn the feature list into assumptions

A feature idea is a bundle of beliefs. "Add a dashboard for team leads" quietly assumes that team leads have a recurring question, that they cannot answer it today, that they care enough to change a habit, and that a dashboard is the right answer. If any one is false, the dashboard is wasted work.

UK civil service guidance describes this trap. It lists the phrases that give it away, such as "I think that will confuse users", and says to replace them with a plan to test the claim. Its rule is blunt:¹.

So before you book a single interview, write the map. One row per assumption. Here is an invented map for the team-lead dashboard idea, so you can see the shape:

Two rules for filling it in. First, write what would change your mind before you hear anyone. If you cannot name a result that would make you drop the idea, you are not testing it. Second, split every "and". "Leads want faster, clearer reports" is two assumptions.

Rank the assumptions by risk

You cannot test everything in one round. Score each row on two things, from 1 to 3:

• Damage if wrong: how much of the plan collapses?
• How little we know: is this backed by something you saw, or by a feeling?

Multiply the two, as in the Score column above: the habit and the cost of a late answer come first (9 each), then trust (6), then the by-hand row (4). A real map is longer than this one. Its top three or four rows become the spine of your interview guide. Everything else waits.

You are ranking beliefs, not ideas. Two feature ideas can rest on the same risky belief, for example "this group has a recurring problem here". One round of interviews can then test both at once.

Ask about the last time, not about your idea

Ask for specific events, not general habits. Nielsen Norman Group says to² in which they faced a hard case, and warns that asking how people "usually" do something often gets you an idealised workflow rather than real behaviour. The same group makes the underlying point about self-reports:³. Treat every "I would" as a wish, not as evidence.

A GOV.UK Health Tech blog post puts it plainly:⁴. The GOV.UK Service Manual lists what to learn at the start of a project, including⁵ they are trying to do, and the problems and frustrations they meet. That list is your interview guide in outline.

Here is a guide to copy. Plan 30 to 45 minutes: the timings below add up to 30, which leaves room for follow-ups. Pilot the guide with three people, then run a first round of six to eight people from the group you care about. That count is our suggestion for a starting point. The real stopping rule is to stop when new interviews no longer change your map.

Opening (2 minutes)

"I'm trying to understand how people handle [the area]. I'm not selling anything and I have nothing to show you. There are no right answers, and critical stories help me most."

The last time (10 minutes)

• "Tell me about the last time you [did the task / hit the problem]. Where were you? What set it off?"
• "What did you do first? Then what?"
• "Who else was involved?"
• "How long did it take? What was the worst part?"
• "What did you do about it afterwards?"

Current workarounds (10 minutes)

• "How do you handle this today? Can you show me or walk me through it?"
• "What have you tried that did not work? Why did you stop?"
• "What does it cost you when it goes wrong: time, money, an awkward conversation?"
• "Have you looked for something better? What did you find? What did you do next?"

The edges (5 minutes)

• "When was the last time this went badly wrong?"
• "Who would notice if you stopped doing it?"
• "What do you do instead when you have no time?"

Close (3 minutes)

• "What did I not ask that I should have?"
• "Who else deals with this that I should talk to?"

No question names your idea. For more wording for the follow-ups, see how to ask questions that move beyond surface answers.

Never pitch during discovery

Do not describe your solution during the interview. Once you do, you invite a review of your idea instead of a story from the person's life, and you collect opinions about a thing that does not exist. Those are answers you cannot decide on. Mock-ups and prototypes belong in the experiment that comes after discovery. Nielsen Norman Group also notes that people³, and a pitch tells them exactly what that is.

If someone asks "what are you building?", answer after the interview. During it, say "I'd rather hear how it works for you first, then I'll tell you everything."

Keep your reactions flat: no grin at a good story, no nod at the answer you hoped for. Never finish a sentence for someone. After an answer, count to five in your head before you speak.

Spot polite enthusiasm

Polite enthusiasm is easy to miss while you are in it. Look for these in your notes:

• Praise with no story. "That's a great idea" with no recent episode behind it is worth nothing.
• Promises about the future. "I'd definitely use that" and "send it over when it's ready" cost the speaker nothing.
• Vague pain. "It's annoying sometimes" is not an event. Ask for the last time.
• No workaround. If someone has done nothing about a problem, either it is small, they lack the authority to fix it, or you have not found their real problem yet. A person who built a spreadsheet, paid a freelancer or wrote a rule for the team is showing you something an opinion never will.
• Agreement with your wording. If they repeat your phrase back, check whether they used the phrase before you did.

Weight what people did over what they said. File every claim in your notes in one of two columns: "told me a story" or "gave me an opinion". Only the first column decides anything.

Use a decision rubric after the interviews

Do not decide in the hour after the best interview. Score the next day, from your notes, with the same five items for every candidate problem.

For each problem you heard about, score these five items from 0 to 2. A higher score always means stronger evidence.

1. Recent evidence: 0 = nobody described a real episode from the last few weeks; 1 = one or two people did; 2 = several did, with matching details.
2. Workaround effort (what people do today): 0 = no workaround; 1 = a light one; 2 = a clumsy or costly one.
3. Cost of the status quo: 0 = no cost mentioned; 1 = a cost described but not measured; 2 = a cost someone measures or owns.
4. Active search (what people did to replace the workaround): 0 = nobody has tried to fix it; 1 = someone asked around, complained to someone who could act, or tried a quick fix and dropped it; 2 = someone built, bought or paid for a fix.
5. Fit: 0 = not the people you want to serve, and not a problem you can address; 1 = one of the two; 2 = both.

The sixth item is not scored. Contradictions: write down anything someone said that does not fit, and do not average it away.

Add up the five scores, out of 10. Then use the total to sort, not to decide: the top problem is a candidate, and the bottom ones are the ideas you can drop with a clear conscience. Keep the notes and contradictions next to the score; the numbers hide the stories.

A worked example: four ideas, two beliefs

Here is an invented example to show the method. Maya runs product at a small company that sells scheduling software to dental clinics. The team has four ideas: a reminder-text editor, a waiting-list tool, a revenue dashboard and a mobile app for dentists. Everyone has a favourite. Maya builds the assumption map and finds that three ideas (the reminder editor, the waiting-list tool and the app) share one belief: front-desk staff spend real time chasing last-minute gaps in the diary. The dashboard rests on a different belief: practice managers want revenue reporting.

She interviews six front-desk staff and two practice managers. She asks for the last time a patient cancelled late. Five of the eight describe the same routine: they scroll a printed list, phone patients one by one, and keep a handwritten note of who said "maybe". Two had tried a group message and stopped because replies were chaotic. One practice manager says a gap costs the clinic an hour of a dentist's day, and she knows because she tracks it herself in a notebook.

Nobody brings up revenue reporting. After the last interview, a practice manager asks what the team is building. Maya tells her about the dashboard and the manager says "that sounds useful". Maya records it as an opinion and discounts it. The mobile app comes up once, as a passing wish from one front-desk worker. Nobody mentions the wording of reminder texts at all.

Maya scores the problems, not the ideas. "Filling last-minute gaps in the diary" scores 9 out of 10. Recent evidence gets 2, because five of the eight described the same routine after a recent late cancellation. Workaround effort gets 2, for the printed list and the phone calls. Cost gets 2, because one practice manager measures it herself. Active search gets 1, because two people tried a group message and dropped it. Fit gets 2. Her contradiction note: one front-desk worker said gaps are rare at her clinic, so Maya asks where the problem concentrates. The problems behind the dashboard, the reminder editor and the app each score 2 out of 10, all of it from Fit.

The shared belief held: front-desk staff do spend real time on late gaps. The notes also point at one idea: once a gap opens, the front desk chases patients by hand, and that is the job a waiting-list tool would take over. The reminder editor and the app rest on the same belief, but no story points at them, so Maya parks both for this round, along with the dashboard. She re-reads the stories behind the top problem, writes down why she parked the rest and shares the notes. The team builds a rough waiting-list prototype next, and that is where the real test starts.

When the interviews contradict the roadmap

This will happen, and it is the work paying off. People will describe a problem you did not expect, or none of the one you planned for. How to handle it:

• Check who you asked. If the people you spoke to are not the ones the idea is for, the result says nothing about it. Fix the recruiting and run it again.
• Check how you asked. Re-read your transcript for questions that named your idea or suggested an answer. If you led, the conflict is smaller than it looks, and so is any confirmation.
• Do not average. Three people with a vivid recent problem and four with no problem are two groups, not one lukewarm one. Ask what separates them.
• Go back to your map. You wrote what would change your mind. If that evidence arrived, change your mind and say so in the plan.
• Name the favourite. If a senior person's idea lost, tell them what you asked, what you heard and which row of the map it broke. Show the stories, not a verdict.

When to stop interviewing and run an experiment

Interviews tell you which problems are worth solving. They cannot tell you whether people will act on your solution. To see whether someone will sign up, pay or switch, put a real option in front of them, such as a rough prototype, a pilot or a simple landing page, and watch what happens. That is an experiment, and discovery tells you which one is worth running. Match the method to the question: a⁶ warns that research activities that do not map clearly to your questions can leave researchers scrabbling around in their data.

If your open question is "what do they actually do?", sit beside them and watch, then ask about what you saw. A GOV.UK Health Tech blog post recommends⁴ by pairing interviews with observation.

What this will not tell you

Interviews tell you which problems are real and worth attention for the people you spoke to. They do not tell you how many people share a problem, whether a solution will be adopted, or what people will pay. A small round can miss a problem that affects a few people, and it can over-represent the people who agreed to talk. Your own questions can still lead, however careful the guide. The rubric ranks the evidence you collected, not the market. Treat the winner as the best-supported bet to test next.

Your next step

Pick the feature on your list you are most sure about. Write its assumption map today, and name the one row that, if wrong, would make you drop it. Then book three interviews with people who live with that problem, and ask only about the last time. Those three are the pilot of your guide and a first test of that one assumption. The round of six to eight comes after, once the guide has survived them. More on customer interview studies.