Have you embraced the outcome-driven product roadmap?
The product roadmap is an essential part of a winning product strategy, acting as a single source of truth that outlines the vision, priorities, progress, and new features.
There’s been a steady shift away from feature-driven roadmaps, a staple of product development, towards more outcome-based strategies. And we got the chance to chat with internationally renowned product management expert, Roman Pichler, about all things product roadmaps.
Roman explored the power of focusing on the why instead of the how, when to use different types of product roadmaps effectively, and more. Here, we’ve got some of the key highlights from the session, but if you want to listen to the full interview, simply click below. 👇
The first roadmap I ever put together was full of features. Traditionally, a product roadmap is essentially a timeline that shows which features will be delivered and when.
That can work. But for digital products, throughout the entire product lifecycle, we have some amount of change or uncertainty. Something always seems to be changing, whether that’s the market, the user needs, or their technologies. I don't really find traditional roadmaps particularly helpful, and certainly not if they have loads of features.
The shift away from feature-based roadmaps
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.
Different types of product roadmaps
I always try to keep things simple. For me, I like to distinguish between two main product roadmap types. There’s an internal product roadmap that really facilitates all the work that needs to be done in order to progress a product and essentially guides the work of the stakeholders and development team.
Then there’s the external roadmap. That shows the users and customers that the company is committed to the product and has some great ideas in the pipeline. To a certain extent, it can be used as a sales tool.
The main difference between the two is that you need to be careful in terms of the amount of detail that you put on an external roadmap. I wouldn't necessarily state specific timelines or dates. Some people don't like to show dates at all or specific timeframes on their roadmaps. Personally, I think for an internal roadmap, it makes a lot of sense.
I find that often there's a trade-off between fully meeting a goal or fully achieving the desired outcome and doing it in a timely manner. That’s when it's useful to have an understanding of the kind of timeframe or date we’re targeting.
When it comes to an external roadmap, I'd use very vague timeframes. The same is true with any detailed pieces of information, particularly detailed features. For an external roadmap, I think you either don't want to show any features or if you do show features, you want to really keep them very selective. Only detail very big product capabilities.
Effective project roadmaps
To create an effective product roadmap, it's important to base it on a validated product strategy. A product strategy describes the approach that you're taking in order to achieve product success. I would expect that a product strategy talks about the target group, the market, or the market segment.
You need to ensure you’re addressing the main benefit that will be generated for your users. Finally, the business benefits and goals information needs to be available. You need to have data to show that these statements are likely to be valid. l like to recommend that the roadmap shows how a validated product strategy will be implemented over the next nine to twelve months.
The benefit of having such a validated product strategy is that you can then directly derive the product goals from the user's needs and goals. Ask yourself, what will be helpful intermediate steps to address the problem, or generate the desired benefit for the users?
I think that's very hard to achieve. The point is that you attentively listen to people, and you show people that you care about their perspective. You care about their ideas and concerns, and you try to reach a consensus. You try to reach an agreement, but at the same time, you do want to make sure that the right product decisions are being captured. The roadmap should show the meaningful progression of your product and how your product is likely to create value.
Choosing the right strategy
I was working with what I thought was a really interesting startup. We were discussing product roadmapping practices, and I was helping the guys build an outcome-based roadmap.
A few months later, we had a follow-up session. They showed me the roadmap that they'd sent to the investors. And it was nothing like what we discussed before. It was completely feature-based. I asked them why they had created this roadmap. They said they used outcome-based roadmaps internally, but the investors wanted us to create this roadmap.
It shows how difficult it can be for people sometimes to do what they think is right. It goes back to empowerment and respect. I've seen similar things in larger organizations, where a product person says they’d love to use outcome-driven roadmaps, but the stakeholders won’t allow them to do it. This isn’t really a road mapping issue. It’s really an issue around product management and maturity
How product leaders can share the roadmap
Avoid speculative pieces of information on your roadmap. Only look as far as you can see. If that's six months, this is where you should stop. If it's nine months, stop at nine months. I've learned that products that consist of more than software often have to look out a little bit further simply because of the longer hardware cycles.
If you have some hardware, you may have to look at the next 24 months, but only look as far as you can realistically see. Avoid too much detail, keep the product roadmap high level and strategic. If you do include features on your roadmap, which I still like to do, it’s simply to give the stakeholders and the development teams an idea and create a shared understanding of what it might take in order to meet a goal.
Think about product capabilities, no epics, no user stories that are too detailed, and create a competition with the product backlog. Limit the number of features per outcome to three. Make sure that every feature, every deliverable, every output, is required in order to achieve the goal or outcome. The features must be dependent on the outcomes. That means if a stakeholder comes to you and says they’ve got a great idea, you'd have to find an outcome or goal that this feature supports.
If you can’t find one, then you either should decline the request, or you should consider adjusting one of the goals or introducing a new one. Once you get closer to launching your product, or once you've launched and you've received the general market response, then you should be in a better position to look out further. You can then create a roadmap for the next six months or so.
