The Discovery Phase, or: The Stakeholder You Forget Fills Your Queue
Conception asks how. Discovery asks whether, what, and who. Skip the second and you ship a flawless answer to a question nobody asked. I skipped one stakeholder on a native-app build and paid in tickets. The team holding the answer was one meeting away.
On a native-app project I skipped Customer Support. Not a decision. I just never thought to invite them. They're support. What would they know about a new build?
Everything, obviously.
They were sitting on a daily, ranked list of the exact complaints the new version needed to answer. That list should have been our week-one design input. I never asked. We shipped without addressing a single one.
The reward arrived on schedule: a flood of tickets describing problems we could have designed out in week one. Filed by users. Triaged by the exact team that had been quietly holding the answer the whole time. They would have handed it over for the cost of one meeting.
That is the discovery phase.
Discovery decides what deserves to be built
Two different things get called planning.
One is conception: engineering working out how to build a thing everyone already agreed to build. I wrote about that one.
Discovery comes first. It is earlier, messier, and full of other people's opinions. Conception is "how." Discovery is "whether," "what," and "who."
Get brilliant at the first while skipping the second and you ship a flawlessly engineered answer to a question nobody asked.
The projects I watched die outright, not slip, didn't die on the code. They died upstream of the first commit, where nobody had established what we were solving and for whom.
Discovery is not an engineering exercise with product invited as a courtesy. It is the cross-functional phase engineers most want to skip. It means meetings, market research, and opinions you don't control. None of it compiles. To an engineer, work has a commit attached. A week spent talking to users registers as the soft stuff before the real stuff starts.
The outside world has data on the soft stuff. Microsoft ran controlled experiments on its own shipped ideas; Kohavi and Thomke published the tally in HBR in 2017. Only about one third of well-designed, well-built ideas improved the metric they were built to move. Two thirds came back flat or negative.
That's Microsoft, with experiment infrastructure most teams will never have, testing ideas that had already survived internal scrutiny. Skip discovery entirely and you're betting months of engineering on worse odds than a coin flip.
The same mistake has four prices
Discovery is the only phase where finding out you're building the wrong thing is cheap. The cost climbs with every phase you push that discovery into.
- In discovery: a week of conversations and some bruised assumptions.
- In conception: a redesign.
- In build: months of burned engineering, and a team that can feel the thing isn't landing.
- At launch, where the skippers catch it: a support queue on fire, and a chunk of your credibility with it.
The ladder has a source. NASA measured it in 2004, in the INCOSE error-cost escalation study. A requirements mistake caught during requirements costs 1x. In design, 3-8x. In build, 7-16x. In test, 21-78x. In operations, 29-1500x.
Aerospace data, scoped to requirements errors. Which is exactly the discovery case: not a bug in the code, a mistake in the direction.
One honesty note, because this neighborhood is full of fake numbers. The famous cousin, "bugs cost 100x more to fix in production," traces through a 1987 textbook to IBM training slides nobody can produce. And when Menzies and colleagues measured real defect-fix effort across 171 projects in 2016, the smooth curve wasn't there.
Bug-cost curves are contested. Direction-error curves are not. Keep the two separate, and cite the one that's real.
Ask whether it is survivable
The work of discovery isn't exotic: real users, stakeholder interviews, goals concrete enough to fail. A goal that cannot fail is a wish. Teams still botch two pieces of it on repeat.
When engineering gets pulled into discovery, it usually answers the wrong question. Product asks "can we build this." Engineering says "sure." Both sides walk away satisfied, and zero information changed hands.
Almost everything is buildable. The answer is always yes, which is exactly why it's worthless.
The question that bites three years later never gets asked: what does this cost to keep alive on a bad night?
Whether it pages someone every week. What it adds to the cloud bill. Whether the team that has to own it after launch even exists yet.
Feasibility was never "is it buildable." It's "is it survivable once it's built." That's the one piece of discovery only engineering can supply. Nobody else in the room knows what a bad night costs.
Build the invite list from the pain
The Forgotten Stakeholder Rule came out of that native-app project: whoever you leave out of discovery is the one who fills your queue later.
That's selection, not luck. Un-designed-for problems surface after launch, which is exactly where that stakeholder works. Skip Support and the tickets find you. Skip Ops and it's the pager at 3am.
The fix costs one column. A stakeholder map is a prediction of where the pain will surface. Build the invite list from who feels it when this breaks, not from the org chart.
Support. Whoever carries the pager. The people who answer the renewal call.
If they have nothing to say, you lose thirty minutes. If they do, they just saved you a quarter.
Discovery has to end
The opposite failure is just as real. Discovery with no end date is analysis paralysis with a budget code. Some teams hide in research forever, and for a reason: research can't fail the way shipping can. A study is never wrong at launch, because it never launches.
Time-box it. Two weeks for market and user research. One week for stakeholder interviews. A hard stop. Then a decision.
The goal is enough clarity to commit. If discovery is still "ongoing" in month two, it stopped being discovery and became a hiding place. Discovery earns its keep by ending.
On time, under budget, total silence
The expensive outcome isn't the project that lands two weeks late. Late projects ship, get used, get forgiven.
The expensive one is the well-built product that solves a problem nobody had. It shipped on schedule, came in under budget, and nobody showed up.
And silence isn't even rare. Pendo's 2019 Feature Adoption Report, built on its own usage data across 615 customer subscriptions, found 80% of features in the average product are rarely or never used, and priced the sunk R&D at $29.5 billion.
Vendor data, from a vendor selling the fix, so salt it hard. The direction survives the salt: most shipped software is never touched.
You can't refactor your way out of that one. There was never anything wrong with the code.
The lesson is to ask whether, what, and who before engineering answers how. Build the invite list from who feels the failure, and catch direction errors while they are still cheap.
The code was fine. It almost always is.
There was something wrong with the invite list.
I never asked.