.svg)
What Product Discovery Should Settle Before Design Begins
Discovery exists to swap assumptions for evidence while changes are still cheap. These are the questions a discovery phase should close before anyone designs a screen.
Discovery exists to swap assumptions for evidence while changes are still cheap. These are the questions a discovery phase should close before anyone designs a screen.
Many teams run discovery as a workshop followed by a slide deck, then move on. A useful discovery phase ends differently: with specific questions answered, each supported by something observed. An interview, a usage log, a competing product tried from start to finish. Below is the scorecard we use to judge whether discovery has done its job.
Question
Evidence that settles it
Interviews with several people who match the intended user
Sign it is still open
Profiles written from the team’s own opinions
Evidence that settles it
Observed workarounds: spreadsheets, manual steps, other tools
Sign it is still open
A claim that nobody solves this yet, left unchecked
Evidence that settles it
Time, money or frustration users mention without prompting
Sign it is still open
Interest that appears only when the idea is pitched
Evidence that settles it
A short feature list tied to the core task
Sign it is still open
Every idea on the list scheduled for the first release
Evidence that settles it
A feasibility check and an estimate per feature
Sign it is still open
A total price quoted before the scope exists
Use the table as a running checklist through the phase. When a row has no evidence yet, record it as an open risk and plan how to close it: another round of interviews, a quick prototype, a conversation with the engineer who will own the backend. Open rows are normal in the first week. Open rows at the end of discovery mean the build starts on a guess.The last two rows carry more weight than they appear to. A validated problem paired with an unlimited feature list still produces a late, expensive first release.
A discovery phase produces documents, and each one has a job. The project brief records goals, constraints and the assumptions still being tested. Research findings and user profiles describe real people in their own words. Flow diagrams show how someone moves through the core task, including what happens when something goes wrong. The feature specification says what the first release does and, just as usefully, what it leaves for later. The roadmap and estimate turn all of this into a plan with a sequence and a cost. If any of these is missing, ask which question it was meant to answer and whether that question is still open.
Even well-run discovery phases lose accuracy in familiar ways. Watch for these:
Discovery is complete when the answers can be shown and checked. Until then the plan is a set of hopes, and the cheapest moment to test them is before the build begins.