Executives, salespeople and marketing leaders are frequently frustrated with the perceived short-term focus in product management. They often have no idea what is planned—if anything—beyond the next two-week sprint. That’s why they ask for a roadmap: an 18- to 24-month view of the major sets of functionality that are planned for a product or a portfolio of products.
But only 15 percent of organizations worldwide have deployed multi-year product strategies and less than half of those organizations admit to having done so effectively, according to “The Study of Product Team Performance” from Actuation Consulting.
Part of the problem lies in the definition of roadmapping. A team of product managers were prioritizing their plans using product roadmaps. We talked about themes, markets, financial returns and how various strategic elements could filter the items selected for the roadmap. One product manager finally complained, “But when are we going to get to the roadmap?” He wasn’t interested in how items were selected; he was only interested in having a graphical depiction. But roadmapping must come before the roadmap.
Roadmapping is a technique for strategic planning; the roadmap is a key artifact showing current plans. And not every document with a timeline isa roadmap.
For a roadmap, you’ll want to show major features planned for the next three to six months and any new initiatives over the next three to six quarters. (The first is a “going to” list; the second is a “want to” list.)
Developing Your Roadmap
Your goal is to talk to the market to define the major sets of work, sequence them in a way that makes sense to the market and to the business, and balance the effort over time. If you’re using a program like Excel for your planning tool, you’ll want to include these fields in your spreadsheet:
- Effort (a qualitative value of effort by the product team)
- Release assignment (either a release number or date)
- Name of idea or feature (or whatever you call a set of work)
- Release theme (a technique for grouping similar items to deliver sets of capabilities)
Of course, each of these items needs to include the many, many features, user stories and tasks necessary to make the idea a reality. And with these fields, you can easily build a pivot table as a planning tool for the roadmapping process, like the one shown here.
Estimate Your Effort
The biggest challenge in putting together the roadmap is likely to be estimating how much effort each item will take. You want to get an estimate before anyone spends too much time designing a solution, but you can’t really get a valid estimate without some level of design.
Here’s the big trick: guess.
A guess is good enough for this level of planning. You don’t need a person-hour estimate; you just need an idea of whether it’s a month or a year, tiny or huge.
Many experienced teams find they can quickly and easily estimate roadmap items by fiscal quarters. This item will take one quarter; that one will take three quarters.
Or, rather than estimating in months and quarters, some teams are more comfortable—and more accurate—when estimating size. It’s difficult to say “this will take two months”; it’s easy to say “this is larger than that.” Assign a relative number to estimates so that you can more effectively compare dissimilar things. But be careful with numbers. Before you know it, some fool (maybe you) will try to equate these effort numbers with person weeks or person months, and create an atmosphere of distrust between the development team and the rest of the company. And remember: An estimate is a guess, not a commitment. Assure your teams that sizing estimates are not date commitments.
Get Organizational Buy In
To align your roadmap with internal priorities, show your process.
Start by reminding everyone that there are more ideas than you can deliver. You can’t have everything you want, given the resources available. You have to choose. And you want to choose using a formula instead of your opinions.
Explain the different factors you use when you’re prioritizing items: impact to customer, number or percentage of customers affected, revenue and cost estimates, strategic initiatives, and so on. Explain the formulas. You want them discussing the factors and the weights, not complaining about individual items. Once they see a method in your approach, they’re more inclined to support it.
You can take it even further by asking representatives from each team to say “yea” or “nay” to each item on the roadmap. Add internal buy in to the roadmapping process, with rows containing the ideas you are considering and columns for each of the organizational groups. Then allow each group to say whether that item is critical for them or their customers.
Some facilitators choose to limit the number of votes per operational area. For example, if there are 11 items in the list, give each team five or six votes and see. Like the game of musical chairs where there’s always one chair fewer than the number of children playing, this approach prevents people from choosing everything and really forces them to prioritize. I’ve found that people are more inclined to support something when they’ve had the chance to define it or at least contribute to its definition.
Share the Roadmap
A product or portfolio roadmap is a key tool in planning and looking beyond your current product deliverables to the months and years ahead. Some companies simply do not share roadmaps. They want you to buy what they have now, not defer your purchase waiting for the next big thing. I once saw a presentation with a clever logic diagram for sharing the roadmap:
- Do you want to delay your sale? If yes, then show the roadmap.
- Do you want to delay the next release? If yes, then show the roadmap.
- Anything else? Don’t show the roadmap.
On the other hand, if you don’t share your plans, others will guess what you’re planning. Many companies, particularly startups, find sharing the roadmap a great way to promote and validate their innovation plans. A roadmap can also be a helpful tool with salespeople, prospects and customers.
You can’t do everything at once, but a roadmap shows that you’re thinking beyond the current development iterations. Existing customers want to know where you’re going, so they can make their own plans. Which technologies and major capabilities can they expect this year and next? How will changes in your architecture affect their own plans? The same is true for potential clients; they want to see you’re in sync with their plans.
But a roadmap isn’t a substitute for delivery. Many times, sales teams are frustrated by a slow development pace, so they sell “futures,” hoping to persuade clients to buy now instead of waiting. They sell the roadmap as a commitment, not a plan. A roadmap, just like a sales forecast, is a plan that will likely change. Be very cautious of guarantees. Plans change, commitments change and market conditions change. And resources get reallocated. The more your colleagues and your clients think the roadmap is committed, the more frustration you cause for product management, development, sales and marketing.
Most product leaders ultimately conclude the need for two roadmaps: 1) for internal use, shared with executives and development teams and 2) for external use, shared with salespeople, analysts and clients. The internal roadmap has more detail and more specific dates; the external roadmap offers major themes spread across quarters or half-years.
For your current plans to have any meaning, you have to know where you’re going with a rough idea of how you’re going to get there. And that’s why roadmaps done right are such a powerful tool.
