How to Stop Building the Wrong Thing

The feature shipped. It was well-built. It met every requirement in the spec. Nobody uses it.

If this sounds familiar, you don't have an execution problem. You have an understanding problem. Your team is optimized for building, not for understanding what to build. And that gap is where most engineering effort goes to die.

The execution trap

Engineering teams are extraordinarily good at execution. Give them a clear spec and they'll ship it. The problem is that specs describe what someone thinks they want, not what they actually need.

Requirements are artifacts of someone's current understanding. They capture the surface of a problem, not the root. And when you execute flawlessly against a surface understanding, you get a beautifully engineered solution to the wrong problem.

This isn't a failure of the team. It's a failure of the process that treats requirements as input rather than as hypotheses to be examined.

The gap between stated and real

Every requirement has a stated problem and a real problem. They're almost never the same.

Here's one I see constantly:

Stated: "We need a notification system." Why? Because decisions are getting stuck. Why are decisions stuck? Because the right people don't know when something changed. Why don't they know? Because there's no mechanism for information to flow to the people who need it. Physics: Information routing is broken.

Notifications are one possible fix for broken information routing. But they're not the only fix, and they might not be the best fix. Maybe the real solution is restructuring how teams communicate changes. Maybe it's a daily async sync. Maybe it's changing who's in which Slack channel.

You can't see any of these alternatives if you start from "build a notification system." You can only see them if you start from "information routing is broken."

Requirements are hypotheses

Here's the shift that changes everything: stop treating requirements as facts and start treating them as hypotheses.

"We need a notification system" is a hypothesis. It says: "I believe that notifications will solve the decision-bottleneck problem." That hypothesis might be right. It might also be wrong. The only way to know is to examine it before building.

This is where the SURFACE stage of excavation earns its keep. Every requirement has embedded assumptions:

• "We need a notification system" assumes notifications are the right intervention
• It assumes people will act on notifications (they often don't)
• It assumes the problem is awareness, not authority or incentive
• It assumes a technical solution will fix an organizational problem

Surface these assumptions before building and you save weeks of wasted effort. Skip this step and you'll discover them mid-sprint, when they show up as "scope changes" and "new requirements."

Excavation as engineering practice

I'm not proposing a heavyweight process. I'm proposing a 30-minute conversation before the sprint planning meeting.

Take the top item on the backlog. Before anyone estimates it, excavate it:

STATE -- What problem does this requirement claim to solve? Write it down in one sentence. If the team can't agree on the sentence, that's already a finding.

SURFACE -- What assumptions are embedded in this requirement? List them. Don't judge them yet. Just name them.

DRILL -- For each assumption, ask: is this actually true? Do we have evidence? The drill uses specific options, not open-ended "why?" questions. Options force you to confront what you'd rather avoid.

PATTERN -- Have we seen this kind of requirement before? What happened? If you've built notification systems before and nobody used them, that's a pattern worth acknowledging before you build another one.

CHALLENGE -- We think we understand the real problem. What would prove us wrong?

PHYSICS -- What's the irreducible truth? The thing that, if it changed, would make the entire requirement unnecessary?

FORK -- Given the physics, what are our actual options? The original requirement might be one. It might not be the best one.

The multiplier effect

Here's what makes this powerful in a team setting: different roles see different parts of the problem.

The CTO sees: "Engineering is slow." The product lead sees: "Requirements keep changing." The tech lead sees: "We keep rebuilding features." They're all looking at the same root cause from different angles. Individually, each sees a symptom. Together, the root causes connect.

When a CTO excavates "engineering is slow" and the product lead excavates "requirements keep changing," the physics often converge. The CTO's irreducible truth connects to the product lead's irreducible truth. Suddenly, instead of three separate problems, there's one systemic issue -- and it's solvable.

This is the Problem Map: the connected graph of root causes that emerges when multiple people excavate the same system from different vantage points.

The most productive 30 minutes

The most productive thing an engineering team can do is spend 30 minutes excavating the problem before writing a single line of code. Not brainstorming solutions. Not estimating. Not designing. Excavating.

The issue isn't execution. Your team executes beautifully. The issue is that nobody excavated the requirement before handing it to the team that builds things for a living.

Stop building the wrong thing. Start excavating the right problem.

---

Try it yourself

The gallery has real excavation sessions where CTOs worked through problems like this. See the method in action, then start your own excavation.