A product strategy isn't a single claim to defend — it's a stack of unproven beliefs about customers, markets, and capabilities. Name every assumption, rank each by importance and uncertainty, and turn the riskiest one — the leap-of-faith assumption — into your next experiment before it quietly makes the decision for you.
Quick answer: Treat your strategy as a set of testable beliefs, not a fixed plan. Build an assumption map, score each belief by importance × uncertainty, and de-risk the highest-scoring one first — that's the leap-of-faith assumption Eric Ries named in The Lean Startup.
Every Strategy Is a Stack of Unproven Beliefs
A strategy document reads like a conclusion, but every line in it hides a claim you haven't yet proven — about what customers want, what they'll pay, and what your team can actually build. Naming those claims as assumptions, instead of treating them as settled facts, is what separates a strategy you can adapt from one you can only defend.
This isn't a semantic trick. In The Lean Startup, Eric Ries described every new venture as running on leap-of-faith assumptions — the handful of beliefs that, if wrong, invalidate the entire plan, distinct from the dozens of smaller assumptions that barely matter. Ries split these into a value hypothesis (will customers want this) and a growth hypothesis (will the business scale once they do). Most strategy decks conflate the two and test neither.
Rita McGrath and Ian MacMillan made a similar case decades earlier in their Harvard Business Review work on discovery-driven planning: instead of writing a plan and then hunting for evidence to support it, they argued teams should write down the assumptions the plan requires to be true, then design the cheapest possible checkpoints to test them — before, not after, the capital is spent. That ordering is the entire point.
The cost of skipping this step shows up in failure data, not just theory. CB Insights' long-running analysis of startup post-mortems has repeatedly found "no market need" near the top of founders' self-reported reasons for failure — cited in roughly a third of the cases it tracks. Not a broken feature. Not a competitor. A desirability assumption nobody tested until the business ran out of runway to fix it.
Two things follow from treating strategy this way:
- You stop defending the plan and start de-risking it. A strategy conversation shifts from "is this the right call" (unanswerable in the room) to "which belief, if wrong, breaks the plan, and how do we find out cheaply" (answerable this week).
- You separate what's early-stage from what's already proven. The full framework for building a defensible strategy — including how to sequence bets and set a strategic direction in the first place — is covered in our complete guide to product strategy; this piece is about the discipline of pressure-testing whatever strategy you've already committed to on paper.
The mix of assumptions also shifts depending on where the strategy sits on the growth curve. A brand-new product is mostly betting on desirability — does anyone want this at all. A scaling product is mostly betting on viability and distribution — will this specific expansion pay back without breaking what already works. That distinction is worth getting right before you map anything, and it's the core split covered in our comparison of zero-to-one versus scaling strategy.
Build an Assumption Map for Your Strategy
An assumption map lists every belief your strategy quietly depends on, grouped so nothing stays implicit — typically split into desirability (will customers want it), feasibility (can you build and deliver it), and viability (does it make business sense). The grouping matters because each category fails differently and gets tested with different tools.
That three-way split comes from David J. Bland and Alexander Osterwalder's Testing Business Ideas, which formalized the Assumptions Map as a standalone artifact separate from the strategy or business model it supports. The point of a dedicated map, in their framing, is that a strategy deck buries assumptions inside prose and bullet points where nobody can rank or challenge them individually.
Here's a worked example. Say the strategy is: a B2B workflow-analytics company, sold today only through annual, sales-led enterprise contracts, will launch a self-serve tier at $49/user/month, billed by credit card, aimed at mid-market operations teams who currently only get access when their VP signs an enterprise deal.
| # | Assumption | Category | Why the strategy depends on it |
|---|---|---|---|
| 1 | Mid-market managers will evaluate and buy without talking to sales | Desirability | The entire self-serve motion assumes buyers are willing and able to self-qualify |
| 2 | Mid-market teams have enough workflow complexity to need this at team scale | Desirability | If value only shows up at enterprise-wide deployment, a team tier has nothing to sell |
| 3 | $49/user/month clears an individual manager's expense threshold | Viability | Self-serve pricing only works if it skips the procurement chain the enterprise tier requires |
| 4 | New teams reach first value in under a day with zero CS involvement | Feasibility | The support-cost model for self-serve assumes near-zero white-glove onboarding |
| 5 | Support and infrastructure absorb signup volume without enterprise-grade hand-holding | Feasibility | Unit economics assume support cost per self-serve account is a fraction of enterprise cost |
| 6 | Self-serve won't let departments route around existing enterprise contracts | Viability | Cannibalizing negotiated enterprise revenue turns the tier into a loss, not a growth channel |
| 7 | Self-serve accounts expand into larger contracts over time | Viability | The tier's long-term math depends on expansion revenue, not just entry-level fees |
Notice what the map does that the strategy slide never could: it turns "launch a self-serve tier" from one decision into seven falsifiable claims, each ownable, testable, and wrong in its own particular way.
Desirability assumptions like #1 and #2 are really claims about customer behavior and motivation — which is exactly the terrain a JTBD interview is built to probe. If you haven't validated why a mid-market manager would reach for this tool at all, our Jobs to Be Done complete guide is the sharper tool for that specific assumption, not a generic customer survey.
Assumptions about the buying moment itself are a different animal — where in a manager's day-to-day the need surfaces, and what triggers the search for a fix. Those are worth mapping against a customer journey, so you can see where the self-serve flow has to intercept an existing habit instead of creating a new one from scratch.
Rank Assumptions by Importance and Uncertainty
Not every assumption on the map deserves equal attention. Plot each one on importance (how much the strategy depends on it being true) against uncertainty (how little evidence you currently have) — the assumption in the high-importance, high-uncertainty corner is your leap-of-faith assumption, and it goes first.
This is the ranking step teams skip, and it's the one that turns a list of worries into a sequenced learning agenda. Teresa Torres, in Continuous Discovery Habits, makes the same case at the level of individual product bets: an opportunity or solution is worth almost nothing to discuss further until you've surfaced the assumption underneath it that would kill the idea if false, and tested that one first.
Strategyzer's Value Proposition Canvas work runs the identical logic one layer up, at the level of an entire value proposition rather than a single feature. Either way, the mechanism is the same: rank before you test, so the team's limited experiment capacity goes to the belief that can actually sink the strategy.
Score each assumption from the map above on a simple 1–3 scale for both axes, multiply, and sort:
| # | Assumption (short) | Importance | Uncertainty | Score | Verdict |
|---|---|---|---|---|---|
| 1 | Buy without a sales conversation | High (3) | High (3) | 9 | Leap-of-faith — test first |
| 3 | $49 clears the expense threshold | High (3) | Medium (2) | 6 | Test soon |
| 4 | First value in a day, no CS | High (3) | Medium (2) | 6 | Test soon |
| 7 | Expansion over time | Medium (2) | High (3) | 6 | Test, but after launch |
| 2 | Team-scale complexity is enough | Medium (2) | Medium (2) | 4 | Light test, low urgency |
| 6 | No cannibalization | High (3) | Low (1) | 3 | Monitor, revisit if data shifts |
| 5 | Support absorbs volume | Medium (2) | Low (1) | 2 | Monitor |
The table earns its keep here: it's the difference between "we have concerns about this launch" and "assumption 1 is nine times riskier than assumption 5, so it gets the team's attention this sprint and the rest wait." Rank-ordering also protects against a common failure mode — testing whichever assumption is easiest to test, rather than the one that actually threatens the strategy.
It's worth zooming out one more level before you commit resources to testing: an assumption map tells you what you believe about your own strategy, but it doesn't show you the competitive terrain those beliefs sit on — how commoditized a capability is, or whether a component you're relying on is about to become table stakes. Wardley Mapping is the complementary tool for that view, and pairing the two is covered in our guide to seeing the whole competitive board with Wardley Mapping.
Turn the Riskiest Assumption Into Your Next Experiment
Once you've identified the leap-of-faith assumption, design the cheapest test that could prove it false, with a threshold you commit to before you see the results — not a feature build, a fake-door test, a concierge pilot, or a smoke-test landing page sized to the specific claim you're worried about.
For the self-serve example, the leap-of-faith assumption was #1: mid-market managers will buy without a sales conversation. You do not need to build, price, and ship a full self-serve product to learn whether that's true. You need the smallest artifact that forces a real buying decision:
- Fake-door test: a pricing page with a working "Start now" button that ends at a checkout page collecting intent (and, ideally, a card) before anything is actually provisioned. Success threshold: a defined click-to-intent conversion rate from qualified traffic, agreed before launch.
- Concierge pilot: manually onboard 10–15 mid-market prospects through a self-serve-feeling flow that you operate by hand behind the scenes. You're testing willingness to buy without sales, not your automation.
- Smoke-test outreach: a direct offer to a segment of mid-market leads currently stuck waiting for an enterprise deal cycle, with an explicit self-serve price and no salesperson in the loop.
Alberto Savoia's pretotyping work (later published as The Right It) is useful here for the discipline of writing the hypothesis down in an unambiguous, falsifiable form before running any of the above — his XYZ hypothesis format ("we believe that at least X% of Y will Z") forces a number and a deadline into a claim that would otherwise stay comfortably vague.
Write the hypothesis as: "We believe mid-market ops managers will complete self-serve checkout without contacting sales. We'll know we're right if at least 8% of qualified pricing-page visitors reach checkout within 30 days."
This is also where most strategies quietly die — not in the planning room, but in the gap between what the deck said and what the team actually does next sprint. A leap-of-faith assumption identified and never scheduled as a test is functionally the same as an assumption never named at all; it's the exact failure mode we break down in the gap between a strategy deck and daily execution. Ranking assumptions only pays off if the top-ranked one becomes a ticket, not a footnote.
Track Assumptions Over Time, Not as a One-Time Workshop
An assumption map isn't a deliverable you produce once during a planning offsite — it's a living log, because the evidence underneath your riskiest beliefs keeps arriving whether or not you're watching for it. Each assumption needs an owner, a date, and a verdict that updates as experiments land: holding, weakening, or retired.
Most teams do the mapping exercise once, feel good about it for a quarter, and then let the strategy calcify back into a set of assumed facts by the next planning cycle. The map's value compounds only if it's revisited on a cadence — commonly tied to whatever review rhythm already exists (quarterly strategy reviews, monthly roadmap checkpoints) rather than invented as a new ritual nobody attends.
A practical cadence:
- At the moment a belief surfaces — in a customer call, a stakeholder debate, a strategy review — log it immediately, before it either gets forgotten or silently hardens into "fact."
- When an experiment resolves, update the assumption's status and, critically, note what the evidence actually showed, not just pass/fail.
- At each planning cycle, re-sort the map: yesterday's low-uncertainty assumption can become high-uncertainty again the moment market conditions shift underneath it.
This is the exact gap Prodinja's Journals are built to close. Journals let you capture an Assumption entry the moment it surfaces — typed, or spoken through real browser-based voice input when you're mid-conversation and don't want to break flow to type — so the belief gets logged where it was actually said, not reconstructed from memory in a retro two weeks later. From there, each entry stays revisitable and gets retired explicitly as evidence arrives, instead of quietly forgotten in a slide nobody reopens.
Key Takeaways
- A strategy is a stack of assumptions, not a single claim — naming each one turns an unfalsifiable debate into a ranked, testable agenda.
- The leap-of-faith assumption, a term from Eric Ries's
The Lean Startup, is the belief that would invalidate the entire strategy if wrong — find it before you fund anything downstream of it. - Build an assumption map grouped by desirability, feasibility, and viability (per David J. Bland and Alexander Osterwalder's
Testing Business Ideas) so each belief gets tested with the right tool, not a generic survey. - Score importance × uncertainty for every assumption and sort; the highest score is what gets tested next, regardless of what's easiest to test.
- Design the cheapest possible experiment — fake door, concierge pilot, smoke test — with a falsifiable threshold set before you look at results, using Alberto Savoia's
XYZ hypothesisformat to keep the claim precise. - Assumption mapping only works as a living log, revisited on a real cadence, not a one-time workshop artifact that calcifies by next quarter.
- What counts as "risky" shifts with where the strategy sits on the growth curve — a new bet is mostly desirability risk, a scaling bet is mostly viability and distribution risk.
Frequently Asked Questions
What is a leap-of-faith assumption in product strategy?
A leap-of-faith assumption is the belief your strategy can't survive being wrong about — the term comes from Eric Ries's The Lean Startup. Unlike minor assumptions that barely move the outcome, it sits in the high-importance, high-uncertainty corner of an assumption map and should be the first thing you test, not the last.
How is assumption mapping different from a risk register?
A risk register typically catalogs threats to execution (budget, timeline, resourcing) after a strategy is set; an assumption map catalogs the unproven beliefs the strategy itself is built on, before you've committed resources. The two are complementary — a risk register assumes the strategy's premise is correct and asks what could go wrong; assumption mapping questions the premise itself.
How often should you revisit strategic assumptions?
Revisit assumptions whenever an experiment resolves, and on whatever planning cadence your organization already runs — commonly quarterly for the full map, with high-uncertainty items checked sooner. An assumption's status isn't permanent: evidence that made something "holding" this quarter can reverse the next as markets, competitors, or customer behavior shift.
Can assumption mapping work for a product that's already scaling, not just a new one?
Yes — the technique applies at any stage, though the assumptions themselves change character. An early-stage strategy carries mostly desirability risk (does anyone want this); a scaling strategy carries mostly viability and distribution risk (will this specific expansion pay back without cannibalizing what already works) — a different risk profile than a first-time launch, but the same mapping and ranking discipline applies either way.
What's the fastest way to test a risky assumption without building the full feature?
Use the smallest artifact that forces a real decision from a real prospect: a fake-door pricing page, a manually operated concierge pilot, or a smoke-test offer to a narrow segment. Set the success threshold — a specific conversion rate or response rate — before you launch the test, so the result can't be quietly reinterpreted afterward to match what you wanted to hear.