Like so many of the tools used by Product Managers to make the software product successful – the Requirements documents come to mind – the Product Road Map takes many different forms at different companies, and needs to be customized to suit each company. While it may seem that no two of these are alike, in every case the Product Manager struggles to balance the ideal with the real in putting together a road map.
In addition, the Product Road Map deals with information at different levels of detail. And what looks realistic from 30,000 feet may seem a little idealistic once you get down to ground level.
How do you balance the real and the ideal in your product’s road map? Read on for a look at the types of content to include.
[private]
WHERE AND WHEREFORE
First we’ll talk about the Product Road Map and what it covers, then talk about how it is used.
THE OUTER BOUNDARIES
At the highest – and most ideal – level, your Product Road Map shows a map of the whole territory that your product covers. Create a picture of everything which a product, say, field service management, or analytical CRM, or reverse logistics ought to do if it were the perfect product, covering all user needs within its category.
Take a look at the Product Road Maps that SAP has put together. You can find these at www.sap.com. Search for “cross-industry business maps” on the home page and look for items called Solution Maps with little rainbow colored boxes next to them. These solution maps have definitely gone down the path of the ideal. They are all things to all companies. If there was a mission statement for a product that fit those maps, it would be “To be an application that handles all work done by all employees at a company, and their business partners.” It’s a little bit much.
But you, too need to start off with the equivalent of the SAP solution maps for your own product. Find the outer bounds of the market and the functionality that you are focusing on, and lay out all the pieces that fall within them.
This definitely falls on the ideal side, because it’s a picture of what your product would contain if development resources were unlimited.
THE TERRITORIES BEYOND
Just as important as understanding the outer bounds of your product is some explanation of what lies beyond the territory you intend to cover. That’s because you need to know what your product is not in order to be clear about what it is.
For example, if your product is a subset of CRM, Analytical CRM for example, you want to sketch the outlines of what Operational CRM is, how it’s different, and how the two fit together.
The territories beyond need to contain some references to the other systems your application normally interfaces with, and the nature of those interfaces.
Or your focus may be more market-oriented. Your product may fall into the financial services market, but is aimed at insurance, not investment.
WHERE ARE YOU TODAY?
Somewhere in that big, beautiful picture of everything that you want your product to be lies what your product actually does today. The Product Road Map is like the complete picture that you will get once you have put together a puzzle. But the portions of that picture which you have actually assembled represent the picture of where you are today.
Everything that lies beyond today’s product but within the boundaries you are aiming for becomes the list of capabilities that you need to add, either via internal development, partnerships, or acquisitions. It’s your own internal gap analysis.
WHAT ARE YOU GOING TO DO NEXT?
Since the Product Road Map is a tool that gives everyone at the company their marching orders (see a related topic called Product Roadmap to the Promised Land), it’s helpful to point out the capabilities you plan to add in the next release. This takes a map that is still very high level and provides some practical guidance to people in Development, Marketing, and Sales about upcoming features.
There’s no sense using your collateral to hype something that is three years down the road, but you may very well want to include near-term additions in your collateral.
STEP BY STEP
Break the list of everything that needs to done into logical groupings. At a very high level, this is the capability in your next series of releases, for the next one, two, three, even five years.
Yes, it will change as the needs of the market change in ways you cannot anticipate today. But you’ve got a pretty comprehensive and long-term guide for all upcoming product development.
IT REALLY IS LIKE A MAP
I used to wonder why these things were called Product Road Maps. It seemed like an over-elaborate way of describing something that wasn’t really a map. But it provides a picture of where you are today, your intended destination, how you’re going to get there, and when. Kind of like a map (it even includes the itinerary and travel schedule).
WHAT’S THE USE?
The various levels of detail in the Product Road Map have different uses. The top level, the most ideal, which is the picture of all that your product will become, is something you can use to attract potential business partners, or even acquirers.
The all-inclusive map is useful when attracting investors. And the detail that explains which capabilities will be added on what schedule provides the raw material from which to develop estimates of the money required, which of course is a vital piece of information to prospective investors.
Use the lowest level of detail in the Road Map to build the Requirements document, the list of all capabilities and engineering activities, both for the next release and releases beyond. In fact, you can set initial priorities based on how many steps away you are from adding a specific capability.
So the Product Road Map becomes a useful mixture of the ideal and the real, which guides your company, attracts customers, investors, partners, and possibly mergers and acquisitions. And on the very practical level it gives you the contents of the Requirements document for the next release.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]