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 fall short, the explanation often centers on execution: the team moved too slowly, the technology did not scale, marketing failed to create demand, the launch was poorly managed—or, most troublingly, “customers just didn’t get it.” Sometimes those explanations are true. But in many cases, execution is not 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 form beliefs about customer needs, market opportunities, competitive threats, and the outcomes their investments will create.

The problem is not that assumptions exist; innovation depends on them. The problem is that organizations stop treating them like assumptions, allowing confidence to develop faster than new information.

Closing the Assumption Gap requires a different allocation of attention and effort. Before teams invest deeply in execution, they need to make the beliefs beneath a decision visible, identify which assumptions carry the greatest risk, and determine what they need to learn before making a deeper commitment.

How Organizations Fall Into the Gap

During a major platform reimagining, what initially appeared to be a disagreement about talking to customers revealed a deeper disagreement about whose perspectives the organization trusted when interpreting customer challenges and needs.

I repeatedly pushed to speak directly with customers. The response was consistent: I first needed to better understand the existing product. On the surface, that sounded reasonable. Product knowledge matters. Yet customer access remained off the table while decisions about the product continued moving forward, and internal stakeholders increasingly became the primary source of truth about customer needs and priorities.

Looking back, the problem was not product expertise itself, but the assumption that understanding the product was equivalent to understanding the customer.

Those most familiar with the legacy system carried the most authority, leaving less room for customers or newer perspectives to challenge established beliefs. Product knowledge had begun replacing the work of learning what customers actually valued.

This was not just one disagreement about customer access. The same underlying belief showed up in other decisions:

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

Each choice seemed reasonable on its own. Together, however, they reinforced what the organization already believed and left fewer opportunities to learn something new from customers.

Learning the product, the domain, and the history of a business is valuable. The problem emerges when learning about the system begins to replace learning from the system.

Expertise in the existing system explains why things are the way they are. Evidence reveals whether they should stay that way.

This is how the Assumption Gap forms.

Expertise and Evidence

Two ways organizations learn

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

An internal expert describes what customers need based on years of experience with the legacy product. The perspective carries authority, so the team moves forward without seeking direct customer input. As the same belief passes through strategy discussions, requirements, design critiques, and roadmap decisions, it stops sounding like an assumption and begins functioning as fact.

Once the belief is accepted as fact, the work shifts from questioning it to executing against it. Designers and other teams are measured by what they produce—designs completed, milestones met, and features shipped—not by the uncertainty they reduce. Discovery gives way to delivery, exploration gives way to planning, and the assumption becomes a commitment.

In 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 that certainty gets manufactured—not through new information, but through familiarity.

Familiarity creates confidence. New information creates understanding. As organizations seek less of it, their existing confidence makes further learning appear less necessary.

Organizations do not fall into the Assumption Gap because they lack knowledge. They fall into it because existing knowledge gradually becomes a substitute for new learning.

When Assumptions Become Knowledge

By the time delivery begins, the original assumption may no longer be visible. It now appears as a backlog requirement, an epic, an estimate in a planning meeting, a roadmap commitment, a promised delivery date, or a design direction being refined in critique.

The solution is repeatedly reviewed by internal stakeholders, creating the appearance of validation even though the people expected to use it may never have confirmed the belief beneath it. Each discipline then begins optimizing a different part of the same unproven theory.

In Escaping the Build Trap, Melissa Perri describes the organizational focus on producing features rather than outcomes as the “build trap.” The Assumption Gap helps explain how teams enter it: uncertain beliefs become accepted knowledge, accepted knowledge becomes commitment, and commitment shifts attention from learning to delivery.

The gap can also exist between teams. An organization may appear aligned around a feature while product, engineering, design, and leadership hold different assumptions about why it is being built, how well the customer problem is understood, and how much uncertainty remains.

Product may believe it has defined the solution before validating the problem or testing the approach. Engineering may treat that decision as final and begin estimating it. Design may still see the problem and solution as open for exploration, while leadership interprets the roadmap entry as evidence that the organization has aligned.

The teams appear aligned around an output, but they are operating from different assumptions about what has actually been decided.

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.

That misalignment often becomes visible once a feature is treated as the answer.

A dashboard assumes the metrics it surfaces will change behavior. A recommendation engine assumes customers will engage with its suggestions. A workflow assumes customers will recognize the problem it was designed to solve and adopt a new way of working. These are not simply solutions; they are assumptions about how customers will respond.

Once a feature is proposed, the conversation often shifts quickly to implementation, scalability, timelines, and delivery. A dashboard becomes an epic, the epic receives estimates, design begins refining the experience, and engineering starts making architectural decisions.

Questions about customer value are deferred with the reassurance that “we’ll test it later.” But by the time later arrives, the organization may already have invested enough in the solution that testing is more likely to improve it than challenge whether it should exist. The longer the underlying assumptions remain untested, the more expensive they become to revisit.

In The Design Cycle of Doom, I described how design often enters after key decisions have already been made. At that point, testing is usually framed around usability, comprehension, and refinement—not whether the team chose the right problem or solution.

Once assumptions become accepted as knowledge, exploration no longer feels necessary. Design is invited to refine the answer rather than investigate whether the organization is answering the right question.

The Cost

A proposed workflow begins as an idea. Engineering starts debating architecture and scalability. Product turns it into delivery plans and milestones. Design spends weeks refining interactions, while business leaders react to timelines, deadlines, and commitments already made. Each function pushes the solution forward, even though its value to customers may still be unproven.

Some costs are visible, including rework, delays, and abandoned development. Others accumulate more quietly through unused features, poor adoption, increased support burden, missed opportunities, and the design or technical debt created by extending a solution that never fully fit the problem.

The original assumption may have been inexpensive to challenge while the idea was still flexible. It becomes more costly as estimates, designs, technical decisions, timelines, and expectations accumulate around it.

Assumptions become expensive when they become commitments before they are tested.

The Cost of Late Learning

As an idea moves from concept to roadmap commitment, more decisions accumulate around it. A belief that could have been tested through a conversation or lightweight experiment may later require changes to architecture, workflows, staffing, launch plans, and promises already made.

At that point, the organization is no longer reconsidering only an idea. It is reconsidering everything built around it.

Strong Teams Manage Assumptions Before Commitments

Teams focused primarily on delivery ask: “What should we build?” Teams focused on reducing uncertainty ask: “What needs to be true for this idea to create value?”

That question exposes the beliefs connecting a proposed feature to its intended outcome:

• Customers experience the problem and care enough to seek a solution.
• The proposed solution meaningfully addresses the problem.
• Customers can understand, use, and adopt it.
• Adoption creates value for both the customer and the business.

Each link is an assumption. Strong execution cannot compensate when one of the critical links proves false.

I have seen customer-validation sessions canceled days before they were scheduled because the software was not ready. But the purpose of the session was not to evaluate finished software. It was to test whether the assumptions guiding the work were sound.

Waiting until the solution was ready changed the purpose of validation. Instead of asking whether the team should continue pursuing the idea, testing became an evaluation of how well the team had executed it.

The Value of Earlier Learning

Assumptions are not a flaw in innovation. They are the starting point. The challenge is to test the assumptions carrying the greatest risk before teams make expensive commitments around them.

In The UX Paradox, I argued that some of the most valuable work in organizations is invisible. A feature that is never built does not appear in a product release. A costly change avoided through earlier learning does not appear on a roadmap. An investment redirected before development rarely looks as productive as a launched feature.

Yet preventing an organization from scaling the wrong solution may create more value than executing that solution efficiently.

Closing the Gap in Practice

Closing the Assumption Gap is an organizational practice, not simply a mindset. In my work, it begins before the roadmap is written by exposing, prioritizing, testing, and reassessing the beliefs beneath a proposed investment.

Expose the Assumptions

I facilitate structured conversations with product, engineering, design, and business stakeholders to identify what the team believes about the customer, what it is treating as established fact, and what has not yet been tested.

Making those beliefs visible changes the conversation. Teams can distinguish real alignment from agreement around a preferred solution and identify where different functions are operating from different assumptions.

Prioritize the Uncertainty

Not every assumption deserves equal attention. The focus should be on beliefs that could cause the initiative to fail, become prohibitively expensive, or create little customer or business value.

Teams can ask:

• Which belief would most seriously undermine this initiative if it proved false?
• Which important assumption has the weakest support?
• Which decision will become most expensive to reverse?
• What are we relying on customers to understand, adopt, or change?

These questions shift attention from how strongly people support an idea to how much confidence the available information justifies.

Generate Proportionate Learning

Not every assumption requires a formal research study. A customer conversation, lightweight prototype, behavioral-data review, or technical experiment may be enough to inform the next decision.

The objective is not to add process. It is to redirect a small portion of the effort normally spent refining a solution toward determining whether that solution deserves deeper investment.

Teams do not need certainty. They need enough information to proceed, adjust, reduce the commitment, or investigate further.

Reassess Before Commitment

I pay particular attention to the point when a rough idea becomes a roadmap entry. Once it appears on the roadmap, teams estimate it, leaders communicate it, engineering considers its architecture, and design begins refining its workflows. The conversation gradually shifts from whether the idea is justified to how quickly it can be delivered.

A brief checkpoint before that transition allows the team to revisit what must still be true, identify what it can learn quickly, and decide whether deeper investment is warranted.

The result is not more discovery for its own sake. It is more deliberate commitment.

Building a System That Rewards Learning

Individual curiosity is not enough. Teams must be able to question assumptions without appearing indecisive, and leaders must reward learning even when it challenges a favored idea. Roadmap processes need moments when uncertainty can be discussed before commitments become difficult to reverse.

Otherwise, organizations will continue rewarding the appearance of progress—requirements completed, estimates produced, designs delivered, and features shipped—while overlooking the value of determining whether those investments were justified.

That is the shift I help teams make: treating learning not as an activity that happens before delivery, but as part of deciding what deserves delivery.

Conclusion

Every feature is a hypothesis. Every roadmap is a theory. Every strategy rests on assumptions about customers, markets, behavior, and value.

Assumptions are not the enemy. The danger begins when they stop being treated as assumptions. The question is not whether your strategy contains them. It does. The question is whether you know where they are—and whether you are paying to learn before delivery or after it.

The work of product and design leadership is not to remove uncertainty. It is to make uncertainty visible early enough that teams can align around what they know, learn what they do not, and commit resources with greater confidence.