Product discovery cycle
From customer problem to validated requirements and feature spec.
Most shipped features fail not because the engineering is bad, but because nobody talked to users before coding. This template maps the research-before-build rhythm: problem identification, interview rounds, pattern-finding loops, design validation, and the moment when customer consensus becomes a spec.
The decision diamonds enforce the questions every PM should ask: Do we see a consistent pattern, or are we chasing anecdotes? Do users actually want to solve this problem our way, or are we over-designing? Until both are yes, go back to users.
When to use this template
- Kickoff meetings — walk the team through the discovery process before engineering estimates, so everyone knows what a "done" discovery looks like.
- Retrospectives — trace back to this diagram and ask which step we skipped when a shipped feature underperformed. Often it's the validation loop after wireframes.
- Scaling product process — new PMs use this as a checklist to run discovery correctly, complete with the decision gates that separate research from speculation.
How to adapt it
Customize the research methods to your domain — surveys, analytics review, competitive teardown, usability tests, or A/B tests can replace interviews:
- Add a competitive analysis branch after identifying the problem, running in parallel to user interviews.
- Insert a data analysis step that queries your product analytics to measure whether the problem exists at scale (some users mention friction; does the funnel support it?).
- Replace "mockups" with a working prototype for technical products or complex UIs, then validate on that prototype instead of sketches.
Drag nodes to reorder or add steps without writing syntax — the editor regenerates Mermaid code automatically.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Customer problem identified] --> B[Schedule discovery interviews]
B --> C[Conduct user research sessions]
C --> D{Clear pattern found?}
D -->|No| E[Refine hypothesis]
E --> B
D -->|Yes| F[Document requirements]
F --> G[Create wireframes/mockups]
G --> H[Validate with users]
H --> I{Solution resonates?}
I -->|No| J[Iterate on design]
J --> G
I -->|Yes| K[Write feature spec]
K --> L[Ready for development]
Frequently asked questions
- What is product discovery and why is it important?
- Product discovery is the research phase before building: talking to real users to understand their problems, validating that your solution fits, and defining requirements before engineering starts. It reduces the risk of shipping features nobody wants and catches misaligned assumptions while they're cheap to fix.
- How many users should I interview before I'm confident?
- For a new product area, 5–8 interviews often reveal 80% of the patterns; interviews 9–12 show diminishing returns. For a specific user segment, aim for 10–15. Stop when new interviews repeat the same themes. Count patterns, not just single data points — one user saying 'I want feature X' is anecdote; three independent users describing the same underlying problem is evidence.
- What is the difference between discovery and requirements?
- Discovery is learning what users actually need (problem-focused). Requirements are what you'll actually build (solution-focused). A discovery finding might be 'users waste 20 min daily on manual reconciliation'; the requirement is 'auto-reconciliation in the UI'. Visual edits regenerate clean Mermaid, so you can use this to map the entire loop in one artifact your team references throughout.
- What artifacts should come out of discovery?
- Raw interview notes, a research synthesis (common themes + direct quotes), user personas or journey maps, a prioritized list of problems, mockups or wireframes to validate solutions, and finally a spec for the winning direction. This diagram maps them into a decision loop — include which artifacts you've produced before greenlighting development.