Discovery Is De-Risking, Not Requirements Gathering

Дата публикации: 04-07-2026 22:54:55

Originally published on yuvalyeret.com.Most organizations I work with are very, very good at executing projects. Give them a defined scope and a date, and they will drive it to done. That muscle is a real strength. It is also the thing that quietly caps the return on their software investments. A project-execution mindset optimizes one question: did we ship what we said we would, on time? That is a fine question for building a bridge, where the requirements are knowable up front and the cost of changing your mind late is enormous.It is the wrong question for software, where the requirements are mostly guesses and the cost of changing your mind early is almost nothing. Introducing product thinking into that kind of organization is really about changing the question to: did the investment actually pay off? The honest answer, often, is that nobody checked the riskiest assumptions before the money was committed. The work shipped. Whether it was worth building is a separate conversation that happens much later, if at all.The instinct that helps you — and the one that hurts youThe 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.Why "discovery" is a loaded wordThe 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 decision: double down on discovery — but reframe what it is forThe 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).The thinking: Investment ConvictionHow 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.Investment Conviction is a product, not an average Investment Conviction = Desirability × Viability × Feasibility Multiply, don’t average — a weak dimension drags the whole investment down. × × = Green Commit — or skip de-risking entirely. × × = Amber Validate the one soft spot, then commit. × × = Red Two ambers compound — de-risk before committing. × × = Red One true unknown tanks it — validate first. Investment Conviction is a product, not an average. "Two out of three green" feels safe — that is exactly the trap.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.Try itSet 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.Interactive: pick a clarity level per dimension to see the combined Investment Conviction and the recommended action.The flow: frame it, rate it, validate or skip, then commitDe-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 de-risking flow Frame it hypotheses & riskiest assumptions Rate D · V · F on evidence Investment Conviction = D × V × F Conviction green? green · skip de-risking Commit & Plan Build → Ship → Tweak amber / red Validate the soft dimension(s) smallest timeboxed experiment Re-rate · watch leading indicators Convinced now? yes → go not yet no Stop / pivot Frame it, rate Investment Conviction, then validate the soft dimensions or skip — and only commit once the risk is burned down.The steps, in plain language: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.Rate D / V / F on evidence and read the conviction. Green means skip. Amber or red means there is something specific worth validating.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.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.Decide what signal will change your mind, up front. Prefer leading indicators you can read now over lagging totals that only confirm the past.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.Match the approach to the riskNot every uncertainty deserves the same response. Pick the approach by the level of risk, not by habit.Risk levelApproachWhen it fitsLowJust do itEvidence-backed clarity across D/V/F; the cost of being wrong is small. Skip de-risking and go straight to planning.MediumShip and measurePlausible conviction, but you want a real-world read. Release a thin slice and learn from actual usage.HighRun an experiment firstMajor open questions — especially desirability — where building the wrong thing would be expensive.High and strategicGo after the riskiest unknownDeliberately attack the single leap-of-faith assumption before anything else.Do I even need to de-risk? A quick checklistSkip 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.The smells to watch forSmellWhat it looks likeWhat to doRubber stampCommitting or building with open desirability or viability questions, because "we already decided"Name the cheapest experiment that would close the gap, and run it firstWatermelon"We're confident" with no evidence underneath — green outside, red insideSeparate opinion from fact; isolate the riskiest leap-of-faith assumptionProcrastination testingEndless discovery on something that is actually low-riskMake the call and move to commitDiscovery as requirementsUsing the stage to spec an already-decided buildRe-anchor on the go/no-go — you have not committed yetSteering by activity"We shipped twelve things, the team is busy" offered as proof of progressRe-anchor on a leading indicator tied to an outcomeMaking it stick in a delivery cultureIf 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.Yuval Yeret helps product and technology leaders move from agile theater to evidence-informed, outcome-oriented delivery. He's shaped the agility path of dozens of organizations and influenced the frameworks used across the industry.More insights on yuvalyeret.com →

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Wird Product-Ownership zum Flaschenhals im KI-Zeitalter? Warum viele Product-Owner schlecht priorisieren, warum KI das sichtbar macht und 10 Werkzeuge, um besser zu entscheiden	0	7	07-07-2026
2	The Most Passionate Transformations Make the Worst Decisions	-2	6	09-07-2026
3	Why Your AI Effort Has Activity But Not Impact	0	7	06-07-2026
4	Prioritizing Is the Hardest Thing Your Brain Does. Your Calendar Treats It Like the Easiest.	0	5	05-07-2026
5	The New AI Operating Model. Start By Using Scrum	0	6	07-07-2026
6	Ordering the Product Backlog with RICE: From Opinion to Evidence	0	5	09-07-2026
7	Generative KI-Anwendung entwickeln: Mein ehrlicher Leitfaden für Product-Owner – von der ersten Idee bis zum laufenden Betrieb	0	6	07-07-2026
8	If You Can Write Acceptance Criteria, You Can Write an AI Routing Policy	0	7	05-07-2026
9	Myth: The Scrum Master has to be at every meeting	0	5	06-07-2026
10	You Helped Your Teams Into Helplessness	-2	6	02-07-2026

Классификация: Мнения. Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 6. Источник: scrum.org.