Get the Outcomes on Your Product Roadmap Right

Speaker A: Foreign. 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 uh stakeholders, create focus and give development teams clear direction. But getting them right isn't easy. Too often product teams uh, choose outcomes that are vague, oversized or worse, just features uh dressed up as goals. The results? Confusion, misalignment and roadmaps 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. Traditionally, a UH product roadmap is a feature based plan that assigns capabilities like registration, search and reporting to a timeline. Such a roadmap 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 UH feature based roadmap 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 uh, avoided by using a different approach, an outcome based goal oriented product roadmap. As the name suggests, this plan focuses on product outcomes which are also referred to as product goals and objectives as in okrs. Examples are uh, 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 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 a 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 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 a, uh, 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 latter. To put it differently, the strategy forms the foundation for identifying the right product outcomes. If I can see further than the initial offering, I, uh, 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. They 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 at 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 right 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 bugs 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, uh, customer needs and business goals. This ensures that the product strategy guides roadmapping decisions and and that the roadmap 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 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. Therefore, be careful not to mistake features for outcomes and ensure that your product goals always capture the desired outcome and not the output. Um, after choosing the right outcomes and checking that they describe actual benefits, take the next step and get their size right. Roadmap goals should be no smaller than six weeks and no bigger than four months. Here is why. If an outcome can be accomplished in less than four weeks, it tends to be too granular and often resembles more a, uh, short term tactical goal like a sprint goal. And if it takes longer than four 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, uh, 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 into the following two goals. Help users understand their breakfast habits and help them be aware of what they eat for lunch and dinner. Now, some product teams, uh, like to work with quarterly goals. This can make roadmap planning easier and help manage stakeholder expectations. But there is no hard requirement for all outcomes on a roadmap 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 bhag, a big hairy, audacious goal as the product vision and strategic needs and business goals that act as guardrails but aren't necessarily measurable and time bound. However, when it comes to product outcomes, you should use goals that offer more concrete guidance and meet the following three first, they are specific. Everyone understands what the goals mean everyone 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 here are efforts it is common in my experience to initially identify comparatively big, coarse grained product goals which are neither specific nor measurable. 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 how you're going to measure if the objective has been met. Does a successful acquisition require 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 pace 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 timeframe 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 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 and 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 time frames and prioritize them as I'll explain in more detail shortly. Now, the best product outcomes and the most amazing roadmap are, uh, 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 uh first, jointly identify candidate outcomes, for example by asking the workshop attendees to capture their goals or notes. Then invite them to share their suggestions. Check that the items are actual outcomes and not features in disguise. Second, group similar items and explore if they support the user customer 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 rice and Rice stands for reach, impact, confidence and effort. Third, prioritize 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 team coach or scrum master. This allows you, the person in charge of the product, to to focus on determining the right outcomes instead of having to ensure that everybody is hurt and nobody dominates. Um, note 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. Those goals that help maximize 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. This ensures that it continues to be a helpful forward looking plan that uh, aligns 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 explain this approach in more detail in the episode Continuous Strategizing. 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 roadmaps by attending my product strategy and roadmap workshop and by reading or listening to my book Strategize. Thank you for listening Sam.