Building a Technical Roadmap That Survives Reality

Last December's technical roadmap for Q1–Q3 was a Jira export with dates stapled on. One hundred forty tickets. Four themes through September. By week six of Q1, product had rewritten checkout twice and the slide still said "wallet UI — June."

We keep doing this because a dated deck looks like control. Leadership can hire against it. Sales can promise against it. The backlog looks like evidence. Then the quarter review grades engineering on a forecast nobody believed by Valentine's Day.

The backlog was never the plan. It was the pile.

---

The Forecast Ritual

A Forecast Ritual is the quarterly meeting that turns a request pile into a calendar and calls the result a technical roadmap.

Epics get sorted into Q2 / Q3 / Q4. Theme names get picked because they sound like strategy. Target months land on work nobody has shaped. You leave the room with a slide that will be wrong the first time product changes the ask — which, in this shop, is a monthly event, not an exception.

The ritual feels like planning because it produces dates. Dates are not a plan. They are a costume the pile wears so it can enter a steering committee.

Monthly requirement change is not why the deck dies.

Backlog-as-forecast is.

If your "roadmap" cannot survive a product rewrite of the skin, it was a feature list with a timeline. Change is the environment. Dating the pile is the error.

---

The Backlog Is Not a Roadmap

The Scrum Guide calls the Product Backlog an emergent, ordered list of what is needed to improve the product — not a promise, not a schedule.

The commitment attached to that list is a Product Goal, a future state to plan against. The rest emerges. It is allowed to change when the environment changes.

That is the opposite of a dated dump.

A backlog is a request pile with timestamps. Partner asks from last spring. Refactors nobody will defend in a review. Bugs that are real and still not a Q3 theme. Mike Cohn's version is blunter: it is not a complete requirements document, not a promise every item will be built, and not a warehouse for every idea anyone has ever had.

Sequencing that warehouse into quarters is how you launder fiction into a slide.

The warehouse tax is real. Dozens of tasks pile up that everyone knows will never happen. The pile makes the team feel behind when it is not. Grooming old ideas crowds out the work that is actually timely.

The vendor-shaped fix is worse: sync Jira into the roadmap so the slide "stays current."

Roadmap is the strategic why. Backlog is the task list. Executives will not grasp strategy by working backwards from tickets. Connecting the two so every ticket mutation reprints the deck is how the pile becomes the plan.

It's not alignment. It's a live feed of the lie.

Request pile vs forecast

A forecast says: this is what the system will need, and we will spend capacity on it.

A request pile says: these are the things someone asked for, in the order we last argued about.

You can order a pile. You cannot date a pile and call the dates a technical plan. Near-term items can be small and clear. Items farther down should stay rough — because they may disappear. Dating the rough ones is how you invent a September theme out of a maybe.

How sequencing tickets launders fiction

Take the 140-ticket "Q3 platform" epic. Forty are stale partner asks. Twelve are "nice" refactors with no owner who will say no to a Sev-2 for them. The remaining set is a mix of real platform work and checkout cosmetics that will be rewritten when brand restyles the funnel.

The slide still shows four dated themes through December.

Nobody lied in the room. They exported the truth they had — a queue — and dressed it as a forecast. The quarter then grades the costume.

---

The Bet Sheet

A Bet Sheet is a technical roadmap you can still defend after a monthly rewrite.

Not twelve themes. Not an 18-month Gantt of stories. Two or three technical bets you will hold this quarter, each with a kill line, a capacity reservation, and a page that says what you will not start.

Basecamp talks about betting instead of planning because the word sets different expectations: a payout, a commitment of uninterrupted time, and a cap on the downside.

You do not need their six-week cycle to steal the shape. You need the honesty.

A bet you cannot kill is a hostage. A bet with no reserved seats is a wish.

• Bets — two or three technical outcomes you will still defend if the UI restyles. Extract checkout pricing from the monolith. Cut ledger reconciliation from four hours to thirty minutes. Not "improve checkout."
• Kill / keep + reserved capacity — what evidence retires the bet, and which slice of the team is non-negotiable until that evidence shows up. If you add work, you name what comes out. Fowler's rule is the whole practice: you cannot ram ten pounds into a five-pound bag, and a feature that enters without something leaving means the planning is already bad.
• Will-not-start — new wallet UI, event-bus rewrite, the loud asks you refuse this quarter so the bets have somewhere to sit. This is the page people skip. It is the only page that makes the other two real.

The useful roadmap names what you will not start.

A shorter roadmap is more honest than a longer one.

Two quarters of named bets beat an 18-month theme slide nobody is allowed to kill.

Keep it simple and objective-shaped. Not a spec. Not a laundry list. The dates you put on it before anyone has costed the work are hopes.

Keep the hopes off the sheet. Put them in a one-line horizon: we expect to stay on payments rails. That is direction. It is not a June promise.

You might want the 12–18 month view so leadership can staff.

Staffing from fiction produces fiction headcount. Show two quarters of bets and the horizon line. If they need a date that is actually a date — mobile needs the new auth interface by November — that is a high-integrity commitment, not a theme. Date the interface. Do not date the ticket pile behind it.

A kill line is the sentence that makes the bet honest.

"Kill if a partner-API outage burns two sprints." "Keep even if product restyles checkout, because the bet is the extract, not the skin." "Kill if we cannot name a payout after four weeks of shaping."

If the work does not finish inside the appetite, you do not extend by default — you reshape or you walk away, and the most you lose is the time you bet.

Without a kill line, every slip becomes a sunk-cost sequel. Next quarter inherits a zombie plus a story that last quarter "almost shipped."

Record the kill in the same doc the exec saw at kickoff. Quiet deaths are how the Forecast Ritual reproduces itself.

The sheet can die in the same quarter you wrote it, and it usually dies one of these quiet ways.

The reservation is a wiki percentage and no swimlane. Standup cannot see the seats, so Sev-2s eat them and everyone still points at the sheet.

Or the kill line is unfalsifiable — "kill if it gets too hard." Nothing ever trips it, so every slip becomes a sequel.

Or the "bet" is a rewrite with no payout. Event-bus rewrite. There is no done, only more rewrite, and the will-not-start list is empty because the rewrite is the list.

If you cannot name the payout and the evidence that retires the bet, you are back in the Forecast Ritual with nicer vocabulary.

---

Monthly Change Without a New Deck

"Be agile — don't roadmap" is abdication with better branding.

Adaptive planning still plans. The plan is a tool for gauging the effect of a change: if this ask lands, what leaves the bag?

Long-term pictures stay fluid. The stable plan is the current bet.

Following a predictive process when the requirements are volatile is not "more professional." It is the risk — for the people who asked for the dates as much as for the people who have to miss them.

A product rewrite is allowed to move the skin. It is not automatically allowed to move the bet.

Checkout restyles three times. If your technical bet was "ship the new checkout," you will rewrite the deck three times and call it agility.

If your bet was "pricing logic leaves the monolith," the restyle is noise. The bet still holds. You renegotiate only when the rewrite changes the technical outcome — new pricing rules, a different ledger, a partner who now owns the calculation.

If the bet cannot survive a sprint-level rewrite, it was a feature list. Write a smaller bet or admit you are running a delivery queue and stop calling it a roadmap.

Now-Next-Later is the product-side cousin: dated columns turn every date into a commitment, and a horizon with no shared definition collapses back into a vaguer timeline. Steal the split, not the workshop. Now is the bets with seats. Later is the horizon line.

When stakeholders stop reading the sheet and start calling you for the "real" plan, the sheet is already dead. Atlassian calls that out as the stale-roadmap tell. The fix is not a prettier slide. The fix is a sheet short enough to renegotiate in the same meeting the ask arrived.

---

Payments Platform, Q2–Q3

Six engineers. Payments. Product will change checkout. That is not a risk register item. That is the weather.

Bet 1 — ledger reconciliation. Cut the daily reconcile from four hours to thirty minutes. 20% capacity. Kill if a partner-API outage burns two sprints; then the bet reshapes around the partner or it dies in the same doc.

Bet 2 — extract checkout pricing. Pricing logic leaves the monolith. 15% capacity. Keep even if product restyles checkout three times. The bet is the extract.

Will-not-start. New wallet UI. Event-bus rewrite. Both are loud. Both would eat the seats.

Week four: brand restyles the funnel. The Forecast Ritual would have rebuilt the Q3 slide. The Bet Sheet does not move. Bet 2 was never the skin.

Week seven: partner API catches fire for ten days. Two sprints of the reserved lane go to the outage. The EM calls the kill line on Bet 1 in the same channel the exec saw at kickoff. Bet 2 keeps its 15%. Wallet UI still does not start.

The sheet named the trade while the quarter was still running. A forecast cannot do that.

The pile can wait. It always could.