In short
Product discovery is the evidence-gathering work used to decide which problem to solve, for whom, why the solution may create value, and whether it is feasible and viable enough to invest in. It should produce decisions, assumptions, evidence, risks, a bounded opportunity, and a testable next step—not a pile of workshop artefacts.
Four uncertainties
Discovery investigates:
- Value: does the problem matter enough?
- Usability: can the intended audience understand and use the approach?
- Feasibility: can the team deliver and operate it?
- Viability: can the organisation support the model, economics, risk, and strategy?
The mix depends on the decision. A known internal workflow may need feasibility and operational evidence more than market interviews.
Discovery activities
- stakeholder and operator interviews;
- customer observation and interviews;
- analytics, support, sales, and market evidence;
- journey and workflow mapping;
- data and integration investigation;
- content or domain modelling;
- prototypes and usability tests;
- technical spikes;
- concierge or demand tests;
- risk, constraint, and dependency mapping.
Activities are not outputs. Each must change confidence or a decision.
What discovery should produce
A precise opportunity
Audience, context, problem, current alternative, consequence, and evidence.
Assumption map
What must be true across value, behaviour, technology, data, operations, and business—and which assumption is most dangerous.
Bounded scope
The smallest workflow or intervention worth testing, plus explicit non-objectives.
Evidence and uncertainty
What is observed, what is inferred, what remains unknown, and how strongly the sources support it.
Product and technical risks
Permissions, data, integrations, security, accessibility, operations, adoption, and constraints that can change the approach.
A recommended next step
Prototype, technical spike, MVP, service test, more focused research, purchase decision, or stop.
What discovery should not become
- workshops with no decision;
- personas invented without evidence;
- a fixed feature list disguised as research;
- months of analysis avoiding contact with reality;
- stakeholder consensus treated as user evidence;
- a promise that uncertainty is gone.
Discovery reduces risk; it does not make product work deterministic.
Timebox around the decision
A small, known problem may need one or two weeks. A new product with several user groups, complex data, and regulated workflows may need six or more.
Set exit conditions:
- the problem and audience are bounded;
- critical assumptions have evidence or a test plan;
- feasibility risks are understood enough for the next investment;
- decision-makers agree on scope and non-objectives;
- the next step has owner, cost range, and success criteria.
Common questions
Is discovery the same as research?
Research is one input. Discovery combines user, business, technical, and operational evidence to make a product investment decision.
Does discovery happen only before development?
No. Teams discover continuously as evidence and constraints change, though concentrated discovery is useful before major commitments.
Who participates in product discovery?
Product, design, engineering, business owners, operators, and representative users should contribute according to the uncertainty being investigated.
What if discovery shows the idea is weak?
Stopping or changing direction is a successful result when it prevents a larger unsupported investment.
Should discovery produce a fixed specification?
It should produce enough scope, rules, risks, and acceptance evidence for the next step—not pretend every future detail is known.
