Portfolio roadmaps

January 4, 2013 / Steve Johnson

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.

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 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.

Developing your roadmap

You’re probably using EXCEL for your backlog or roadmapping tool. If so, you’ll want to have these fields in your spreadsheet:

• Name of idea or feature (or whatever you call a set of work)
• Effort (a qualitative value of effort by the product team)
• Release assignment (either a release number or date)
• Release theme (optional)

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.