Skip to content
Log in

Theory

Keeping it fresh and rolling it out in the organization

How often to review a roadmap, how to size and explain a change, how to answer special requests and strategic forks, and how to roll out outcome-based roadmaps, ending with CatChow's full roadmap.

~13 min read · 13 exercises · 250 points

Before you start

The December review

December at CatChow, and you're still the product team's keeper of the roadmap. The board went quietly, and today is the last review of the year and the end of the quarter, so the columns roll. On top of the planned update, a few unplanned requests have arrived.

In this final lesson you'll set a review rhythm for each part of the roadmap, size and explain a change, answer special requests, and see how outcome-based roadmaps take root in a company, ending with CatChow's full roadmap.

Match the review rhythm to the horizon

A roadmap that never changes is lying; one that changes every week can't be planned around. The way out is to give each part its own rhythm, matched to its horizon and to how fast things change there, the same two things that set the timeframe unit in Timeframes and the roadmap disclaimer:

  • Now: a monthly check of signals, carryover and anything blocked.
  • Next: a deeper look every quarter, when the columns roll and Next becomes Now.
  • The vision and the objectives: about once a year, or when the strategy really shifts. Change them monthly and nobody can plan anything.
  • The “not now” list: at every review, against each item's return condition. Skip it and the conditions turn into empty promises.
A gardener waters seedlings in front, trims a hedge in the middle with shears and only glances at a big old tree at the back.
The near columns change often, the vision rarely.

This rhythm is planned change: it happens on known dates, so people know when to bring things. Unplanned change is whatever arrives in between: a slipped date, a big request, a competitor's headline. A good December review handles both: the quarter rolls on schedule, and the surprises get sized and answered by the same rules.

  • Do
    “Now: checked monthly. Next: reworked each quarter. Vision and objectives: reviewed yearly.”

    Each part has a rhythm people can plan around.

  • Don't
    “Let's revisit the objectives at every monthly review, just in case.”

    Objectives that move monthly leave nothing to plan around.

Size the change first

Before you react to any change, size it. The deeper the change, the further back in the process you go.

  • Small change: a date moves within the quarter, a subtheme is added. It lives in the release plan. You tell the people it touches; the roadmap page stays as it is.
  • Broad change: a theme moves between columns, or one is added or dropped. That's a roadmap update, explained to every audience.
  • Fundamental change: it touches an objective or the vision. Back to the inputs, with the CEO and the board.
A small change lives in the release plan, a broad one updates the roadmap and is explained to everyone, and a fundamental one goes back to the inputs with Ian and the board.
Size every change before you act on it.

The news from Lucy, the tech lead, is a textbook small change: clinic orders move to the new system a week later, in the week of 18 January, and February for PurrPoint still holds. Brandon, who manages the PurrPoint account, and Lucy's team need to know; nothing moves on the page.

Two opposite slips are common. Treating a small change as broad sends a “roadmap update” to everyone over one week and teaches people to ignore updates. Sitting on it until the next quarterly review means the people it affects find out too late to adjust.

  • Do
    To Brandon and Lucy's team: “The move slips a week, to the week of 18 January. PurrPoint's February start still holds.”

    A small change: tell those it touches, the roadmap stays.

  • Don't
    “ROADMAP UPDATE” to the whole company over a one-week slip

    Treats a small change as broad; people learn to ignore updates.

Broad and fundamental changes

The line between the three sizes is what moves on the roadmap itself.

A broad change moves the shape of the roadmap without touching its purpose. The theme “clinics easily recommend CatChow” moving from Later into Next because partner clinics start asking for it is broad: a theme changes column. So is adding a new theme or dropping one. The roadmap is updated, and every audience hears why, because the board, sales, engineering and PurrPoint all plan around those columns.

A fundamental change touches the purpose: an objective or the vision. If CatChow dropped the vet clinic channel to focus only on subscribers, one of its two objectives would disappear. You don't patch that into the page. You go back to the inputs, with Ian and the board, and rebuild from there.

Small changes stay below the page: a week's slip inside the quarter, or a new subtheme such as delivery windows under the subscriber theme, goes into the release plan and to the people affected.

When in doubt, ask: does a theme move, appear or go (broad), or does a goal change (fundamental)?

  • Do
    “Broad change: ‘clinics recommend CatChow’ moves from Later to Next. Here's why, for every team.”

    A theme changed column, so everyone hears the reason.

  • Don't
    Quietly deleting the clinic objective from the page and carrying on

    A fundamental change needs the inputs and the board, not an edit.

Four questions for any request

Big requests arrive with momentum. Brandon brings a chain of nine clinics that will join only with 24-hour delivery, and nine of the 26 clinics CatChow still needs is hard to refuse. Don't answer yet. Ask every request, big or small, the same four questions in the same order, so the answer doesn't depend on who asked or how loudly:

  1. Who has the problem, and what happens to them if we do nothing? The chain's clinics run out and lose clients.
  2. Which key result would solving it move? Partner clinics (54 to 80) and stock-outs.
  3. What would it push out, and who needs to hear that? Next-day delivery is warehouse and courier work, and Lucy's team is busy with the move until March.
  4. What's the smallest step that would show it's worth it? See whether the form plus earlier low-stock warnings make 24 hours unnecessary.

Each question is a gate: if the first or second answer is weak, stop there. Jumping straight to “what would it cost?” or “let's pilot it” skips whether the request matters at all.

  • Do
    “Before we talk delivery times: which clinics run out, how often, and what does it cost them?”

    Starts with who has the problem.

  • Don't
    “Nine clinics! Let's pilot 24-hour delivery with them in January.”

    Jumps to a solution and skips what it would push out.

From the four questions to one honest line

The four questions give you the decision; the reply still has to be written. For the nine-clinic chain that wants 24-hour delivery before the holidays, they point to “not now”: Lucy's team is on the warehouse move until March, and the smallest test is whether earlier reordering makes 24 hours unnecessary.

The reply reuses the “not now” from module 4, a reason plus a checkable way back, reshaped for an outside client who wants an answer fast. A vague “maybe later” would sound like a promise that depends on nothing. Give the chain three things instead:

  • What they can have now: the online form in spring, after PurrPoint, with the earlier low-stock warnings.
  • Why not the rest yet: the warehouse is busy until March, and two or three days may be enough once clinics reorder before the shelf is empty.
  • The condition for a yes: if clinics on the form still run out, faster delivery is back on the table.

Then put the same line into the change note, so Brandon and sales repeat exactly that and promise nothing the roadmap doesn't.

  • Do
    “In spring your clinics join the online form, after PurrPoint. If they still run out, faster delivery is back on the table.”

    An offer now and a visible condition for a yes.

  • Don't
    “We'll probably look at 24-hour delivery sometime next year.”

    Sounds like a promise, depends on nothing anyone can see.

News is not evidence

A headline is news, not evidence: it becomes evidence only when your own data shows customers acting on it. Ian, CatChow's CEO, forwards one: a supermarket chain has launched a cat food subscription 20% cheaper than CatChow's, so “we need loyalty points now”. The question to ask is: is anyone actually leaving us for it?

CatChow's cancellation survey has a price question. In December, 27 of about 450 people who cancelled named price:

27 ÷ 450 = 0.06, and 0.06 × 100 = 6%.

Meanwhile cancellations citing running out fell from 30% to 26% in the reminders' first month. So the decision made in November stands: you don't reopen a decision on a headline.

That doesn't mean ignoring the supermarket. It is a real strategic fork: answer on price, or keep betting on never running out. The calm way to handle a fork is to decide in advance what evidence would make you switch, while nobody is panicking.

When you compute a share, keep the base straight: divide by the people who cancelled, not by all subscribers, and remember to multiply by 100.

  • Do
    “27 ÷ 450 = 0.06, so 6% of December's cancellations named price.”

    The right base and the ×100.

  • Don't
    “27 ÷ 450 = 0.06, so only 0.06% named price.”

    Forgets to multiply by 100: the share is 6%, a hundred times bigger.

  • Don't
    “A cheaper rival just launched. Move loyalty points into Now today.”

    Reopens a decision on a headline, without evidence.

Decision thresholds

For a real fork, decide now what would make you switch. A decision threshold has four parts:

  • a measure: the share of cancellations that name price, or monthly churn;
  • a level: more than 15%, above 8%;
  • a date to look: the end of January and February, the June review;
  • what happens on each side: a small loyalty-points test starts in April, or the plan stays.

For example: “If more than 15% of people who cancel in January or February name price or a cheaper subscription, a small loyalty-points test starts in April.” Or: “If partner clinics on the form still have more than two stock-outs a month at the end of March, automatic reorders for clinics move up.”

Compare that with “if the supermarket seems to be doing well”, “when the founders feel strongly enough” or “if competitors keep launching things”. None of those can be checked, so every month they restart the same argument.

A calm person checks a gauge with an orange line marked on the dial while a megaphone blares loudly beside her.

And if the number lands close to the line? The plan stays, and you look again next month. A threshold you argue about after the fact isn't a threshold.

  • Do
    “If churn is still above 8% at the June review, the loyalty-points test starts in July.”

    Measure, level, date and action in one sentence.

  • Don't
    “We'll act if the supermarket's subscription seems to be taking off.”

    Can't be checked, so it restarts the argument every month.

Explain every change: why, what, when

After a review, the tempting update is a list of what changed. People can read a list. What they can't guess is the reason, and without it they fill the gap themselves, usually with the least charitable version: “they dropped my item” instead of “the evidence moved”.

So every change note follows the same order:

  1. Why: the evidence or event behind the change. It's often the longest part, and it's the one that matters most.
  2. What changed, sized honestly, and what didn't. Say especially that the vision and objectives hold: when they do, a change reads as learning, not chaos.
  3. When it takes effect, and when you'll look again.
A presenter points in turn at a glowing lightbulb, a card being moved between columns and a calendar page.
Without the why, people fill the gap with the least charitable version.

For CatChow's December note, that means: the reminders are working (cancellations citing running out fell from 30% to 26%), and two requests were checked against the objectives; the move slips a week but PurrPoint's February holds; the chain gets a “not now” with a way back; the vision, objectives and loyalty-points decision stay; Now becomes January to March, next review at the end of January.

  • Do
    “Why: the reminders cut running-out cancellations from 30% to 26%. What: … What stays: the vision and both objectives. When: …”

    Reason first, then the change, what holds and the dates.

  • Don't
    “Roadmap changes: loyalty points stay in Later; 24-hour delivery not planned. Questions? Ask me.”

    A bare list: people supply their own reasons.

Roll it out small

When marketing and support want to plan this way too, the temptation is a big launch: every team, January, maybe a training and a new tool. Each of those spreads the first mistakes everywhere at once.

Start small instead: one team, one objective, one quarter. Support is a good first candidate because it already brings evidence to every review.

Before anything starts, get the people whose way of planning changes to agree: the team, its lead, and whoever used to receive dated feature lists from them. A practice imposed from above slides back into a feature list at the first deadline. A quick health check of how the team plans today, five short questions, shows where to begin.

Then give it a steering rhythm. The monthly review becomes a short meeting with a person from each team and the same agenda every time: key results, changes, new requests, decisions, and who tells whom. That way the company learns the practice at the review, on real work, not in a training session. A tool can come later; it doesn't decide how people plan.

  • Do
    “Support plans one objective this way from January to March, and brings it to the monthly review.”

    One team, one objective, one quarter, inside the shared rhythm.

  • Don't
    “From January every team plans by outcomes. Training is on the 10th, the new tool is live on the 11th.”

    Spreads the first mistakes everywhere at once.

A health check for any roadmap

Any roadmap can be checked in a few minutes with five questions, one for each part of the page and the practice around it. They extend the three checks from What a roadmap is (and isn't): trace, change and reader.

  1. Vision and objectives: can most people say where the product is going and which results matter this year?
  2. Themes: does every row name a customer need or a business result?
  3. Timeframes, confidence and the disclaimer: could next month's evidence change the page without breaking a promise?
  4. Prioritization criteria: does everyone know how the order was decided and how to challenge it?
  5. Alignment, presenting and the review rhythm: did every audience hear why the plan last changed?

Answer each with yes, partly or no, and fix the weakest one first.

How it fits together: The course built one page in five versions: inputs and the why layer, themes from needs, an order backed by evidence, people behind it, and a rhythm that keeps it true. Run these five questions whenever it starts to feel like a promise list again.

  • Do
    “Themes: partly. Three rows still name features, so we rewrite those first.”

    An honest answer and the weakest part fixed first.

  • Don't
    “The roadmap is fine: every item has a date.”

    Dates are not health; this page would fail the change question.

Ready to practise?

Answer the lesson's exercises and earn 250 points the first time you finish it.

Start the exercises