Discovery Is De-Risking, Not Requirements Gathering

The instinct in a strong delivery org is to get it going. That instinct keeps things moving and it is worth protecting. Applied blindly, though, it means initiatives regularly enter execution before anyone has tested whether customers want the thing, whether the business case holds, or whether it can actually be built within the constraints. The result is predictable: late surprises, rework and write-offs, and “green” status reports that turn out to be red on the inside. So the natural advice is “do more discovery first.” And here is where it falls apart.

The moment you tell a delivery-driven organization to slow down and do discovery, one of two things happens. The first is that people hear “go away and analyze for a while longer.” Open-ended study with no clear finish line. They resist it, and they are right to — that kind of discovery genuinely is waste. It is procrastination dressed up as diligence.

The second is that discovery quietly becomes requirements gathering for something already decided. The build is greenlit; “discovery” is just the phase where we write the spec in more detail. No assumption is ever at risk of being wrong, because the decision was made before the learning started. There is a third problem on top of those two: the word is ambiguous. Technical discovery — figuring out how to build something — also happens later, during the build itself. Calling two different activities “discovery” muddies the whole lifecycle. So the word is working against you. It signals the wrong thing, invites the wrong behavior, and points at the wrong part of the process.

The answer is not to drop discovery. It is to double down on it and be ruthless about its purpose. Discovery is a de-risking mechanism, not a requirements-gathering mechanism. Its job is to reduce the biggest uncertainties about an initiative just enough to make an honest investment decision — and then get out of the way. Its output is evidence and a go/no-go, not a specification.

That gives us a one-line rule you can teach:

Validate your high-risk assumptions before you commit real money — or skip ahead if none of them are high-risk.

It is a smarter start, not a slower start. You only slow down where the risk actually is. Everywhere else, you move. That framing matters enormously in a delivery culture, because it answers the “don’t slow me down” objection honestly: most of the time, de-risking is skipped, and that is the correct call. The mantra I leave teams with: learn before you burn (money).

How do you know which assumptions are high-risk, and whether you are clear enough to commit? You read the Investment Conviction of the initiative. Start by scoring three dimensions, each on evidence rather than how confident anyone feels:

• Desirability — do customers actually want this?
• Viability — does the business case and cost-to-serve add up?
• Feasibility — can we build and run it within our constraints?

Rate each green (we know, with evidence), amber (we think, it is opinion or partial), or red (we are guessing). Then combine them — and the way you combine them is the whole point.

Why multiply instead of average? Because “two out of three green” feels safe, and that feeling is precisely the trap. Brilliant desirability and viability cannot rescue broken feasibility. A single unknown drags the whole investment case down, and two soft spots compound into something genuinely risky. Averaging hides that. Multiplying surfaces it. And only evidence earns a green — confident opinion with nothing underneath it is amber at best.

Set the clarity on each dimension and watch the conviction — and the recommended action — move. The interesting cases are the ambers: two of them, individually “probably fine,” combine into a red.

De-risking is not a stage you pass through every time. It is a decision you make, and most of the time the decision is to keep moving. Here is the whole loop.

The steps, in plain language:

1. Start from hypotheses, not a blank page. You enter de-risking with well-formed hypotheses and a named set of riskiest assumptions. If you do not have those yet, you are still framing the problem — go back and do that first.
2. Rate D / V / F on evidence and read the conviction. Green means skip. Amber or red means there is something specific worth validating.
3. Validate the soft dimension, or skip. Aim the work at the actual open question. A feasibility spike does nothing for a “do customers want this?” gap.
4. Run the smallest experiment that buys the most confidence. A handful of customer conversations, a prototype, a technical spike, a thin shippable slice, a pricing probe. Timebox it. The goal is learning, not a mini-project.
5. Decide what signal will change your mind, up front. Prefer leading indicators you can read now over lagging totals that only confirm the past.
6. Re-rate and make the call. Green now means commit. Still soft means one more bounded loop. Will not move means stop or pivot — and a cheap “no” here is a win, not a failure.

Not every uncertainty deserves the same response. Pick the approach by the level of risk, not by habit.

Skip de-risking and go straight to commit when all of these are true:

• You have evidence — not opinion — that customers want this. (Desirability known)
• The value and the cost-to-serve are understood and add up. (Viability known)
• You are confident you can build and run it within known constraints. (Feasibility known)
• The cost of being wrong is small or easily reversible.

If any box is unchecked and the cost of being wrong is meaningful, de-risk that specific gap — and only that gap — before committing. The rule cuts both ways. Do not over-discover the certain: heavyweight discovery on a low-risk tweak is procrastination dressed as diligence. And do not under-discover the risky: “just build it” on a high-uncertainty strategic bet is a rubber stamp, not a decision.

If you are introducing this into an organization that prides itself on execution, a few things matter more than the framework itself. The process artifacts — the board, the canvas, the scoring — are facilitation tools, not the point. If a team walks away using the shared language — “what’s the desirability risk here? have we burned it down?” — that is the win, even if they never fall in love with the ceremony.

Reduce the effort wherever you can. Where the conviction read can be pulled from artifacts the team already maintains, pull it automatically rather than asking people to keep a separate scorecard by hand. The friction is something you own, not a tax you impose. And be explicit about what is in it for the people doing the work: fewer death-march rebuilds, fewer “why didn’t we know this sooner” moments, and a defensible record of why you committed when you did.

That is the whole move. Keep the bias for action that makes a strong delivery org strong. Aim a small, bounded amount of that energy at the riskiest unknowns before the money is committed. Learn before you burn — and treat a cheap “no” as one of the most valuable things discovery can buy you.