“Where we’re going we don’t need roa… no wait we DO need roadmaps!”
'Said Doc Brown to the product manager.'
Okay, so Marty Mcfly was never a product manager. But if he had been… he would've definitely been given the advice above (and there probably would have been more stringent testing on the time machine, but anyway…). Because the product roadmap is, of course, an absolutely essential part of a winning product strategy.
The product roadmap acts as a guide and strategic plan of action, which clearly communicates how your short-term product efforts match up with your long-term organizational goals.
It serves as a shared source of truth that product owners can utilize to outline the vision, future product functionality, priorities, progress, and new features that will be released. The product roadmap really sets the bar for communication, and in agile product development, it offers crucial context for the day-to-day work of the team.
Traditionally, the feature-driven product roadmap has been a staple of product development. Full to the brim of features and enhancements that, when taken in isolation, don’t actually mean a whole lot. In fact, these roadmaps often lack representations of any desired outcomes. That’s why there’s been a steady shift away from the feature-based product roadmapping of the past, towards a more outcome-focused future.
But should you make the change?
Let’s unpack the problems with feature-driven product roadmaps, and why more teams are focusing on outcomes. Ultimately, we’ll dive into how adopting an outcome-driven mindset can make your product roadmap work better, bring more focus, and communicate more effectively with stakeholders…
Problems with feature-driven product roadmaps
It can certainly be argued that there’s an abundance of product roadmaps out there that simply list features. These features are normally set out on a vague timeline, which creates a lot of pressure on teams to build everything on that list, even when they don’t really solve the right problems.
The standard procedure is to complete one feature, then move on and start developing the next. This happens even when the overall product strategy and user needs have actually changed since the roadmap was put in place.
The feature-based roadmap ends up leaving product managers in a position where they’ve delivered on almost every feature within the intended estimate, but the key metrics are all going in the wrong direction. Unfortunately, this can be quite common with feature-list product roadmaps. Teams can often continue to doggedly deliver on the list, even when features aren’t hitting the mark.
“Feature roadmapping adopts a predefined prioritization method, not responsive to the goals and needs of the company or market...”
“A roadmap based primarily on customer requests is an example of a feature roadmap because it often leads to focusing on the superficial level of customer needs and wants and you create features to solve them on an incremental level.”
Becky Flint, CEO of Dragonboat
Becky Flint knows all about how having an outcome-driven culture can be a solid foundation for roadmap success that ties everything together. A feature-driven roadmap means you’ve already set out your list of features and set some sort of priority. But as your customer needs change and your organization evolves, these defined priorities need to evolve too.
Escaping the feature-driven product roadmap
The list-based roadmap can set product managers down the wrong path, especially in large organizations where a top-down culture often translates to senior management handing down features to teams to deliver.
You’ll likely feel backed into a corner, and have your role boil down to just delivering each feature most effectively. This feature-driven mindset can often be a side effect of a product strategy that’s more aligned with ticking off features than creating positive outcomes.
So how do you escape from the feature-based roadmap path, and start heading in the right direction?
The answer - you start focusing on the ‘why’ as well as the ‘how’.
Adopt the outcome-driven product mindset
“Many product people I work with still use traditional feature-based roadmaps and are fairly new to the concept of outcome or goal-oriented roadmaps. The whole point is rather than focusing on output and deliverables, i.e, “what needs to be done?” try asking, “why do we want to enhance the product? What is the specific value that we want to create?”
“What are the specific outcomes and goals we'd like to achieve?” That might be to acquire more users or customers, to increase engagement, to improve conversion and start generating revenue, etc. I think part of the reason why feature-based roadmaps are still dominant is that it’s hard to shrug off that traditional way of doing it.
There's an interesting correlation between product roadmapping and the level of empowerment that product people have. I find that when product people aren't fully empowered, they're often given a feature-based roadmap and told to deliver.”
Roman Pichler, Product Management Author, Consultant, and Trainer
You can listen to more of what Roman had to say when it comes to embracing the outcome-driven product roadmap approach, on his For the Love of Product podcast episode.
It’s important to forgo the features and start focusing on the actual problems:
- Focus on the outcomes.
- Focus on how things will look if the team succeeds.
- Focus on how your customers will feel.
- And focus on what your customers will now be able to achieve.
By taking this approach, you can avoid being stuck delivering on a list of features, and instead, your whole team can own the problem.
The outcome-driven product mindset places more autonomy back within your teams and allows for more knowledge to be shared. You’ll have greater certainty on when an actual customer problem is solved, as opposed to when a particular feature is shipped.
When you gain clarity on outcomes, you’ll be able to realize a wider range of possibilities and gain better context for specific items on your product roadmap and their prioritization. At the same time, you’ll also be able to ensure the product strategy is still well communicated and consistently adhered to.
With clear outcomes, every necessary step is captured, along with the reason each step is there. The reason is well understood, extraneous steps are avoided, and the desired goals are more measurable.
Building an outcome-driven product roadmap
So, you’ve decided to commit to focusing on outcomes, as opposed to a roadmap of endless features. But how do you begin putting an outcome-driven product roadmap together?
Just like your overall goals, any outcomes you put in place need to be measurable, and recognizable to your stakeholders and customers as something valuable. For example, focusing on an outcome like “the customer getting seeing more marketing emails” isn’t valuable to them. So, let's summarize some key steps you can follow to build an outcome-driven product roadmap.
Ensure your product vision, strategy, and objectives are aligned
A strong product roadmap needs to effectively communicate your product vision, strategy, and objectives. It needs to make them understandable and unite your team behind a common purpose.
To do this, think about the long-term outcomes and benefits you want or need to deliver to your customers. And when crafting the product vision and strategy, consider the following:
- What you hope to achieve in the short and long-term.
- Customer insights.
- Market and technology trends.
- Competitive intelligence.
- Your organization’s business model.
- Any unique differentiators.
Once you’ve cemented your product vision and strategy, it’s time to break them down into objectives. These objectives should represent the desired outcome for your customers or product, while also helping you prioritize decisions around the features to focus on next.
Prioritize the features based on your desired outcomes
So, you’ve aligned around your central vision, strategy, and objectives. Next, you need to prioritize the features that will go onto the product roadmap. This stage can be a little overwhelming due to the amount of information you’ll be dealing with while juggling stakeholder needs; from customer insights and date-based milestones to the capacity of your team.
Customers can be a great source of feedback at this stage, but keep in mind their suggestions may not address the actual underlying problems. But going through this stage will help shift your focus from the ‘how’ to the ‘why’.
Check out our product prioritization frameworks by becoming a PLA member. Having a framework in place will help you assess the various inputs more effectively.
Create a product roadmap to communicate your features
Time to create the roadmap itself, which needs to communicate the products and/or features you’re building. It needs to outline:
- Each planned product feature.
- When each product feature will be worked on.
- Roughly when a specific product feature will be released.
- And why certain features are a priority above other options.
To craft an informative and easily understood outcome-driven product roadmap, remember to set realistic expectations around when features will be rolled out so other teams can plan accordingly. You don’t have to be terribly specific with a deadline, just communicate a general time, like a month of the coming year.
Keep in mind you can be as detailed as you want when it comes to outlining the features you’ve planned into the timeline. But ensure you clearly explain why you’re including a feature to provide the right amount of context.
Your teams must know exactly why you’re building certain features next, as this provides valuable strategic context. This will alleviate stakeholder concerns, as they will better understand the rationale behind decisions.
Empower your team around the product roadmap
Now it’s time to lay out your outcome-based product roadmap and empower your team by providing them with all the information they require. Ensure each product team member has access to the roadmap and anyone else involved in the product lifecycle.
Of course, the benefit of using outcome-driven roadmaps, which focus on broad timelines, is they can meet the needs of varying stakeholders and senior executives. You just need to make sure they include information such as market opportunities, and profit and loss details if needed.
From feature-based to outcome-driven roadmaps
Remember, a product roadmap is a living, breathing document that needs to allow for deviations along the way. It’s okay to have several versions, depending on your audience. You may still require a feature-driven roadmap, especially for things in the shorter term.
External teams may need to know exactly when you’re delivering certain features, and the sales and customers will need different details than engineering, so this kind of roadmap can help with reassurance.
But it’s important to show how you’re driving towards outcomes. To communicate how your strategic initiatives will evolve from a problem into a solution. The outcome-driven roadmap works extremely well for your internal development team because it allows you to bring clarification and focus. It allows you to stop loading up your product with features that users may not want.
It will likely lead to getting the maximum impact out of existing features, instead of just piling new things on top of them. And may also allow you to retire certain features that are getting in the way of your customers.
But you have to shift away from the mindset that sees your roadmap as a list of commitments, that leads you down a path where shipping features have become more important than delivering outcomes.
So perhaps it’s time to take a new approach. Forgo the long list of features and focus your product roadmap on outcomes!
Are you making the switch from feature-based roadmaps to outcome-driven roadmaps? What advice would you give? Let us know, by continuing the conversation on our Slack community.
