Discovery has a bad reputation, and a lot of it is earned. Plenty of agencies sell three weeks of workshops that produce a slide deck restating what the client already said, followed by a proposal for the work the agency wanted to do anyway.

That is not an argument against discovery. It is an argument for knowing what a good one produces. There is a short, checkable list, and one test that separates the real thing from the sales process.

The test

At the end of discovery you should be able to hand the output to a supplier who was not involved in producing it, and get back a quote you could meaningfully compare against ours.

That single criterion rules out most of what goes wrong. A deck of workshop photographs fails it. A document whose recommendations only make sense if the author builds them fails it. A prioritised backlog with no reasoning attached fails it, because the next supplier cannot tell which items are load-bearing.

It also explains why an honest discovery is uncomfortable to sell: the deliverable is deliberately portable, which means it reduces the client's switching cost. A supplier who is confident in the build should be fine with that.

What has to be in it

Nine documents, and each one answers a question that would otherwise be answered during development at ten times the cost.

  • Objectives and success criteria, written as outcomes with numbers where numbers exist. "Reduce inbound status requests" is an objective. "Modern, user-friendly website" is not.
  • Stakeholder findings. Who was interviewed, what they said, and where they disagreed. The disagreements are the useful part: they are the decisions somebody will have to make later, and they are cheaper to surface now.
  • Current-state map of systems, data, integrations, content and traffic. Replacement projects fail on undocumented things, so the documentation is the deliverable.
  • Prioritised requirements, written as outcomes, with an explicit line between the first release and the roadmap.
  • A technology recommendation with its alternatives. Not just what, but what else was considered and what each option costs in year three.
  • An integration plan naming, field by field, which system owns which value.
  • A risk register with mitigations and owners.
  • A phased delivery plan with effort ranges, the assumptions each range depends on, and the unknowns that would change it.
  • A measurement plan saying what will be tracked and which decision each metric supports.

Why the deferred list matters more than the scope

Every discovery produces a scope. Good ones also produce a written record of everything that was considered and deliberately left out, with the reasoning.

This sounds like paperwork. It is the single most valuable artefact six months later, when someone asks why the portal does not do invoicing. Without the record, that conversation is an argument about competence. With it, it is a five-minute reference: we considered it, it was deferred because the finance integration would have doubled the first release, and here is the point in the roadmap where it returns.

It also protects the client from a common agency behaviour: quietly dropping the awkward requirements and hoping nobody notices until after sign-off.

How long it should take

Two to five weeks for most engagements. The two variables are the number of stakeholders who need interviewing and the number of existing systems that need mapping. Neither is affected by how large the eventual build is, which is why discovery cost does not scale with project cost.

Anything under a week is a scoping call with a document attached. Anything over six weeks is usually a symptom: either the organisation cannot make decisions, or the discovery is being used to keep a team busy.

Fixed duration and fixed price, agreed before starting. Discovery that runs on time and materials has an obvious incentive problem.

The outcome nobody sells

Occasionally discovery concludes that the project should not happen: the process the software would automate runs twice a month, or an existing product covers it, or the real problem is organisational and no software will touch it.

That is a successful discovery. It cost a small fraction of finding out during development, and it is the outcome most likely to be suppressed by an agency whose next quarter depends on the build.

It is rare. But the willingness to reach it is the thing worth checking for before you commission the work.

When to skip it

Discovery is not free and it is not always warranted. Skip it when the scope is genuinely settled, the integrations are understood, and the technology decision is obvious – for example, a marketing site replacing a marketing site on a platform the team already runs.

In that situation a short technical review is the right size of intervention: a few days to check the assumptions, confirm the URL and content inventory, and price the work. Paying for three weeks of workshops to reach a conclusion everyone already held is waste, and a supplier who cannot tell you that is not giving you advice.