What discovery is for
Most software projects that run over budget were under-defined at the start. Someone estimated a list of features without knowing who would use them, which existing systems were involved or which half of the list mattered. Discovery is the short, deliberate phase that replaces those guesses with decisions before the expensive work begins.
It takes different forms: a single intensive day for a small product, or a few weeks of interviews, mapping and prototyping for a complex one. The format matters less than the outcome. At the end, the people funding the project and the people building it should hold the same picture of what will be made first and why.
What you should receive
| Deliverable | What it contains | How to judge it |
|---|---|---|
| Problem and goals | The problem in a paragraph, and how success will be measured | Would every stakeholder sign it? |
| Users and workflows | Who uses the product and the steps of their main tasks | Could a newcomer follow a case from start to finish? |
| Scope of the first release | What is in, what waits, what is out | Is the out list as specific as the in list? |
| Key screens or prototype | Enough design to show how the main workflow feels | Did real users or staff react to it? |
| Technical approach | Architecture in outline, integrations, data, hosting | Are the unknowns named, not hidden? |
| Risks and assumptions | What could change the plan, with a response for each | Is anything uncomfortable written down? |
| Estimate and plan | Cost and duration ranges for the first release, by stage | Does it say what would make it wrong? |
Ask before the workshop starts whether the deliverables will be handed to you to use with any company. A discovery whose results only make sense to its authors is a sales process, not a service.
Look for decisions, not notes
The easiest discovery to run is one that records everything everyone said. It produces a thick document and no progress. The useful kind forces choices, and the evidence is in what was cut.
Signs of a real discovery
- Features were removed or postponed, with reasons
- A disagreement between departments was settled
- An assumption was tested and turned out wrong
- The estimate is a range, with the causes of the spread
- One or two questions remain open, clearly marked
Signs of a workshop that only listened
- Every request made it into scope
- The summary restates the original brief
- No risk is mentioned
- A single precise figure with no assumptions
- The next step is simply to sign the build contract
A worked example
Discovery for a field inspection product
This example is invented. An engineering firm wants an app for inspectors to record site visits, and arrives with a list of forty features.
- WorkflowsFollowing two inspectors for a morning shows that most of their time goes on photographs and on retyping notes at the office. Report writing, which was not on the feature list, is the real problem.
- ScopeThe first release becomes offline capture with photos, and a generated report. Scheduling, invoicing and a client portal move to later phases. The list of forty becomes eleven.
- RiskThe firm's document system has no published interface. The discovery tests an export route and records it as an assumption with a fallback.
- EstimateA range for the first release in three stages, with the document system integration priced separately because it is the least certain part.
The firm takes the output to two other companies for comparison. Both can price it without a further workshop, and their figures fall inside the range, which is the best evidence that the discovery was sound.
Who needs to be in the room
Discovery fails quietly when the wrong people attend. Senior sponsors describe how the work is supposed to happen. The people who do it know how it actually happens, and the gap between the two is where the requirements are.
- 01
Someone who can decide
Why they are neededScope choices need an owner with authority over budget and priorities, present for the decisions and not only the kick-off.
- 02
People who do the work today
Why they are neededTwo or three users of the current process, including one who is sceptical. They know the exceptions.
- 03
Whoever runs the existing systems
Why they are neededIntegration questions need a person who can say what the current tools can and cannot provide.
- 04
From the supplier, a designer and an engineer
Why they are neededDesign without engineering promises what cannot be built. Engineering without design solves the wrong problem.
What you can do with the result
A finished discovery opens three honest options, and a good supplier will present all three.
- Build the first release. With scope, design direction and estimate agreed, development can start with far fewer surprises.
- Tender it. Use the output as the core of a request for proposal and compare several companies on equal terms.
- Stop, or change direction. Sometimes discovery shows that a packaged product would do, or that the case for the project is weak. That is a successful outcome, and a cheap one.
Ownership and licensing terms for the deliverables are defined in the project agreement, so read that clause before you begin if you intend to share the output with other companies.
A checklist for judging a discovery
Discovery deliverables checklist
0 of 10 checkedWhat to do next
If a company has offered you a discovery, ask to see an anonymized example of what one produces, and hold it against the table above. If you are preparing for one, our custom software requirements builder will get your own thinking onto a page first, which shortens the workshop.
Our product discovery workshops page describes how we run them. Tell us about the project and we will say honestly whether it needs one.
Common questions
Is a discovery workshop worth paying for?
For a project of real size, usually yes, because the cost of building the wrong thing is far higher than the cost of a short discovery. For a small, well-understood piece of work it may be unnecessary, and a good company will say so. The test is whether important questions about users, scope or systems are still open.
How long should discovery take?
It varies with the complexity of the product and how many people must be consulted, from a single intensive session for something small to a longer structured phase for a system with several user groups and integrations. Be wary of a fixed format sold to every client regardless of the project. The length should follow the number of open questions.
Can we use the discovery output with a different company?
You should be able to, and it is worth confirming before you start, since the terms are set by your agreement. A discovery written so that only its authors can use it protects the supplier, not you. Clear, self-contained deliverables are also a sign of confidence, because a company that expects to win the build does not need to lock you in.
What if discovery shows the project is not worth doing?
Then it has saved you most of the budget. Discovering that a packaged product would meet the need, that the expected benefit is small, or that a dependency makes the project impractical is a legitimate result. It is uncommon for a project to be abandoned entirely. More often the scope shrinks to the part that clearly pays for itself.
Do we need discovery if we already have a requirements document?
Possibly a shorter one. An existing document gives discovery a head start, and the work becomes testing it: walking through workflows with real users, checking integrations and challenging the scope. Requirements written without the people who will build the product often contain assumptions that only surface when someone tries to estimate them.