PRODUCT· q3 · keeper's board

The roadmap is a compression algorithm.

Leadership sees four boxes. The team sees forty. What ships is three, plus an unrelated thing. We're not behind. We're compressed.

There's a thing every footballer who plays in goal on Sunday evenings learns by his second season. Forwards see space, midfielders see passes, and you see, from forty yards back with the floodlights on the third pylon out, the holes the back four have already started to leave for next week's striker. The roadmap is the same shape of object. From the keeper's end of the line, the slide leadership opens on Monday is a heavily compressed file produced from a much larger one nobody outside the squad ever reads.

Leadership opens that deck and sees four boxes in a clean row with four crisp verbs above them, and forms a mental model that fits in roughly a paragraph. The squad opens Jira the same morning and sees forty open tickets, half of which sit in a status called "Refinement Needed," which everyone in standup quietly understands to mean nobody has read this since October. By quarter end, three of the forty have shipped, plus one extra thing that was on no view anywhere. Most teams call that slippage. It's actually compression doing exactly what compression is built to do.

OPN 40DRP 00MRG 00SHP 00

match minute

01' First whistle. Forty open.

ROAD-101

New onboarding flow

ROAD-102

Welcome screen copy A/B

ROAD-103

Tooltip pass on signup

ROAD-104

Email verification fallback

ROAD-105

Onboarding analytics events

ROAD-106

Sentry breadcrumbs cleanup

ROAD-107

Animated empty state

ROAD-108

Fix reset-password bug #2147

ROAD-109

API rate limiting

ROAD-110

Per-tenant token bucket

ROAD-111

Burst headroom for premium tier

ROAD-112

Rate-limit response shape

ROAD-113

Retry-After header support

ROAD-114

Grafana panel for 429s

ROAD-115

Refactor auth middleware

ROAD-116

Move config to Vault

ROAD-117

Partner SSO integration

ROAD-118

SAML metadata exchange

ROAD-119

JIT user provisioning

ROAD-120

Group-claim mapping UI

ROAD-121

IdP-initiated login flow

ROAD-122

Scimitar deprovisioning

ROAD-123

Audit log for SSO sessions

ROAD-124

Old auth provider sunset

ROAD-125

Quarterly billing reconciliation

ROAD-126

Invoice PDF template

ROAD-127

Dunning email cadence

ROAD-128

Stripe webhook retry

ROAD-129

VAT field on invoice

ROAD-130

Refund partial-period logic

ROAD-131

Currency rounding bug

ROAD-132

Trial-extension flow

ROAD-133

Storybook upgrade to v9

ROAD-134

ESLint flat-config migration

ROAD-135

Replace moment with dayjs

ROAD-136

Doc: ADR for queue choice

ROAD-137

On-call runbook refresh

ROAD-138

k6 load test harness

ROAD-139

Feature-flag cleanup pass

ROAD-140

Deprecate v1 webhook

scroll to compress

Forty tickets on the board. The leadership view sees four.

Every roadmap loses information by design, the way a goalie loses sight of the ball every time it goes into the corner kick zone behind his shoulder. You don't get to keep all forty in your head; you keep four, with the muscle memory of where the rest were when the corner came in.

The alternative is the Gantt chart your skip level once asked for, which got built, lived nine days, and was last touched the morning of the all-hands.

The lossy translation between dense plan and sparse deck is the job a PM is paid to do.

Pretending the lossy translation between the deck and the Jira board can somehow be made lossless is the original sin most product organisations keep paying interest on for the rest of their seasons.
from the back

When leadership says "the roadmap slipped," they mean the decompression at the squad level produced a different set of bytes than the compression at the top had implied. The question worth asking your peers is how well your team is compressing, not whether they should be doing it at all. Someone who complains the roadmap missed a thing hasn't understood that the missing thing is, definitionally, the part good compression is supposed to leave out.

The compression pipeline.

Strategy

4 bets

Planning

40 tickets

Quarter

3 ships + 1

Demo

the slide that omits the 37

Good compression keeps the load-bearing details and drops the rest, which sounds simple right up until you're the one deciding, at eleven at night before the deck goes out, which four of the forty get to count as load-bearing this time. The four bets on the leadership slide aren't lies; they're the parts of the forty tickets that, if removed, leave the rest making no sense. JPEG keeps edges, MP3 keeps the frequencies your ear uses, and a good roadmap keeps the decisions that constrain everything else. Bad compression keeps what looks impressive and drops what holds the structure up. You see this when a roadmap has six "AI" boxes on it and no mention of the migration off the legacy auth provider quietly eating two engineers all quarter. Six boxes look aggressive on the slide, right up until that migration finally breaks in production and nobody in the room remembers being warned.

There's a rule I keep coming back to. If a stakeholder reads your roadmap and forms a mental model that survives contact with what the team is actually doing, your compression is good. If the model needs constant correction in 1:1s, you've shipped a corrupted file, and everyone finds out the hard way once the sprint is over. It sounds obvious written down like that, and it is, which is exactly why so many teams still manage to fail it twice in the same quarter.

There's another law worth naming. Every quarter ships one item that was never on the roadmap, the Jira board, or any skip-level conversation. A security patch that ate a sprint, or an escalation from your second largest account that needed a real fix rather than a clever workaround. Once, memorably, a Bangla translation defect went live mid-quarter on an internal project; the date format we'd shipped at launch turned out to be unreadable to anyone actually using the product in Bangla. Three engineers, four days, no slide for it on the QBR, and the kind of "where did this come from" silence on the all-hands that nobody had a good answer for. It never makes next quarter's roadmap either, because by the time the deck gets built again, the thing has already happened, and roadmaps aren't built to look backward.

You can plan for that, not for the specific thing but for the fact of it. Reserve a slice of the quarter as a line item called "the thing we don't know is coming yet." Don't call it buffer; buffer gets eaten by ambition the second you name it that. Treat the unknown unknown as a known unknown and the surprise stops being one. The PMs who get this right tend to look slow on paper, because they commit to less than the rest of the org wants them to, and end up shipping more of what they actually committed to.

I think about this every morning when I open Prothom Alo on the way to work. Two hundred stories filed across the day. Eight make the front page. One of those eight was added twenty minutes before the press run because something happened at Shahbagh, or a minister said the wrong thing on television, or a court ruling dropped at quarter to ten. The other 192 went somewhere else, the way 36 of your 40 tickets are still on the board in March even if nobody in the QBR room mentions them.

That's the compression at work. The 192 stories that didn't make the front page didn't fail; they went inside the paper, online, into the archive, into tomorrow. A roadmap is the same shape of object, a quarterly cover with the full work going inside, online, archived, into next quarter. The PM is doing what the night editor at the Karwan Bazar office is doing, with ninety days instead of ninety minutes and worse coffee.

A great editor isn't the one who can line up the eight obvious stories at three in the afternoon; anyone with a working WhatsApp group can do that. The editor worth keeping on the front page is the one who, at quarter to ten with the press warming up in the basement, takes a single story that arrived late and lets it quietly reframe how the other seven need to read. That's the harder skill, and it's the one that separates a roadmap that merely lists work from one that actually explains why the work matters in the order it's presented.

By the time you're at the steering committee, the forty have collapsed into one sentence. "We shipped the new onboarding flow, the API rate-limiting work, and the partner SSO integration. Also resolved a critical translation defect mid-quarter." The thirty-seven that didn't ship don't appear in the room. They aren't failures; they're the dark matter that gave the four bets their gravity, the build-up that doesn't make the highlight reel because the reel only has the goal and the save.

You can mourn that result every quarter, or you can start compressing on purpose. Once you do, you notice patterns. Some work compresses cleanly into a one-line bet, while other work always blows up at decompression no matter how careful the wording, and some stakeholders read the headline and stop while others quietly need the appendix open in a tab beside it. Over a few cycles you find yourself writing roadmaps the way Matiur writes a front page in the basement at Karwan Bazar: opinion in the layout, omission as a deliberate act, and a quiet line item reserved for whatever this quarter's Bangla defect turns out to be. That story tends to arrive somewhere around the forty third minute of a Tuesday standup, the same week the QBR slide already went to print without it.