Roadmapping That Works

Thanks to everyone who attended last week's webinar. I appreciated all the great questions. The recording and slides are now available as well as a full set of Visio and Excel templates below. I will also post the questions and answers from the webinar. I plan to add a lot more content in the coming weeks to provide greater detail about our product roadmapping framework and how to use it.


Basic Template - Excel / Visio

Expanded Template - Excel / Visio

Advanced Template - Excel / Visio

productcampRTP 2014 Presentation

I enjoyed spending Saturday at pcampRTP and appreciated the opportunity to present Finding the Best Frameworks for Product Management. The concepts in the presentation have been percolating in my head for a long time and I finally had a great venue to get the ideas organized, expressed and validated through feedback from a terrific audience. The roadmapping concepts resonated most and I plan to follow up with several more posts on roadmaps.

I look forward to seeing the other presentations once they're shared by the organizers. Some highlights - Mark McClear from Cree delivered a great keynote about their LED light bulb history from a product adoption point of view. Greg Hopper presented a fantastic overview of Product Strategy Lessons from Apple - a light speed talk in over 90 slides in 40 minutes. I can see how his courses at Duke must interest students.

Steve Johnson will be at the next pcamp in Boston on May 3rd. I recommend attending if you're in the area since time at these camps is well spent. 

Make the Most of Roadmaps

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.

Read the full article at 


You can download the spreadsheet used in the examples here: The Portfolio Roadmap. I'm available to work with work with you and your team to apply this and other methods in your organization.


Sharing the roadmap

A product or portfolio roadmap is a key tool in planning, looking beyond your current product deliverables to months and years ahead. But a roadmap can also be a helpful tool with sales people, prospects, and customers. 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.

Some companies do not share roadmaps. They want you to buy what they have now. They don’t want you to defer your purchase waiting for the “next big thing.” Apple is particularly closed-mouthed about future plans so journalists, bloggers, and analysts try to guess, as shown here:

image kuo_2013_apple_roadmap

image kuo_2013_apple_roadmap

(I like the logos on the left, don’t you? And I can just see their sales people saying, “Hmmm, iPhone 5s shows in the beginning of 3Q, so that’s sometime in May, right?”)

Companies like Apple keep their internal plans internal.

But many companies, particularly startups, find sharing the roadmap is a great way to promote and validate their innovation plans. Obviously you cannot do everything at once so a roadmap shows your market 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.

However, be very cautious of guarantees. Plans change; commitments change; market conditions change. And resources get reallocated. So the more your colleagues and your clients think the roadmap is committed, the more frustration you cause for product management, development, sales and marketing.

A roadmap isn’t a substitute for delivery. Many times, sales teams are frustrated by the slow pace of development 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.

Most product leaders ultimately conclude the need for two roadmaps: one for internal use, shared with executives and development teams, and the other for external use, shared with sales people, 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.

Even more ambiguous is the “now and later” roadmap. For example, this “roadmap” reveals current projects, near-term projects, and future projects. (Nice!)

image no dates roadmap

image no dates roadmap


The likelihood of change increases as plans move beyond the current set of work. Agile teams can be fairly confident in what’s in the current iteration or sprint, and perhaps the next few iterations, but next year? Who knows? But 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.

The roadmap is a planning tool that blocks out the next 18-36 months.  Give a summary in some form to your external audiences so they can see your plans. Or you’ll find your sales people and customers making stuff up (and that won’t be good!).

Estimating items on your roadmap

Estimating is perhaps the biggest issue facing product managers regarding roadmaps. Here are some tips to do better sizing estimates.


Did you ever have this conversation growing up?

You: “When’s dinner gonna be ready?”

Mom: “Seven-ish.”

You: “Uh, can you be more specific?”

Mom: “It’ll be ready when it’s ready!”


Estimating is perhaps the biggest issue facing product managers regarding product and portfolio roadmaps. Obviously 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. For roadmapping 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. 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.

Unfortunately, a lot of product leaders and company leaders expect precision in these estimates much too soon. Postpone this level of detail until your team has a chance to examine the idea further and get more specific in terms of effort.

And remember: an estimate is a guess, not a commitment. Assure your teams that these are sizing estimates, not date commitments. If they said it might take a quarter, assure them that you are not committing them to delivering it this quarter. Estimates are “no-sooner-than dates.” An item estimated at two quarters will be available no-sooner-than two quarters from when we begin.

Estimating relative effort is the key

Rather than estimating in months and quarters, most teams are more comfortable—and more accurate—when estimating size: this is bigger than that. A little bigger or a lot bigger.

I like assigning a relative number to estimates so that you can 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 –months, and create an atmosphere of distrust between the development team and the rest of the company.

Your teams probably have history estimating user stories; they can use the same techniques with epics and roadmap items.

Agile teams generally use the Fibonacci numbering scheme for estimating. Fibonacci numbering is the sum of the prior two numbers in the sequence, like this:

1, 2, 3, 5, 8, 13, 21, 34, 55

Estimating using a Fibonacci sequence means that each estimate level is as big as the prior two levels combined.

But Fibonacci is not the only way to estimate. It’s fairly common for agile teams to use “shirt sizes” for the first, rough estimation. This feature is small; that feature is large. You can assign numbers with shirt sizes using a scheme like this:

Tiny: 1, Small: 2, Medium: 4, Large: 8, Huge: 16

This “Doubles” method shows that each level of effort is twice as large as the prior one. So “small” is twice as big as “tiny;” “medium” is twice as big as “small.” Another way of thinking about it is you can do two “tiny” things for the same effort as one “small” thing.

For a more dramatic escalation curve, some teams prefer the “Squares” method:

12: 1, 22: 4, 32: 9, 42: 16, 52: 25.

Here, “small” is four times bigger than “tiny” and “medium” is more than twice as big as “small”.

Comparing three schemes

Comparing three schemes

Here’s the thing: The actual values don’t really matter as much as the relative values. It turns out that people cannot accurately estimate time but they can estimate relative effort. It’s difficult to say “this will take 2 months” but it’s easy to say “this is larger than that.”

Estimating is a team effort

So bring your team together, discuss the various items you have planned for the roadmap, and get their estimates.

image sizing estimates

image sizing estimates

It’s been proven that team estimates are more accurate than an estimate from one person. Three people on a team is good; five is even better. When there’s a discrepancy, you’ll want to get those who estimated highest and lowest to explain their reasoning. Maybe they’ve seen something or assumed something that the others haven’t. Explaining this point of view may cause the team to re-estimate with the new assumptions.

This approach for assessing the effort for a roadmap item, a user story, or an epic is known as “planning poker.” Read more about this method of estimating at from Mountain Goat Software.

One last tip: Before you start an estimating exercise, I recommend you begin with a benchmark. Choose an item or two that your team has already completed—one that you know the time and effort it really took—and then compare new items against that benchmark.

So whatever your method—time in quarters or relative effort—you’ll want an estimate of size for each roadmap item. It will help you ensure that you’re not over-committing your team.