Most failed software projects did not fail in week twenty. They failed in week one — when nobody agreed what “done” meant, who the user was, or which constraint was non-negotiable.
A discovery phase is structured product work: map users, journeys, risks, and the smallest release that proves value — before budgets harden around the wrong problem.
What discovery should produce
- Problem statement and success metrics stakeholders share
- Prioritized backlog for a first release (and an explicit not-now list)
- UX direction clear enough to estimate, not a 200-screen fantasy
- Technical approach options with trade-offs written down
- A delivery plan and budget band you can say yes or no to
“We almost built the wrong portal for the wrong audience. Two weeks of discovery made that argument early — and cheap.”
Discovery is not a pitch deck
Useful discovery puts builders and decision-makers in the same room. It kills weak ideas with evidence. It does not invent urgency to start coding on Friday.
If the outcome is only slides with no backlog, architecture notes, or decision log, you ran a workshop — not discovery.
Why teams invest early
1–2 wks
typical focused discovery
10×
cost of fixing a wrong assumption late
1 backlog
everyone estimates from
Go/no-go
decision with real numbers
