The Assumption Gap

Assumptions always have a cost.

Organizations can pay through learning, through rework, or through building things nobody needed in the first place.

When products fail, the explanation is often blamed on execution.

The team moved too slowly. The technology didn’t scale. Marketing failed to create demand. The launch was poorly managed.

Sometimes those explanations are true.

But in many cases, execution isn’t where failure begins.

Failure begins much earlier—when assumptions are mistaken for knowledge.

Long before a feature is designed, a line of code is written, or a roadmap commitment is made, organizations make assumptions about customer needs, market opportunities, competitive threats, and the outcomes their investments will create.

The problem isn’t that these assumptions exist. Innovation depends on them.

The problem is that we stop treating them like assumptions.

The easy conclusion, when things go wrong, is that teams failed to execute.

I think the deeper explanation is that organizations became confident before they became informed.

They committed to ideas before converting their assumptions into evidence.

How Organizations Fall Into the Gap

During a major platform reimagining, I repeatedly pushed to speak directly with customers. The response was consistent: I needed to better understand the existing product. Yet customer access remained off the table while strategic decisions continued moving forward. On the surface, that sounded reasonable. Product knowledge matters. But over time I noticed something else.

Internal stakeholders had become the primary source of truth about customers. Existing domain knowledge carried more weight than direct customer evidence.

Looking back, the issue wasn’t expertise. It wasn’t a lack of intelligence, experience, or good intentions. It was an assumption.

The assumption that understanding the product was equivalent to understanding the customer.

The organization wasn’t treating product knowledge as preparation for learning. It was treating product knowledge as a substitute for it. The more expertise accumulated, the more authority it carried—and the less room remained for new evidence to challenge it.

What made this experience interesting wasn’t the decision itself. It was how many other decisions reflected the same underlying belief.

The same pattern appeared elsewhere:

• New team members were tested on their knowledge of the legacy software rather than engaging with customers.
• Hiring often favored candidates with existing domain knowledge over those with fresh perspectives or complementary skills.
• Internal stakeholders were viewed as authoritative sources of customer needs.
• Strategic decisions moved forward without creating opportunities to challenge underlying assumptions.

None of these decisions were irrational on their own.

Together, however, they created a system optimized for reinforcing existing knowledge rather than generating new knowledge. The organization didn’t resist learning. It simply trusted what it already knew more than what it had yet to discover.

To be clear, learning the product, the domain, and the history of a business is valuable. Teams need context. The problem emerges when learning about the system begins to replace learning from the system.

Expertise explains why things are the way they are.
Evidence determines whether they should stay that way.

This is how the Assumption Gap forms.

Expertise vs. Evidence

Two ways organizations learn

Expertise explains why things are the way they are. Evidence determines whether they should stay that way.

Organizations become increasingly confident in what they know while creating fewer opportunities to discover what they don’t.

Over time, assumptions stop feeling like assumptions.

They begin to feel like facts.

Once something feels like a fact, organizations stop investing in learning and start investing in execution. Discovery gives way to delivery. Exploration gives way to planning. Evidence gives way to commitment.

In my article on The Outcome Certainty Trap, I argued that organizations often seek certainty before they have enough information to justify it.

The Assumption Gap is one way certainty gets manufactured—not through evidence, but through familiarity. Familiarity creates confidence. Evidence creates understanding. The less we seek one, the less necessary the other appears.

Organizations don’t fall into the Assumption Gap because they lack knowledge. They fall into it because existing knowledge gradually becomes a substitute for new evidence.

That’s how assumptions become facts.

When Assumptions Become Knowledge

By the time a team begins delivery, many of the most important assumptions are no longer visible.

One of the most common assumptions in product development is that features naturally create benefits.

Every feature is a hypothesis. The benefit is what still needs to be proven.

A recommendation engine assumes customers will engage with its suggestions. A dashboard assumes the metrics it surfaces will change behavior. A workflow assumes customers have the problem it was designed to solve. These aren’t solutions—they’re theories.

Once a feature is proposed, organizations often begin discussing implementation, scalability, timelines, and delivery. Rarely do they stop to examine the chain of assumptions connecting the feature to the outcome they hope to achieve.

In The Design Cycle of Doom, I described how design often enters the process after key decisions have already been made.

Once assumptions become accepted as knowledge, exploration feels unnecessary.

The Cost

Yet organizations routinely invest enormous effort optimizing solutions before validating the assumptions beneath them.

Engineering teams debate scalability, architecture, and performance for solutions whose value has never been established.

Product teams invest more effort planning delivery than reducing uncertainty.

Detailed revenue projections are created for initiatives supported by less customer evidence than a usability test.

Design teams spend weeks refining workflows before confirming they’re solving the right problem.

Some costs are visible, such as rework and delays. Others appear more quietly through unused features, missed opportunities, the support burden of features that don’t fit, or investments that never deliver their intended value.

Assumptions are cheap. Challenging them is cheap.

Assumptions become expensive when they’re converted into commitments before they’re converted into evidence.

The Cost of Late Learning

High-Performing Teams Treat Assumptions Differently

Average organizations ask: “What should we build?”

High-performing organizations ask: “What must be true for this idea to succeed?”

• Customers have this problem.
• Customers care about this problem.
• Our solution addresses it.
• Customers can use it.
• Customers will adopt it.
• The business benefits.

I’ve seen customer validation sessions canceled days before they were scheduled because the software wasn’t quite ready. The irony was that the purpose of the session wasn’t to validate the software. It was to validate the assumptions behind it.

The Transition to Evidence

Assumptions aren’t a flaw in innovation. They’re the starting point.

The challenge isn’t eliminating them. The challenge is building systems that convert assumptions into evidence before they become expensive commitments.

In The UX Paradox, I argued that some of the most valuable work in organizations is invisible.

Exposing flawed assumptions before delivery may be one of the most valuable—and least visible—contributions a team can make.

Conclusion

Every feature is a hypothesis. Every roadmap is a theory. Every strategy is an assumption about how the world works.

Assumptions are not the enemy. The danger begins when they stop being treated as assumptions.

The question isn’t whether your strategy contains them. It does. The question is whether you know where they are—and whether you’re paying to find out before delivery, or after it.