The Discovery Tax

"Just build it."

Three words that sound like a decision but function as a transfer. The person saying them feels decisive. The team hearing them inherits every question that didn’t get answered, every assumption that didn’t get tested, and a deadline that has no relationship to the work it describes. It’s the same pattern that shows up in premature green lights — confidence substituting for validation.

While there are many triggers for this, one common pathway is when someone commits to a timeline or a price before the technical reality has been assessed. When the assessment comes back and contradicts the commitment, the commitment wins. The promise already exists. The assessment is just an inconvenience.

“I’ve already promised them, so we have to do it.”

That sentence is where discovery dies. Not in a planning meeting. Not in a budget review. In a hallway conversation where someone decides that the cost of disappointing a client today is worse than the cost of failing them in three months.

The transfer

There’s a meaningful difference between two project kickoffs.

The first sounds like this: “We’re going to build this app by December 18th.”

The second sounds like this: “Over the next six weeks, we’re going to execute on the following components, in this order, with these dependencies, as we work toward the final deliverable. Here’s where we expect to hit friction. Here’s the mitigation plan. Here’s who owns what.”

The first one fits on a sticky note, but the second one requires actual work before the work starts. Most organizations pick the sticky note because the second version forces you to confront how much you don’t know yet, and confronting that is uncomfortable. It’s easier to commit to a date and figure it out later.

The problem is that “figure it out later” has a cost, and it’s always higher than figuring it out now. Barry Boehm’s cost-of-change research showed that fixing a requirements mistake after delivery can cost up to 100x what it would have cost to catch it during discovery. A two-week discovery phase at the beginning of a project can prevent a two-month correction in the middle. But the two weeks feels like delay, and the two months feels like bad luck.

It’s not bad luck.

It’s the discovery tax. You pay it now, at a discount. Or you pay it later, with interest.

What wishful thinking looks like in a spreadsheet

A few years ago, a project landed on my desk that had already been promised to a client. Complex application. Six-week timeline. The rationale: “We already had something similar” and “it shouldn’t be too hard.”

When I looked at the actual scope, the minimum viable product was going to take longer than six weeks and cost roughly twice what had been quoted. I said this directly. The response: “I’ve already promised them, so we have to do it.”

So we did it. Or tried to.

The project was marked by exactly the problems you’d predict: scope creep from day one (because the scope was never fully defined), miscommunications (because the deliverables were unclear), and a team stretched across too many shifting priorities with no framework for managing any of them. Every week surfaced a new assumption that hadn’t been validated. Every new assumption required rework.

We missed every target. Over budget. Past deadline. The thing that was supposed to take six weeks dragged for months. Not because the team was incompetent, but because the foundation was built on optimism instead of analysis. Governance is architecture — and this project had neither. The Standish Group’s CHAOS research found that only 16% of software projects succeed on time and on budget. The top causes? Incomplete requirements, changing requirements, and unclear objectives — exactly the things a discovery phase is designed to surface before the first line of code.

Everything that went wrong was predictable. I’d flagged it, in writing, before the first line of code was committed. And afterward, I was acknowledged exactly once for having been right. Then the same pattern repeated on another project, and another, and another. No further acknowledgment.

That experience is what drove me to get a Google PM certification and a Scrum Master certification. Not because I was asked to, or directed to; because I watched a project fail in exactly the way I predicted, and I wanted the vocabulary and framework to prevent it from happening again, or at minimum, to document why it kept happening.

What discovery actually buys

When discovery is done properly, the team experiences something that sounds simple but is remarkably rare: they know what they’re building, why they’re building it, and what “done” looks like.

That clarity changes everything downstream. Standup meetings have substance, decisions get made against actual criteria, and when scope creep appears (and it always appears), there’s a documented baseline to measure it against. “That’s a great idea, and it’s out of scope for this phase” is a sentence you can only say if the scope exists in writing.

Good discovery also identifies where the project is going to hurt before the pain starts. Risk profiles, mitigation plans, RACI charts — these aren’t bureaucratic overhead. They’re how a team hits a problem and keeps moving instead of stopping everything to figure out what to do.

In practice, good discovery looks like stakeholder interviews before the kickoff, not after the first sprint. A constraints inventory that names the things you can’t change. A risk register that identifies where the project will probably hurt, so the team isn’t surprised when it does. A rough work breakdown that sequences dependencies instead of treating every feature as independent. And critically: an explicit list of what you’re not building, because scope is defined as much by its boundaries as by its contents.

None of this requires months. A focused two-week discovery on a six-month project is a 6% time investment that de-risks the other 94%.

Discovery isn’t a phase you complete and file away; it’s the foundation that every subsequent decision rests on. Skip it and every decision downstream is a guess. You might guess right. But you’re betting the project (and your reputation!) on it.

Realistic advice

Not everyone has the authority to demand a discovery phase. Sometimes the promise has already been made, the budget has already been committed, and you’re the person who has to build what someone else sold.

When that happens: document everything.

Not to assign blame, not to build a case against anyone. Document because when an under-scoped project fails (and under-scoped projects fail at a rate that would alarm anyone who tracked it), someone is going to ask why. And in that moment, you want to be the person who can say “I know exactly why this failed” rather than the person everyone else points at.

Document the scope as you understood it.

Document the gaps you identified.

Document the conversations where you flagged risks.

Document the decisions that were made anyway.

Build a paper trail that reflects reality, because reality is going to show up eventually, and when it does, the person with documentation has a factual record. The person without it becomes the default explanation.

I’d been overextended across too many domains, too many concurrent projects, too many responsibilities. I’d started to wonder if the problem was me. “Maybe I’m not good enough. Maybe a better engineer could handle all of this.”

The documentation proved that the scope was the problem, not my competence. And once I could see the scope clearly, written down, across months of projects, the pattern coalesced. No individual contributor can compensate for a structural refusal to scope properly. The failure is architectural, not personal — and the damage compounds long after the project closes. That realization is what eventually led me to build systems that externalize knowledge continuously — not as a reaction to one bad project, but as a methodology for every project.

You can’t build anything on hopes and dreams.

Sources: RACI Chart: Definitions, Uses And Examples For Project Managers — Forbes Advisor Software Defect Reduction Top 10 List — Boehm & Basili, IEEE Computer (cost-of-change curve) The CHAOS Report — Standish Group (project success/failure rates)