What decision is discovery supposed to unblock?
Discovery has a mixed reputation. If what you are offered is a fixed-calendar exercise that ends in a document repeating what you said at the kickoff, that reputation is deserved and the engagement is worth refusing.
A discovery phase is useful when it exists to unblock a decision you can name. Write down which decision you need answered before you agree to anything. It might be whether to build this at all, what the smallest version worth building is, whether it can be delivered inside the constraints you already have, or whether this team is the right one to do it. If nobody can name the decision, there is nothing to discover.
That framing also gives you a way to decline things. If a proposed session cannot be traced back to the decision you named, ask what it contributes before it goes on the schedule. Personas with no bearing on a build decision, sessions that produce sentiment but no constraints, and workshops that restate the brief all fail that test.
Artifacts worth asking for up front
A discovery earns its place through what it hands over, so ask for the outputs by name before it starts.
Settle the format at the same time. If the outputs only work inside the tools of the firm that produced them, you are not left with much you can carry elsewhere, so ask for versions you can edit.
- A written problem statement describing the current process and what is wrong with it, in the language your staff actually uses.
- A scope list with an explicit out-of-scope list beside it. The second list is the more useful of the two.
- A domain glossary. Two teams can use the same noun for different things for months without noticing.
- An inventory of every system the new software must read from or write to, with the interface each one really offers and the name of whoever owns it.
- Non-functional requirements filled in with figures your side supplies: expected users, data volumes, retention rules, availability expectations, response time thresholds.
- An architecture direction that also records the options considered and rejected, and why.
- A risk register with a named owner against each entry.
- A delivery shape: sequence, milestones, dependencies, and which parts can run in parallel.
- A list of the questions discovery did not close, with what it would take to close each one.
What the work should look like while it runs
One thing to watch for is whether anything comes back ruled out. A discovery that confirms every idea you walked in with has not tested any of them.
Beyond that, these are the working habits to look for:
- The team asks to speak with the people doing the work today, not only the sponsor who signed the engagement.
- Assumptions are written down as assumptions, and flagged where they remain unverified.
- Unknowns are named and ranked by how much damage they do if the answer turns out badly.
- Findings reach you while the work is running, so nothing in the closing document is a surprise.
- The output reads clearly to somebody who was not in any of the sessions.
Questions worth putting to your own people
A discovery should put these questions to your own staff, and if it does not, ask them yourself.
The question about previous attempts is worth pressing on. If an earlier effort stopped, the reason may still be sitting in the organization, and asking about it can surface constraints nobody thought to state.
- Who does this work today, and what do they do when the system is unavailable?
- Where does the data live now, and which system wins when two of them disagree?
- What has to be true for this to count as done, stated so that someone outside the project could check it?
- What actually happens to the business if it ships later than planned?
- Which rules are legal or regulatory obligations, and which are habits nobody has questioned?
- What has been tried here before, and why did it stop?
How do you know discovery is finished?
Discovery should end when its exit criteria are met. A date is not an exit criterion. It is finished when the decision you named at the start can be made, and when the unknowns that remain are ones you have consciously accepted.
Two failure modes sit either side of that. Stopping early leaves the build team to invent the answers, and those decisions then get made without you in the room. Running long risks producing documentation that ages before anything is built against it, and chasing certainty on questions that only a working version can settle.
A practical test: can the team write acceptance criteria for the first slice of work without opening a question that would change the architecture? If so, stop discovering and start building.
When a short scoping conversation is enough
Not every project needs a discovery phase. If you think yours might not, raise it before you sign rather than after.
Where the conditions below hold, the alternative is a short scoping conversation followed by a slice of real work. If a full discovery is proposed anyway, ask which decision it unblocks. Sometimes there is a good answer. No answer tells you something too.
- The change is well understood and confined to a system your team already knows.
- You are replacing a system like for like, and the behavior of the old one is documented or can be observed.
- A specification already exists that a delivery team can read and challenge directly.
- The work is small enough that a first working version can answer the open questions directly.
Carrying discovery into delivery
Discovery output is only worth having if it survives contact with the build. A few things should carry forward explicitly: acceptance criteria attached to individual features, a stated process for how scope changes get raised and agreed, and a fixed point in the schedule where the plan is checked against what has actually been built.
Ask for the discovery outputs to be named in the delivery agreement so they stay in use after handover. When the scope list and the assumptions are the stated basis of the plan, a change to either has a visible consequence, and that is what keeps a project honest on both sides.
Related service: Our custom software development page describes the delivery work that follows scoping, and how a project is run once the questions above have answers.