The discovery phase: what to settle before development

When a software project disappoints, the post-mortem usually looks at delivery: estimates, speed, scope creep, the team. Sometimes that is the real story.

More often, the outcome was decided months earlier, in a handful of conversations nobody considered technical. A discovery phase is the moment those conversations happen deliberately.

What a discovery phase is

Discovery is a short, focused stage before development in which the business, product and technical decisions that shape a project are made and written down. It is not a delay and not a document for its own sake: its value lies in unblocking the build and in avoiding the mistakes that are expensive to fix later.

Four decisions that shape a project

• Scope written as outcomes, not features. "Reduce the time from enquiry to quote" tells a team what to protect when the schedule tightens; "a quote builder with PDF export" does not.
• The riskiest assumption, tested first. Every project rests on something unverified: data quality, a third-party API, a migration, user acceptance. Testing it in week one is cheap; discovering it at the end is not.
• Architecture chosen deliberately. The database, the rendering model, how identity and permissions work: these are expensive to change and deserve written reasoning.
• An agreed definition of success. One sentence saying what the first version must achieve prevents a great deal of disappointment later.

What discovery should produce

• A problem statement and the outcome to measure, with the number that will show success.
• The users and their key journeys, including the ones that happen rarely but matter.
• The scope of the first version, with an explicit list of what is left out.
• The main risks and assumptions, and how each one is tested.
• The architecture and technology choices, with the reasoning behind them.
• A plan for delivery, with milestones and an estimate your team can use to decide.

Who should take part

Discovery fails quietly when the right people are missing. On your side and the supplier's, the room needs:

• The person who decides on budget and priorities, for at least the start and the final review.
• The people who run the process or serve the customers today, because they know where the real problems are.
• Whoever owns the existing systems and data, even if they will not build anything.
• From the supplier: the people who will design and build the product, not only a salesperson or an analyst.

A typical discovery, step by step

• Agree the goal and the question discovery has to answer, in one page.
• Interview the people who use, run and pay for the process, and look at the real tools and documents they work with.
• Map how the work happens today, including the data: where it lives, who changes it and how clean it is.
• Test the riskiest assumption directly, with a small technical spike or a clickable prototype put in front of users.
• Define the scope of the first version and the architecture, with the reasons behind each choice.
• Estimate, plan the milestones and review everything with the people who decide.

How to judge the result

A discovery is good if it passes a few simple checks:

• A new person can understand the project from the outputs in an hour.
• Every item in the first version can be traced back to the outcome it serves.
• Each major risk has an owner and a way to test it.
• The estimate states its assumptions, so you know what would change it.
• Your team could hand the plan to another supplier and still use it.

What it should not be

• A long document that nobody reads after it is approved.
• A design-only exercise that skips the technical and data questions.
• A sales step whose only conclusion is "build everything".

How long it takes

Usually weeks, not months. It is deliberately short: long enough to answer the questions that would otherwise surface in the middle of development, short enough that the project keeps its momentum.

When you can skip it

• The change is small and well understood, such as a new page or an integration with a documented API.
• You already have clear specifications, validated with users and reviewed technically.
• The project repeats something your team has built before, with the same stack.