Identifying Hidden Assumptions

Every Product Failure Is a Failed Assumption Nobody Tested

Behind every product failure is a chain of assumptions that seemed so obvious they were never questioned. The team assumed customers would pay for the feature. They assumed the technical architecture would scale. They assumed the market timing was right. None of these assumptions were tested until it was too late.

Teresa Torres, in her Continuous Discovery Habits framework, identifies assumption testing as the single most impactful practice a product team can adopt. According to her research, teams that explicitly identify and test assumptions before building are 3x more likely to achieve their desired outcomes.

The Problem

Assumptions hide in plain sight. They are embedded in user stories ("As a user, I want to..." assumes someone actually wants this). They are embedded in technical estimates ("This will take two sprints" assumes no unexpected dependencies). They are embedded in business models ("Users will upgrade to the paid tier" assumes the free tier has meaningful limitations).

The most dangerous assumptions are the ones the team shares. When everyone believes something, nobody thinks to test it. These shared blind spots are responsible for the largest product failures -- not edge cases or obscure risks, but fundamental misunderstandings that the entire team accepted as truth.

According to a 2023 study by the Product Development and Management Association, the average success rate for new products is approximately 40%, meaning more products fail than succeed. The primary predictor of failure is not execution quality but flawed assumptions about customer needs and market dynamics.

How This Prompt Works

The Identifying Hidden Assumptions prompt uses Teresa Torres's assumption mapping framework to surface the beliefs your product plan depends on. You input your product strategy, feature plan, or user story, and the prompt extracts every assumption embedded in it.

Assumptions are categorized across four dimensions: desirability (will customers want this?), viability (will this create business value?), feasibility (can we build this?), and usability (can customers figure out how to use this?). Each assumption gets a risk rating based on how much damage it would cause if wrong and how uncertain the team is about it.

The prompt then generates lightweight test designs for the highest-risk assumptions -- experiments you can run in days, not months, to convert assumptions into knowledge.

When to Use It

• Before writing a PRD to ensure the foundation is sound
• When a project feels risky but the team cannot articulate why
• During opportunity assessment to evaluate which bets have the most untested assumptions
• After a failed launch to practice identifying assumptions retroactively and build the skill

Common Pitfalls

Testing only the easy assumptions. Teams gravitate toward assumptions that are cheap to test and avoid the ones that would be painful to disprove. The most important assumption to test is the one you are most afraid to be wrong about.

Confusing opinions with tests. Asking five colleagues whether they think an assumption is valid is not a test. A test produces evidence from the target market using methods that could genuinely disprove the assumption.

Analysis paralysis. Not every assumption needs testing. Focus on the ones that are both high-risk and high-uncertainty. If an assumption is well-supported by existing data, move on. According to Marty Cagan of the Silicon Valley Product Group, the best teams test their riskiest assumptions first rather than trying to validate everything.

Sources

• Continuous Discovery Habits - Teresa Torres
• New Product Success Rates - PDMA
• Assumption Testing - Silicon Valley Product Group