Who Needs a Roadmap?

Who needs a roadmap? Anyone who's going someplace they haven't been before. And creating or enhancing a product is always a new journey.

A product roadmap explains where you're going, and describes your routes and stopping points along the way. Its purpose is to get you where you want to go.

It's not, however, a list of what you're packing in your suitcase or what you're going to eat at each rest stop.

A good roadmap lists the high level functionality that is intended for each product release, as well as the reason for choosing this configuration. The reason shouldn't just be "we have to build function A before function B", but instead should explain why the release configuration will make sense to customers…and why it will excite them enough to use it, buy it, or upgrade. The roadmap should name the release - not with numbers or code names, but referencing target markets or personas ("the health services release" or "the system administrator release") or feature sets ("the text formatting release").

The roadmap isn't product specification. It's not a multipage spreadsheet. The more concise it is, the better. The feature list for a release can change without the theme of the release changing. It's also not a schedule or project plan: dates can change without substantially effecting the roadmap.

Here are some reasons why every product should have an articulated roadmap:


Product releases - the stopping points on your route - are critical elements of your long-term product vision. If a release is "whatever features are ready to throw in", then you may find yourself stopping someplace where you don't want to be. Or somewhere your customers don't want to be. Better make sure you make the release points worth stopping at.

A roadmap is one tool (among others) for building the product vision. It's something that everyone on the team can refer to when they want to see, at a glance, the
results of your feature-set prioritization.

If every decision maker on the team (and that includes leads from Engineering and QA, as well as executives) has a chance to review and comment on a roadmap before it's finalized, the roadmap becomes a tool for fine-tuning the strategy and for
building and maintaining team consensus.

Routes change. Detours happen. The clearer your map is, the more effectively you can adjust it and create a new route.

Next time you start a project, make sure you've got a map, and don't leave home without it.

Popular posts from this blog

Agile Thinking

Agile development processes have had a pretty big impact on product management. An agile product manager has to be adept at bringing clear customer requirements into an iterative development context. This can be a terrific opportunity for product management and engineering to innovate during the development process. But I've found that this kind of agile approach can be applied to a more traditional development process, too. In an agile world, a product manager (often serving as product owner, as well) is responsible for delivering customer requirements in the form of use cases as the team goes through a series of rapid development cycles. The product design may change after (or even during) each of the sprints, so the PM is responsible for restating the customer requirements in the new context, as well as creating new use case examples. All the while, the PM must keep the product vision and goals at the forefront. In a traditional "waterfall" development process, the...
Read more

Just Saying "No"

"No" can be the toughest word to say. Nobody likes to hear it. Executives generally hate to be told "no." But sometimes it's the most valuable word in a product manager's vocabulary, especially when it makes "yes!" possible. You can't build all your ideas, so someone has to say no to some of them. That means saying yes to the right ones. Any good product development organization has more good ideas than it can possibly execute. Sometimes the ideas come from executives, sometimes from engineers, sometimes from customers and sometimes from product managers. It's the product manager's job to understand the company's business, the market situation, the customers, and potential customers well enough to make a case for what gets a yes or no (or a "later"). Each case will involve many factors - business goals, investment issues,  sales considerations, competitive conditions, technology opportunities and development resources - ...
Read more

Consistency vs. Innovation

One of the most vexing user experience questions is: When must applications be consistent with each other? When is it OK to invent news ways of doing things that require users to relearn established methods? There is rarely an easy answer, but a Product Manager can play an important role in making these decisions. Most of us assume that it's a good thing when a mouse click performs the same action in different applications. Few of us miss the bad old days when every word processor had its own conventions, and there were no Windows interface guidelines and web interaction conventions. De facto standards have been created by successful products and suites, such as Microsoft Office and the Adobe suites. If you've learned one application, you've learned most of what you need to know to use another. But product designers are constantly confronted with opportunities to do things in a better , but different way. Is consistency an inviolable "must", or, as the saying ...
Read more