Nobody Remembers the Asterisk: Why Your Roadmap's 'March' Became a Promise You Never Made

Day 10: The Roadmap Is a Bet-Sizing Document, Not a Delivery Schedule

Here's the trap: treat a roadmap date as a schedule, and every miss reads as an execution failure. Spend your career like that and you get better at estimating, never better at deciding what's actually worth a bet. The fix isn't a sharper number. It's a different artifact.

Three months ago I wrote 'March' next to a feature on a roadmap doc, with a mental asterisk attached: rough guess, maybe 60% confidence, we hadn't even validated the approach yet. In the stakeholder review last week, someone pulled up that same doc and said, flat, 'this was supposed to ship in March — what happened?' The asterisk was gone. Nobody in the room remembered a confidence level. Everybody remembered a date. That's the exact moment a hypothesis I'd written turned into a promise I'd apparently made — and I hadn't noticed it happen.

The pattern: postmortems interrogate everything except the artifact

Every 'why did the roadmap slip' retro I've sat through — startup, CTO seat, now as an EM — circles the same three questions: was the estimate wrong, did scope creep in, were we blocked. Nobody asks the fourth: was that date ever a real commitment to begin with. We treat the line item as sacred and put the humans around it on trial instead. That's backwards. AI feature work exposes this faster than anything else, because the real unknown isn't 'how long will the coding take' — it's 'will the model even do this reliably.' You cannot estimate your way out of not knowing whether an LLM can hold a multi-step tool-use chain without drifting. That's not a scheduling problem. That's an open question dressed up in a scheduling problem's clothes.

The mechanism: how a bet gets laundered into a schedule

A real roadmap item, stated honestly, reads like this: 'We think retrieval-augmented answers matter for support tickets. We're willing to spend three weeks finding out.' That's a bet — a belief plus a budget. But the roadmap format only has room for a feature name and a date. The belief falls out. The budget falls out. What's left on the page is 'RAG support answers — March.' Everyone downstream reads a schedule, because a schedule is all the format lets them see. Nobody communicated the bet wrong. The medium erased it.

Put the two versions of the exact same information side by side:

Version A (schedule, disguised as fact):
  Ship feature X by March.

Version B (bet, stated honestly):
  Betting 3 weeks on X because we believe Y.
  Kill/ship decision at week 3, based on [metric/eval].

Same underlying plan. Opposite psychological contract. Version A hands everyone permission to feel betrayed the moment it slips — there's nothing else to feel, since 'March' was the only information that made it through. Version B builds the exit right into the sentence: at week 3 you look at the evidence and you ship, extend, or kill. Nobody's 'late,' because lateness was never the metric. This is exactly how AI teams should run eval-gated bets — 'we're spending two weeks trying to push the agent's tool-call success rate above 90% on the eval set; if it's not there at the checkpoint, we cut scope or kill the feature' — instead of quietly sliding a date on an internal doc and hoping nobody clocks that the number moved.

Day 9 showed you that engineers instinctively invent a fake precise number just to make the discomfort of 'I don't know' go away — today's lesson is that the org does the exact same thing to the artifact itself, and that's why now/next/later beats dates: it protects the uncertainty instead of laundering it into fact.

The rewrite rule to try this week

• ▹For every dated line on your roadmap, ask yourself: if this slips, what would I actually believe changed?
• ▹If the answer's a real belief ('the model can't clear the accuracy bar we need' / 'the integration is harder than we scoped'), the date was a genuine bet — keep it, just write the belief next to it.
• ▹If you've got no answer — if slipping just means 'we're bad at estimating' — the date was never a bet. It was a promise wearing a bet's clothes. Swap it for now/next/later before it goes anywhere near a stakeholder.

The fix people always reach for is 'let's get better at estimating.' Wrong layer. Better estimation still spits out a single number, and a single number still gets typeset as fact the second it lands on a doc with your name on it. The real fix is refusing to let a hypothesis get typeset as a fact in the first place — keep the belief, the budget, and the kill/ship line visible on the page, every time, so the format can't lie to the room on your behalf.

Extend your knowledge

• ▹Read Basecamp's 'Shape Up' (Ryan Singer) — the 'How Much Is Enough?' chapter lays out appetite vs. estimate, and the book's 'betting table' concept is basically this post's argument in product-team form. Free at basecamp.com/shapeup.
• ▹Look at Marty Cagan's writing (INSPIRED / EMPOWERED, svpg.com) on roadmaps as commitments vs. outcomes — same argument from a product-org angle.
• ▹Take your team's next AI feature and write its bet explicitly: belief, budget, and the eval metric that decides kill/ship — then compare how that conversation feels versus the last time you just wrote a ship date.
• ▹Pull your last three roadmap 'slippage' postmortems and re-read them asking only: did anyone question whether the date was ever a real commitment?