Part four of four on the assumptions under your Decision Stack. Part one, Assumption #1: If our strategy is coherent, it's right., argued every layer has assumptions underneath it. Part two, Assumption #2: We're a data-driven company. We test everything., that our tools only test the bottom one. Part three, Assumption #3: If we were wrong, somebody would tell me., that the evidence they're failing never climbs. This one is about the room where it should end up.
Boards are asking the right question. They just don't always know how to ask it, so we don't always recognise it, and then we go away and answer a completely different one.
You know the shape of it. The board asks where are we going, or what's our strategy, or what's the roadmap. And the product leader comes back three weeks later with a list of features for the next three quarters.
It's usually a good list. It's also an answer to a question nobody asked, and it leaves the assumptions holding up the real answer exactly where they were: unnamed, unowned, and unwatched.
Two meanings of one word
Here's the trap. When a board member says "roadmap", they mean the answer to where are we going and how will we get there. It's a figure of speech. A road, a map, a destination.
When a product leader hears "roadmap", they hear a specific artefact: a prioritised list of the things we're going to build, probably with quarters against them (and if there are dates on it I've got a whole other post for you). It's a defined thing in our craft, and we're trained to produce it under pressure.
So the board asks for strategy in their language, product hears a feature list in ours, and product duly delivers the feature list. Everybody did their job. Nobody had the conversation.
The Decision Stack asks five questions. Where are we going? How will we get there? What's important now, and how do we measure progress? What actions are we taking to move forward? And how do we make the right choices?
A roadmap isn't a layer of the stack. It's one way of describing the fourth answer, the priority order of the opportunities you've chosen to go after. Useful, but it's an output of the stack, and the board was asking about the top two layers that produced it. Those two layers are also where the assumptions nobody wrote down live, which makes a roadmap review the one meeting guaranteed never to surface them.
What the room does with a list of features
Hand a board a list of actions and one of two things happens.
Either they nod, because what else are they going to do with a list of actions, and everybody leaves the room with the real question still unanswered. Then eighteen months later something breaks near the top of the stack and nobody can point to when that decision was made, because it never quite was.
Or, and this is worse, they engage. Features are concrete, technical, and easy to have an opinion about, so the room starts arguing about the list. Somebody's portfolio company did a thing like item four and it went badly. Somebody else's teenager wants dark mode. The one bit of the stack the board is least qualified to decide becomes the only bit they discuss, and you leave with a reprioritised roadmap and no strategy.
I've been the person with the roadmap, more than once. I'd done the work, I had the deck, I knew my dates (yes, dates, I was young), and I'd sit through the wrong conversation feeling vaguely cheated. It took me longer than I'd like to admit to work out that the fix was simple. Stop bringing the roadmap. Bring the strategy, and bring the choices inside it.
Bring the choices, and the tradeoffs
Strategy is choice, and every real choice has a tradeoff. Helping you make that choice is what a board is for. So bring the choice, and bring what each side would cost.
Say you've got signals pointing two ways. Some of your best growth is coming from enterprise: high-touch, sales-led, and it needs SSO, ISO certification, enterprise integrations, user management, someone to answer the security questionnaires. Some of it is coming from SMB: low-touch, product-led, and it needs dead-simple onboarding, self-serve billing, in-product upgrades. Both are real. Both have evidence behind them. And each one is standing on an assumption: that enterprise buyers will keep paying for compliance, or that SMBs will convert without a human in the loop. You cannot build for both at once without doing both poorly (ask me about Huddle).
That's a strategy conversation, and it's one a board is unusually good at. Something close to this, out loud:
"Our roadmap depends on a choice we haven't made yet. Here are the two real options. Here's what each one needs from us in investment, in what we'd build, and in what we'd have to stop building. Here's what would have to be true for each one to work, and here's what we've tested so far. What do you know that I don't?"
That last question is the one that changes the meeting. You're opening something up. And boards are full of former founders and former operators who have made exactly this bet themselves, usually painfully, and who are desperate to talk about something other than last month's numbers. Give them the chance and you'll watch the room come alive.
Risk is the language they already speak
Boards are primed for risk. It's the vocabulary of governance, which is the job they were appointed to do. Say "assumption" in a board meeting and a good half of the room hears something academic, something for the offsite. Say "risk" and your CFO sits up, because now you're talking about a thing they already have a register for and a strong opinion on.
Same content, different word. That isn't spin, it's translation, and it's the difference between being heard and being thanked.
You don't have to test it
The thing that stops most people running this upstairs is a belief that every named assumption needs an answer, and that the answer has to be an experiment.
But naming the assumption is a complete answer. So is accepting it deliberately, out loud, on the record:
"This is a big assumption. We've validated it as far as we reasonably can. It's still a bet on the future. Are we comfortable taking that risk?"
It might be the most senior sentence available to you in that room, and it does three things at once. It puts the bet where everyone can see it. It makes the risk a shared decision rather than your private problem. And it earns you the right to come back in a year and say the conditions have changed, because everybody agreed in advance what the conditions were.
If you're on the other side of the table
If you're the one asking, ask better. "What's the roadmap?" reliably gets you a feature list, because that's the artefact we're trained to produce.
Try these instead. What are we betting on? What would have to be true for that bet to pay off? And how would we know early if it stopped being true?
If those sound familiar, it's because they're the three moves from part one (name it, sort it, set a signpost) asked from the other chair. The product leader's job is to bring the assumptions up. The board's job is to ask for them.
You'll get a different meeting. You may also discover that nobody in your organisation has ever been asked.
Change the conversation
The stack gives you a way to do this that doesn't depend on anyone's goodwill. Vision and strategy are where the board is strongest, so bring those. Objectives are where you agree what progress looks like, so bring those too. Opportunities and solutions belong to the teams closest to the customer, so leave them there, and say so.
Do that and two things happen. The board stops arguing about features and starts doing the job you actually need from them: pressure-testing the bets with everything they've seen before, and a view of the market you don't get from inside it. And the teams get to own their end of the stack without a board member's pet feature landing on it from a great height.
It also fixes the problem from part three. When the board is pressure-testing bets rather than reprioritising features, the bad news from the edges finally has a room to arrive in, and somebody senior whose job it is to hear it.
Better conversations at the top, better decisions in the middle, more room at the bottom, and a strategy somebody can actually point to when it's time to change it.
So when's your next board meeting, and what are you planning to bring to it?
This is the last of four on the assumptions under your Decision Stack. Part one is Assumption #1: If our strategy is coherent, it's right.. Part two is Assumption #2: We're a data-driven company. We test everything.. Part three is Assumption #3: If we were wrong, somebody would tell me.. Some of the thinking here came out of a conversation with David Bland on his How I Tested That podcast.
