From Feature Oriented to Outcomes Oriented Product Management

Fani Bahar at UXDX Community: Europe West. Video: https://www.youtube.com/watch?v=k_SClFXjvhc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The common roadmap story

[00:00:00] Welcome everyone to "From Feature Oriented to Outcomes Oriented Roadmap." My name is Fani Bahar, and let's get started.

[00:00:08] The story starts as I am a product manager and I'm a consultant, so I've been working with a lot of different clients. From working with a lot of different clients I learned about a big struggle in terms of roadmaps, and I will probably show you the story that I kind of see as a commonality between one client and another client. This might also be related to your current development processes.

[00:00:37] Most of my clients have this yearly meeting, where in this yearly meeting they are creating a roadmap between the stakeholder and the project manager. From this roadmap they start to also have a quarterly goal. What is the quarterly goal? Which feature set do we have to achieve each quarter? They start creating a backlog, they start having the implementation, and sometimes they will do some kind of roadmap review. Then the stakeholder would start having specific requests, or they say, "Okay, we need this feature, because I have a meeting with a specific client and they want to have, let's say, feature X."

[00:01:18] Then, as product manager, we start having this negotiation with the client: "Okay, should we do it? If we want to do it, then it will impact this." And then finally we will define what the compromises are that we can make. Sometimes in the middle of the implementation you will have a production bug, and after that you need to focus on fixing the bug. As a product manager you would be worried about how to actually achieve your target, your quarterly target.

[00:01:55] Then you might actually miss your release plan, and you have a lot of discussion with your stakeholder: "Okay, if we miss this release, this is what it looks like, and this is the impact for the next quarter and the next quarter." Then, the moment that you are releasing, you also start wondering, okay, how can we release it in a good way, so make sure that we can roll it out to customers safely. And then finally, when you release your features, you start wondering: either the client complains, or probably the client doesn't use the feature that you just released. So this is the common scenario that I have seen with my multiple different clients.

Why feature roadmaps don't work

[00:02:42] I could see that this is a problem. And what is actually the problem? Why does this yearly roadmap thing that seems like a perfect plan not really work well in reality?

[00:03:00] First of all, it's because most of these feature roadmaps are really focused on the output, not so much the outcomes. So what is actually the difference between outcomes and output? Outcomes here means that you are really thinking about the impact that you want to achieve from your product or from the new feature that you just released. The impact can be a business impact, the impact also can be increasing your user value inside. The output is just like a number, like how many features you release.

[00:03:36] If you are thinking about the output, you really focus on releasing a number of features rather than impact, and that would actually give you a disadvantage in understanding any success or understanding any failure you have with your product and your features.

[00:03:57] Another problem from having this feature set roadmap is that you assume you can predict the future and then you can create a perfect plan. As I mentioned, yearly planning, a yearly roadmap, doesn't really work really well, because you are working in an agile environment and sometimes there are things that shift. It might be that a specific piece of research would actually impact your product direction, or it might be that a specific production bug will actually impact your resources.

[00:04:37] The other thing is that having this yearly roadmap, it's hard to motivate the team, because you make a commitment on behalf of your team. Basically you commit even though, as a product manager, you are not the one who delivers the features. And we also kind of give the stakeholder or the executive the idea that they are the expert on what customers desire, when unfortunately we need to do our research and validate whether our assumption is validated or it's not validated. So that's actually the biggest problem with having a feature set roadmap.

Introduction and the six steps

[00:05:30] Before we start about the outcome based roadmap: my name is Fani Bahar, I am a senior product manager at VMware Tanzu Labs. My responsibility is, I've worked with a lot of different clients and helped them to build their digital product. It can be a new product, or it can also be a legacy product, so I'm helping them in their application modernization journey. I am a food and sport enthusiast. I don't have Twitter, but you guys can find me on LinkedIn.

[00:06:03] All right, so let's get started. How do we shift our mind from feature oriented to outcomes oriented roadmap? It's a very extensive workshop, but I think I want to summarize that there are six steps that can help you in order to achieve your outcomes oriented roadmap.

[00:06:35] The six steps actually start with your product vision. The second thing is, from this you define your strategy to achieve your vision. The third thing is to start identifying the outcomes based on the strategy that you decide, and then prioritize it. The fourth thing is you also realize the success metric for each outcome. The fifth, you start to brainstorm what the validation or research is that you need to do, or the potential feature that you need to implement. The last thing is you keep track of the progress of your outcome based roadmap.

[00:07:14] For this presentation I would use an example from an imaginary client. Unfortunately I cannot use the real client example. In the whole presentation you would see a lot of diagrams, which, as I mentioned, are aligned with the steps that I shared in the previous slide. So we have the vision, we have the strategy, we have the outcomes, and then we have the metrics, and then we have the brainstorming for the features and the experiments we need, and the last thing is about keeping track of your progress.

Step one: product vision

[00:07:53] Let's get started. Every time I went to a client and asked them what their product vision is, sometimes they always give me the answer that the product vision is basically a specific feature, or how the product would look like in the future. Which is a good start, but what I'm looking for here is, a product vision is always about communicating the reason why your product exists and what kind of problem you are trying to address by having this product.

[00:08:29] Vision basically really gives you a big picture for your team, so your team understands that we are talking about things that we want to achieve. So we are starting the discussion at the problem level rather than always at the feature level. And then you have to make sure that your vision is easy to understand and definitely aligns with your company strategy or company vision.

[00:09:00] For having this product vision, it's something that you can do with your team. You can have a vision workshop where you're trying to understand, basically, who is your customer, why your customer needs your product, and how your product actually can solve your customer's problem.

[00:09:24] For this example, I also ran a vision workshop with my client, until finally we came up with our vision. My client for this example is a music instrument e-commerce, and they have a vision to be the customer's go-to platform for all kinds of music instruments, that makes them more motivated and happy. So here this vision really describes the who. The who is their customer, who purchases the music instrument. And then, what desire needs to be addressed? It seems like they want to provide different kinds of instruments, because they believe this is what motivates their customer and makes their customer happy.

[00:10:10] So you are settled with your vision. Usually a vision should be something that's set for the next ten years. If a company, or if you, always change your vision every month or every year, then it's a flag that maybe you don't really know why your product exists.

Step two: define the strategy

[00:10:29] The second thing is define the strategy to achieve your vision. It's really talking about how you want to drive specific initiatives, so that you are one step closer to your vision. By discussing the strategy, it also makes you align with your team for things that you want to build and things that you don't want to build, and why.

[00:10:58] At the end, strategy really scopes or covers a lot of questions that you might actually discuss with your team. For example, again, who are your key customer and user? At this point, who is your highest priority? Maybe you have a lot of different customers and then you actually can prioritize it. And then, what kind of problem do you really want to solve for this specific customer? And maybe a discussion about how you can differentiate yourself from the other products that are already in the market. The strategy can also be discussing which market you want to focus on now, or even how you would come up with the pricing strategy for your product, and how you definitely measure the success of your product.

[00:12:03] Again, this is another team exercise. After you settle in with the vision, the vision is the input for your strategy exercise. So you also brainstorm with your team and then come up with the strategy that is sequential, based on the short-term strategy until the long-term strategy.

[00:12:30] For example, for this music instrument e-commerce, at that time they were really focused on their inventory management. So the first strategy for them is actually to optimize their inventory management, to make sure that the customer is happy, because the customer can get the instrument as soon as possible, or probably the customer can find the instrument that they want to have. The second strategy that they want to achieve is also to provide a diverse selection of music instruments. At that time they thought that maybe they were just really focused on string instruments like guitar, but they want to explore a different type, like maybe a digital music instrument. So this is also another strategy.

[00:13:19] This is a good strategy, because it also puts the team's focus in terms of the customer that you want to focus on, the market you want to focus on, and what problem you want to focus on at that time. And it also shows you how you can actually measure the success of your product. If you're not achieving this strategy, then what is the implication?

[00:13:46] For strategy, usually it's good to have a strategy on a yearly basis. I know some companies that might set a strategy for one year, they might actually have a strategy for five years. I think at the end of the day it's really a discussion with your team. But the point is, make sure that you have a strategy and then you're trying to achieve it, you're trying to validate whether your strategy is good or not. If it's not good, then it might be good to shift to the next strategy that you have.

Step three: identify the outcomes

[00:14:25] The third thing is identify the outcomes based on the strategy that you already defined. Again, outcomes are really the result that you want to see after, let's say, you run a research or you release your features. Because again, outcomes really give the reason why a specific feature or specific product will bring user value or business value.

[00:15:00] For outcomes, maybe for one strategy you need to have a lot of different outcomes, which is okay. It's a matter of prioritization: which outcome do you think is pressing, and then you need to deliver it as soon as possible. And again, this is also a team exercise. You try to brainstorm with your team what the outcomes needed for achieving your strategy are.

[00:15:35] For this music instrument e-commerce, they believe the outcomes, or the impact they want to see, is basically that customer satisfaction is increasing because they have a better fulfillment rate. In that discussion they believe that having a good fulfillment rate, meaning that every time they have a product they always have it in stock, will increase customer interest toward the platform and then they will purchase it from the platform. And definitely, if the company can deliver the product to customers as soon as possible, it will also increase customer satisfaction.

[00:16:24] The second outcome that they really want to see from these strategies is to also reduce the costs because of the wasted instruments. This music instrument e-commerce is a big company. Basically they already have a lot of history from purchase history from the client, and they can understand at which time a lot of people want to buy music instruments, what kind of music instrument people usually look at. From here they can have better planning for their procurement. So at that time, this is the outcome that they really want to see.

[00:17:06] Again, outcomes usually really answer what actually the impact is that you want to see by implementing or releasing a specific feature or specific product.

Step four: set the success metrics

[00:17:22] The next step, as I mentioned, is about setting the success metric for each outcome. Because it's good that you understand the impact that you want to achieve, but it's even better if you can measure it, if you can track it, if what you are implementing or what you are researching is giving you an indicator that you are one step closer to your outcomes.

[00:17:56] Having the metrics, definitely you need to make sure that the metric is an honest metric, meaning that it's actionable. So you understand every direction. If the metric is going up or going down, it really gives you information about what the next step is that you have to do.

[00:18:18] Again, this is also another team exercise, trying to brainstorm what kind of metrics might be good metrics for your outcomes. For this music instrument e-commerce, we also agreed that for the first outcome, customer satisfaction increasing because of the fulfillment, we agreed that the metric would be repeat order rate increased by 20%.

[00:18:49] During the brainstorming there were a lot of them that mentioned the NPS score, or they mentioned order fulfilled, for example. That's all good metrics. But then we started questioning: is this metric actionable? Does everyone understand it? Is it auditable or not? Until finally the underlying metric that we want to achieve here, by having a good... like, when the customer is satisfied purchasing from your platform, most likely they would buy it again from your platform. And that's why we agreed, maybe having a repeat order rate increase by 20%.

[00:19:38] And then for the second outcome, which is reduced cost because of the wasted instruments, we agreed on unusable instruments decreasing by 30%. By having more effective planning for procurement, understanding your customer purchase behavior, it makes you also optimize which instrument you have to buy and which instrument probably shouldn't stay in your warehouse for X months, something like that.

[00:20:14] So this is, again, metrics. It's a good exercise so that as a team you always can track your outcome. Let's say that you release specific features and then you have these metrics in mind, and you always monitor your metrics. Any decrease or any increase would really give you more information about the impact of the feature or the product.

Step five: brainstorm features and experiments

[00:20:49] I think the fifth step is basically the most exciting part for my clients, because I think they have a lot of good ideas for the features that they want to implement. Which is good, if they already have a lot of ideas. But I think the difference here is that we always try to encourage them to think about the feature based on the outcomes that we already agreed on.

[00:21:22] Here we're trying to brainstorm with the team, make sure that we can come up with a lot of different ideas. The idea can be a short-term feature, like a quick win feature, or a long-term feature, because I think it's good to have a lot of different ideas. Once you agree with the team in terms of the prioritization, you can also start asking yourself, is this looking right? Does this roadmap help us move towards our vision?

[00:22:05] Every time you do it, it will also practice the way our team thinks. Every time they come up with a feature idea, they will also start asking, is this valuable for our user? Are we confident to actually implement this feature and there is value to our customers? Because sometimes I come across a lot of different teams and they always come up with a feature idea because there is new technology that is exciting, there is a lot of buzzwords that are exciting, but then it's very hard for them to justify what the value of this specific feature is for the users.

[00:22:49] For example, for this music instrument e-commerce, they mentioned that at that time, turns out they don't really know what the customer pain point is when they are ordering. They keep saying that a lot of people left the platform or left the website because they couldn't find a stock of a specific music instrument. But then, when we started asking, "Okay, maybe we need to ramp up the stock for the music instrument," some team members didn't really believe that the biggest customer pain point is because of low stock.

[00:23:39] So in this case we also agreed, okay, how about we make sure that we have good evidence that the biggest customer pain point when they are purchasing is not only about fulfillment. That's why, when you are having a discussion with the team to prioritize the feature idea or the research idea, you start asking, do we have enough evidence about this feature? If not, then what is the experiment that we need to do?

[00:24:15] At the end, this is actually the look of the outcome based roadmap. You always have the outcomes, and you always have the feature idea or the research idea that you want to perform together with the team, and then what the metrics are that you want to track in order to understand whether this outcome is achieved or not.

[00:24:44] When you are discussing with the team, definitely we always have this prioritization discussion. Which outcome do you want to achieve as soon as possible? Which outcome might need more validation, we need more information, and it's more of a long-term kind of goal? So that's basically the look of an outcome based roadmap.

[00:25:11] And again, as a team you need to always look back and ask yourself, okay, do these outcomes look right? Is it really the thing that would bring us much more closer to our vision or not? Sometimes, probably in the middle of the implementation, you run some experiment and you figure out specific information that might actually impact the prioritization of your roadmap. Which is totally okay, because at the end of the day you really need to focus on the outcomes that you want to achieve. So then you can always justify why a specific feature suddenly becomes the highest priority at that point, at that moment.

Step six: track progress, and closing

[00:26:05] The last step is basically a regular check with your team in terms of your roadmap. What I did with my client, usually I run on a weekly basis a quick checkup, a quick progress. Usually I just run a quick chrome unfold[?], like, "Okay, let's start with this outcome. What do you guys feel? How are we achieving it, how is our progress? Is it good, so-so, or bad?" And let's say that a lot of people say, "Okay, I'm not feeling it, I think we are not making good progress at all." So then let's start asking ourselves, what action item do we need to do as soon as possible in order to make sure our progress is improving the next time we have the review?

[00:27:02] Again, regularly keep track of your progress with your team. An outcome based roadmap is a good communication tool, not only for your team but also for your stakeholder, because by starting with an outcome based roadmap, you always start the discussion with your stakeholder from the problem level rather than the feature level. It's also easier for you to justify why you believe this specific feature is valuable, so it's better to achieve it now rather than later.

[00:27:47] So yeah, that's the six steps: how to achieve an outcome based roadmap, how to shift your mind from feature oriented to outcome based roadmap. It's a very extensive workshop, and I think I would also invite everyone to check out the step-by-step practices on our VMware Tanzu website. It's really a good starting point if you want to exercise an outcome based roadmap with your team.

[00:28:23] So yeah, check it out. Thank you for your time. I really hope that you enjoyed the talk and you can pick up something from it. Feel free to reach out to me, I'm happy to discuss more about the outcome based roadmap, share feedback, and let's have a discussion.