Imagine this… You’re a new product operations manager joining a company that’s reached product-market fit, has a few product managers, and a brand new Chief Product Officer who wants to move away from feature-based roadmapping to outcome-driven roadmaps. You’ve read Marty Cagan’s books, “Inspired” and “Empowered” and are now trying to figure out how to make the switch from product management to portfolio management. Your goal is to empower your product organization to become truly outcome-focused. Sound familiar?
At Dragonboat, we’ve first handedly led the scaling of multiple startups into unicorns and have been working with many teams to support their journey from feature-focused roadmapping to outcome-driven OKR roadmapping, an important aspect of responsive product portfolio management.
In this post, we’ll share a summarized version of a recent conversation between Dragonboat CEO, Becky Flint, and a new product operations manager and product manager (both work in a new scaling company like the one mentioned above). Read on for Becky’s practical advice on getting started with outcome-driven roadmaps.
How Do Outcome-Driven Roadmaps Differ from Feature Roadmaps?
Typically, product managers have a product backlog of ways they think a product could improve based on customer feedback, market insights, and so on. This practice is okay. At some point, Product Managers were taught that you should always have a well-groomed, prioritized backlog. Sounds good, but that’s the opposite of an outcome-focused approach. The reason is that when you groom the list of features you want to build, you’ve already decided on some sort of priority. However, as the business, customer, and market evolve, the way you define priority should also evolve, right?
Feature roadmapping adopts a predefined prioritization method, not responsive to the goals and needs of the company or market. Outcome-based OKR roadmapping adjusts priority and focus based on the business and market needs.
For example, let’s say you’re a company whose first product is doing really well and people are adopting it in droves. Great! In this case, you’re going to naturally gather a lot of feedback from your customers. You start to collect this feedback and create a roadmap based on it, according to how many people mentioned certain challenges and issues, etc. This all seems great, right? At first, yes, but I’d argue this is not the best way to define your roadmap.
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.
Whereas, outcome-driven roadmaps differ because they originate from a higher level of needs (goals). To explain, first, let’s take a step back. For example, an executive will look at the product focus in a different time horizon than a director or product manager.
So from the perspective of the company, you might say, “Okay, if we’re starting fresh this year, what’s the area we’re going to focus on?” The board, investors, and the finance team will come in and propose a business goal such as, “We need to grow 100% YoY.” The next question is then, “How do we achieve that growth?” The outcome-driven roadmap will be the product team’s answer to that question, throughout the year or quarter.
At the highest level, outcome-driven roadmaps derive from a strategy that’s in alignment with the overarching goals of the company.
Product-led organizations are abandoning feature-based roadmaps because they can result in teams delivering a faster horse. Instead, they want to achieve market-leading innovation via outcome-focused roadmaps that follow the responsive product portfolio management framework.
It’s not to say that customer insight isn’t important. It’s critical to create products that solve customer needs, but be careful when collecting feedback. There can be a self-selection bias in the feedback because only some of the customers like to give feedback. We learned to let customers show us what they are doing instead of what some are telling, by analyzing user behavior in a variety of qualitative and quantitative ways.
What Are the Steps to Build an Outcome-Driven Roadmap?
In an outcome-focused company, the executive team will conduct periodic strategic product planning sessions, resulting in company-wide OKRs. In these sessions, the leaders may ask, “If we’re going to grow revenue 80% YoY, what are the key buckets we need to fill?”
Then, the team sets key results to help reach that objective. For example:
- Grow new customer revenue by X%
- Expand existing customer revenue by Y%
- Launch a new service
In a strategic planning session, you take the business goals (objectives) and turn them into strategic goals (key results), which provide more detail on how you plan to achieve them. This level of alignment must begin at the executive level.
During your own strategic planning, look at all your goals and conduct a SWOT analysis wherein you identify your company’s strengths and weaknesses, as well as the market; what opportunities and threats exist today.
Based on that analysis, seeing where the company currently stands and where it wants to be in one year, let’s say, in terms of growing revenue, the next step would be to generate a list of BIG initiatives or “big rocks” to potentially undertake.
Remaining at the executive level, it’s time to then narrow it down to no more than five to six “big rocks.” Even giant companies like eBay limit themselves to no more than six because the whole organization is going to be moved by them.
These five or six “big rocks” are the strategic goals aka outcomes that your organization must produce.
Ultimately, being outcome-focused implies starting with top-level strategic goals which become a set of actions that translate to strategic goals for the level below.
Read more about the rock, pebble, and sand product management approach.
Should Features in Our Product Backlog Link Back to a Specific Outcome?
Features can come from your known backlog, when they tie to known pain points to solve.
So you can take a problem area, for example, feature adoption, and your goal could be to increase the adoption rate by 30%.
And you say, “Okay, where are the problems related to feature adoption?” Then you prioritize your backlog items into that. Today, teams that use feature roadmaps very rarely state the desired outcome of a new feature explicitly, yet this is important to communicate with stakeholders.
Essentially, you have to ask, “Which are the things we want to solve first? What is the worst pain point or the most valuable improvement we could make?” and then prioritize your backlog items towards the answers to those questions.
Your prioritization method or framework needs to be highly related to the goals that matter for that specific roadmap.
If your main pain point is feature adoption speed, then you know not to focus on customer referrals at this point because users need to adopt the feature quickly and be happy with it before they refer it to others.
Therefore, looking towards the next quarter, if your aim is to drive feature adoption, you can look at all the things that the team could do, including the things that have already come up. Move those items up on the roadmap, ship them, then measure their impact on feature adoption.
If those changes moved the needle enough and drove those metrics, then the team can focus on driving referrals next. While you don’t have to do just one or the other, it’s important to be primarily focused on one.
That way, from a product operations perspective, you have a dashboard and you can work across multiple teams because all outcome-driven roadmaps depend on cross-team collaboration.
How Often Should We Communicate Our OKR-Roadmaps to Stakeholders?
In an outcome-focused product team, the communication, or rather, engagement, with stakeholders should be bi-directional and frequent. There are different types of engagement. For example at semi-annual strategic alignment, the engagement and communication are around goals and strategies at the executive level.
And then on a quarterly or bi-monthly basis, sort of the mid-range for alignment, the communication and engagement is around reviewing their annual or semi-annual goals, and then adjusting the quarterly focus.
And then there are also bi-weekly or weekly product operations reviews or roadmap updates, which are mostly around the product team itself. They look at their metrics, KPIs, goals, progress against the roadmap, etc.
The product team may also have a bi-weekly read-out interaction with other cross-functional teams like sales and customer success. This does not need to be a meeting. It can be just a refresher of the point in time state of the product portfolio. A tool like Dragonboat can help with stakeholder engagement by creating a central source of truth for data to be accessible and referred to in real-time.
If the function exists, product operations designs and orchestrates the product rhythm, from annual/ semi-annual strategic planning to quarterly alignment, and bi-weekly or weekly ops reviews and stakeholder engagement.
How Can Outcome-Driven OKR Roadmaps Make Our Product Managers’ Lives Easier?
Outcome-driven roadmaps make it easy for non-product managers to understand why one feature is prioritized higher than another.
When communicating with stakeholders, product managers may use scores like RICE (reach, impact, confidence and effort) or other scoring systems. But these terms and numbers in the scores are hard to understand.
When speaking about the roadmap in terms of business objectives, it becomes more tangible, everyone can understand the same language. Product managers will say, “We’re going to aim towards greater feature adoption because that will help us to grow faster,” rather than something like, “Feature A will have a 25% larger button.”
There are often multiple teams involved to drive a desired business outcome. With an outcome-focused OKR roadmapping practice, not only do you build an outcome-focused product organization, you build a collaborative organization.
How Often Do You Suggest Refocusing Across Team Roadmaps?
Outcome-focused OKR roadmapping by definition needs to be adjusted periodically. How often depends on how often you can measure the impact of your new product releases.
Speaking generally, there are three types of outcome velocity:
Fast to result, for example, a growth roadmap is often filled with quick experiments like A/B tests. This type of roadmap obviously changes very fast, because as soon as you release something to production, you can measure the outcome. You can then use that information to inform the next decision.
Slow to measure, for example, platform work, refactors, etc. It takes a long time to build and may or may not be immediately measurable in a meaningful way.
And then the third type of roadmap is somewhere in the middle. You might ship something in a month or two, but it doesn’t immediately hit customers. This happens especially if you’re in B2B where you need to get users to adopt it and then get relevant metrics. So, in this case, it will take longer.
The frequency with which you refocus your roadmap depends on how quickly you can measure the change in the outcome metrics.
That’s why, for most B2B companies, quarterly roadmap alignment becomes more common because they release something maybe once or twice a month, and then it takes a couple of months to really see the impact.
Do You Have Any Tips on Making the Change to Being Outcome-Focused Stick?
There are three things that teams need in order to pull off the transition to being outcome-focused.
- Find someone to act as a change agent – in many cases, that could be the Chief Product Officer. They were most likely brought on to scale and take the product org to the next level. This is often when the Product Ops role is introduced to help product teams scale effectively.
- Plan an agile rollout – make outcome-focused roadmapping part of a responsive product portfolio practice. Product is a product. Have a vision, roll out gradually, and update as needed. A common path is to start with mapping initiative to OKRs, then expand to cross-portfolio dependency mapping, then portfolio allocations, and then closing the loop with outcomes fed back to planning.
- Use the right tool to complement the process – rather than starting with homegrown spreadsheets, find a tool that has the process and framework baked in.
Adopt the right outcome-focused OKR roadmapping / ppm tool along with your process change because the tool will facilitate and reinforce the change and provide visibility on improvements needed.
For example, imagine you want to transition your team from waterfall to agile by using sticky notes or spreadsheets. It would be very hard. But if you say, “Hey, here is agile and scrum 101, and here’s Jira. Let’s use it as we transition to agile development.” Then, you’ve already made some progress in the right direction just by starting to use Jira with its structure built for agile development.
Are you making the switch from feature roadmaps to outcome-driven roadmaps? What other advice would you give? Let us know, tweet us at @dragonboat_io!
