Your roadmap is a feature list, not a growth plan

Every quarter, the same review. The roadmap slide is green. Everything shipped on time. Then someone puts up the revenue chart, and it looks exactly like last quarter’s.

The team did its job. The roadmap did not.

Most roadmaps I review are feature lists with dates attached. They say what will be built and when. They do not say why those features, and not the dozens of others that were requested. Knowing how to prioritize a product roadmap starts with that why. Without it, a roadmap measures activity, and activity is easy to confuse with growth.

Why a feature list feels like progress

Features are easy to count and easier to celebrate. A list of them gives everyone something to demo and point at in a board meeting. It also fills up from whoever asks most often: the largest customer, the newest sales deal, the engineer with a promising idea, the competitor’s latest launch.

Each of those requests can be reasonable on its own. The trouble is that each one usually passes a single test. The big customer wants it. Engineering can build it. Sales says it will close a deal. One test is not enough.

How to prioritize a product roadmap

A roadmap item deserves its place only when it sits at the intersection of three things:

• Customers want it. It solves a problem real users have, in a way they will actually use. A need you understand across your audience, rather than a request from one account.
• The team can build it well. It is technically feasible with the people, systems and time you have, without creating debt that slows every release after it.
• The business gains from it. It earns revenue, protects revenue, or lowers the cost of serving customers.

Miss any one and the item fails in a predictable way. Customers love it and the team can build it, but it loses money. The business wants it and the team can build it, but nobody uses it once the deal closes. Customers want it and it would pay, but engineering cannot deliver it, so the date slips every quarter.

A feature that passes one test is a request. A feature that passes all three is a priority.

You cannot judge desirability from a request queue

Of the three, the customer side is the one most teams guess at. Feasibility has engineers to answer it. Viability has finance and sales. What customers actually want usually gets decided by the loudest account or the latest competitor launch.

Knowing what customers want takes real time with them: their motivations, the problems they work around every day, the goals they are trying to reach. That work finds opportunities no request queue will surface, and it is the foundation of any product strategy worth the name. Skip it, and the roadmap fills with whatever is easiest to ask for, or with whatever a competitor shipped last month.

Dates are what make a roadmap accountable

Some teams respond to a bad roadmap by dropping dates altogether. I think that is a mistake. Dates are how a leadership team holds itself accountable for progress. A roadmap without dates is a wish list, and nobody can tell whether it is working.

The point is to put dates on the right things. When every dated item has passed all three tests, a missed date is a real signal worth discussing. When half the roadmap is there because someone asked loudly, hitting every date proves very little.

Sequence for value, not volume

Getting the right items onto the roadmap is half the job. The order matters as much, and the order comes from weighing value against cost.

Value is the benefit to customers and to the business. You learn it from two inputs: user research, which tells you how much a problem matters to the people you serve, and business opportunity, which tells you what solving it is worth. Cost is the effort, time and risk it takes to deliver. Items with high value and modest effort go first. High value and high effort earn a planned slot with a date. Low value goes, however easy it looks.

Then sequence so that each release makes the next one more valuable. Foundations come before the features that depend on them. Problems that affect most of your customers come before edge cases. The bets that teach you the most come before the ones that assume you already know. That is what a roadmap sequenced to revenue looks like. One sequenced by request date just gets longer.

This is also where a short list wins. Three items that pass every test will move the business further than twelve that each pass one.

AI raises the stakes

AI is making teams faster at building. For a roadmap built on the right priorities, that is good news. For a feature list, it means you reach the wrong destination sooner. Speed multiplies whatever is on the roadmap, so choosing well is worth more now than it was a year ago, and experts still need to be the ones choosing.

A test for your next roadmap review

Take the top ten items on your current roadmap and ask three questions of each:

1. What evidence do we have that customers want this, beyond someone asking for it?
2. Can we build it well, on time, without slowing everything after it?
3. How does it earn or protect revenue, or lower our costs?

Count the items with strong answers to all three. That number tells you how much of your roadmap is a growth plan, and how much is a feature list.

Try this week: find the item on your roadmap that passed the fewest of those tests and ask who put it there. Then decide whether it still deserves its date.