Get the Outcomes on Your Product Roadmap Right

0:00Reumann's Product Management Podcast Product outcomes define the specific value your product is meant to create for users, customers and the business. When applied correctly, they align stakeholders create focus and give development teams clear direction. But, getting them right isn't easy. Too often product teams choose outcomes that are vague, oversized or worse, just features dressed up as goals. The results, confusion, misalignment and road maps that look strategic, but fail to drive meaningful impact. In this podcast episode, I'll address these issues and provide practical advice to help you define the right outcomes that maximize your chances of building a successful product. But before I share my recommendations, let me give a brief introduction to outcomes and outcome-based product roadmaps to make sure we're all on the same page.

1:01Traditionally, a product road map is a feature-based plan that assigns capabilities like registration, search and reporting to a timeline. Such a road map essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders, but unfortunately it has several drawbacks, including the following two. First, a feature-based road map can make it hard to secure agreement as stakeholders compete to get their features implemented. In the worst case, this results in a Frankenstein product, a collection of unrelated features with a terrible value proposition in a horrible user experience. Second, the features are sometimes regarded as a commitment rather than a part of a high-level plan that is likely to change. This limits your ability to experiment and learn to discover the best way to address the user and customer needs and create value for the business. These drawbacks are avoided by using a different approach, an outcome-based goal-oriented product

2:04road map. As the name suggests, this plan focuses on product outcomes, which are also referred to as product goals and objectives as in OKRs. These are acquiring customers, increasing engagement and reducing cost. What's more, using outcomes makes it easier to align stakeholders and guide development teams and it helps discover the right product functionality and direct the product backlog. If you're interested in learning more about outcome-based product roadmaps, follow the links in the show notes. As outcomes on a product roadmap play such an important role, the first step is to identify the right ones. To achieve this, I've found two methods helpful, first, deriving them directly from the needs and business goals stated in the product strategy, and second, determining them with the help of key performance indicators or KPIs. Let's start with the first one. And to make the discussion more concrete, let's use an example, say that I want to offer

3:09a new healthy eating app, its product strategy states that the user need is to reduce the risk of developing type 2 diabetes, and the main business goal is to create a new revenue source. Let's also assume that the business model I have chosen is freemium, giving away a free basic version and generating revenue through subscriptions. With this information in place, I can ask myself what the first concrete step is to meet the needs and business goals. My answer might be, help users understand their eating habits and acquire an initial user base. What I've done here is break down the two higher level goals stated in the strategy into more a more specific outcome. Applying this method not only helps determine the right product goals, it also connects the roadmap and the strategy. The former is literally derived from the letter. To put it differently, the strategy forms the foundation for identifying the right product

4:14outcomes. If I can see further than the initial offering, I would derive additional outcomes. These might include assisting users in improving their dietary habits and expanding the user base, as well as supporting users in achieving greater fitness and generating revenue through subscriptions. Together these goals form a meaningful narrative. We describe how the product is likely to evolve in the coming months. Each outcome is a step towards realizing the overarching needs and business goals, thereby helping implement the product strategy. Now deriving product outcomes directly from the product strategy is all well and good for a product that experiences innovation and change, that's it, the introduction or early growth stage, for example. But the method is not as effective for products that are stable or mature, that undergo incremental changes and smaller updates. Luckily, there's an alternative using the key performance indicators to identify the

5:15right product outcomes. Say that engagement, like daily active users, is a key indicator for my healthy eating app and that it has been declining over the past few months. I may then want to choose a product goal that addresses the issue and improves the metric. This might be enhancing the user experience by simplifying an important user journey, or providing performance and stability improvements, depending on what causes the engagement to be low. Another example would be an increase in software box and code complexity, which indicates that the product's health is degrading and that the software is becoming more difficult to extend and maintain. In this case, I might choose a product goal like decrease technical debt to reduce development cost to address the issue. In both cases, the outcomes identified must be aligned with the product strategy, they must help meet its user customer needs and business goals.

6:17This ensures that the product strategy guides road mapping decisions and that the road map and its outcomes implement the strategy. Once you've identified an initial set of outcomes, check that they are not features in disguise, that they describe product capabilities rather than the positive impact you want to achieve. Let's take my healthy eating app again to illustrate this issue. Say that I want to explore what the product could do for the users and I come up with measure calorie intake and determine blood sugar level. Do these statements then qualify as product outcomes? I don't think so. In my mind, they describe product capabilities and characterize the solution, but they don't state why it is worthwhile to progress the product. A good test is therefore to ask the why question. For example, why would it be helpful to measure calorie intake? The answer would then reveal the true goal such as help the users improve their eating habits.

7:18Therefore be careful not to mistake features for outcomes and ensure that your product goals always capture the desired outcome and not the output. After choosing the right outcomes and checking that they describe actual benefits, take the next step and get their size right. Road map goals should be no smaller than 6 weeks and no bigger than 4 months. Here is why. If an outcome can be accomplished in less than 4 weeks, it tends to be too granular, and often resembles more short term tactical goal like a sprint goal. And if it takes longer than 4 months to achieve it, it is too coarse-grained and does not offer enough guidance and focus. If it turns out that the outcomes you have identified are too big or small, rework them until they are the right size. In some cases, this may require splitting a larger goal into two sub-goals that can be met separately. I might for instance split an outcome like help users understand their eating habits

8:20into the following two goals. Help users understand their breakfast habits and help them be aware of what they eat for lunch in dinner. Now some product teams like to work with quarterly goals, this can make road map planning easier and help manage stakeholder expectations. But there is no hard requirement for all outcomes on a road map to have the same size and you should not be afraid to use smaller or bigger goals if required. For instance, if you discover that your product suffers from an increasing amount of technical debt that threatens its architectural integrity and makes it more expensive and time-consuming to add new features, you might want to set a two-month goal that addresses the issue, thereby deviating from the quarterly cadence, assuming of course that that's enough time to carry out the necessary work. Now it's great to have a B-hack, a big hairy audacious goal as the product vision and strategic needs and business goals that act as guardrails but aren't necessarily measurable

9:23and time-bound. However, when it comes to product outcomes, you should use goals that offer more concrete guidance and meet the following three qualities. First, they are specific, everyone understands what the goals mean and what it takes to meet them. Second, they're measurable, you can tell if the outcomes have been met or not, if they have created the desired impact, and third, they are feasible, the goals can be achieved without having to rely on overtime and hero efforts. It is common in my experience to initially identify comparatively big course grain protocols which are neither specific nor measurable and consequently they have to be reworked and improved until they are clear and contain a target. With specific outcomes in place, make sure that you can clearly determine if a goal has been met and if the desired impact has been achieved. For instance, if your goal is to acquire between 5 and 10% of new customers, determine

10:25how you're going to measure if the objective has been met. There's a successful acquisition required that an individual registers with your website for example, or should you measure if the number of unique visits has increased? And what does new mean? Should the customers belong to the same market or market segment that is currently served? Or do you intend to reach out to a new one? Additionally, state by when the goal should be met. In the case of an acquisition goal, you might have to wait several days or even a few weeks after the software is released before enough data has become available so you can understand whether the desired benefit has materialized. If however you find that making all the goals on your product roadmap specific and measurable is too difficult at present, then focus on the first outcome and ensure that at least this goal can be measured. Leave the other ones as they are for now and rework them when you review the product roadmap. Finally, check that each outcome is feasible and can be achieved without violating sustainable

11:28pace and requiring people to work overtime. The best way to do this is to involve the development team members in identifying and refining the goals as I'll discuss shortly. Moving on, you might be tempted to use multiple outcomes per time frame on your roadmap in an effort to maybe please the stakeholders and speed things up. For example, if you've chosen a quarterly cadence, you might opt for setting two or three outcomes per quarter. Now this might look like a good thing but it is likely to actually slow you down. Following multiple goals dilutes focus and undermines teamwork. A better approach is to use one product goal at a time. This offers the following three benefits. First enhanced focus and alignment, working on a single outcome creates a shared objective that everyone works towards. Second increased productivity and speed, a single shared goal encourages collaboration

12:31and it avoids resource conflicts and task switching. Third improved transparency, a single outcome makes it easier to understand progress and determine if the goal has been met. You should therefore avoid setting several product goals for a given period and if you choose to use multiple outcomes make it an exception and don't let it become the norm. If this is challenging consider using smaller goals that can be achieved in shorter timeframes and prioritize them as I'll explain in more detail shortly. Now the best product outcomes in the most amazing roadmap are of little use if the key stakeholders and development team members don't understand and support them. You should therefore ensure that the product outcomes are shared. To achieve this I recommend involving the individuals in setting the outcomes preferably in the form of a collaborative workshop in which you take the following five steps. First jointly identify candidate outcomes for example by asking the workshop attendees

13:34to capture their goals or notes, then invite them to share their suggestions. Check that the items are actual outcomes and not features in disguise. And group similar items and explore if they support the user custom needs and the business goals stated in the strategy and or address issues highlighted by the KPIs. If there are too many outcomes choose the ones that are likely to create the most value using an impact effort based metric like race and race stands for reach impact confidence and effort. Third prioritise the outcomes by considering dependencies between the goals and their cost of delay. Fourth right size the outcomes and make sure that they are specific, measurable and feasible. And finally secure consent to the outcomes from all participants to create the necessary buy-in and alignment. Consider using a dedicated facilitator to moderate the workshop for instance the teamcoach or

14:36scrum master. This allows you the person in charge of the product to focus on determining the right outcomes instead of having to ensure that everybody is hurt and nobody dominates. Notes that as the product manager you have to be empowered to have the final say if no agreement can be reached. Collaborative goal setting does not mean that everybody gets their way or is necessarily super happy with every single outcome. It means leveraging people's expertise to create the best possible goals. These goals that help maximise the value the product creates and that attract as much support as possible. Finally don't forget to review and update the outcomes regularly. An outcome based product roadmap is not a fixed plan but an adaptive one. As market conditions the competitive landscape and technologies change the roadmap together with its outcomes must be updated.

15:40This ensures that it continues to be a helpful forward looking plan that align stakeholders and guides the development teams. Reviewing the outcomes is best done as part of a strategy workshop where the product strategy and roadmap are discussed together. The workshop should take place once per quarter as a rule of thumb and involve the individuals who have helped you create the roadmap. Additionally I recommend continuously reviewing the product performance using KPIs as well as keeping an eye on the competition and relevant trends. This ensures that you spot opportunities and threats as early as possible so you can respond to them proactively and adjust the product outcomes as soon as possible. And I explained this approach in more detail in the episode continuous strategising the link is in the show notes. And that brings me to the end of today's podcast episode. I hope you found my advice helpful. You can learn more about setting the right product outcomes and building effective product

16:43roadmaps by attending my product strategy and roadmap workshop and by reading or listening to my book strategize. Thank you for listening.