Theme-based Roadmap

Artifact

A roadmap format where each cell holds a subject that groups related work, leaving the individual features inside it open to change.

Why it exists

Put a feature name in a roadmap cell and that name gets read outside as a promise. What was a candidate internally becomes a scheduled product externally. The person who wrote the document meant to convey a direction, and the person reading it took away a list.

That happened on the roadmap Pagedeck publishes to customers. Twelve feature names were listed across the current and next quarter, and a customer close to signing pointed at two of them and asked for both in a contract appendix. What made it awkward for Sofia wasn't that the two were bad features. They were items the team would swap out if a cheaper way to solve the same problem turned up. Once they're in a contract, that swap is a breach.

The problem was the size of the cell. When one feature occupies one cell, that feature becomes the plan. A theme-based roadmap sidesteps this by making the cell one size larger. A grouping like "a new team can get set up without help" goes in the cell, and how to achieve it sits inside as candidates. The direction still carries, and no individual feature hardens into a commitment. Cell size and commitment size travel together, so resizing one resizes the other. If Now-Next-Later lowers the precision of the time axis, this format lowers the precision of the item axis.

What goes in it

A cell opens with the subject's name, and five things sit under it.

  1. The theme name — written as a state the user is in, not as a name for our work. "Onboarding improvements" is an internal label; "a new team can get set up without help" reads correctly from outside. Half of what this format does comes from that one line. A name that only makes sense inside the company gets rewritten the first time it travels outward.
  2. The problem being solved — a couple of lines on why this grouping is in this quarter. Something observed, like "half of new teams stop before creating a second document," becomes the standard for swapping items later.
  3. Candidate items — two or three ways to deliver the theme, each marked as a candidate. Rebuilding the first-document walkthrough, seeding sample documents, shortening the invite flow, listed side by side. These changing is normal. Three candidates is usually about right; a theme with one candidate was a feature all along.
  4. What counts as done — one line on the condition for calling this theme finished. A number and a date, like raising the share of teams that create a second document from half to 70 percent, is what makes it judgeable at quarter's end.
  5. Time band and confidence — the quarter or column this sits in, plus the odds of it landing as written, marked high, medium, or low. Keeping sales from writing a low-confidence theme into a contract is what this field is for.

Owner and current status ride along. Three states are enough: not looked at, being explored, being built. A milestone — a checkpoint planted mid-course to confirm progress — attaches to the items inside, not to the theme. Pin a date on the theme and the point of the larger cell disappears.

No more than three themes in a quarter. Put five up and none of them finishes before the quarter ends, and whoever reads that table stops reading theme names next quarter.

Who writes it and who reads it

A product manager writes it and picks the themes once a quarter. A product manager is the person who decides what gets built and why, and stays accountable through launch. What changes mid-quarter is the candidate list; the theme name and the problem statement stay. A theme that changes monthly is a to-do list wearing a different word.

Four groups read it, each looking at a different line.

  1. The team building the work reads the candidate items. Because the methods are candidates, there's room to bring research back and change one.
  2. Design and research use the theme name as a research scope. Instead of validating one feature, they look at where people get stuck anywhere inside that theme. A theme is roughly the size of one round of research.
  3. Leadership reads the theme name and the done condition. Those two lines are what Grace copies into board material.
  4. Sales and customer success use the published version. With no individual feature names, the conversation about putting one item into a contract mostly stops happening.

Low-confidence themes get dropped from the published version. The least certain cell is the one most badly misread from outside.

How it sounds at work

"That's a candidate inside the theme. We haven't decided to solve the theme with that feature."

A correction that an item in the cell isn't a fixed plan.

"Rename the theme from our internal label to the state the customer is in."

A request for a name that reads correctly from outside.

"Five themes this quarter with two teams. Let's cut it to two."

The document has gone past what can move at once, so it no longer matches reality.

Since that contract request, Pagedeck publishes its external roadmap as themes. Mia grouped the items from the three columns into three themes and named the first one "a new team can get set up without help." Three candidates went inside it.

A month later, research showed that seeding sample documents beat rebuilding the walkthrough. The theme name stayed and only the order inside changed. Sofia didn't have to re-explain anything to the customer, and Grace's board material needed no edit.

What people get wrong

The most common reading is that themes are packaging that blurs feature names to dodge commitments. The specifics are gone, so sales feels this most sharply. But the candidate items are written inside, so what the team will look at is still there. What disappeared is the room to read those items as fixed from outside. Leave the misreading alone and you get a document with empty themes, which really is a direction with no plan behind it. An empty theme is worse than the feature list it replaced.

The other common belief is that grouping into themes removes the need to track schedules. No date field is visible, so it reads that way. But the cell grew only in the precision shown outward; the items being built inside still need checkpoints. Without them, nobody knows mid-quarter that a theme is slipping, and the quarter ends with three themes each half done.

Easily confused with

TermWhat goes in a cellHow it differs
Outcome-based roadmapThe result to reach, stated as a numberThe cell is itself a number, so judging it at quarter's end is unambiguous, but it only holds up when the team can move that number. A theme stops at grouping the problem, which lowers the barrier to adopt and makes it easier to explain to someone expecting feature names. Plenty of teams overlap the two: put a done condition under the theme name and that line is an outcome sentence

Where to go next

Last updated 2026-09-16