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

You Are Who You Hire (part 1)

The recession has done strange things to the hiring process. Few openings, many applicants. Stacks of resumes, many embarrassingly overqualified, some grotesquely underqualified. All too frequently, companies are treating applicants poorly, not following up after interviews and behaving arrogantly. And often people are hired in a hurry, without sufficient scrutiny. Hiring may be the most important process at any company. Everything else depends on having the right people in place, especially when it comes to product managers. But whether you're hiring a product manager, a CEO, or a product support rep, your company's future depends on having the best people in place. You are who you hire. Hiring the right person isn't that difficult if you know what you're looking for, make the effort to get to know applicants well, and are patient. Here's what I look for when I'm hiring, in order of importance: 1. Intelligence . You can't teach this, and if it isn&#
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

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