Avoid ‘Product’ Ground Hog Day: Unlocking Success When Crafting an Outcome-Driven Roadmap

John Utz
Product Coalition
Published in
12 min readOct 30, 2023

--

It was another bad start to what seemed like Groundhog Day.

“I don’t care about outcomes, your objectives, or your key results; I want to know when I will get this feature!” an angry internal stakeholder shouted.

Now, to be fair, I wasn’t giving an inch.

This was the third conversation we were having about the product, an app that served our own company along with external customers. We were at odds. And we all know that internal customers take more work to manage. Ugh, so entitled — haha.

“Look, we are moving away from feature commitments to outcomes. It’s happening whether you want it or not. I won’t give you a commitment on this feature. So either we work together to understand your objectives, call them goals if you’d like, and the outcome you are looking for from the product, or we will end the discussion, and you won’t get a committed set of work on the roadmap.” I said calmly, fighting back the anger while focusing on staying Zen.

The change from features to outcomes wasn’t going as planned or nearly as well as I thought. But I also recognized it was a significant change for stakeholders and customers. For the past couple of years, it had been all features, all day, every day. Sales sold based on features. And features are what stakeholders expected. That’s how budgets were constructed up until this year.

We shifted from functional and feature budgeting to portfolio and product budgeting. We moved away from feature commitments. We went away from detailed, long-term, feature-committed roadmaps. It was a lot of change — maybe too much. I was trying to be mindful and put myself in their shoes. But it’s not like we shut the product down. And we did not deprioritize their roadmap requests. I explained this many times.

A few more fights and arguments ensued.

But we got there. However, a part of me, a large part of me wished we had started with outcomes-oriented roadmaps from the beginning. Water under the bridge. It was a significant cultural change. Our commitment was firm, leadership backed the change, and it was underway.

If only I knew what I know today.

So, what is an outcome-oriented roadmap?

An outcome-oriented roadmap is straightforward in principle. Rather than features committed for delivery on a date, you shift to outcomes achieved by quarters. It’s relatively simple at a surface level. Yet, for many product managers, simplicity is challenging to achieve.

Unlike featured-based roadmaps, which focus on the delivery and output of capabilities, outcomes-oriented roadmaps prioritize desired outcomes or results — a key element of product strategy. A feature might be something like adding a search to the home screen. An outcome instead might be to help users find the information they are looking for in half the time.

Why go through the trouble? An outcome-oriented approach helps teams remain focused on the bigger picture, ensures efforts go toward delivering meaningful value to customers, and gives them the freedom to figure out the best way instead of having ‘the way’ committed well before discovery.

A quick side note — If you are a product manager who works in a company where this is the norm — congrats! Life is good. If you don’t work at an outcome-oriented organization, my condolences.

It may take time to reach an outcomes focus; however, the change is possible (and inevitable). Stakeholders will eventually seek results for their investment. I’ve moved product organizations from feature factories not once, not twice, but three times.

Starting your outcomes-oriented roadmap

When discussing outcomes and roadmaps, I am almost always asked what an outcome is in practice. Why? Even though the concept of an outcome is relatively straightforward, applying it can be tricky — especially at first.

Once understood, it’s a matter of identifying the optimal outcome. Outcomes that initially float to the surface are often weak. Optimal and meaningful outcomes take effort and time to tease out — plan for feedback and iteration.

Once optimized, it’s critical to tie the outcome back to the company’s strategy and objectives. Often, product managers skip this step in favor of speed. Do not skip this step.

The root cause? A need for more transparency. The company and/or product strategy are only sometimes openly shared. You must rectify this issue, but at least the strategy exists.

On the flip side, in many cases, lack of transparency indicates that the strategy does not exist or management did not set the objectives and key results (OKRs).

Let’s focus on that last issue — the objectives and key results are not set. Without clear goals in the form of objectives and key results, defining the outcomes on your roadmap can be difficult.

What about the customer’s goals? Of course, customer goals are important, but your roadmap must also incorporate goals from the company. You need both.

On the bright side — if there are no objectives and key results, you can create them for your product based on your understanding of the company and the product.

OKRs: What are they?

OKRs stand for Objectives and Key Results. OKRs are a goal-setting framework individuals, teams, and organizations use to define measurable goals and track their outcomes. As a result, they are a solid way to cascade strategy from the top to the product and the roadmap.

Objectives are 12–18 month targets with corresponding key results set quarterly. OKRs should be ambitious but achievable. Think about stretch goals for objectives that you can accomplish about 70–80% doing your job. 100% if you knock it out of the park.

The methodology originated at Intel under Andy Grove and has been popularized by companies like Google.

The three parts of an OKR are:

  • Objective: A clear and concise statement of what you want to achieve.
  • Key Results: A set of measurable milestones that track progress toward the objective.
  • Metrics: The data points you will use to measure the key results.

Here is an example:

Objective: Increase customer satisfaction by 10%.

Key Results:

  • Reduce the number of customer complaints by 50%.
  • Increase the number of positive customer reviews by 20%.
  • Increase the customer satisfaction score on our website by 3 points.

Metrics:

  • Customer complaints as measured by complaints submitted through all channels
  • Positive customer reviews as calculated on the Apple App Store and Google Play Store
  • Customer satisfaction as measured by quarterly surveys

Why do OKRs matter to product managers and product teams?

From a product manager’s perspective, OKRs help prioritize work, align the product team with the broader organization’s goals, and measure success in quantifiable terms. OKRs also empower product managers in the creation of an outcomes-oriented roadmap.

Let’s look further at how OKRs can benefit you as you create your roadmap :

  • Clarity and Focus: With clear objectives and measurable key results, a product manager can ensure that the team knows what is essential and what success looks like
  • Alignment: OKRs help align the product team with the broader organization, ensuring everyone works towards shared goals. This alignment is crucial for product managers who often sit at the intersection of business, technology, and user needs.
  • Engagement: Having clear and challenging OKRs can motivate teams, as they can see the bigger picture and understand the impact of their work.
  • Flexibility: Unlike traditional planning methods, OKRs offer the flexibility to adapt as you learn. If circumstances change or new information comes to light, teams can adjust their OKRs to reflect the new reality.

OKRs ultimately benefit product managers and product teams by creating clarity where ambiguity exists. OKRs enable a clear, measurable path forward and lay the groundwork to pivot if the product is off track. They also generate transparency from leadership to those working on the product daily.

How do I set OKRs and link them to outcomes on the roadmap?

I like to follow a 2-week process to set objectives at the beginning of the year and a one-week process to select or adjust the key results each quarter. I use a mix of individual reflection, top-down/bottom-up representation, and workshops.

When I set OKRs for the product, we start by reviewing the company’s OKRs (or goals). We then discuss which OKRs should cascade to a specific product as a team. We then think about creating OKRs for the product (if they have not already been set in the product strategy). Finally, we think about how those OKRs translate to the roadmap’s themes and the key results (outcomes) for each theme by quarter. Those themes and outcomes then form the basis for the roadmap.

Let’s look at an example.

Let’s imagine the company set ambitious objectives to take a 10% share in OKR management SaaS space (yes, that is real) and reach $100 million in recurring revenue over the next 18 months. The objective is 10% market share, and the KR is to reach $100 million in SaaS-based recurring revenue over 18 months.

Then, let’s imagine the company sells subscriptions to its software to small, medium, and large businesses. You are responsible for the version of the product that supports the small business market. Your segment revenue is $10 million. You need to double the number of customers to hit a 10% share in your segment. So, 5% to 10% share and $10 million to $20 million recurring revenue in 18 months. No problem, right?

Finally, let’s imagine you have a retention problem.

Your revenue would be $20 million if you didn’t have a 50% drop off of customers in the first three months. You know the objective for the small business segment is to hit $20 million in revenue, so if you solved your retention problem, you could get close to 10% market share and $20 million in revenue — no one hits 100% retention, but 80% would make a significant dent.

Your product OKR is increasing retention in the small business segment to 80%, thereby increasing revenue by $6 million annually.

How would you break this down into an outcome for the roadmap?

Your theme is increasing retention. Your outcome for the first quarter would be an increase in retention from 50% to 60%. What next?

This is where you need to break the outcome down to its component parts on the roadmap. What will enable a jump from 50% to 60% retention?

For simplicity’s sake, let’s break this down into three outcomes framed to benefit the customer (based on customer feedback) we believe will lead to this jump in retention.

  • Provide 24/7 live chat-based customer onboarding support during the first four months. This support will ensure customers can use the product successfully. We will measure this with a target of a 10% lift in the retention of customers using the chat.
  • Add a program to reward customers for engaging with new customers in the online community forum. How? With credits against their bill. Success will be measured by a 10% lift in retention of new and existing customers engaging in the online community.
  • Develop next-level, engaging training videos covering how to use the product based on the most commonly asked questions by new customers. Success will be measured by a 10% lift in retention of new customers engaging with the videos.

Simple, right :) I hope this example helps you envision how to translate company goals into outcomes on the roadmap. It will be challenging in the beginning, so don’t get discouraged.

The work is worth it!

The basic structure of an outcome-oriented feature

The structure of an outcome-oriented roadmap is the same format as your typical feature-based roadmap with one critical difference — rather than focusing on the output or task to complete; you focus on the desired result or outcome.

Shift output to outcomes.

This subtle shift will pay dividends as the team rallies around delivering value to the user instead of functionality.

The second change, less structural, is leaving the definition of the feature loose and open. You must give the team freedom and latitude to reach the outcome with guidelines/boundary conditions rather than a rigid, detailed definition of what you expect the feature to be. Outcome-oriented roadmaps encourage the team to achieve the outcome by collaborating on the solution.

Here’s a basic structure for an outcome-oriented feature:

1. Title/Name: Each outcome-oriented feature of the roadmap needs a brief, clear name that communicates its purpose at a glance.

2. Outcome: Define the specific, measurable goal the feature aims to achieve. This goal isn’t about what the feature does but what changes it brings for the user or the business. For example, instead of “Implement social sharing buttons,” an outcome might be “Increase content visibility by 20% via social shares”.

3. Metrics: Identify key performance indicators (KPIs) to measure the feature’s success. KPIs could be user engagement, customer satisfaction, revenue, etc.

4. Description/Details: This is a more detailed explanation of the guidelines and boundary conditions for the feature targeted at achieving the outcome. It should include its assumptions, constraints, boundary conditions, how it supports the defined outcome and any necessary technical details.

5. Dependencies: Dependencies could be other features, teams, or resources required to implement the feature.

6. User Stories/Use Cases: Define who will benefit from the outcome and why. What problem does it solve for them? This approach helps to ensure the feature is user-focused.

7. Status: Where is this feature in the development process? Is it still in planning, progress, testing, completed, etc?

8. Timeline: When is the feature planned for release? Considering and communicating how this fits into the product roadmap is essential.

9. Owner: Who is responsible for the feature? This person should be the go-to for any questions or updates regarding the feature.

Remember, outcome-oriented road mapping focuses on achieving business and customer goals instead of just releasing features. This makes the product roadmap a strategic tool that guides your product towards market and business objectives.

Let’s close with an example

Here’s an example of an outcome-oriented feature for a hypothetical project management software product:

1. Title/Name: Task Auto-Scheduling

2. Outcome: Increase project completion rate by 15% by optimizing task management efficiency.

3. Metrics: Measure the success of this feature by tracking project completion rates before and after implementation, the average duration of projects, and user satisfaction survey scores regarding task management.

4. Description/Details: The Task Auto-Scheduling feature will use machine learning to predict optimal task schedules based on project requirements, available resources, and historical data, automatically creating and adjusting schedules to ensure the most efficient use of resources and time.

5. Dependencies: This feature will require collaboration between the Machine Learning team for predictive modeling and the UI/UX team for creating an intuitive interface for schedule visualization and modifications. Also, it depends on completing the “Data Collection & Analysis” feature that will provide the necessary historical data.

6. User Stories/Use Cases: Project managers will use this feature to automate the initial scheduling of tasks and adjustments per the project’s needs. This change will save their time, reduce scheduling errors, and increase overall efficiency.

7. Status: In planning

8. Timeline: Planning and design to be completed by Q3 2023, development and testing by Q1 2024, and launch by Q2 2024.

9. Owner: Johnny Five, Product Manager

By focusing on the outcome — increasing project completion rate by improving task management efficiency — rather than simply the output — building an auto-scheduling feature — teams work toward the user’s goal, not a capability with a specific function.

Don’t set it and forget it

In closing, as you shift toward an outcome-oriented roadmap, don’t set it and forget it. Continuously challenge the outcomes and priorities. However, when you do, don’t reset with an eye on maximizing feature output; instead, prioritize the highest value outcomes you can achieve for the user and the company based on the OKRs.

If circumstances change or you gain new insights, change is necessary.

--

--

Customer obsessed digital product and strategy leader with experience at startups, consulting firms and Fortune 500. https://tinyurl.com/John-Utz-YouTube