Product and portfolio roadmaps are key deliverables in any product planning process. A roadmap looks beyond what you’re doing now. It explores not only where you’ll be soon but where you could be a year or more down the road.
When my kids were young and still in car seats, my family would drive from Dallas to Virginia for holidays with my parents. America is a big place! The trip from my home to my family’s home was 24 hours of driving.
Here’s the route from Dallas to our home near Washington, DC: we started on Interstate 30, going to Little Rock, Arkansas, and merged with I-40. We took I-40 all the way to Nashville and stayed overnight with my friend Frank. (If you’re ever in Nashville, be sure to shop at Hart Hardware and say “Hi” to Frank). From Nashville, we continued on I-40 until we connected to I-81 in Bristol, Tennessee. From there, it was a straight shot to Strasburg, Virginia, where we connected to I-66 and drove into the DC area.
So, while it’s a long, long trip, it’s really an easy route. And that’s our roadmap.
When describing it to friends and family, I told them the highlights—30 to 40, then 81 to 66. Texas to Arkansas to Tennessee to Virginia. I avoided too much unnecessary detail. They don’t need to know where we’re stopping for lunch, and we can’t know exactly what time we’ll arrive at Frank’s, but it’ll be as close to dinner time as I can make it. But hey, Frank will understand if we’re an hour early or an hour late.
Before you embark on a long trip—or a long development project—be clear on the goals with a rough idea of the logical steps.
Why build a roadmap?
A roadmap has become the preferred way to show product 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. Problems to solve, not features.
I was helping a team of product managers define their plans using product roadmaps. We discussed themes and markets and financial returns; we examined how various strategic elements could filter the items selected for the roadmap. One product manager finally complained, “But when will we get to the roadmap?” He wasn’t interested in how items were selected or prioritized; he only wanted a graphical depiction. (Sigh.)
Obviously, I’d failed to convey that the roadmapping comes before the roadmap.
Roadmapping is a technique for strategic planning; the roadmap is a key artifact showing current plans.
Executives, salespeople, and marketing leaders are often frustrated with the short-term focus of product plans, particularly in teams using agile development methods (which is just about everybody these days). Leaders have no idea what is planned—if anything—beyond the next two-week sprint. And that’s why they ask for a roadmap.
In fact, many people use the term “roadmap” when they really mean something else. Not every document with a timeline is a roadmap. Some executives ask for a roadmap when they want a project briefing or a release plan.
A roadmap is a multi-year view of the major capabilities planned or problems to be solved for a product or portfolio of products.
A backlog is the collection of requested items from myriad sources that may one day be included in the product. They must be prioritized, defined, and designed before being scheduled.
A release plan is those items from both the roadmap and backlog plus any technical considerations proposed for addition to the product in a specified timeframe.
Only 15% of organizations 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.
There are two ways to build a roadmap
Most agile teams reverse-engineer the roadmap from their list of planned user stories. And this bottom-up approach can work—although it tends to be more tactical than it could be. 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 must happen before that. Then you must break those down into the problem and user stories necessary to deliver that capability.
A roadmap example
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 all the confirmation emails for your flights, hotels, and cars to TripIt. They’ll collate it into a coherent, chronological itinerary you can view and manage online or 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 all at once. They needed to get a basic product into the market and build a following. New capabilities were rolled out every few months.
Here’s how I saw it:
Integrate confirmations via email from the most common travel services, such as airlines, hotels, and rental cars
Friends network: see who’s near when traveling
Admin support: create itineraries for others
Share trips via calendars
iPhone app
Android app
Real-time status updates
Social media (tell people where you are)
Point tracker (track frequent flyer miles & hotel points in one place)
From 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 take. Now you’ve got a roadmap. Some items may have been done in parallel by different groups but could just as easily have been done one after the other, which is why sequencing into a roadmap is critical.
Without a roadmap, product teams can build the wrong thing faster than ever.—Steve Johnson
The buyer-value approach
I’ve always been impressed at the virtual overnight success of Marriott Courtyard. In the early 80s, Marriott noticed a surge in female guests—women traveling alone. At that time, many women were moving into sales and consulting jobs, traveling for work. So Marriott interviewed these women to see how their traveling requirements differed from those of men who traveled for work and how they differed from women who traveled with family.
Think about it for a second. What do you think those requirements were?
What new capabilities are required?
As you probably guessed, the number one issue with women was security. So Marriott designed around safety... in particular, offering limited access to the sleeping rooms. And I read somewhere that the name “Courtyard” was chosen specifically because of its safety connotations.
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 a hotel “must have” according to industry standards. 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.
For this buyer persona, it’s clear that hotels are over-performing in areas that are not valued and low-cost motels are underperforming in areas that are valued. Courtyard focused on those areas that are valued and dramatically reduced or eliminated in areas that aren’t valued.
Blue Ocean Strategy (W. Chan Kim and Renee Mauborgne) argues that you can identify which de facto standards for the industry are out of sync with the buyer’s value. But is their “value curve” idea a predictive tool or an evaluation tool?
Want to try?
Put together a simple spreadsheet to determine the ideal value curve for products. Of course, to make it a relevant exercise, you must know your target customers and what they value.
Getting organizational buy-in
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.
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 each idea to the business and also 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 is the feature for my top customer?” “What about AI?” “I thought the new infrastructure was going to be next!” “Waaa, waaa.”
I’m sure we’ve all had occasions where colleagues questioned the roadmap priorities or, worse, supported them strongly during the team meeting but then complained bitterly about them immediately afterward. In some cases, sharing your roadmap internally is 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 why you put one thing ahead of another.
So here’s a technique to align your roadmap with internal priorities.
Show them your process.
Start by reminding everyone that there are always more ideas than you can deliver; you simply can’t have everything you want, given the resources available. So you’ll have to choose. And you’re trying to choose using a formula instead of using your opinions and the opinions of others.
Explain the different factors you use when prioritizing the roadmap: impact to customer, number or percentage of customers affected, alignment with strategic initiatives, and so on. Explain your formulas. You want them to discuss the factors and the weights, not complain about individual items. You want them to buy into the columns, not the rows. Once they see a method in your approach, they’re more inclined to support it. [Need help? Our method for prioritizing items in a roadmap is called IDEAS. Check it out.]
But let’s take it further. If you have the patience, ask representatives from each team to say “yay or nay” to each item on the roadmap. Have each group say whether that item is critical for their group or their customers.
In this example, it’s clear that the first feature is important to everyone. Further down, you can see the sales and marketing teams are big on social media integrations, while the post-sales groups want real-time status updates and the point tracker. The leadership team seems to want everything, which doesn’t help much (although I guess it makes them feel better).
Some facilitators choose to limit the number of votes per operational area. In this example, there are 11 items on the list; you could 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 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.
But wait. Who’s missing?
That’s right. Customers are missing.
Use this same approach at your next customer meeting. Or use an online polling tool to expand it to more groups. Then you can see that Japan and China want certain capabilities while Western Europe wants a different set. Or how the needs of financial services compare to manufacturing.
Jellybeans and fishbowls
I have 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 with 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 seven 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 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 rely on too much technology.
Want buy-in for your roadmap? Solicit feedback and insights from your customers and colleagues and then show them the math.
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 salespeople, 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 simply do not share roadmaps. They want customers to buy what they have now. They don’t want you to defer customer purchases waiting for the “next big thing.”
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 in order to 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.
A roadmap isn’t a substitute for delivery. Sales teams are often 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.
Like a sales forecast, a roadmap is a plan that will likely change.
Be very cautious of guarantees. Plans change, commitments change, 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 everyone.
Every roadmap should include this statement:
SUBJECT TO CHANGE WITHOUT NOTICE
Most product professionals 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 salespeople, analysts, and clients. The internal roadmap has more details and estimated release dates; the external roadmap offers major themes spread across quarters or half-years with no specific delivery dates.
The most common format for external roadmaps is the “now-next-later” roadmap, popularized by ProdPad. This type of roadmap reveals current, near-term, and future projects. (And without dates. Nice!)
My version is now (as in available now), soon (it will be available soon), next (and then we'll work on this stuff), and later (things we may or may not do). No dates.
The likelihood of change increases as plans move beyond the current set of work. 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!? For your plans to have any meaning, you must know where you’re going with a rough idea of how you’ll get there.
A roadmap is a planning tool that shows a vision for the next few quarters or years. Give a summary in some form to your external audiences so they can see your plans. Or else you’ll find your colleagues and customers making stuff up (and that won’t be good!).
What's next?
The roadmap. Should you build one? Yes, every product needs a vision and a direction. Just don't confuse the roadmap with a backlog or release schedule.
The roadmapping process sequences ideas from inside and outside your organization. Roadmaps are the result. Involve leaders inside your company to ensure buy-in.
You’ll want an internal-only version with lots of detail, but you’ll need a less specific version (without dates) for public consumption.
This is one of the many modern methods taught in the Fundamentals of Managing Products series available from Product Growth Leaders. Learn more here.