How do I plan a discovery phase?
Plan it around the decisions you need to make: who the users are, which workflows matter, what the system must connect to, which rules apply, and what is in the first release. End it with concrete outputs, usually a clickable prototype, a prioritised scope and an estimate you can act on.
Last updated
What to cover
- 1Goals and how success will be measured.
- 2Users, their key tasks and the current way they do them.
- 3The main workflows, step by step, including the awkward cases.
- 4Integrations, data sources and who owns them.
- 5Compliance, security and accessibility requirements.
- 6Technical risks worth a small spike, such as AI accuracy or a hard integration.
- 7What goes into the first release and what waits.
Who to involve
A decision-maker who can settle scope, people who do the work today, someone who knows the existing systems, and on the vendor side a designer, an engineer and a project lead. Short, focused workshops beat long meetings.
What you should have at the end
A clickable prototype of the key flows, a prioritised list of features with acceptance criteria, an architecture outline, known risks and an estimate or a milestone plan. At OceanLab the clickable prototype is the step before production on every build.
Check it for your case.
Common follow-up questions.
Is discovery worth paying for?
Usually. It is much cheaper to change a prototype than working software, and the estimate that follows is far more reliable.
Can we skip discovery for a small project?
You can shorten it, not skip it. Even a small project needs agreed scope and acceptance criteria.
Do we own the discovery outputs?
You should. Make sure the contract says so, so you can take them to any team.
