My article, Get Buy In For Your Roadmap, is featured in this month’s Pragmatic Marketing newsletter.
Here’s a list of posts in my series on roadmapping.
BTW, I’m available to work with work with you and your team to apply this and other methods in your organization. Contact your Pragmatic Marketing sales rep for more information.
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:
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:
(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!)
Source: http://www.prodpad.com/2013/01/roadmapping-without-dates/
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 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.
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”.
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.”
So bring your team together, discuss the various items you have planned for the roadmap, and get their 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 http://www.planningpoker.com 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.
Whether you’ve built your roadmap up from a set of features or down from a set of strategic initiatives, you want to get buy-in across the organization. Here’s a simple technique.
Roadmaps and roadmapping continue to be popular topics for product managers and product marketing managers. Perhaps it’s because roadmapping is such a critical strategic activity but no one is quite sure if they’re doing it right.
A roadmap looks beyond what you’re doing now. It explores not where you’ll be soon but where you could be a year or more down the road.
A roadmap begins with ideas, sometimes large epics or themes and sometimes just a laundry list of features and user stories. Likely you’ll have assessments of the importance of that idea to the business and to your target customers. You probably have some estimates of sizing too.
You stick all that in a spreadsheet, move some stuff around, and then present your roadmap to various internal audiences. And whap! you get smacked in the face. “Where the feature for my top customer?” “What about cloud?” “I thought the new infrastructure was going to be next.”
I’m sure we’ve all had occasions where colleagues questioned the roadmap priorities or even supported it strongly during the team meeting but then complained bitterly about it immediately afterwards. In some cases sharing your roadmap internally a no-win scenario but more often, not getting support for the roadmap results from not getting buy-in from the people who sell and support your product. They cannot see how you came up with your list and how you chose to put one thing in front of another.
So here’s a technique to align your roadmap with internal priorities.
Show them your process.
Explain the different factors you use when you’re prioritizing the roadmap: 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. You want them to buy-in to the columns, not the rows. Once they see a method in your approach, they’re more inclined to support it.
But let’s take it further. Ask representatives from each team to say “yay or nay” to each item on the roadmap.
Each idea has one point already built in, since the idea had to be accepted by product management to get on the list. We’ve added a section to the roadmap for internal buy-in with a column for each organizational group. Each group can say whether that item is critical for their group or their customers.
In this case, it’s clear that the first feature is important to everyone. Further down you can see the sales and marketing teams are big on the social media integrations while the post-sales groups want real-time status updates and point tracker. The leadership team seems to want everything!
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.
Some facilitators choose to limit the number of votes per operational area. There are 11 items in this list; give each team 5 or 6 votes and see what happens. 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.
This method enables you to earn buy-in from your colleagues and leadership.
But wait. Who’s missing?
That’s right. Customers are missing.
Some companies prefer to keep their internal plans internal. But others—particularly startups—find sharing their roadmaps can be a great way to promote and validate innovation plans.
You could use this same approach at your next customer meeting. Or use a voting tool like UserVoice to expand it to more groups. You could choose to add a column for customer votes but it’d be better if you added a column for each target market segment. Then you can see that Japan and Korea want certain capabilities while Western Europe wants a different set. Or you can distinguish the needs of financial services from those of manufacturing.
I used a similar technique with my customers using jellybeans and fishbowls. We had many big initiatives—more than we could do—and no clear strategic direction from inside the company.
So I held a customer advisory board meeting of a dozen customers. At the side of the room I had a dozen fishbowls, each labeled with the name of one initiative. 
I gave each company a bag of 50 jellybeans and asked them to vote. Some were very careful, putting 7 beans here and 17 beans there, but one customer (our most vocal) threw his entire bag of jellybeans into one fishbowl, saying “I can’t keep using your product if you don’t complete this!” This “jellybean and fishbowl” method is simple; it’s easy to explain and it doesn’t cost much.
Ideally you want to create a prioritization scheme that makes sense to both colleagues and customers and one that doesn’t require too much technology to support it.
Want buy in for your roadmap? Create a prioritization scheme that makes sense to both colleagues and customers and that doesn’t require too much effort to support. Solicit feedback and insights, and then show them the math. When they understand the logic behind your longer-term plans, they feel part of the process—and are more likely to get on board.
At the start of each year, I read a book to spark my strategic thinking. I usually find that re-reading a classic reveals that my point of view has changed since the initial read and I pick up much more the second time around.
This year, I’m re-reading Blue Ocean Strategy by W. Chan Kim and Renee Mauborgne. As I’m reading it again, I wonder if it’s possible to predict a successful strategy. It’s certainly easier to work backward from success and use value innovation as a tool to explain the success. As a predictive tool, the authors argue that you can identify which de facto standards for the industry are out of sync with the buyer’s value. Is the authors’ “value curve” idea a predictive tool or an evaluation tool?
I don’t think this is from the book but I’ve always been impressed at the virtual overnight success of Marriott Courtyard. In the late 70s/early 80s, Marriott noticed a surge in female guests–women traveling alone. At that time, many women were moving into sales jobs and customer implementation jobs; they were traveling for work. So Marriott interviewed these women to see how their traveling requirements were different from women who traveled with family or men who traveled for work.
Think about it for a second. What do you think those requirements were?
The number one issue with women, as you probably guessed, was security. So Marriott designed around safety… in particular, offering limited access to the sleeping rooms and (I read somewhere) the name “Courtyard” was chosen because of its safety connotations.
What other requirements come to mind?
And what can you eliminate? If travelers have a rental car and mostly work at the client site, you can eliminate the concierge, meeting rooms, catering, and a fancy restaurant–all de facto standards that a hotel “must have” according to industry leaders. Take a look at the value of various hotel amenities for traveling business people and compare these values to what’s delivered by full-service hotels versus low-end motels. It might look like this:
For this buyer persona, it’s clear that hotels are over-performing in areas that are not valued and low-cost motels are under-performing in areas that are valued. Courtyard focuses on those areas that are valued and dramatically reduced or eliminated in areas that aren’t valued.
So my question is this: can this type of assessment be a predictive tool for your products? Of course to make it a relevant exercise, you’ll really have to know your customers and what they value. Want to try? I put together a simple spreadsheet. Download this [value-assessment] template and try to determine the ideal value curve for your products.
Executives, sales people, and marketing leaders are often frustrated with the short-term focus in product management, particularly those using agile development methods. Leaders have no idea what is planned—if anything—beyond the next two-week sprint. And that’s why they ask for a roadmap.
A portfolio roadmap has become the preferred way to show delivery plans over time. It’s not just a desired feature list by month; it’s bigger than that. It describes major blocks of work, not a laundry list of features.
Yet only 15% of organizations worldwide have deployed multi-year product strategies and less than half of these organizations admit to having done so effectively. Additionally, 20% of organizations reported relying primarily on tactical product roadmaps as the primary vehicle to align with their company’s business strategy. (See The Study of Product Team Performance.)
There are two ways to build a roadmap. Most agile teams reverse-engineer the roadmap from their list of user stories. And this bottom-up approach can work. You look at the personas and problems described by all the user stories and look for common themes. Then group similar capabilities together, get a rough sizing, and plot it on a timeline.
A better approach is top-down. Look at big ideas—often huge ideas—and spread them across time. You can see that this has to happen before that. Then for each, you break those down into the user stories that deliver on that capability.
I can envision the roadmap for my favorite online travel tool: Tripit. If you travel a lot, you should totally check it out. But here’s the gist: Forward the confirmation emails for your flights, hotels, and cars to TripIt. They’ll collate all the info into a coherent, chronological itinerary that you can manage online, and then print or view from your phone. Need a confirmation number at check-in? Need to know which hotel you booked? Which car agency did you use? It’s all right there in TripIt.
Obviously, TripIt couldn’t deliver all this goodness is one release. They needed to get a basic product out into the market and start building a following. New capabilities rolled out every few months.
Here’s how I saw it:
1. Integrate confirmations via email from the most common travel services such as airlines, hotels, and rental cars
2. Friends network: see who’s near when traveling
3. Admin support: create itineraries for others
4. Share trips via calendars
5. iPhone app
6. Android app
7. Real-time status updates
8. Social media (tell people where you are)
9. Point tracker (track frequent flyer miles & hotel points in one place)
If you look at this list, you can see that each item is a project by itself. A quick estimate from a development leader will tell you roughly how many months each project will be. Now you’ve got a roadmap. Some items may have been done in parallel by different groups but they could just as easily have been done one after the other, which is why sequencing into a roadmap is so critical.
You’re probably using EXCEL for your backlog or roadmapping tool. If so, you’ll want to have these fields in your spreadsheet:
With these fields, you can easily build a pivot table like this:
Our goal is to define the major sets of work, sequence them in a way that makes sense to the customer and the business as well as balance the effort over time. You’re not trying to do a project plan here but it’s obvious that you don’t want to attempt 20 person-months of work in one quarter with only 5 person-months in the next.
Of course, each of these items needs to be reduced to the many, many features, user stories, and tasks necessary to make the idea a reality. But without a vision for 12 to 18 months, agile teams can keep building feature after feature. Without a roadmap, agile teams are in danger of building the wrong thing faster than ever before.
Need help refining your roadmapping method? Contact me for onsite consulting.
