Roadmap, project plan or backlog: which do you need?

Three requests arrive in the same week. Your supplier mentions the backlog and says it's getting long. Your finance team asks for a project plan so they can forecast spend. The board would like to see a roadmap. You could be forgiven for asking whether you are being asked for the same thing three times.

You're not, although the words are often used loosely enough that it sounds that way. These are three different documents with three different readers, and each answers a different question. This article puts them side by side, shows how they fit together, and helps you decide which ones your organisation actually needs. If you want the case for having a roadmap in the first place, we covered that in why have a product roadmap.

An analogy from an office refurbishment

Imagine you own an office building and intend to improve it over several years.

• The roadmap is the multi-year intent: first make the building safe and warm, then improve the meeting spaces, then rework the ground-floor reception. It says what matters and in what order, and it's honest that the later years are less certain.
• The project plan is the schedule for one piece of that work: the second-floor refit, with the contractor, the dates, who does what, what has to finish before the next step starts, and the budget.
• The backlog is the full schedule of works, down to the snag list: every job anyone has identified, from replacing the boiler to fixing a sticking door, kept in one place, roughly ordered, with some items that will never be done.

Nobody would hand the board the schedule of works and call it the strategy, and nobody would ask the contractor to work from a three-year intent. Software is the same.

The three side by side

The "how far ahead" row catches people out. A roadmap that gives exact dates two years out is a promise nobody can keep. A backlog planned in detail for a year is a lot of effort that will be thrown away.

How they connect

The three aren't rivals. They feed each other.

The roadmap decides which themes deserve funding and attention: for example, reducing manual re-keying between the sales system and the finance system, or getting off an unsupported platform. A project plan then delivers one of those themes, with dates and owners. The backlog supplies the detailed work for the plan and also collects everything else people notice along the way, some of which later influences the roadmap.

If you picture it as a funnel in one direction and a stream of information in the other, you have most of it. Direction flows down from the roadmap. Evidence flows back up from the backlog and from the people using the software.

Common mistakes

Each of these is easy to fall into, and each has a simple correction.

• A roadmap that is really a backlog with dates. If it lists forty features and a date against each, it's a delivery schedule in disguise. A roadmap should be readable on one page.
• A project plan used as a strategy. A plan tells you how to deliver something. It doesn't tell you whether it's the right thing to deliver.
• A backlog nobody has pruned for three years. Hundreds of items, many obsolete, some contradicting each other. It becomes impossible to see what matters. Regular pruning, including closing items that will never be done, is part of keeping it useful.
• One document trying to be all three. The result is too detailed for the board and too vague for the developers.

Outcome-based or feature-based

Roadmaps come in two styles: a list of things to build, or a list of results to achieve. We made the case for outcomes in why have a product roadmap, but many organisations end up with a mix, and that's fine. A useful test for any item, in either style, is to ask what changes for the business if it is done.

What a director should ask to see

If you rely on a supplier for software and want to know where things stand, three requests are reasonable:

1. A roadmap on one page, in terms you recognise: goals, rough order, and what has been deliberately left out.
2. The current plan for any piece of work you're paying for, showing what is done, what is next and what has slipped.
3. Access to the backlog, so that you can see what has been raised and what has been decided. You don't need to read it all. Being able to look is part of owning your software.

If a supplier can't produce these, that tells you something too, though not necessarily something bad. It may simply mean the work has never been written down.

How much of this do you need?

It depends on how much software you depend on. An organisation with one or two systems may need no more than a one-page roadmap that's reviewed briefly each quarter, plus a backlog that someone keeps tidy. A formal plan is worth writing when a specific piece of work has a budget and a deadline. Larger or more varied estates benefit from a little more structure, but even then the goal is the same: each reader gets the level of detail they need, and no more.

A sensible first step

Over the next week or two, you could:

• Ask your supplier for the current backlog and see how many items are older than a year. A large number usually just means nobody has had time to tidy it, and a tidy-up is the fix.
• Note which of the three documents you have today, and who owns each. A blank in the owner column is the gap to close first.
• Check whether any piece of work you are funding has a plan with dates, and whether anyone looks at it regularly.

If you'd like help pulling these into one clear view, our product roadmap service is designed for exactly that. For the software itself, software care covers keeping it in good order once the direction is agreed.