Discovery Is De-Risking, Not Requirements Gathering

The useful part

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.

How it works

• The result is predictable: late surprises, rework and write-offs, and "green" status reports that turn out to be red on the inside.
• Most organizations I work with are very, very good at executing projects.
• 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.
• Whether it was worth building is a separate conversation that happens much later, if at all.

What to take from it

The instinct that helps you — and the one that hurts you The instinct in a strong delivery org is to get it going. 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. So the natural advice is "do more discovery first." And here is where it f...

Details worth keeping

Give them a defined scope and a date, and they will drive it to done. That instinct keeps things moving and it is worth protecting.