A product roadmap is a frequent request from the sales force and others in the company. "What's coming in the next release and the ones after that?" Long buying cycles common with strategic products often mean the buyers need to know what the product will contain when the cycle ends. A roadmap details the features and platforms for future releases over the upcoming months and years. A product roadmap reveals your current plans but is not a commitment.

Just like planning a trip, a roadmap communicates in broad strokes what you plan to do. One normally plans a route for a trip, but rarely follows the route precisely. You may see a restaurant and decide to deviate from your plan to lunch there. You might hear a traffic or weather report and change your route to bypass the problem. You can make corrections to the plan and still make it to your destination.

What should be in a roadmap?

Typically a roadmap contains release names and approximate delivery dates. Break the table into major features, impacts on client-side and server-side applications, platform support, and markets served. We often see this done in a table with dates across the top and product areas down the left, like this:

Market forces impact each level of the roadmap. Key industry events, new operating systems and platforms, new competitors all act as market forces that should be documented in the roadmap. Changes in market forces usually result in changed priorities in your roadmap.

A roadmap should contain those items that are virtually certain. My advice: stick to the truth. The more you know, the more you can comfortably tell. Major features that are mandatory can be assigned to a release schedule. But don't put "hoped for" features on the list. Remember: the sales channel and the customer will assume that the roadmap will be delivered, so only publish what you know to be guaranteed.

What is the downside?

A product roadmap shows the sales channel and our major customers where the product is headed and what features to expect in future product releases. Unfortunately, it also tells the competition. The competitor may ace your new features before your product hits the street.

And once a roadmap is published, it cannot easily be changed. More than one product manager has been shocked to see the roadmap stapled to a contract as an attachment. What began as a plan has now become a commitment. Many companies find that they need two roadmaps: one for internal use and another for external delivery. While this may be necessary, a better rule is "never print your roadmap." Only the product manager should talk about product futures. A product manager may use the roadmap in a presentation but should never print or distribute the presentation.

Be prepared for this: once you hint at the feature-set of the "blue" release, the sales channel will ask for a little more detail. "Will it be Java? Will it also have reporting?" Before you know it, they've dragged information out of you that you hadn't intended to reveal. They will absolutely complain that they need more specifics, and then they'll need demos, and then they'll need an early copy to close a deal.

Decide what will be communicated in your product roadmap and then don't say any more.

Solve the right problem

A product roadmap is often an effective sales tool in a long sales cycle. It may also be perceived by the sales people as a "magic document" to help close a deal. But perhaps you don't need to talk about roadmaps at all. Interview your sales people to find the root cause behind their requests for a roadmap. The two most common root causes for a roadmap are missed delivery dates and unfocused segmentation strategy--neither of which can be cured with a roadmap.

In order to publish a roadmap officially, a development organization must be able to hit scheduled dates. The best way to achieve this is to reduce the size of every feature set to what can be achieved in 90 to 180 days. With smaller releases, your product comes out more often; the deal-closer feature ships this year instead of next year. Pragmatic Marketing's Requirements That Work class teaches how to define smaller releases that ship more often, often completely nullifying the channel's need to sell futures. One organization with two to three years between product releases used this method to cut their delivery time to a release every quarter. Their customers asked them to ship less often!

The other common reason that channels sell futures is a mismatch of customer and product. Without a market segmentation strategy, we often find the channel pitching the product to people that it isn't really defined for. As a result, the product lacks certain features that are necessary to solve the customer's problem. The sales people attempt to convince the customer that their necessary feature will be in the next product release, and then campaign to get that feature in the release. That's how custom requirements end up in contracts.

Next Steps

A roadmap can be an effective sales tool in a long sales cycle if it communicates without committing. Review your product plans for the next few releases and see what items are certain. Put those on a grid with dates. Now discuss the roadmap with your manager and with your development lead. Are they (and are you) willing to share this information with sales people, customers and competitors?

Steve Johnson is an expert in technology product management. He works for Pragmatic Marketing as an instructor for the top-rated courses Practical Product Management and Requirements That Work.  Steve is also a frequent presenter for various technology marketing forums throughout the United States and Europe, author of many articles on technology product management.