How to build a product roadmap: a process for non-specialists

You have decided that the software your organisation depends on needs a roadmap. Perhaps requests arrive from three directions and are dealt with in the order of who shouted last. Perhaps the board has asked what the plan is for the next two years, and the honest answer is a list in someone's inbox.

Good. The hard part is deciding to do it. This article walks through a process that a finance or operations director can lead, with no product-management department, to produce a first roadmap in a few weeks. It follows our piece on why to have a product roadmap, and the difference between a roadmap, a project plan and a backlog is covered in a separate article.

Who needs to be in the room

Keep the group small. Four roles cover it:

• A sponsor with the authority to set the goals and budget, and to sign the roadmap off. Often the finance, operations or managing director.
• Someone from finance, because every roadmap is a set of spending decisions.
• Someone who uses the system daily, who knows what annoys people and what they would miss.
• An engineer who knows the system, whether in-house or from your supplier, to say what is easy, what is hard and what is ageing.

You may be tempted to invite everyone with an opinion. Gather their views beforehand instead, and keep the decision-making group to those four, plus the person who will own the roadmap day to day if that is someone else.

Step 1: write down the business goals

Start with what the organisation wants over the next one to three years, in sentences a director would say aloud. "Take online orders without re-keying them" is useful. "Improve digital capability" is not. Three to five goals is plenty. Everything on the roadmap should trace back to one of them, and anything that cannot is a candidate to drop.

Step 2: take stock of the system as it is

Before deciding where to go, record where you are. One page is enough:

• who uses the system, and what depends on it (other systems, reports, customers)
• where it is hosted, and who looks after it
• the versions of the main frameworks, with their support dates, because a version that stops receiving security fixes is a fact the roadmap must plan around. Our article on what "out of support" means explains why. A current example of a dated input is .NET 8 and .NET 9 reaching end of support on 10 November.
• known risks, such as a single person who understands it, or no tested backup

If you cannot fill in this page, that tells you where to start, and a software health audit is one way to fill it in.

Step 3: gather every request and idea in one place

Collect what users, staff, customers and your supplier have asked for. Put it all in a single list, however rough, with who asked and why. Do not judge yet. The aim is to see everything at once, including requests that have been sitting in different inboxes for a year.

Step 4: group them into themes

A list of sixty items cannot be discussed. Group them into five to eight themes, each tied to a goal from Step 1. "Make ordering faster for customers" might hold a dozen requests. A theme is a sensible unit for a roadmap because it states the outcome and leaves the exact solution open.

Some items will belong to no goal. That is a useful discovery: either the goals are missing something, or the item can go.

Step 5: apply simple criteria

For each theme, discuss five questions:

• Value. How much does this help a goal?
• Risk. What happens if we do not do it, or if we do it badly?
• Effort. Roughly how big is it: days, weeks or months?
• Dependencies. What must happen first?
• Time-sensitivity. Is there a date after which this loses value or gets harder? The hard dates themselves are placed in Step 7.

Rough ratings of high, medium and low are enough at this stage. We will look at prioritisation in more depth in a later article, including how to explain to people why their request did not make the cut.

Step 6: lay it out in horizons

Resist the calendar. A roadmap with a date against every item turns into a set of promises that the first surprise will break. Use three horizons instead:

Detail belongs in Now. Later can be a single line.

Step 7: add the dated constraints

Some things do have dates, and they belong on the roadmap as fixed points rather than as wishes. End-of-support dates for frameworks and hosting, contract renewals, regulatory deadlines and the financial year end are all examples. Place them first, then see how the themes fit around them. This is often where a roadmap pays for itself, because it turns a surprise in a year's time into a plan today.

Step 8: agree an owner, and write it on one or two pages

Name the owner, who keeps the roadmap current and runs its reviews, and confirm the sponsor, who signs it off. In a small organisation they may be the same person. Then write it down: goals, themes by horizon, dated constraints, the criteria used, and the date of the next review. One or two pages is the right length. If it takes ten, nobody will read it.

Share it with the people who contributed, and tell them how and when it will be reviewed. We will cover review cycles in a later article.

A first workshop, in two hours

If you would like to start quickly, a first session can follow this shape:

1. Goals (20 minutes). Agree the three to five goals.
2. Stock-take (20 minutes). Walk through the one-page picture of the system and its dates.
3. Themes (30 minutes). Group the gathered requests and tie each to a goal.
4. Criteria and horizons (40 minutes). Rate the themes and place them in Now, Next and Later.
5. Owner and next steps (10 minutes). Name the owner, the sign-off and the review date.

Prepare the lists in advance. A workshop is for deciding, not for collecting.

Pitfalls to avoid

• A wish list. If nothing is ever left out, you have written a list and not a roadmap.
• Dates as promises. Use horizons, and mark which dates are fixed by the outside world.
• No owner. A roadmap that belongs to everyone belongs to no one.
• No review. A roadmap not revisited goes stale within a quarter or two.

A sensible first step

This week, write your three to five business goals on a single page and ask each person you would invite to a workshop to comment on them. If they cannot agree on the goals, that is the conversation to have first, because everything else rests on it.

Eastpoint offers product roadmap planning for organisations that would like help with the first one.