Reviewing your product roadmap: how often, who and what can change

You have a roadmap. It was agreed with some care, perhaps after a workshop, and it sits in a shared folder. Then a year passes. The order of work has drifted, two of the themes have quietly died and a third has appeared that nobody wrote down. When someone new asks what the plan is, the honest answer is "it's in the document, but not really".

A roadmap that is never reviewed goes stale. One that is reviewed constantly stops being a plan, because nothing stays still long enough to be worked on. The useful position is in between: a steady rhythm of review, a standard agenda, and a clear rule for what may change and who decides. This article follows how to build a product roadmap and covers what happens afterwards.

A three-layer rhythm

Different questions need different frequencies. Three layers are enough for most organisations.

The monthly check is deliberately small. Its job is to catch drift early and to decide whether anything needs to be brought forward to the quarterly review. The annual reset is the only point at which the goals themselves are up for challenge, which is what keeps the quarterly reviews from becoming arguments about direction.

The agenda for a quarterly review

Keep to the same agenda each time, so people arrive knowing what is expected.

1. What shipped. What was delivered since the last review, in plain terms, and whether it did what we hoped.
2. What we learned. Feedback from users, support requests, anything that surprised us.
3. What has changed outside. Suppliers, regulation, competitors, the organisation itself.
4. What moves up or down. Proposed changes to the order of work.
5. What we decided and why. Read the decisions back before the meeting ends, and agree the wording.

Send a one-page summary of items 1 to 3 in advance, so the meeting is spent on 4 and 5.

Who attends, and who decides

These are largely the roles that built the roadmap, with the owner in place of the sponsor, who joins for the annual reset. Four roles should be in the room, and not necessarily four people:

• An accountable owner, who makes the final call on the order of work.
• Finance, because almost every change has a cost or a timing consequence.
• A user representative, someone who works with the system day to day. Reviews held without the people who use the software tend to optimise for what is interesting to build.
• The engineer who knows the system, who can say what a change really involves.

Agree beforehand who decides, and write the name down.

What may change, and what needs more weight

A simple rule keeps reviews calm: some things can be changed in the room, and some need a longer conversation.

Can change at a review:

• The order of themes within a horizon
• Scope within a theme
• Which horizon an item sits in, and any target dates in the project plans behind it, which are estimates and should be treated as such

Needs more weight, and usually a separate decision:

• The goals the roadmap serves
• Anything that changes the budget or commits a supplier
• Dropping something that other work depends on

Writing this down once, at the start, saves an argument every quarter.

Events that justify an unscheduled review

Some things should not wait for the calendar:

• A serious security vulnerability, or a supplier announcing an end-of-support date for something you depend on. A fixed date from outside moves things up the list.
• A change of supplier, hosting provider or key software dependency.
• An acquisition, merger or restructure.
• A regulatory change that affects the system.
• A key person leaving. If the person who knows the system is going, treat it as urgent: our first-week guide covers the case where they have already gone.

Record decisions and reasons

Keep a short log: the date, what was decided, the reason and who agreed. It need not be elaborate. The reason is the valuable part. In two years, a new owner or a new engineer will want to know why something was dropped, and "we decided to" is no help without the because.

Traps to avoid

• Every review becomes a prioritisation fight. Reserve the quarterly review for decisions already prepared, and settle disagreements about direction at the annual reset.
• Horizons treated as commitments. An item in Next is expected, not promised, and a target date in a project plan is a best estimate. If either is read as a promise, people stop telling you when things are slipping.
• No follow-through. If decisions are made and not reflected in the roadmap within a week, the document stops being trusted.

A one-page review template

Copy this outline into whatever tool you use.

Roadmap review: [date]    Attendees: [names and roles]

1. Shipped since last review:
2. What we learned:
3. Outside changes (suppliers, security, regulation, people):
4. Proposed changes to order, scope or dates:
5. Decisions made, with reasons:
6. Needs a separate decision (goals, budget):
7. Actions, owners and dates:
Next check: [date]    Next quarterly review: [date]

A sensible first step

Put three dates in the diary this week: a monthly check, the next quarterly review and the annual reset, the last one tied to your budget timetable. Then name the person who decides. That is most of the work. If your roadmap has not been looked at for a year, make the first review a catch-up on items 1 to 3 and do not try to change much.

Reviewing the roadmap with you regularly, and keeping it current, is part of our product roadmap service. If the systems it covers are ones nobody currently looks after, software care is the other half of the picture.