Let’s start with a bit of contrast. Company A meticulously lays out an annual plan, outlining projects and features on a precise timeline. Their product roadmap answers questions like, “Who gets resources from whom?” and “Who made their deadlines and who didn’t?” It looks an awful lot like a Gantt chart. Employees at company A know exactly what’s going to happen and when. They get rewarded when they deliver the promised output on time.
Company B hasn’t got a clue what’s going to be built this year. But there’s alignment on which company goal they’ll be pursuing: 2024 will be all about, drumroll please, increasing revenue. They’ve set team-level outcomes, so each team has a broad understanding of how they can contribute to the company goal. Employees are rewarded for making a difference for the customer, and eventually, the business. The way there is unclear. This is understood and embraced.
So, which of these two companies do you want to work at? Most PMs will raise their hands at company B, but harbor a secret preference for company A. Let’s be honest, working at company A can feel great — you get a pat on the back for delivering features on time, your sales team loves you for jumping when they say jump, and you sleep soundly at night. Delivering output is a lot easier than delivering outcomes.
It’s no surprise that most product organizations work in a feature-driven manner. But working in an outcome-driven In this article, we’ll talk about feature-driven vs. outcome-driven roadmaps and why outcome-driven roadmaps can actually be more efficient and productive. We’ll talk about the do’s and don’ts of moving to an outcome-driven roadmap, and its dangers, and give a few examples.
The dangers of feature-driven roadmaps
It’s hard to build products that customers want, need, or love, and it’s hard to create features that drive business results. And even the best product managers are wrong most of the time about what will move the needle. Some harrowing figures for you: 80 percent of features are rarely or never used. At AirBnB (famous for its experimentation culture), 92 percent of A/B tests are failures At Microsoft, about two-thirds of ideas fail
The worst feature-driven roadmaps are full of fully-formed solution ideas that are copy-pasted directly from the highest-paid or loudest person in the room, with little to no scrutiny. They include concrete timelines to make stakeholders happy and are paired with a gigantic product backlog. Features are built because they’re requested, not because they’re assumed to have a positive impact on a specific metric. It’s safe to assume that the vast majority of these solution ideas will add no value.
The best feature-driven roadmaps outline only a few items into the future. The importance of each item is based on an understanding of the target customer and based on concrete proof points, e.g., patterns detected from customer interviews or customer service tickets, multiple sales requests, shadowing, or prototyping. The product manager has a strong, evidence-backed assumption that this feature will move a specific metric. Around half of the items on this roadmap will still add no value. That’s OK, if they have product analytics in place to monitor feature retention and adoption, and can easily reverse their decision: Source: 2019 Pendo adoption report.
Feature-driven roadmaps provide a false sense of security that delivering a specific feature will deliver results. They feed straight into the four villains of decision-making as outlined by Chip and Dan Heath in their book Decisive:
Looking too narrowly at a problem — Caused by diving immediately into solution modus without testing whether the problem is worth solving, or whether there might be a better alternative solution) Confirmation bias — Looking for evidence to support your hypothesis, disregarding everything else Letting short-term emotions have an impact on decisions — Such as falling in love with your solution idea Overconfidence
Introducing the outcome-driven roadmap
I can’t say “outcome” without thinking about Teresa Torres (if you haven’t read her book Continuous Discovery Habits, do it now), and I lean heavily on her thinking when working with outcome-driven roadmaps:
Inspired by Teresa Torres’ book, Continuous Discovery Habits.
Rather than dictating which product changes will be made at which time, an outcome-driven roadmap looks like a prioritized list of product outcomes, or in some cases, traction metrics, that the team will be aiming to achieve. Ideally, these outcomes tie back to company-level goals or OKRs. Instead of saying, “This is exactly what we’ll be doing in the future,” an outcome-driven roadmap provides a frame for how we will make decisions and shows what success looks like.
Product outcomes measure the value a product brings to the customer or business. Examples are increases in engagement, conversion, average order value, upsell, free-to-paid rate, activation, etc. Good product metrics are a leading indicator for business metrics. For example, an increase in the free-to-paid rate is a strong leading indicator for an increase in revenue. Giving your team the task to “increase revenue” is so broad that it doesn’t give enough foothold or clarity to know what to do next. Business metrics aren’t actionable. However, when assigned the product metric “increase the free-to-paid ratio, teams can ask themselves, “What is blocking our free users from upgrading to paid today?” They can then identify potential friction points, problems, or needs (which Teresa calls opportunities), and generate fitting solution ideas.
Your outcome-driven roadmap should be short, and continuously adapted. 3–5 outcomes ordered by priority is enough. Focus is the name of the game. The top one or two outcomes can be fleshed out with high-level solution ideas and experiments to validate these ideas.
The do’s and don’ts of an outcome-driven roadmap
Do’s
– Tie back ideas to company-level goals/OKRs
– Commit to specific solutions (but you can present “potential solutions”)
– Assign outcomes that the team can move autonomously (it’s not an issue if other teams or external factors also have an impact on that outcome)
– Commit to timelines on when an outcome will be achieved. This goes directly against the principle of accepting uncertainty. If you accept that most of your assumptions will be falsified, you can’t reasonably provide a timeline for when something turns out to be true. You can still include a time component by categorizing outcomes as now, next, and later
– Specify why this outcome matters
– Overengineer to present a perfectly defined roadmap on day 1
– Iterate and make your roadmap more concrete as things come into focus
How to move to an outcome-driven roadmap
When you’re just moving from feature-based to outcome-based ways of working, you’ll likely struggle to fill up the roadmap with feasible performance goals. Sticking with the example above, you’re essentially telling your team to bin their old trusted roadmap, which told them to build features A, B, and C in the next three months, and replace it with the outcome “increase the free-to-paid rate.” Please resist the temptation to reverse-engineer your old feature-based roadmap by simply assigning the ideas that were already there to an outcome. It’s far better to work top-down. Start with your desired outcome and ask: What is blocking customers from bringing the business there? In our case, what is blocking free users from upgrading to paid? You might not know at this point, and that’s OK. Your first outcome-driven roadmap can be very high-level and include only learning goals, rather than performance goals.
Example outcome-driven roadmap v1 (lots of uncertainty)
In this scenario, the onboarding team is tasked with increasing the free-to-paid ratio. They can’t confidently say yet whether they can move this number by 1 percent or 50 percent because they’re unfamiliar with it. Their work will revolve around learning (extracting insights from five interviews/surveys with churned users) and finding something that increases the conversion rate (finding one strategy with a positive impact on the activation rate).
The acquisition team is in a similar boat. To ultimately improve the website visitor-to-sign-up rate, they’ll look for the top three reasons why visitors aren’t signing up today, and they’ll be implementing a heatmap on the website.
In a later iteration, the teams can use their learnings to make the outcome-driven roadmap more concrete and populate it with performance goals.
Example outcome-driven roadmap v2 (strong hypotheses)
Based on customer interviews, shadowing, a competitive analysis, and eating their own dog food, the onboarding team has formulated a…
Source link
