Product Strategy8 min read
Product discovery before product design
Discovery is not a phase you can compress into a workshop. It is the work of finding out whether the thing is worth designing at all.
By Product Practice, Product design & research
Discovery has been diluted into a scheduling artefact, the two weeks before design starts, filled with a workshop, some personas and a journey map on a virtual whiteboard. Everyone leaves aligned and nothing anyone believed has changed.
Discovery that works has a different test: it is capable of changing the plan. If the outcome of a discovery phase could not have been 'we should not build this', it was not discovery. It was onboarding.
The four risks worth spending time on
Discovery is risk reduction. It helps to be explicit about which risk you are reducing, because they need different methods and different amounts of time.
| Risk | The question | How you reduce it |
|---|---|---|
| Value | Will anyone care enough to change behaviour? | Interviews, demand tests, existing-behaviour evidence |
| Usability | Can people work out how to use it? | Prototypes and task-based testing |
| Feasibility | Can we build and run it? | Technical spikes, data audits, cost modelling |
| Viability | Does it work for the business? | Unit economics, sales and support implications, compliance |
Most teams over-invest in usability, which is the cheapest to fix later, and under-invest in value, which is the most expensive to get wrong. Usability problems surface in a week of testing. Value problems surface eighteen months in, after a launch.
Size discovery to the decision
The right amount of discovery is the amount required to stop guessing about the specific decision in front of you. Sometimes that is six interviews and two days of analytics. Sometimes it is a month in the field.
- Reversible, low-cost decision → decide and instrument it; learning by shipping is cheaper
- Expensive but well-understood problem → validate the solution, not the problem
- Cheap to build, unclear demand → test demand before building anything
- Expensive and unclear → this is where real discovery earns its keep
Look for existing behaviour, not stated intent
People are unreliable narrators of their future behaviour and excellent narrators of their current workarounds. The most valuable discovery finding is usually a workaround: a spreadsheet, a WhatsApp group, a saved view, a manual step someone does every Friday.
A workaround is a specification written by a user who was sufficiently motivated to build it themselves. It tells you what matters, in what combination, at what frequency, with the noise already removed.
Write problem statements that can be wrong
The output of discovery is not insight. It is a small number of sharply worded problem statements with a business consequence attached to each, written so they could be disproved.
'Users find onboarding confusing' cannot be disproved and cannot be designed against. 'New users cannot complete their first import without contacting support, which is why activation stalls at day three and support cost per new account is £42' names a mechanism, a measure and a consequence.
Knowing when discovery is finished
Not when the calendar says so. Discovery is finished when new evidence stops changing your mind, when the fifth interview confirms what the third one told you, and the decision in front of you has an obvious answer.
If evidence is still reshaping the problem, stopping because the phase ended means you will design against a problem statement you already know is wrong.
If discovery could not have concluded 'do not build this', it was not discovery.
Product Practice
Product design & research
The product practice covers discovery, research, interaction design and design systems. It writes about the structural decisions that sit underneath an interface, and what happens when they are made carelessly.
