Part two of four on the assumptions under your Decision Stack. Part one, Assumption #1: If our strategy is coherent, it's right., argued that every layer of your stack has assumptions underneath it. You don't need to have read it.
Watch a good product team run discovery and it's impressive. They'll talk to customers, form a hypothesis, map the assumptions under it, build a prototype, put it in front of five customers, run a fake door test, and then argue for forty minutes about whether five is a big enough sample.
Now watch the same organisation commit to a twenty-year vision because somebody had a strong feeling at an offsite in Lisbon.
I've sat in both of those rooms. In thirty years I have never once been asked what would have to be true for a vision to work, but I have been asked to justify a two-week build more times than I can count.
Jeff Bezos gave us the language for why that's the wrong way round. Some decisions are one-way doors, and those "must be made methodically, carefully, slowly, with great deliberation and consultation." But most decisions are two-way doors. You walk through, and if you don't like what's on the other side, you can walk back and pick another door.
An assumption at the bottom of your stack is a two-way door. You built the wrong thing, you learned something, you build a different thing next week.
An assumption at the top is a one-way door. It sets the direction everything else inherits, and by the time it fails you've spent three years and a balance sheet finding out.
Our entire discipline is pointed at the two-way doors.
(The inverse failure exists too, and in big organisations it's the more common one: treat every decision as a one-way door, debate it for six months, then carry on exactly as before without testing any of it. Treating a decision as consequential and actually testing it turn out to be very different habits.)
This isn't a criticism of the tools
The tools are excellent and I use them. Janice Fraser, David Bland, Alex Osterwalder, and others gave us assumption mapping. Teresa Torres hung assumption tests off the opportunity solution tree. Marty Cagan gave us the four risks. This is some of the best thinking our craft has produced, and between them they've saved an enormous amount of wasted engineering.
My only criticism is of the altitude we use these tools at. And the altitude has a cause.
David Bland is honest about where his own work came from: "I wasted years of my life building things nobody wanted." That's a wound you get at the bottom of the stack, standing next to something you shipped that nobody used. I have it too. And the methods that grew out of that pain were built looking out from that eye level.
David got here before I did. When we talked about this on his How I Tested That podcast, his own summary of his work was that if you strip the frameworks away, it's about whether we can talk openly about assumptions at all. So this isn't me pointing at a blind spot. It's me adding a map to an argument he's already making, because knowing that assumptions live at every layer tells you where to point the tools next.
You can see it in the artefacts
On the opportunity solution tree, assumption tests are the leaves. They hang off solutions, which hang off opportunities, which hang off a desired outcome that arrives from strategy already decided. The tree is rigorous all the way up to the point where somebody senior made a choice, and then it stops.
Every one of Cagan's four risks contains the word solution, product, or user. Value, usability, feasibility, viability. All four are questions about the thing being built.
Strategyzer's innovation scorecard is the sharpest example, because it does both things in one document. It demands evidence from multiple experiments before a team gets funded, and then scores "strategic fit" as alignment with the company vision. So the team's beliefs have to be evidenced. Leadership's are the ungraded input.
None of this was a conspiracy. Every one of these people built a tool for the problem in front of them, and the problem in front of them was at the bottom of the Decision Stack. But we've now spent decades getting very good at interrogating the decisions that cost the least to get wrong.
Your call recordings are a record of the past
There's a second reason the toolkit doesn't just lift straight up, and it's mechanical rather than cultural.
Solution assumptions can be tested against what customers already do. You have the call recordings, the support tickets, the usage data, the five people you can put a prototype in front of. Strategy assumptions are bets on a world that doesn't exist yet. What would have to be true about your market in three years is not in your call recordings, because your call recordings are a record of the past.
Test a forward-looking bet against backward-looking evidence and you'll get a confident answer. It just won't be about the future. The data can't tell you how customers will react to something they can't even imagine yet.
The tests all came back clean
At Huddle we had a good vision and a terrible strategy. We believed collaboration meant having all the tools in one place, so we set out to build the full suite: file sharing, chat, task management, whiteboarding, the lot. Spreading ourselves across five products meant we couldn't build any one of them exceptionally well, while better-funded competitors focused on just one. Dropbox and Box ate our lunch on file sharing. Then Slack came along and ate our dinner on chat. We tried to boil the ocean and ended up with lukewarm water.
No amount of solution-layer discovery would have caught that. Customers did want file sharing, and chat, and tasks; every feature we tested came back clean. What nobody tested was the belief doing the pointing, that they wanted all of it from us, in one place. We were testing the right things against the wrong destination.
That's the part that should bother you. A rotten assumption at the top doesn't announce itself as failing tests at the bottom. It shows up as a run of small, well-evidenced successes that add up to nothing at all.
What a one-way door looks like when it fails
Boeing's bet against Airbus's A320neo was that they could win with a new 737 derivative requiring no simulator training, because retraining cost was what their biggest customers actually bought on.
They were confident enough to write it into a sales contract: a rebate of a million dollars per aircraft to Southwest if simulator training ever became mandatory. Across roughly 280 aircraft.
The moment that contract was signed, the assumption stopped being an assumption. It became a constraint that every layer below it had to satisfy.
Engineers had test data showing pilots needed more than ten seconds to respond to an MCAS malfunction, against a four-second federal guideline. That finding sat at the bottom of the stack with no route upward that could invalidate a commercial commitment made at the top.
346 people died. The aircraft was grounded for twenty months. Boeing paid out over $2.5 billion.
I'm not going to claim an assumption register would have prevented that. I am saying the finding that contradicted the bet already existed inside the company, and there was no mechanism obliging anyone to carry it back up to the people who had signed the contract.
That's what a one-way door does. It converts a belief into a floor that everything below has to stand on, and it does it silently.
The economics just changed underneath us
The whole argument for testing before building rested on one premise: building is the most expensive way to learn. That was true for twenty years and it justified everything we built on top of it.
I'm no longer sure it holds. If building gets cheap, experiment throughput stops being the constraint. You'll be able to run more tests than you can think about.
So what becomes scarce? Not the test. Knowing which belief is worth testing.
That question has never been the one prototyping and experiments were built to answer. Which is why I think the interesting work in our craft over the next few years happens above the solution layer.
The mechanics already work up there
Nothing is stopping you. Assumption mapping doesn't care what altitude it's used at. What would have to be true, how load-bearing is it (RAND's word, as I said in part one, before a certain LLM wore it out), how would we know if it broke? Those questions work exactly as well on a vision or a strategy as on an opportunity, and I've watched leadership teams run the whole exercise on their own strategy in an afternoon and come out with three things nobody had ever said out loud.
There's no technical reason it isn't standard practice. It just isn't the habit, because the tools arrived from below and nobody carried them up.
So carry them up. Run the assumption map on the strategy before you run it on the roadmap. Ask what would have to be true for the vision, not just for the feature. Put a name against the belief the whole plan is standing on, the same way you'd put a name against a test.
The next time you're in a room where a one-way door is about to be opened, ask the question you'd ask about any feature. What would have to be true for this to work? And how would we know if it stopped being true?
You already know how to run that conversation. When did you last run it above your own eye level?
This is part two of four on the assumptions under your Decision Stack. Part one is Assumption #1: If our strategy is coherent, it's right.. Part three is Assumption #3: If we were wrong, somebody would tell me., on why the evidence that an assumption is failing never climbs. Part four is Assumption #4: The board wants to see the roadmap., on taking the assumptions to the room that owns them.
