Discovery phase
Also called discovery, scoping phase, inception.
The short stretch before a build where the team works out the problem, the users, the scope and the rough cost.
Last updated
What it is.
Discovery happens before full development starts. The team talks to users and stakeholders, maps the current process, lists the systems the product must connect to, and finds the riskiest assumptions.
It ends with things you can act on: a written scope or statement of work, wireframes or a clickable prototype, a first product roadmap, an estimate and a list of open risks. Some teams also run a proof of concept for the hardest technical part.
Why it matters
Estimates made before discovery are guesses. A week or two of discovery turns them into numbers based on the real scope, and often removes features nobody needed. It is also the cheapest point to learn that an integration or a rule makes the plan harder than it looked.
In a product build
OceanLab builds start with a clickable prototype before production code. Discovery work is what decides which flows that prototype covers and what the first milestones are.
Common mistakes.
- 01
Skipping it to start coding sooner, then paying for it later in change requests.
- 02
Only talking to managers. The people who will use the software daily know where it hurts.
- 03
Ending with a slide deck instead of a scope, an estimate and a prototype the team can build from.
Work it out with a tool.
Related terms.
- Statement of work (SOW)The document that sets out what a supplier will deliver, by when, for how much, and how the work will be accepted.
- Proof of concept (PoC)A small, often throwaway build that tests whether one risky technical idea can work at all.
- WireframeA simple, usually grey, sketch of a screen showing layout, content and actions, without final styling.
- Clickable prototypeA set of linked screens you can click through, built to test a design before the real software exists.
Guides and pages
Browse the full glossary or read answers to common questions.
