Opportunity Solution Tree Talk - in company - Scout24

So, Opportunity Solution 3, a way for you to deliver more business impact by structuring your discovery. So, before I talk about Opportunity Solution 3, I want to talk a bit about product development and the problems with it. So, what's the deal? You know, lots of times we deliver features without value. So, and when I say we, everyone is guilty of this. There is research that shows that around 80% of all launch stuff gets used never or almost never by user. 80%. Chaotic discovery. So, you know, we all know, yeah, we have to do discovery, but it often feels very chaotic. Like you go into several directions and people like, okay, what's the next step? What's going on? And, you know. After we have our ideas, our goals and all this, it's often very hard to prioritize. This happens because lots of times we are comparing apples to oranges. So, you know, it's hard to prioritize apples or oranges. And also it's difficult to communicate product development. So where we are going, why you are researching something, why you're doing X and not Y, etc. So all these are problems with... product development. So the opportunity solution three come to the rescue for these problems. So let me first talk about like a very important topic, which is who created this. So I imagine you have heard of Teresa Torres. If you haven't, definitely check it out. She has this book called Continuous Discovery Habits. I didn't invent any of this. It's all there. And it's amazing. This is the most practical product development book that you can get. So if anything sticks about this presentation, read this book. If you don't get anything else, that's fine. All right. So the opportunity solution tree is very basic. Like the theory is you have like on the top a desired outcome. So what your team wants to achieve. So some metric, some goal. Then you have... opportunities. So what are the levers for this goal? So what are the things that they can influence that will impact the goal? And then there are ideas on how to actually deliver on those opportunities. If you notice most of the time, a product development team jumps from desired outcome to ideas. And this is what makes it hard. So let's walk step by step. So imagine we are Netflix. Netflix because everyone knows. So desired outcome, let's say that, you know, I'm part of the of the retention tribe or whatever they are called and our goal is to increase the viewing hours per viewing. So I want the average viewer watching more Netflix because this will lead to better retention. All right. So a team that's not using Opportunity Solution 3 might, okay, let's focus on ideas on how to do that. And that's not the approach. So the first thing is to think about opportunities. All right, so how can I influence this goal? So these are just a few examples. So I can't find something to watch. And then like you have some opportunities of this for clarity. Oh, I don't know how to search for a specific show. Or I am out of episodes of my favorite show. Or is the show even any good? You know, so the second opportunity, I don't want to miss out on good stuff. And then you break it down into sub-opportunities. I don't know when a new season is available and I want to know what my friends are watching, et cetera, et cetera. So this is a way of structuring your thoughts. Okay. And then you have ideas. Okay. So you get like this opportunities or sub-opportunities and okay, what can I concretely can do? as a product team to impact this opportunity or sub-opportunity. So for example, in I am out of episodes of my favorite show, oh, I can have like a similar to Suggester. And all these things like for most of them, Netflix already did. Yeah, don't work at Netflix. So I'm not thinking that deep into that. But, you know, at some point someone had this opportunity, you know, even if they didn't. use the opportunity solution tree. All right, but how does that little scheme tree, whatever you want to call it, actually help with those, you know, these problems that are very real for product development? So I'm going to start with the first two. So features with no value and difficult to communicate. So how does it help? Imagine that same tree and let's focus on a single branch. So, okay, so... First, you have like increased view hours per viewing. You have like a clear and measurable goal. So this already helps with communication and this helps, you know. So the second thing, so which user problem we are actually trying to solve to achieve this goal. So again, you know, this helps with delivering features that actually have value and also to communicate clearly where you are going. And the same thing for the idea. So how do I want to actually solve that user problem? And if you notice, the opportunities are often framed or written in the form of a user problem, a market problem. So, you know, it comes from the mouth of someone. So you don't fall into the trap of writing just stuff that are opportunities to the company. So you don't actually deliver value to the user, to the customers, et cetera. So this is how it helps with features with no value and clear communication. And what about chaotic discovery and hard to prioritize? So, you know, you have this goal. Imagine you start here. All right, I have this goal. I have been allocated this desired outcome by the leadership. What do I do now? So the first thing is what the problems or opportunities that actually impacts this goal. So I'm going to do some research. Oh, all right. I found some opportunities. Yes. I can't find something to watch. I don't know. I don't want to miss good stuff. And I want a better view experience. I can't find several ones. Some of this stuff might already be on my mind because I did previous researches or by just guessing, it doesn't matter. And then, okay, what do I need to validate to prioritize among only these opportunities? The next step is clear. Okay, which one is the bigger opportunity right now to impact the goal? Oh, okay. I found that it's I don't want to miss out on good stuff because of reasons. You know, I have some data that shows this. I have some user interviews. I don't know. And then, okay, what do I need to validate to prioritize just among these two sub-opportunities? So, you know, the next step is also clear. It's not like super broad. Oh, yeah, fine. I found that I don't know when a new season is available is the thing that I can have the most impact here and I have a few ideas. Fine. So what do I need to prioritize and validate in these ideas? So the discovery becomes much less chaotic, much more step by step logic and also easier to explain to others what's going on. But you're probably wondering, fine. Yeah, Netflix is cool, but how do I do this? So let's go. So you first need to define an outcome. Then you have to list the opportunities and a solution hypothesis. Then you validate and prioritize those, do some discovery of those. And with this, it's a kind of iterative process where you update the tree. And then, you know, okay, I have my prioritized opportunity. I will test my solutions and then if the tests go well, I will build and iterate and this starts all over again. So this is the simplistic overview and I'm going to talk about each of these steps. So first, define product outcome. Yes, if you don't know which port you're sailing, there is no favorable wind. So basically, if you don't have a clear goal, that's absolutely a must, you know, you need a goal. But there are two types of goals and one of them is better than the other. So business outcome goals or product outcome goals. So business outcome goals are like, you know, increase revenue, increase profit margin, increase market share, reduce cost, reduce churn, increase rotation, all of this. So, you know, they are... what we actually want to achieve as a business. But they're not very good for product teams because they are lagging indicators. They're output metrics. They're hard to actually impact because they're so broad. And also many other teams and many other areas in the company influence on this. So if you want to reduce costs, sure, you can think about stuff. But at the same time, like... if the company is going on a trajectory of increasing costs, then your savings are not very good. So what Teresa Torres proposed is that we use product outcomes. They are more like leading indicators. So input metrics to the output metrics of business metrics. So examples, increase conversion on a certain funnel or increase satisfaction with a certain feature. or increase the first seven day retention or reduce time to perform some action, increase the adoption of a certain feature or reduce for tickets about a certain feature. You know, they are more concrete actionable to the product team and they are easier to impact. So examples of a product outcome, a bad one is to launch feature. So, oh, I want to launch feature X and that's my outcome. No, that's an output. That's not an outcome. So, an okay one is I want to increase the follow X conversion. All right, that's good. But it can be better if you are more specific. So I want to increase that follow conversion for users in their first seven days. So this is very, you know, okay, like it's laser focused on a certain type of user and I can have a better discovery. And the best is you add like, okay, I want to increase from X to Y. So, you know, it's clear what sort of level of increase you want, because you have very different thought process if you want to increase 1% or 100% of something. So you need to crazier ideas or more disruptive ideas if you want to have like a big increase than if you just want to increase a little. And of course, like this business outcome, product outcome, it's something that needs to be negotiated with the leadership. So sometimes your leader will come with a business outcome and you have to reflect and, okay, so I see we want to achieve this. So I have this hypothesis that by impacting this product metric, we are going to help with the business metric. Is that okay? Or sometimes the leader will just come with the product metric and you have to clarify like, hey, so what sort of business outcome we want by impacting this product metric? This will also guide your thought process. And of course, sometimes like, yeah, we leaders, we fuck up and you don't have neither business outcome or product outcome. And so it's your job also to come and, hey, Like I'm thinking that I can impact this product outcome to achieve this business outcome. What do you think? And it's a negotiation, you know. So in the end, you have to agree with something with your leader. So after defining your outcome, you just list what is on your mind. So both opportunities and solutions. So, you know, you make the three. And that's as easy as I'm saying, you know. So, okay, I have this outcome. What are the opportunities that could be related to this? And I am brainstorming, maybe with the team, maybe with myself, maybe with my UX and engineer manager, I don't know. So this is not like rocket science. The hard part is structuring this because sometimes, you know, oh, maybe I want to skip a show intro is in fact like I put like as a big opportunity. And, you know, grouping these things and making sense, you need a bit of work. But it's not like there's a right way of doing this. You know, there is a way that works and you have to try something. And of course, like this is not like on theory, you shouldn't be thinking about ideas or solutions right now. But for me, it's impossible. So once I have like opportunities, I immediately think, okay, I could impact this opportunity by doing this and this and this and that. So I just write them down anyway. And yes, but you have like this tree or this kind of prototype tree, but nothing is validated. You didn't talk to anyone. So it's not very good. So now you need to prioritize and discover a bit and then update the tree because, okay, I created this. But which opportunity do I actually prioritize? Are these actually the opportunities that I should be pursuing? Is there something that I'm missing? So all this makes sense. All right. So I like to think about four big criteria to prioritize opportunities. So opportunity sizing, market factors, company factors, and customer factors. So opportunity sizing. This is how big this opportunity is. How many users are affected by this problem or opportunity and how often they are impacted. Because sometimes you have something that, yeah, 100% of users suffer this, but they suffer this once every four years. Okay? And then I have this that 20% of the users are impacted, but they suffer this every day that they use the product. You know, so. The market factors is a bit like what is external to the company. So is this opportunity, is this like a thing that will differentiate us in the market? Or maybe this is something that is stable stakes. So, you know, if you don't have this, you are out, like you're not even considered by customers. And does this address some external threat or opportunity, like for example, eBay, client assignments coming and they have more private listings, blah, blah, blah. So, okay, maybe this opportunity addresses that external threat, competitor threat. Company factors is internal. So, you know, okay, does this opportunity help to drive the vision or the strategy of the company? Like for example, the transactions. Oh yes. Okay, good. Or maybe it's exploiting some company advantage. The classic example is AWS. So Amazon had like a bunch of servers. They were all there with all their APIs exposed internally, blah. So, okay, why not create AWS? So we use the servers that is something that we have to have and it's a strength of the company and we push them to other people. And customer factors. So how important is this to users and customers and the satisfaction? So how satisfied are users and customers with the current state of that opportunity? So, okay, but this criteria, how do I actually figure them out for each opportunity? This is hard work, yes. So examples of activities for opportunity discovery is like, yeah, you can talk to users, customers, ex-customers, all this. user behavior, data analysis, surveys, internal stakeholders' conversations. And really this is the bread and butter of product discovery, you know, and this is not the scope of the talk, but basically it's, if you're not talking to your customers frequent enough, then you won't be having like a good opportunity to discover because like you will be framing things. on your own perspective, on the company perspective, and this will lead to a worse opportunity solution tree. So remember that you have to talk with the mouth of the customer. A few things to watch out when you are validating opportunities. So the first thing is don't make a mathematical formula out of this. So don't say like, okay, opportunity size is a two, the market factor is a three. No, you know, so this is supposed to be messy and this is supposed to be a bit subjective. So product development and product discovery in particular, there's lots of science into it, but it's not without art. You know, there is some subjective decision there. If you just make a mathematical formula, you... you will make the wrong decision and there will be all these discussions all the is this a two or a three which doesn't matter you know so also you don't need perfect or even a hundred percent accurate information so you just need good enough information to compare these opportunities so again this is not rocket science if you were on spacex yes this is rocket science but that's not you know no one is gonna die if we do things bit like 80% correctly and you have like 20% of leeway. So example, oh okay, so I don't need to know that a million three hundred thousand twenty-two users doing do something. I can figure out different opportunities like yeah, have like more than a million people doing this and ten doing this. Clearly opportunity size-wise seems to be the a million more. Okay and most important of all, and that's why it's a bit hard, there might not be a clear winner. Yeah, you can have one opportunity that is better for market factor, another opportunity that's better for customer factor, another opportunity that is bigger in terms of opportunity sizing. What do you do? Make the damn decision. Because this is a two-way door decision. If we pick wrongly, You can just go back into the same door and pick another one. So this is not about spending weeks, months, years figuring out. This is about days, maybe hours even. So you just start and then you update the tree. So let's say that I started with this tree and oh, this opportunity, I discovered that this was not really an opportunity. No one has this problem. This is not a market problem, et cetera. So now. or maybe some people have but it's like one percent and we want to improve this metric by a hundred percent so this is not what we should be pursuing oh yes this one is an opportunity fine because this is this data good maybe this is something we should pursue and also i discovered this oh this is something i didn't think of and i talked to some customers and this came up a lot okay there is also this opportunity that appeared and i have some ideas for this So the goal is you go from this to this. All right, I prioritize. This is what we're going to focus on. And I'm confident because I have this data and because we decided that this is the way to go. Fine. So once you prioritize and you discover it, so now it's about solution testing. So, some water. Dealing with opportunity solution. The first thing I like to do is once you have a focus on some opportunity or some sub-opportunity, add more ideas. So one thing that I really like to do is asynchronous brainstorming. So because there is no limit of participants, you just like explain the problem like, hey, this is the opportunity where we are pursuing to achieve this goal and we discover that this is important because of data, data, data. So what can we do to... address this opportunity and then you ask everyone. So you can put on Slack channels, you can ask your team, you can ask like your leaders, you can ask anyone. So then you have a bunch of ideas. Then you must pick the most promising ideas. No science yet here, just like I think, and you can use something that is very like still very wobbly, which is, okay, I believe this impact and... I believe this difficulty to make and you know so I make a matrix out of this and then okay so this I believe has a high impact and also it's very easy to make nice this seems to be better than this idea that I believe has low impact and it's very hard to make so you can use several ways but you know again don't use weeks to do this this is like quick decision this is an imperfect decision Then the magic happens. So you need to map the ideas that you picked and map the assumptions that you have about this idea. And then you test the risk assumptions and you finally, you either pivot or scrap the idea. Okay, this idea doesn't work or you build it like, yeah, it seems it does work. I'm going to focus on this part because that's where the magic happens. So mapping the idea and assumptions and testing. the risk as assumptions. So let's go. Mapping the idea. I'm going to go away from the Netflix example, just to use something more concrete that I did in the past. So I worked before at OLX. OLX is kind of eBay Klein and Zeigen, but for other European countries, not in Germany. And this is an example for Portugal, for example. So saving a search was correlated to an increase in buyers contacting listings or sellers. And this was my team goal at the time. But the problem was that just 1% of users actually use the Save Search functionality, which was super bad. So with user interviews, we understood that people actually didn't know of the feature. So it was pretty basic. And that was our chosen opportunity for this idea. And the idea was to, when the user scroll the screen, show the save search floating button. If this is very similar to EmoScout floating button, I am not ashamed to say that I blatantly copied it. Yes. Great artist still, right? Yeah, you know, I was looking for ideas. I was just like, wow, this guy solved this really well. Let's try this. So what do we do? So we have this idea, but... Should we build it or not? We definitely didn't just build because Emoscout had cut. Maybe at Emoscout it didn't work. Who knows? Or maybe for our users, it didn't work. So the first thing you have to do is to map the idea. And the first step is mapping the actors of this idea. So this is who needs to do stuff for this idea to work. And this is not about implementation. You know, think like if the idea was already live, who needs to do what for this idea to work? So for us, there was For this idea, there were users that were buyers and there was OLX, the platform, so both web and apps. All right. And then the second step is actually mapping the steps for the idea to work. So what each actor needs to do. So first, like a user that is a buyer, they need to get to the search results listing somehow of a search results that is not saved. Okay. They end up there by... indirect linking or they search something or whatever. All right. Then they need to scroll because if they don't scroll, this will not work. So they need to scroll the results. Then the platform needs to show the button to save search. And then the user needs to click this button. And then the platform needs to save the search and send a message that, yes, it was saved. Cool. So this is... Like for me, the magic of this is that you don't need a UX designer and don't need a lot of time to actually figure out the happy path of an idea. And anyone can do this. And this helps with aligning everyone because sometimes we say stuff, yes, let's create a floating button and people imagine different things that people need to do. So this makes it a bit easier. And just think happy path, you know. Don't make it more complex than it needs to be. If it doesn't work for the happy path, it will not work with the complex paths. Then what do you do? Okay, I have this, but should I build this? No. So you should map the assumptions behind the idea. So what do I mean by this? You have the steps mapped out of the idea, and now the assumption is what needs to be true in each step for this idea to work. Notice the magic here that you don't test the idea. You test the assumptions behind each step. So it's much quicker than testing an idea. So often what we will do when testing ideas is we put an A-B test, but that's like 90% of the work done. So if this doesn't work out, you throw away 90% of work that you could be doing something else. So you can test much quicker if you test assumptions. But how do I even define assumptions? So, okay, so let's say, get to the search results listing page. So users need to do that. So which assumptions do I have here? It's a bit hard to think about this. So what helps to think about the assumptions is this thing of the four risks from Marty Kagan, which became five because it added something. There's value risk, business risk, feasibility risk, feasibility risk, and the added one, ethical risk. So value, do I actually deliver value by doing this? So do users have this problem or will they extract value out of this or will people buy this, et cetera? So this is the value bit. Business, does this work for my business? So are all stakeholders actually agreeing that I can do this? Or is this even legal? You know, is this, what's the risk for my company if I do this? Feasibility is, yeah, so can we actually build? Because, okay, so let's say I have this brilliant idea to make like EmoScout more engaging, like we teleport users that are seeking into the viewing. Yeah, but you can't build a teleport, so that's no point, right? And then usability, can the users actually use it? And ethical, so if I did this and someone wrote this on the newspaper, would I be comfortable with this? So let's map out the assumptions to make it a bit more concrete. So let's go step by step. So get to the search results listing page. Okay, so I mapped out that for the business, for this idea to work, we need more than a million users per day. that gets to the result list page. Why is this a business assumption? Well, because for me to achieve my goal, I need a lot of users doing this action. So if they don't, it's over. All right. So users scroll the screen to see the results. Oh, at least 80% of users scrolled at the screen. So again, this was a business assumption because yes, if people are not doing this in mass, this will not be worth our effort. then display the floating button. Oh, on feasibility, we had some front-end tech tabs. So we were a bit afraid that this might be a problem there. So we didn't know it was an assumption. And for usability, the button doesn't hinder the navigation of the user. So we're putting something there in the middle of search results. So will this be a problem for the user navigating the search results? And then the user clicks to save search button. What assumptions did we have for value? So more than one million users repeat the same search in a month. So why value? If users were not repeating the same search, it was like a clear indication, it was not a proof, but an indication that they didn't want to be notified of new items because, you know, they're not searching the same thing. the search once and they disappear. Yeah, maybe there is other problems with that, but you know. And also a value assumption is users want to be notified when there is a new item in the search. Because yeah, we want them to save the search because we want to notify them when there is a new item that they can buy. So they will contact the seller, which was our goal. And also there was usability concern here on this step. So the users understand the value. of saving a search and know how to do this. Again, if they don't, this step fails. And save a search, there was a feasibility there. So we were not the owners of the API of Save Search. So, okay, this API, it can be used by us in this context. And also another feasibility assumption for display messages about search being saved is the API returns these results. That's cool. All right. So, Clarification here that people often trip. This is what needs to be true for this step to work. So for the get to the search result listing step to work, at least a million users need to land in the listing page. So it's not a question. It's not like a negative thing or a risk or whatever. It's just frame it as true. And this is one of the anti-patterns. Common anti-patterns when mapping is up. You don't create enough assumptions. So you see like this very simple and silly idea had, I don't know, 10, 11, 12 assumptions. And if you put a bit more effort, you probably can get more. Another thing that people often do is create assumptions that need to be false or questions. This will make your life harder when validated. So don't do this. Make them, they need to be true. And the third is not being specific enough. Ah, users like it. Yeah, but like what do you actually assume here? And another anti-pattern is focusing too much on assumptions and one assumption category and completely forgetting the others. This is very common. Like if you are, for example, just doing this with product, you don't think about feasibility or if you're doing only with engineers, then you don't think about value. you know, so it's good to have a multidisciplinary team doing that. All right, but still I have these, I have these assumptions, but these are assumptions. It doesn't mean it will actually work. So what now? I get these assumptions and I will map them in a two by two. So in a matrix of importance versus how strong is the evidence that this is true. So more important at the top. and less the weak evidence on the right. So I get each one of those and evaluate those. Okay. More than a million users per day get to the result list page. Yes, we have strong evidence of this. We knew that a bunch of people were doing that. It's obviously important to the idea, but we knew there was strong evidence that this was happening. 80% of people who scroll, that we didn't know at that time. So it is important because if the user doesn't scroll, it's over. but we didn't have that strong evidence. We thought yes, but we didn't have evidence. The front end tech tabs don't block this. Yes, you know, probably there was ways around it. So it was a bit less important, it's too important. And there was a bit of certainty, but not a lot. And so, you know, we map this out and we have this, right? So we basically mapped it out and the goal is this. So you have these, which are important assumptions for the idea to work. If they're not true, the idea will not work. And you have weak evidence. So this is where the risk lies. So your goal is to get tests to pass these assumptions to the left, you know, strong evidence. Or if they are not true, maybe like, yeah, I can't validate this because it's not true. So you have to change the idea for this assumption to not be needed anymore or scrap the idea. This idea will not work. People don't scroll the screen. That's it. And then you design assumption tests for those. So I got those five assumptions that were on the top right. And okay, let's design some tests here. So the first two, I grouped them together because they were usability test type type of thing. So users understand the value of saving a search and how to do it. And the button, the floating button doesn't hinder the navigation. So yeah, we did like a clickable prototyping test, really standard. Not a lot of effort, low development effort. Value test. So we decided that three out of five should describe the value that they will get by saving a search. So they understand how to do it and how five out of five can actually save the search on the prototype and the hinder test five out of five can navigate. on the prototype without a problem even with the floating button. The other assumption, users want to be notified of new items in the search. So we just sent a manual push notification to users that repeated the same search. You know, we just did like a once time thing manually and then we had the success criteria. So this push click and click rate should be similar. to the people that actually receive safe search notifications because they save a search. So we know that, you know, these people, they are as interested as the rest of the people that were already using. At least 80% of the users scroll the screen. This was data analysis, you know, just looking at the percentage of searches that have one or more page scrolls and the front end tech that won't block us. So we just did like a proof of concept just offline. Let's just place the button there that appears and disappears and see if that is easy enough. All of this was validated good enough, but it could be that it was not. If it was not, you should celebrate because you saved a bunch of resources by actually having a very small test very quickly and you didn't invest in an idea that would turn out to nothing. And of course you can iterate on the idea maybe like there's something you can do for that assumption to not be needed anymore or change a bit. So yes. So then you validated your solution, which means yes, it's time to build them. And after you launch, then check it out. So did the impacts on the desired outcome actually happen? So is this in line with what you're expecting? Because this will also, you know, sometimes we do all this and even though product in the hands of the user has a different result. So this, if you check out and monitor the result of your actions, you will have like better feeling for the next opportunities that you discover. Is there user feedbacks or tweaks that you need to do? Is it necessary to refactor the code or move tech tabs? Is the idea good enough or not? Maybe you scrapped the idea. Now, what you do? I delivered or scrapped it so I can choose the next solution on this opportunity to validate. Or I can maybe like this opportunity is already exhausted. Like I need to get something else. So I go to another opportunity. And maybe like the outcome, you know, you already reached your goal. It's all good. maybe you need to pick another outcome. And that's how you do it. And if you want the slides, you can scan this QR code. And there are two questions that you need to answer about the presentation to get the link to the slide. Yes, discovery, right?

Level-up your product team's business impact by structuring your discovery.

Online course: https://productcrafters.com.br/opportunity-solution-tree-product-discovery-course/