Run a discovery that ends in a decision

Most discovery work ends in a document. A good one, often — current state, findings, themes, recommendations — and six weeks later nothing has changed, because a document is not a decision and nobody in the room was ever asked to make one.

This is not a rigour problem. Teams that produce weak findings and teams that produce excellent findings fail in the same way. It is a structural problem, and the structure is set in the first hour, before anybody has been interviewed.

Write the decision before you book the first interview

One sentence, in the form of a choice somebody has the authority to make.

“By the fourteenth, the operations director decides whether scheduling stays in the current system with a rules layer on top, or moves to a purpose-built tool, on a three-year cost and risk basis.”

That sentence does four things at once. It names the person, so you know whose objections matter. It names the date, so the work has an end. It names the options, so you can tell which evidence is relevant and stop collecting the rest. And it names the basis of comparison, which is where most discoveries quietly go wrong — two options judged on different criteria cannot be decided between, only argued about.

Write it, then show it to the person named in it before you do anything else. Half the time they will correct it, and the correction is worth more than a week of interviews. Sometimes they will say the decision is already made, which saves you the whole engagement and earns you more trust than delivering a report about it would have.

Pick the five people who can change the answer

Discovery interview lists grow the way roadmaps do: by inclusion. Somebody suggests a name, nobody wants to exclude them, and you end up with nineteen conversations that produce the same seven observations.

Invert it. For each candidate, ask what they could tell you that would change the decision. If there is no answer, they are a stakeholder to inform rather than a source to interview, and there is a difference.

Five is usually enough, and they are usually these: the person who does the work today, the person who owns the system, the person who gets blamed when it breaks, the person who pays, and one person downstream who receives the output and has never been asked about it. That last one produces the surprise in a high proportion of engagements, because nobody upstream has ever seen what arrives at the other end.

Interview them separately. Group sessions give you the version everybody has agreed to say, which is the version already in the documentation.

That is the opening. The rest of the lesson — the remaining sections, the exercise and the check-your-understanding questions — is behind the gate below.