The Outcome Framework

Most roadmaps we've seen under the hood can't answer that. They're sorted by quarter, sized in t-shirts, color-coded by team. They tell you what ships when. They don't tell you what has to be true for any of it to matter.

The Shape of the Problem

The default way to build a technical plan is to walk into a room, open a shared doc, and start listing features. Customer requests on the left. Engineering wish list on the right. A compliance deadline forces its way in. Someone loud in a board meeting adds three items. The list gets ordered, stamped "roadmap," and committed to.

You're the CTO holding that doc. Forty-seven items across four quarters. Seven of them are things you actually believe in. The rest are there because nobody wanted the meeting to go longer than an hour. You know the list is wrong. You don't know what to replace it with, because the request wasn't "tell us what's true", it was "commit to a quarter."

That's the position most technical leaders write strategy from, and it's why the documents age badly. Within a quarter the market has moved. Within two, half the list is stale. By three quarters in, "the roadmap" is an oral tradition maintained by whoever was in the last planning meeting. And now that AI is turning every business into a technology business, this problem doesn't stay in the CTO's office; the owner, the president, the founder without a C-suite all face the same list masquerading as a plan.

Features Are Solutions To Questions You Haven't Named

Every feature on a roadmap is an answer. The problem is that most roadmaps never write down the question.

"Build a real-time notifications system" is an answer. The question might be how do we keep users engaged between sessions, how do we reduce support load from missed status changes, or how do we match a competitor who just shipped push alerts. Each question leads somewhere different. The feature is the same. The strategy isn't.

Will Larson has written that a useful engineering strategy names the diagnosis before the action, the specific forces the strategy responds to. A list of features skips that step. It commits you to outputs without committing to a theory of why those outputs should win.

This is where strategy documents fail silently. They're coherent inside the document, features tie to OKRs, OKRs tie to goals, goals tie to a vision, and disconnected from the decisions the engineering team actually makes day to day. Nobody ships a vision statement. They ship the feature on the ticket, against the deadline somebody set in a different room.

Pick the Question First

A strategy that holds up under pressure starts from a different prompt: what must be technically true about our platform, two years from now, for this business to win?

That question is harder to answer than "what should we build next quarter," which is why people skip it. It's also the only version that gives you something to push back against. A directional commitment, "we're going to be demonstrably faster than every competitor in our category", tells you what to stop doing. It gives a junior engineer something to hold onto when the 11pm Slack arrives asking whether to re-platform on the hot framework of the week.

We call the document that comes out of this the Outcome Framework. The name is deliberately plain, because most of what breaks in technical planning breaks upstream of the feature list. The framework's job is to make that upstream decision legible, so the downstream work stops being arbitrary.

Four pieces do the work.

1. Strategic bets

   The two or three hard-to-reverse directional commitments, the load-bearing walls. Have five and you have none; the team will quietly pick which ones they actually believe.

2. Capability investments

   Platform primitives that sit underneath the bets and make the next fifteen features cheap instead of the next five expensive. An integration framework instead of five bespoke integrations. A real-time data layer instead of polling patched onto polling. Invisible to customers, load-bearing for everything downstream.

3. Committed features

   The short list, five to seven per quarter, each tied to a business outcome, each passing two filters: does it serve a bet, does it leverage a capability.

4. Experimental initiatives

   Cheap spikes whose job is to kill bad ideas before they cost a quarter.

The document fits on one page. If it doesn't, you haven't made the hard cuts yet.

The Reframe: Features Are Leaves, Not Roots

Here's what changes when you work this way. You stop treating the roadmap as the plan and start treating it as the output of the plan. The plan is the two or three bets and the capabilities they require. Features are downstream, leaves, not roots. When the market shifts, the features change. The bets mostly don't. If the bets do change, that's a large deliberate conversation, not a drift.

This is also how you build teams that make good calls without asking. A team that knows the bet, "we win enterprise by being demonstrably superior on security, compliance, and scale", rejects the wrong features on its own. They push back on the customer-success request that would compromise multi-tenant isolation. They prioritize the audit-logging work that wasn't on any customer's wish list. DORA's research on high-performing teams keeps landing on the same pattern: autonomy plus alignment, not one or the other. The bet is how you get alignment without micromanaging the leaves.

The Weekly Check That Keeps It Honest

A framework decays the moment the planning cycle ends. The teams we've seen sustain this run a thirty-minute weekly review with technical leadership, structured around three questions: what did we learn this week that should change our plans; where are our assumptions breaking down; do our strategic bets still hold?

"What did we learn" is not "what did we ship." Shipping is a lagging signal. Learning is the leading one, and the assumptions you set at the start of the quarter are the ones most likely to be wrong by the middle of it. If your bet was "enterprise-first" and your three biggest prospects just picked a competitor, that's information. Waiting for the quarterly offsite to notice is how a team perfectly executes the wrong strategy.

The One-Page Test

Open a blank document. Write down your two or three bets. List the capability investments underneath them. List the five to seven committed features for the quarter, each tied to a bet. List your experiments. At the bottom, the part nobody wants to write, a short honest list of what you're explicitly not doing. The things that got cut. The things the loudest voices pushed for and didn't win.

If that document fits on one page and someone on your team can read it and know what to cut from their backlog on Monday, you have a strategy. If it doesn't, you have a list.