This guest post is from Jim Semick, the founder of ProductPlan, roadmap software for product teams. Jim has validated and launched several new products including AppFolio, GoToMyPC, and GoToMeeting. Jim is a frequent speaker on new product development. Want to read more? Read his product management blog posts. Follow him on Medium and Twitter.
Are you focusing on the backlog but missing the big picture?
In this article, I’ll talk about how to prioritize your roadmap, give you techniques for ordering your backlog, and show you how to tie your strategy to your agile planning.
We recently conducted a webinar on this topic—you can watch it here.
The roadmap and the backlog are different. The roadmap defines your product strategy, while the backlog is used for the execution of that strategy. Here is how I think about the major differences between the two:
| The Roadmap | The Backlog |
|---|---|
| Big picture | Detailed |
| Communication focus | Execution focus |
| Longer term horizon | Shorter term horizon |
| Rough dates (or no dates) | Specific dates (if Scrum) or no dates |
| Rough estimates | Granular estimates |
| Communication-focused tools (e.g., PowerPoint, ProductPlan) | Project management tools (e.g., Pivotal Tracker, JIRA, spreadsheets) |
Let’s dive into each of these a bit more.
The roadmap is a strategic communication document. It’s something that you use to talk with different stakeholders about what you want to accomplish. By nature, the roadmap is comprised of big-picture initiatives—themes or epics. It should not include granular details.
The backlog, on the other hand, contains initiatives that you already know you want to accomplish, and the level of detail should therefore be more granular. You should think about your backlog in terms of specific tasks or stories. For every initiative on your roadmap, you may have potentially dozens of items represented on your backlog.
The focus of the roadmap is very different from the focus of the backlog. The roadmap is a communication tool and its purpose is to get all of your stakeholders on the same page about about the big-picture strategy.
The backlog, however, is about execution. You already know what you’re going to accomplish through the roadmap, so the backlog is about how you’re going to execute that strategy.
Because roadmaps are executive-facing, they typically have long-term horizons. Among our customer base at ProductPlan, the average roadmap duration is about one year. Of course, every company is different, both in terms of the product that they produce and where they are in their lifecycle, so a one-year time horizon isn’t right for everyone. For example, at early-stage startups, the roadmap time horizon tends to be shorter because things are moving very quickly and future initiatives are fuzzy.
The backlog is different. The backlog has a short-term horizon. If you are operating in an Agile environment and using Scrum, for example, then you are likely planning in terms of sprints. Sprints are relatively short—one week, two weeks, four weeks, etc. You really don’t want to be planning out further than a few sprints at a time, because the whole point of agile is that you’re able to prioritize and order your backlog on the fly as circumstances change.
The question of whether or not to include dates on the roadmap comes up often. In many cases, the roadmap will have rough dates or very high-level dates—at the level of months or quarters.
We’re seeing a movement in product management toward no dates or fuzzy dates on the roadmap. Product managers are operating in more and more agile environments, where they don’t want to commit to specific deadlines when circumstances are constantly changing. By creating a roadmap without dates, you can eliminate the risk of setting inappropriate expectations with your stakeholders.
Depending on your agile methodology, the backlog may have specific dates. If you’re using Scrum, you’ll want dates associated with your backlog. If you’re on a two-week sprint cycle, for example, then the sprint dates should be well-known and the team should understand that they’re committing to a certain amount of work within that timeframe.
On the other hand, if you’re using Kanban, you may not have dates on your backlog. In Kanban, you simply order your backlog items by priority, with the things that you’re committing to for the current development cycle at the top. Items are processed in order, and they may or may not have dates associated with them.
On the roadmap side, estimates should be very high level. Many product teams use T-shirt sizes to estimate roadmap initiatives. Is this thing we’re considering small, medium, large, or extra large?
The backlog, of course, has much more granular estimates. A lot of organizations use points to estimate stories or assign relative effort level for every item in the backlog.
Because the focus of the roadmap and the backlog are very different, people tend to use different tools for each. Tools that are focused on communication, such as PowerPoint or product roadmap software like ProductPlan, are most appropriate for building the roadmap and sharing it with your stakeholders.
Because the backlog is short term and execution focused, it tends to have project management tools associated with it. Some examples of these tools include Pivotal Tracker, spreadsheets, or even task management software like Trello.
Creating a one-year roadmap and declaring, “This is what we’re committing to this year,” is growing less and less common. At ProductPlan, we’re seeing fewer organizations producing roadmaps that remain unchanged for the year.
Roadmaps are becoming more agile, and that means product managers are prioritizing them more often throughout the year. We’re definitely seeing our customers reprioritizing and reorganizing their roadmaps much more frequently than they used to.
With the roadmap, you are planning initiatives that may be several months in the future. You have an idea of what you want to accomplish, but you don’t know the specifics yet—you don’t know exactly how many resources you’ll need to assign to each initiative.
When prioritizing the roadmap, you need to consider your strategic goals. You should take into account things like customer value, competitive differentiation, risk, and what’s happening in your market. Internal metrics like development effort and support costs should also be considered, but at a high level.
Here are some strategies for prioritizing the roadmap.
One of the most common prioritization frameworks in product management is the value vs. effort model. Whether or not you formalize it in a document, this is the matrix that’s in most product managers’ heads when they’re deciding whether or not to pursue an opportunity.
The model works like this: You prioritize items that have high customer value and low effort to implement. Those items are the low-hanging fruit for your roadmap.
In the example above, the items in the lower right quadrant that represent low value and high effort are items that you will probably never pursue.
What about the items that require high effort but also produce high customer value? These items are up for discussion, and you will certainly want to include some of them on your roadmap. You may also want to pepper in a few items that have low value and require effort to implement.
The matrix can guide your discussion and help your stakeholders understand the trade-off decisions that you’re making as you plan the roadmap.
In the weighted scoring model, you look at the same criteria as in the value vs. effort model, but you formalize your thinking by assigning numerical values for benefits and costs. Many product managers use spreadsheets to go through this process, but ProductPlan has a built-in scoring model that is customizable based on your organization’s criteria for evaluating opportunities.
In this model, you assign values to every initiative on a scale from 1 to 5. For example, if an item has really high benefit, you might score it a 5. Then you will have an offsetting score for cost—1 for low cost and 5 for high cost.
I want to emphasize that at the end of the day, the score itself doesn’t really matter. You don’t want to prioritize based solely on the scores because the scores are subjective. Use the scores as a basis for having a discussion with your stakeholders. The discussion, in my opinion, is the most important part.
On top of that, you’ll want to take into account things like competitive differentiation and customer delight that are really hard to capture in a score. You’ll also want to use your good product management instincts and draw on your knowledge about your user personas and your market.
The Kano model is a way of prioritizing features and future initiatives based on how much customer delight they will deliver.
There are several types of features in the Kano model, but let’s start by talking about basic threshold features. These are features your product has to have simply to be competitive. If your product is missing core functionality, you will have very low customer delight. But as you continue to invest over time in those basic threshold features, they have diminishing returns.
For example, I used to work for a B2B SaaS company that produced accounting software. In order to be competitive, we needed to have an accounts payable module. If we didn’t have accounts payable, people wouldn’t look at our solution. However, those weren’t the features that moved the needle. Once we had the basic functionality for accounts payable, we didn’t necessarily need to continue investing in it to remain competitive.
But there are some features that give you a linear return as you invest in them. These are called performance features. As you continue to make things faster and better in your system, for example, you are going to get a commensurate return in customer delight.
Finally, there are excitement features. Sometimes excitement features aren’t the things that customers are asking for. Customers may not even know these features are possible. But as you invest in excitement features, they give you a disproportionate return in customer delight. So you want to pour investment into excitement features—although not at the expense of performance features and basic functionality.
The backlog, by its very nature, is prioritized frequently—even sometimes within a sprint. As your team move toward the next sprint, the product manager should be reordering the backlog in light of the factors that are changing within the organization.
The backlog represents the initiatives that you’ve already agreed to on the roadmap. The only thing you don’t yet know is development order, and that’s where prioritization comes into play.
Backlog prioritization is often based on project management metrics: story points, available resources, whether or not a team that specializes in a particular area is available. While roadmap prioritization is about big-picture strategy, backlog prioritization is much more granular and precise. You still want to take customer value into account, but many of these decisions have already been made for the larger initiatives on the roadmap.
The methods I’ve already talked about—Kanban, the value vs. effort model, weighted scoring, and the Kano model—can be used for prioritizing the backlog as well. But here are three additional methods you can use for the backlog specifically.
Story mapping is a method of planning out different releases. I’ve used it on several occasions to map out the MVP for new products. There is software you can use to do story mapping, but many people use physical cards or Post-it notes.
Your goal is to map out the user’s flow through your system by arranging cards from left to right. In the example above, the first thing a user needs to do is register and log in. After that, they need to update their preferences. And then, in the next section, they need to search for a room, view room information, and so on.
You then divide the different stages of the user journey into columns, and within every column, list out of the major features involved in that stage. Then, prioritize those features vertically within each column. For example, you wouldn’t have a system if users couldn’t register for an account, so that feature takes highest priority.
Finally, you can draw horizontal lines to represent releases. Your first release should have the minimum functionality in order to provide some level of customer value, and successive releases should build on that.
In MoSCoW analysis, you prioritize the backlog according to:
You can use MoSCoW analysis in conjunction with story mapping and other prioritization methods to drive a discussion with your team.
A lot of companies group stories for a particular sprint or development cycle together based on themes. A theme is often at a higher level than an epic.
What you want to do when creating themes is think about what you’re going to be delivering from a customer’s perspective. For example, you might have a theme for increasing shopping cart completion, and then you would pull stories into the sprint that relate to shopping cart completion.
In the end, the technique you choose isn’t as important as the conversation your team has about the priorities. Whether you are on the product or development side, techniques like this can go a long way to getting buy-in from your team and stakeholders.
Category: Productivity Community Integrations
