Discovery Deliverables That Decide Whether Build Starts

One published case read against two public discovery checklists. Which deliverables can stop a build, which only prepare one, and the gap that decides.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources - a published returns policy, help centre articles, ten public complaint threads I selected myself, consumer law and a walk through the published customer journey. No client, no interviews and no team. I read that case against two public descriptions of what discovery should end with, one from the UK government's Service Manual and one from Nielsen Norman Group. Every status and every verdict in the tables below is mine [MINE], and you can redo them from the case.

Discovery deliverables are the documents a team produces to decide whether to build at all. The ones that actually decide are few: only a deliverable whose content could make the answer "stop" is doing discovery work. Everything else prepares a build that has not been agreed yet.

In short

• Two public checklists ask for different things. NN/g lists outputs. The GOV.UK Service Manual lists the decision those outputs have to support, and names two factors behind it.
• The case has some form of four of the five NN/g outputs. It answers neither GOV.UK decision factor in full: one is argued from outside, the other has no figure on either side.
• The deliverable that decides is the size of the problem, and it is the one the case cannot produce. Section 1.6 says so in advance, which is what keeps the gap honest.
• A pack can look complete and still be unable to say "go". Sort what you have into "decides" and "prepares" before anyone counts pages.

What does discovery have to end with?

The two sources answer this question differently, and the difference is the useful part.

Maria Rosala's NN/g article on discovery defines it as "a preliminary phase in the UX-design process that involves researching the problem space, framing the problem(s) to be solved, and gathering enough evidence and initial direction on what to do next." It then lists outputs, with a warning in front of them: "Discovery isn't about producing outputs for their own sake." The list is a problem statement "backed up with evidence that details how big it is and why it's important", maps such as a journey map or service blueprint, user-needs statements, personas, and high-level concepts or wireframes "for exploring in the next phase".

The GOV.UK Service Manual page on the discovery phase starts from the other end: "Your discovery is finished when you've decided whether or not you want to move on to alpha." It names two factors in that decision: whether "there's a viable service you could build that would make it easier for users to do the thing they need to do", and whether "it's cost effective to pursue the problem - this means weighing up how much it'd cost against how much of an improvement you think you could make". It also lists five things to have in hand if the answer is yes.

Both pages treat stopping as a legitimate result. GOV.UK: "It's not a failure to stop at the end of the discovery phase if your research shows that's the best thing to do." One list says what to produce, the other what the products are for, and a discovery pack is judged by the second.

The output list, run on the case

The first pass is the easy one. Each NN/g output, and what the case holds in its place.

Four of five in some form, one absent on purpose. On this list the case looks finished.

The decision list, run on the case

Now the GOV.UK factors. These are the rows that can say "stop".

One factor argued, none answered. That is the honest reading of a discovery built from outside a company. The case says why: "I cannot price internal effort from outside the company, and an invented figure would be the first thing to break in the room."

The five conditions GOV.UK lists for moving on are a different kind of row. They are what you need in hand once the answer is yes.

Three answered or nearly, one partial, one not attempted. None of these five can stop the build on its own. They prepare it.

Which deliverables decide, and which only prepare?

Putting the three tables together gives a short sort. A deliverable decides if some plausible content in it would turn the answer into "stop". It prepares if, whatever it says, the build is still on.

Decides. The size of the problem. The cost of the change. And one thing neither list asks for by name: a stop line written before the evidence arrives.

Prepares. The process models, the requirements and their criteria, the rules register, the scope tables, the options with a recommendation, the measure of success. All of them are needed. None of them can say no.

That is why a discovery pack can be thick and still undecided. Size needs the queue, cost needs the people who would build it, and the case had neither.

Where does the case write its stop line?

Section 1.6, in full:

If the queue export showed that parked cases are rare and short, this work is not worth a release slot and I would say so. The measurement in OQ-06 is therefore not a nice-to-have at the end. It is the thing that decides whether the rest of this case is right.

It names the evidence (the queue export), the result that would stop the work (parked cases rare and short), and what is at stake (a release slot). The open questions register then gives OQ-06 an owner and a date, which is what scorecard check 05 asks of every open question, and a fallback: "Instrument first, decide second. No further design work on this branch until there is a number."

A stop line has to be written before the number comes in. Written after, it is an explanation of whatever the number turned out to be.

Where the case does more than discovery asks

The table above has an uncomfortable reading. By the case's own words in 1.6, OQ-06 decides whether the rest is right, and the rest was written anyway: five requirements with fifteen acceptance criteria, four business rules, a review log. In the order GOV.UK describes, that is work for after the decision, and the Service Manual is explicit that "You should not start building your service in discovery."

None of that is building. But it is preparation done before the factor that could cancel it, and in a real engagement it would be the wrong order [MINE]. The case has a reason that a real engagement would not: it exists to show the six templates filled, and its opening says the blank templates "are worth very little until you have seen them filled to the standard they are asking for". If I ran the same work with access, I would stop at the brief, the map, the as-is and the one-pager, and pull the queue export before writing REQ-014.

Time tells the same story. GOV.UK calls "around 4 to 8 weeks" typical for a discovery. The case took about 13 hours over four evenings and a Saturday. The gap comes from having no users to research and no data to pull, which is also why the decision rows stay open. The 13 hours say nothing about speed.

The build-start sheet, filled in

One sheet, filled from the case, to sit in front of the one-pager.

The "stop line" row stops a pack being read as a yes because it is long. The "prepared ahead" row stops requirements being counted as evidence that the problem is big enough.

The build-start sheet, blank

Where does this sort stop working?

It assumes the decision is open. When the build is already funded and discovery is there to shape it, nothing in the "decides" group will be allowed to say stop, and the work should be called something else. It also says nothing about how good each deliverable is. A weak problem statement still decides, it just decides badly.

The memo that comes out of a stop line is worked through in the feasibility memo that recommends not building it. Turning "measurable for the first time" into a measure that can fail is in the success measure piece, and why the hours of analysis do not map onto the weeks of a calendar is in how long will the analysis take. The full case is at /case, the one-pager as a template, the tags on the method page, and checks 05, 10, 22 and 25 of the scorecard are the ones a build-start sheet has to pass before it goes to the person who decides.

All field notes · The portfolio guide · More in Requirements That Survive Review