Discovery phase

The term comes from agile product development and has established itself as a counter-model to an old pattern: the project that begins with a quote. Anyone who names a fixed price for a complex system on the basis of an initial conversation is not estimating the project but their chance of a sale. The discovery phase draws a line at exactly this point. It separates the question "What actually is the problem?" from the question "What does the solution cost?", and it answers the first before anyone is allowed to answer the second.

What happens in a discovery phase

A discovery is not a series of meetings but structured investigative work. At its centre are four questions: which problem is to be solved, and for whom? How does the process concerned really work today, rather than how it appears in the organisation chart? Which technical and organisational conditions limit the solution space? And is the solution worthwhile at all, measured against what the problem costs today?

Behind this lies an insight that is explicitly formulated in the British GOV.UK Service Manual, one of the most frequently cited standards for this project phase: at the beginning there is often a ready-made solution ("we need a new portal"), and the first task of discovery is to translate this solution back into a problem. "We need an interactive map of our locations" becomes "How do customers find the right contact person faster?". The quality of this reformulation determines the quality of all later solution ideas.

Typical activities

• Stakeholder and user interviews: conversations with the people who will work with the system and with those who pay for it. The two groups rarely want the same thing.
• Process analysis: looking at the current process where it takes place, including the Excel files, shouted instructions and workarounds that do not appear in any documentation and are often the real core of the problem.
• Technical inventory: which systems are affected, which interfaces really exist, where is the data, which legacy systems set hard limits? The question "Does the ERP have an API or just a CSV export via a nightly job?" belongs in discovery and not in the third sprint.
• Prioritising requirements: separating what belongs in a first productive MVP from what belongs in later expansion stages. Without this separation, there is no plannable scope.
• Risk and constraint analysis: legal requirements, contracts, legacy technology, organisational dependencies. The Service Manual distinguishes hard constraints, which have to be accepted, from soft ones, which can be changed.

The results: how to recognise a genuine discovery

At the end of a robust discovery, three artefacts are on the table. First, a prioritised backlog that separates the MVP scope from expansion stages. Second, an architecture sketch with the critical integration points, because integrations into existing systems are the classic hidden cost driver. Third, an estimate that is justified per building block instead of a total figure falling from the sky. If one of these three results is missing, it was not a discovery but an extended sales conversation.

A fourth, often overlooked result is just as legitimate: the realisation not to build. The GOV.UK Service Manual expressly states that stopping after discovery is not a failure but money saved, for example because off-the-shelf software already solves the problem or the benefit does not justify the costs. A discovery that structurally can never reach this result, because the service provider earns money from the subsequent build contract, has a built-in conflict of interest that clients should be aware of.

Duration, costs and team

There is no standard value for the duration, but there is a reliable range based on experience: the GOV.UK Service Manual names four to eight weeks as typical, depending on how well the problem area is already understood. For a medium-sized custom software project at a mid-sized company, two to six weeks is a common framework, often as a separately commissioned and paid work package with defined results.

The fact that discovery costs money is not a disadvantage but its purpose. It moves a small, controlled part of the budget to the point where insights are cheapest. A requirements error noticed in discovery costs a conversation and a corrected backlog line. The same error, discovered after go-live, costs rework, migration and trust. The cost curve of fixing defects that has been discussed in software engineering for decades, popularised by Barry Boehm's work on software economics, says essentially exactly this: the later a requirements or design error is found, the more expensive its correction becomes, often many times over.

A discovery team typically includes a product or project owner, someone with architecture expertise and, depending on the project, UX research. On the client side, access is needed to the people who carry out the process every day. A discovery that only talks to management examines the idealised picture of the process, not the process.

Discovery phase and classic specifications

Discovery does not replace the specifications; it precedes them and makes them better. The difference lies in the direction: the specifications write down what the client believes they need. A discovery tests this belief before it becomes part of the contract. In practice, the result of a discovery is often the content basis for the specifications and the functional specification, but then with validated rather than assumed requirements.

Distinction: discovery, design sprint, product discovery

Three related terms are often mixed up. The design sprint according to Jake Knapp (developed at Google Ventures) is a highly condensed five-day format in which a specific product idea is tested as a prototype. It can be part of a discovery but does not replace it, because it leaves out the technical inventory and the question of economic viability. In product organisations, product discovery refers to a continuous process of constantly checking which features are worth building; the discovery phase of a project is, in a sense, the one-off, compact version of this. And the concept phase of classic process models such as the V-Model pursues a similar goal but works in a document-driven rather than research-driven way: it fixes requirements, whereas a discovery first questions them.

Real-world example: discovery in the GOV.UK Service Standard

The most prominent documented example of institutionalised discovery phases is the British Government Service Standard. Since 2013, every digital service of the British administration has had to pass through the discovery, alpha, beta and live phases, and the Government Digital Service's Service Manual publicly describes what has to be achieved in discovery: defining the problem instead of adopting a solution, understanding the user context, identifying hard and soft constraints, defining how success is measured and, at the end, deciding consciously whether to continue. What is remarkable is the clarity with which not continuing is treated as a success. For private-sector software projects, this model is interesting because it shows that discovery is not an agile ritual but a checkpoint for investment decisions.

Common mistakes in practice

The most common mistake is the sham discovery: workshops whose result is fixed from the outset because the quote has long since been written. You can recognise it by the fact that at the end there is no justified estimate per building block, but the same total as before, now with slides. The second mistake is the endless discovery, which never leads to a decision out of fear of commitment; a hard time window and a predefined result format help against this. The third is discovery without technical people: if nobody examines the existing systems, the most expensive risks, namely integrations and data quality, move into the project unchecked. And the fourth is the skipped discovery on supposedly clear projects. Migrations and replacements of legacy systems in particular are considered "clear" until the first undocumented special logic turns up, which three clerks knew about and no document did.

Outlook

AI tools are currently changing the mechanics of discovery, not its purpose. Interview transcription, the analysis of process documents and rapid prototyping of interfaces noticeably speed up investigative work, and code analysis tools make the technical inventory of legacy systems more thorough than manual review ever was. What remains is the core that no automation replaces: the decision as to which problem a company really wants to solve and whether it should build software for it. In the end, a discovery phase is exactly that: a small, paid portion of honesty at the beginning of an expensive undertaking.

FAQ on the discovery phase

What is the discovery phase in software development?

The discovery phase is the first project stage, in which the problem, users, processes and technical conditions are examined before development begins. The result is a prioritised backlog, an architecture sketch and an estimate justified per building block, or the conscious decision not to build.

How long does a discovery phase take?

The GOV.UK Service Manual names four to eight weeks as typical. For projects at mid-sized companies, two to six weeks is common depending on complexity, often as a separately commissioned work package. What matters is less the duration than a hard time window with predefined results.

Why should a discovery phase be paid for separately?

Because it has to be open-ended. A free discovery is financed by the subsequent build contract and therefore has a built-in incentive always to recommend "build". A paid work package with defined results can also conclude that off-the-shelf software is sufficient or that the project is not worthwhile.

What is the difference between the discovery phase and the specifications?

The specifications document requirements from the client's point of view; discovery checks beforehand whether these requirements solve the right problem. Ideally, discovery provides the validated basis from which the specifications and functional specification are created, instead of assumptions becoming part of the contract unchecked.

How do you recognise a good discovery phase?

By its results: a prioritised backlog with an MVP cut, an architecture sketch with the critical integration points and an estimate that is justified per building block. And by the attitude: a reputable provider treats "don't build" as a possible, legitimate result, not as an accident.