A Requirements List Is Not a Roadmap

The head of operations asks for the roadmap. The analyst sends him a spreadsheet of 60 requirements, collected from store operations, marketing, customer service and the delivery fleet, sorted by priority, each with an owner and an estimate. He scrolls for a while. "This is a list," he says. "I asked for a roadmap." She had worked hard on it. It was complete, accurate and ordered. It was also not what he meant. That gap between a list and a roadmap catches a lot of analysts who are moving towards product responsibilities, and it is not a failure of effort. It is a difference in the question being answered. This week follows one analyst at a regional online grocery retailer who has been handed 60 requirements for the customer app and the delivery operation and has to turn them into a plan for the next two quarters. The scenario and its figures are illustrative, built to teach the method, but the situation will be familiar to anyone who has been asked for "a roadmap" and was not sure what was meant.

What a list cannot say

A requirements list answers one question well: what has been asked for. It can be complete, it can be traceable to its sources, and it can carry priorities and estimates. What it cannot do is explain itself. It cannot say why the sixth item sits above the seventh, what has to exist before the twelfth can be built, which items are being deliberately left out, how confident anyone is about the dates, or what the whole thing is meant to achieve for the business. Those are exactly the questions a head of operations, a finance director or a delivery lead brings to a roadmap, and a list leaves every one of them for the reader to guess.

A roadmap answers a different question: where are we going, in what order, and how sure are we? It is a communication tool before it is a planning tool. Its job is to let people who will never read the detailed requirements make good decisions around them: marketing planning a campaign, the warehouse team preparing for a change, finance forecasting the cost, the delivery lead deciding what to staff. Think about how differently those readers use the same page. An executive reads it in two minutes before a meeting and wants to know whether the plan serves the goals. A delivery lead reads it carefully and wants to know what to staff. A partner in marketing reads it for one thing only: when does the thing I depend on arrive? A document that serves all three has to be organised around meaning and sequence, not around the order in which requirements happened to arrive. The table below sets the two side by side.

A REQUIREMENTS LIST AND A ROADMAP, COMPARED

Illustrative. Both documents are needed. They do different jobs.

Why analysts keep handing over lists

There are good reasons the list is where analysts end up. The craft of business analysis rewards completeness: capture everything, resolve the ambiguity, trace each item to its source and make sure nothing is missed. A well-kept list is evidence of that craft, and nobody has ever been criticised in a review for being thorough. The list also feels safe. It makes no promises about order or timing, so it cannot be wrong about them.

There is a quieter reason as well. A priority-ordered list treats every item as if it were independent, as though item four could be built or dropped without any effect on item nine. Real work is not like that. Items depend on each other, they compete for the same people, and some only make sense in a group. Sorting by a single priority number hides those relationships, and the reader is left to rediscover them, usually at the point where a delivery team has started building the wrong thing first. In practice a list read by many stakeholders gets read two ways: as an unranked wish list that nobody can act on, or as a set of promises that nobody can keep. Neither reading is the analyst's intention.

What a roadmap adds

A useful roadmap adds five things the list does not have. The first is a direction: a short statement of what the plan is meant to achieve for the business, such as fewer late deliveries and more repeat orders. The second is grouping: related requirements gathered into themes that describe a problem being solved, so a reader can see the shape of the work without reading sixty lines. The third is sequence: an order driven by what depends on what, not by who shouted loudest. The fourth is confidence: an honest signal that the next few weeks are firm and the following months are intentions. The fifth is boundaries: a clear statement of what is not on the plan this time.

A roadmap is also not a project plan with the dates hidden, and it is not a Gantt chart with fewer bars. A project plan commits a team to tasks, owners and deadlines. A roadmap describes direction and order at a level where it can survive change. The distinction matters because the two are read differently. People treat a project plan as a schedule and a roadmap as a statement of intent, and an analyst who presents a roadmap with project-plan precision invites the first reading and then gets blamed when the plan moves. Keep the roadmap at the level of themes and horizons, and let the detailed plan live with the delivery team.

None of this removes the list. The list becomes the detail underneath, and the analyst's skill in keeping it accurate is precisely what makes the roadmap trustworthy, since a roadmap that cannot be traced back to real requirements is just a nice picture. Business analysts are often better placed to build a roadmap than they think, because they know the requirements more thoroughly than anyone else in the room. What changes is the level at which they communicate, and the willingness to commit to an order and defend it.

Tomorrow starts the work. We take the 60 requirements and see how they collapse into a handful of themes, each tied to something the business actually cares about.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

TOMORROW

From Sixty Requirements to Five Themes - Grouping by the problem being solved, and tying each theme to a goal the business cares about.