9 Product Discovery Questions That Force a Decision

Product discovery often produces evidence without producing a decision.

A team interviews customers, reviews analytics, maps a journey, and tests a prototype. The findings are interesting. The roadmap remains exactly as it was.

The problem usually started before the research. Nobody named the decision, the uncertain belief, or the evidence that would justify a different move.

These nine questions are designed to prevent that failure. They are not an interview script or a discovery process. They form a decision frame for one active product bet.

The questions follow a deliberate order. First define the commitment. Then understand the situation and risks. Only then choose a test and decide what the evidence means.

How to use the questions

Choose one decision that could change within the next planning horizon. A broad prompt such as “understand onboarding” is too vague. “Choose whether to redesign setup or improve activation messaging” gives discovery a job.

Write an answer to each question before selecting a method. Mark evidence, assumptions, and unknowns separately. A confident statement supported only by internal agreement remains an assumption.

Return to the answers after every meaningful round of evidence. The document should change as understanding changes. If it only grows, the team is collecting research rather than learning from it.

1. What decision must this discovery change?

Start with the commitment under consideration: fund, sequence, design, launch, expand, pause, or stop.

“Should we build this?” is often too large to answer responsibly. Break it into the next reversible or expensive choice.

For example: should the team fund an engineering spike, test a service-assisted version, or place the opportunity on the next roadmap review?

State who will make the decision and when. Without an owner and a decision date, research can remain “useful context” indefinitely.

GOV.UK research-planning guidance asks teams to state which research questions each round will answer and how it will help the team make decisions. That constraint keeps the work proportionate.

A weak answer: “We want more customer insight.”

A useful answer: “On Thursday, the product trio will choose whether to prototype the import workflow or remove it from this quarter’s scope.”

2. Whose situation are we trying to change?

Name the people, their context, and the moment in which the problem appears. A market segment alone rarely supplies enough detail.

“Finance teams” may include the person entering data, the manager approving it, and the specialist responsible for an audit. They face different constraints and may judge success differently.

Include people affected by the product even when they never touch the interface. An automated decision can create work, risk, or confusion for reviewers, support teams, and customers downstream.

A Practical Guide to User Archetypes explains how to model behavioural differences without inventing biographies.

A weak answer: “Busy professionals.”

A useful answer: “Operations leads who reconcile exceptions before a weekly client review and are accountable for errors they did not create.”

3. What happens today, without our proposed solution?

The current behaviour is the real competitor. It may be another product, a spreadsheet, a colleague, a policy exception, or the decision to tolerate the problem.

Reconstruct a recent instance. What triggered the work? Which steps followed? Who became involved? Where did information move? What did the person protect against?

GOV.UK’s interview guidance recommends focusing on stories and real examples rather than general accounts of how work should happen. That distinction exposes workarounds and hidden dependencies.

Do not dismiss an awkward workaround as irrational. It may preserve control, trust, or flexibility that a cleaner product concept removes.

A weak answer: “They do it manually.”

A useful answer: “They export two reports, reconcile exceptions in a shared sheet, and ask an account owner to approve changes before sending the result.”

4. What evidence says the problem deserves attention?

Frequency alone is not importance. A rare failure can carry serious risk. A frequent irritation can be easy to ignore.

Look for consequence: lost time, failed outcomes, avoidable cost, delayed decisions, exposure to harm, or a workaround people have already invested in.

Separate observed evidence from interpretation. “The logs show abandonment at the same step” is an observation. “People leave because the form feels long” is an explanation that still needs support.

The evidence also needs a boundary. Which users, period, workflow, and product version does it describe? Old support tickets from a retired experience should not decide a new one.

When scale matters, Research-Driven Opportunity Sizing shows how to combine evidence, ranges, and explicit assumptions without manufacturing certainty.

A weak answer: “Several stakeholders say customers hate it.”

A useful answer: “Recent support cases and workflow observations show the same failure point, but the evidence covers only self-serve accounts.”

5. What must be true for this bet to work?

Turn the proposed response into a set of challengeable beliefs.

Users may need to notice the problem, understand the response, trust the output, change a habit, grant access, involve a buyer, or accept a new cost. The team may need reliable data and a viable operating model.

Write each belief separately. “Customers will understand, adopt, and pay” hides three different uncertainties that require different evidence.

Then ask which belief could make the rest of the concept irrelevant. That belief, rather than the most visible feature, often deserves attention first.

How to Approach Assumption Mapping Systematically provides a fuller method for ranking beliefs by importance and evidence.

A weak answer: “The feature needs to be intuitive.”

A useful answer: “Reviewers must be able to trace every suggested change to its source before they will approve it.”

6. Which risk controls the next commitment?

A desirable idea can still be unusable, infeasible, or incompatible with the business. Discovery should examine the risk that can invalidate the next commitment, even when another discipline sees it first.

Silicon Valley Product Group distinguishes value, usability, feasibility, and business viability risks. The categories are useful prompts, but teams do not need equal evidence for every category in every decision.

Ask what is both consequential and weakly supported. Also look for dependencies. Testing a polished interaction has little value if data access may make the response impossible.

Bring in the discipline able to see the risk. Engineering may expose operational limits. Legal or policy specialists may reveal a constraint. Commercial teams may know why an apparently interested buyer cannot act.

A weak answer: “The main risk is low adoption.”

A useful answer: “Before testing adoption, we need to know whether customers can authorise the data connection required to produce the result.”

7. What is the smallest credible way to reduce that risk?

The smallest test is not automatically the fastest activity. It is the least expensive way to produce evidence strong enough for the decision.

An interview can reveal a workflow but cannot demonstrate that a new interaction is usable. A prototype can expose comprehension problems but cannot establish production reliability.

Choose the method after naming the question. GOV.UK’s research-planning guidance advises selecting activities that provide reliable answers with proportionate time, effort, and cost.

Sometimes the responsible test is an engineering spike, policy review, sales conversation, manual service, data analysis, or controlled release. Discovery is broader than customer interviews.

A weak answer: “Run our standard batch of interviews because that is what discovery looks like here.”

A useful answer: “Observe the current approval workflow, then test a traceable draft with people who are personally accountable for the decision.”

8. What evidence would make us change course?

Define the interpretation before the result arrives. Otherwise, an enthusiastic team can explain away any inconvenient finding.

Write the signals that would support, weaken, or leave the belief unresolved. Include evidence quality: whose behaviour counts, in which context, and under which conditions?

Avoid a ceremonial success threshold. Positive comments do not become certainty because a threshold was written in advance. The threshold must fit the method, sample, and consequence of being wrong.

Also define what the test cannot tell you. A concept test may improve the wording while leaving demand unknown. An experiment may estimate the effect of a change without explaining the mechanism behind it.

A weak answer: “We will proceed if feedback is positive.”

A useful answer: “If accountable reviewers cannot identify why the system made a suggestion, we will not fund automation; we will investigate traceability first.”

9. What changed because of what we learned?

Close the loop in a decision record. Capture the observation, interpretation, confidence, limitation, and action separately.

Research observations are not findings, and findings are not decisions. GOV.UK’s analysis guidance keeps these steps distinct, then asks teams to turn findings into product, research, or roadmap actions.

The result may support proceeding. It may also narrow the audience, change the concept, move a dependency earlier, trigger another question, or stop the work.

Record unresolved disagreement. A decision can be legitimate without unanimous interpretation, provided the evidence and judgement are visible.

A weak answer: “The sessions went well and generated useful insights.”

A useful answer: “We removed automatic publishing, retained a reviewable draft, and scheduled a feasibility spike for source-level traceability.”

A hypothetical example: the discovery brief changes the idea

Consider a B2B product team exploring automated weekly account summaries. This example is invented to show how the questions connect.

The initial request is to design a summary email. The decision frame reveals that the actual commitment is whether to fund automated generation for a limited beta.

Research into the current situation shows that account leads already prepare summaries before client calls. The expensive work is checking conflicting source data, not writing prose.

The critical assumption becomes visible: leads must trust where each statement came from. A beautiful generated email would not resolve that risk.

The team tests a manually assembled brief with source links. Reviewers correct several statements but value the traceability. The result does not validate automation. It changes the next move to testing data provenance and review controls.

The discovery succeeds because the product response changes. The team learns before committing to the most expensive version of the idea.

Turn the answers into a one-page discovery brief

Keep the working record short enough to use in a decision meeting:

1. Decision: commitment, owner, and date.
2. People and situation: actor, trigger, workflow, and affected parties.
3. Evidence: observations, boundaries, gaps, and current alternatives.
4. Critical belief: the assumption that controls the next move.
5. Risk: value, usability, feasibility, or business viability.
6. Test: method, participants or data, and limits.
7. Interpretation: supporting, weakening, and unresolved signals.
8. Action: proceed, reshape, research, defer, or stop.

Revisit the brief when the commitment changes. Evidence sufficient for a prototype may be inadequate for a production launch or a regulated market.

Nine completed boxes do not make a decision good. They make its logic inspectable. That is what allows specialists to challenge the right weakness before the organisation pays to discover it in production.

Working artefact: the Discovery Decision Brief

Use a single row for each round of evidence. This preserves how the commitment changed instead of replacing yesterday’s belief with today’s cleaner story.

Record	Before evidence	After evidence
Commitment	Fund, sequence, design, launch, expand, pause, or stop	The revised commitment and owner
Critical belief	The assumption controlling the next move	Supported, weakened, replaced, or unresolved
Risk	Value, usability, feasibility, or business viability	The risk now controlling the next commitment
Test boundary	Method, people or data, conditions, and limitations	What the evidence can and cannot support
Decision rule	Evidence expected to change course	Whether the threshold was met and why
Next action	Smallest credible way to reduce the risk	Proceed, reshape, research, defer, or stop

If the right-hand column never changes, inspect the decision rule. Discovery may be generating observations while the commitment remains protected from evidence.

Sources

• Learning about users and their needs — GOV.UK Service Manual
• Plan user research for your service — GOV.UK Service Manual
• Using in-depth interviews — GOV.UK Service Manual
• Analyse a research session — GOV.UK Service Manual
• The Four Big Risks — Silicon Valley Product Group

Read next

How to Approach Assumption Mapping Systematically turns the most consequential belief in the brief into an evidence plan for the next commitment.