Opportunity Solution Trees - Beyond the basics

I'm Ed Biden, one of the co-founders of Hustle Badger, and today we're going to talk about opportunity solution trees. Now, before I get going, just to tell you a little bit about Hustle Badger, we provide super practical advice, support and training for product managers and digital builders. The opportunity solution tree I am going to show, kind of talk you through it. is one of the templates that we've got on the site. And if you like this session, you're going to love the templates we have on our site, the articles, and also the courses we have on Discovery and Strategy. I'll stick a few links in the chat as we go through. But what I want to do today, if you give me a moment so I can share the right screen, is I'm going to talk you through a very kind of like... nuts and bolts approach to opportunity solution trees so sorry give me one moment whilst I sort my sharing out here we go there we go there we go okay so I should also mention just on a note of how we are recording this session so it'll be on our YouTube channel afterwards if you need to drop off early for any reason and i will also share the link to the this template um is in the chat i'll just stuck it in the chat if you want to to get it but what i'm basically going to do this session is talk through oops um this template for opportunity solution trees how they work and to give you a general overview now i should kind of flag two things like firstly opportunity solution trees they are a bit like spaghetti bolognese. You know, everyone has their own recipe. This is our recipe that we found very effective. It's not exactly the same as, say, Teresa Torres' recipe for opportunity solution trees. She was the first one to come up with these or other people's. But the broad brushstrokes are the same, absolutely. Secondly, If you do have questions, please do drop them in the chat and I will try and answer them as best possible. That's obviously one of the benefits of coming to a live session. So please do make it interactive. But with that, let's dive in. So Opportunity Solution Trees, at their highest level, these are a visual way of mapping out your strategy and discovery. are therefore a tool that helps both you think through where you're going to spend your time, like where you're going to spend your time both doing more research and more investigation and where you're going to spend your time building things. But they're also a really good way of getting input from other stakeholders that might be other people on your team, your designer, your engineers, or it might be communicating with other stakeholders, depending on the level of detail. that you want to go into. And if you look at this, the diagram, then you can see that there are basically four layers. This is a very simplified opportunity solution tree, but we'll dive, you know, to keep it simple, we'll go through the details. So at the top, you have your outcome. This is like the results that you are hoping to get by doing some work. So this could be your goals or your OKRs. Like, what do you actually, what is the impact you want to see happen? The next layer down, you've got your opportunities. So what are the things, what are the problems we could solve for our customers that might deliver this outcome? Below that, you've got your solutions. So this is sort of like, what could we build that might solve these problems, that might deliver these outcomes? And below your solutions, you've then got your assumptions. So what are the things that need to be true or what are the risks that we've got? when we think about the solution that we may want to investigate before we actually start building. So we'll talk through each of these layers one at a time, just so you can understand them. In reality, when you are building these sorts of trees, then it's not a purely linear process, right? You don't necessarily just start at the top, work through, and you're done. This is going to be an iterative process where you probably do start at the top and then sort of start working your way down. But as you start working your way down, you're actually going to realize that, you know, you know, you start thinking about solutions. You need to go back and kind of reframe your opportunities. Maybe your opportunities make you rethink, well, what actually is our goal here and where should we be aiming? Or you get new bits of information, which then kind of change how you think of whole branches. So this is this is not a kind of. purely as with everything in product it's not a purely kind of linear process it's very much an iterative one um and that also means that when you start drawing these things up don't worry about it too much like the structure just start getting your thoughts down and as you start working on it then it'll become easier to kind of tease things out and go into detail where you need to um and you'll find naturally that sum of it to that you're like actually this is less important and that that is actually a good thing right it allows you to focus on the bits that are important so you can see this is kind of like there's two versions of this as i say this is the simplest um version of this that you're going to get of an opportunity solution tree so like one object or one outcome one opportunity one solution and then a set of assumptions in reality you're probably going to have multiple opportunities, you're going to have multiple solutions for each opportunity, and then we're all going to have assumptions. So this is just a simplified version. But we've done two versions of this. One version which shows you the theoretical definition, like what does it mean, what should we do here, and one which shows an example so that between the two you get a really good understanding of what are we trying to do here. Okay. So let's dive into the outcome. So by the way, and if I'm kind of the wrong level of zoom, as it were, you can't quite see what's on the screen, please do again, just stick something in the chat and I can zoom out or zoom in so that it's easy to understand what's going on. So your outcome, this is, yeah, where are you trying to get to? What's the goal for your team? So I like to think of this very simply as, um a combination of a mission and metrics that's how i like to kind of define goals because that's a really effective way of defining things that the mission that's your kind of qualitative inspiring statement about what you're trying to achieve so um that is yeah it's kind of emotional it gives people that kind of like um feeling that you're trying to achieve as well as because it's qualitative it can be a little bit more all-encompassing however the remission on its own can is imprecise right you don't know how much progress you've made so i like to pair it with metrics or a measure um you know metrics are really good because they're very precise right you know exactly like how far you've gone from a to b what they're not good at is kind of describing the whole ambiguity of the whole kind of scope of what you're trying to do because metrics are by definition, they are kind of one dimensional. So pairing emission and metrics together allows you to have the best of both worlds. You can sort of say, hey, what we're trying to do is this, and we'll measure progress in this way. And we'll kind of balance those two off. Now, the metrics, I'll give you an example of what these might look like. But I just want to highlight the kind of the format that I use here. So I always use this format, move metric from baseline to target by date. And this format, is really effective because it means that you don't end up setting a metric which you then can't measure or it's ambiguous when you're going to deliver it by. And so it protects against some of the really common failure modes I've seen our product teams making. So as a CPO, I'd often be doing quarterly planning with teams and we'd be discussing what their target was. And they'd say like, oh, we're going to increase conversion 10%. I'd be like, okay, sounds great. But firstly, what do you mean by conversion rate? Between which steps are we measuring conversion rates? That's the kind of the metric that was the definition. What is that right now? So what is the baseline? Because often teams would find out that they wanted to set as a metric something they couldn't measure. And if you can find out what the baseline is, you know you can measure it. So that kind of protects against that. And then the... The date means that you know what kind of time frame you're dealing with. So it's not ambiguous about whether this is a quarterly goal or an annual goal or anything else. So what does that look like in real life? You might have something like this. This is a rather, I have to say, this is a rather plain mission. Increase our user base. We want to be the best social media app in the world. We want to be the... you know best recipe website going that sort of thing so this template you can find I'm just going to dump all the links again if you follow the one that says more on opportunity solution trees the second link down that's going to have the link to this template on the metric side here grow monthly active users from 80k to 120k by March 31st so you've got that your definition monthly active users you've got your baseline 80 000 you've got your target 120 000 and you've got your date march 31st so that's kind of where you will start off once you've got that you can look at your opportunities so this is sort of like most simply thought of as customer problems that you can solve however it's not strictly customer problems so why do i say that If your goal is to increase revenue, so maybe your goal is to increase revenue 30 percent. Great. You could do that by solving some customer problems and therefore getting more customers. Or you could increase your prices by 30 percent. Right. So in general, you're going to be solving customer problems. That's how product teams usually deliver financial impact. But you shouldn't overlook that there are also opportunities, which may be the way you. package your product or internal ops, things like this, which actually don't change the user experience at all, or may even make it worse, but have the desired business impact that you are looking for. So your opportunities are, yeah, how do you map these out? How do you find these? The ways I think that you can kind of find opportunities, like you may know some already. As soon as you start working on a product, you probably have some kind of intuitive feel for the users, which is a great starting point. But if we're product managers, we want to be driven by data, driven by facts. And so good ways of feeling out opportunities are these four things. So firstly, going and speaking to users directly, going and asking them. What do they want? What will they pay for? Looking at how they currently do tasks and workflows and seeing where the friction points are. Doing user tests on your funnel, on the flow through the product and seeing where they get stuck. You can then back that sort of thing up with behavior analysis. So you can see in the data. which features people are using, which features people aren't using, where they're dropping off in the funnels, that sort of thing. Third way, like process mapping. So if you create a service blueprint or any kind of visual diagram that maps out processes, systems, touch points, these are great ways of spotting where there's complexity or kind of like jarring experiences or inefficiencies. that you can improve and yeah you can also just go and speak to subject matter experts particularly b2b and effectively yeah that works because subject matter experts having worked in the field for so long sort of have almost internalized you know the first three things and you get a bit of a shortcut just by going and having a quick conversation with them so that they're often like a really good starting point which you can then go and double check and dig deeper into with the um the these other three so that's a really good way of finding opportunities you then need to prioritize them right because you'll probably find that you could have you know three four five opportunities which one do you decide to do first one of the benefits of doing an opportunity solution tree right is that you don't have to think of you know you don't have to go and look at a hundred different solutions right and prioritize those you can prioritize higher up the tree and say like actually let's just think about one or two opportunities we're going to look at and then we'll only look at the solutions underneath them we're not going to look at the other branches um yeah because they're they're tackling other opportunities so to prioritize these opportunities i like to do um a few different things so you can sort of impact model it So that's a really good way of looking at it. So it's having often a fairly simple model in a spreadsheet where you can see, OK, what are the drivers here? How much have we changed things with similar features in the past? What do we see as the difference between our best and worst performing cohorts? These are all great ways of coming up with a quantitative model. And this is not going to be a an exact forecast of how much impact you'd get by solving this opportunity, but it is going to give you a better understanding of what is the range of possibilities and what's a reasonable range you might see, and therefore what's a relative difference between different opportunities you're looking at. And there's always going to be uncertainty when you do this prioritisation, but it's going to help you navigate that uncertainty a little bit better. I definitely go and look at customer factors. So again, when you spoke to your customers up here, when you did those user interviews, what did they say about the severity? As in, like, how important is this problem or is this opportunity to them? Is this their number one thing? Is this something they're going to leave the product or is this something that's a kind of minor annoyance? And a really good way to test that out, especially in B2B, is I ask them how much they would pay. to solve you know if that option if you were going to add functionality that completely resolved that that problem how much would that be worth for them or what's their budget for solving that you can also look at incidents or frequency so if you go and speak to 100 customers what percentage of them actually see that problem and those two things you know you know incidence and severity so how big a problem is this and how many people does this affect that then allows you to triangulate quite nicely on the customer side at least how important it is. I should say that's not the only things you should think of though because you should also think about company factors like does this fit with your strategy does this fit with what other teams are doing does this fit with like the marketing strategy or how you're positioning yourself and your business model like it's not just about what a customer wants but that is a large part of it. And you should also have one eye on market factors. So as in, how is the industry moving as a whole? What are other competitors doing? Where are other competitors strong? Where are you strong relative to your competitors? And how do you want to position yourself against them? So all of these things, you can kind of like factor into your prioritization. When I lay out opportunities like this, so I'll often do it as a kind of, you know. I want to, I need to. So very similar to like a user story or how might we, you know, these are all kind of like classic framings for product managers. And I'll put the evidence for like how I prioritize this kind of like near the opportunity. So anyone else can see what the evidence is or I can remind myself how strong the evidence is. Is this like two or three conversations we've had with customers or is this a, you know, an A-B test we did on a previous feature, right? And so that evidence should then justify whatever your prioritization is. Is it as simple as high, medium, low? Do you want to get kind of like more granular than that? That's up to you. So as an example, opportunity here, we want to help users recognize the value the product offers, SAP. So we want to reduce the time to value. And we might have some customer interviews here. We might have some behavior analysis. We might have some competitor. you know analysis as well that's the sort of thing you might put here again this is when you're comparing opportunities when you've got multiple cards looking like this this is unlikely to be black and white about which one you should prioritize this is always going to be an art what you're trying to do is just lay things out visually so it's a little bit easier to see which of these makes more sense you'll also find that as you start to lay this out you know that where are the dividing lines between opportunities a lot of these things are going to be interlinked and that that's fine right you just want to kind of try and tease it out as best possible um and i'd also say that you know the evidence that you have down here this is obviously going to be um you're going to add to your evidence when you actually ship things you know when you actually ship features you'll see what their adoption is you'll see what impact they had that's either going to reinforce how big an opportunity you think this is Or it might actually detract from you and say, hey, we thought this was a big opportunity. We released a feature we thought would be a slam dunk here, and nothing happened. So actually now we're not sure this opportunity is as important as we thought it was. So again, I'm just going to dump the links back into the chat as someone else is asking for the Miro board. Again, this is in the second link down. If you go into the... opportunity solution trees link you'll be able to get this template so that is opportunities if you've got questions about these kind of like top levels please do jump in any moment i'd be happy to answer questions but let's also dive into solutions so your solutions these kind of branch off each opportunity basically like okay we've got this opportunity we've got this kind of customer need or we've got this business problem that we think we can solve because you might have internal stakeholders here right so like you know as the ops team they want to be able to do something right but you then have things you can build that will help you address this opportunity so um where do these solutions come from well actually sorry let's go over like what does this look like so you probably state your solution at least initially as a bit of a hypothesis so we believe you know this feature x will encourage this type of user maybe that's everyone maybe it's power users maybe it's first time users um you could have different segments here to do this thing okay so that's going to give you then um that and and yeah this action should clearly kind of indicate that you know their need is then met and should have a kind of plausible mechanism back up to like moving the metric that you've targeted right so if if this kind of like action does not link back to your outcome this is not this is not a good solution this is not going to like do what you should be and something's gone wrong in your logic either because this opportunity doesn't really deliver against this objective or the solution does not deliver against this opportunity again quick example here we believe adding motivational questions pre-sign up will encourage users to complete the onboarding process so great what are we going to build we're going to think about adding motivational questions and we can see if that works that should help users recognize the value of the products and if we can do that that's going to increase our user base because people will stick around for longer okay so that's the kind of mechanism that we're kind of that we've got a hypothesis for there so where do these ideas come from or what do they look like so good solutions i think come from a mix of two things right you know you've got a really good problem or a really good opportunity right so you've got that objective for success you've got some kind of diagnosis of what's going wrong so you've got evidence right you've done some analysis you've spoken to users and you've also got that context so that kind of company strategy market trends you know industry trends all of that sort of stuff coming together so all the stuff above your your solution your your outcome and your your opportunity and then you're going to kind of mix that with good inspiration and good inspiration look at competitors look at um you know cross industry references look at look at kind of abstract inspiration you know architecture nature that kind of thing and also do this with a diverse group of people so the you know when you speak to people with very diverse viewpoints you're going to get a broader range of um ideas here and therefore you're more likely to find some really great ideas. So if you have the time and if you have the kind of the team, what you want to do is pull together a designer, at least one engineer, like maybe some people from some operational teams or marketing teams or sales teams, you know, as well as yourself, and then have a think about like, okay, if this is the opportunity that we've got up here and that we've prioritized and this is our goal. what might we build down here, given all of this evidence that we've already gathered. So that's kind of what you're doing. And generally, you know you've got a good solution set when you've got a broad range of options to choose between, right? They all look like they're going to create some value. They all have that kind of sense that you're going to address this kind of opportunity there. And they're also impactful. So you think that, as we talked about, that chain back up to the outcome that you actually want to happen. So Alex was asking, Teresa doesn't like brainstorming in groups. What do you think? I think it depends how well prepped you are. So I'm a big fan of things like design sprints. You know, a design sprint doesn't need to be a design sprint, right? It doesn't need to be a kind of like a week long process as defined, you know, in the book kind of thing. But basically... Having this kind of context or this briefing about what is the problem and then getting a diverse group of people together and on the basis of a shared kind of fact base, thinking about ways to solve a solution, I have found hugely, hugely beneficial. I think where brainstorming doesn't work is when you actually don't have that briefing, you don't have that kind of evidence base and you're just sort of saying... hey, let's get in a room and just have some general thoughts on what we might build next. In that case, it can be a little bit counterproductive because you're kind of papering over the fact that you don't have any research, you don't have any fact base, just by getting a bunch of people together. And that's then just a waste of people's time. Once you've got your solutions, then you can move on and you can go down to this assumptions bucket. And I'd say, opportunity solution trees, they're also valuable when they are incomplete. So, Theresa adds assumptions down at the bottom. Even if you just get to the solution stage, that is going to be better than not having this at all. Even if you just use it to prioritize between opportunities, that is going to be useful in its own right. But the more levels of detail, obviously, the more useful this can be. So, I like to map out the assumptions. I think assumptions is really useful because when you're depending on how big these are, right, if these are just little things, you're like, hey, we can build this in five minutes with claw code. I mean, how much do you care about the assumptions? Like a lot less, right? Because the cost to build is less. But if you're talking about, well, this is quite a big change, you know, to the positioning or this really fundamentally changes the user flow, that's a little more risky. And you might want to think through. the risks and the assumptions you've got before you commit to it or before you even test it. But your assumptions, I think you can come up with a bit of a matrix here. You've got your different types of risk, whether you use your Marty Kagan's four risks or your IDEO's three risks or whatever, there are different types of risks, value, business, technical, usability. You've got different classes of risk here. So value is like... do customers actually want this business can we actually deliver this is this profitable technical can we build this usability do people know how to use this solution right so you've got your different risks there and then the other thing i like to do is kind of like map this out by saying like okay well what is the risk like what evidence do we have that this is a risk it's not a risk like why are we worried about this and therefore what is the next steps right so how would we test this or how would we reduce this risk and for me the trick here is not that we kind of you know fill out all the boxes for everything and have a complete you know have 20 000 posters like that's generally actually counterproductive it's more that you've got this mental model where you can think like okay so for this solution we're talking about where are the major risks? Because there's probably like two or three things that might really kind of blurt out the water. Is that a value thing or are we pretty secure on that? Is it a technical thing? Great. Let's just focus on the types of risks that are actually a problem. And then let's think about kind of what do we already know and what do we want to know? So this is a way of prioritizing your discovery. And so again, the success of this is that you have two or three tests that you want to go and run it's not that you've got a comprehensive list of every potential risk and downfall for your future okay so you might end up with something that looks a bit like this um so we have this again go back to this this kind of suggestion here we're going to add motivational questions pre-sign up so sort of like why are you signing up is it because of this or that or um are you looking to get more time back in this way or more time back for that are you looking to save money this way or not That's kind of what we're looking at here. So here, there might be a value risk. Adding questions to the flow has no positive impact on motivation. There might be a business risk. Well, not really. Limited business risk, great. Technical, no, this is pretty easy to build. Fine. If this is a limited technical risk, you see, like, we don't really need to think about the evidence in the next steps because it's not really a risk. But for value, we're like, should we even build this? Well, then we can have a think about, like, okay what is the evidence well we've seen this in in other you know we've seen this written up in behavioral science books we've seen other companies using it we've never tried anything like it ourselves okay so there's some evidence there but yeah we might want to test this do we just go and build it we might just go and build it because this isn't very difficult to build and run an a b test okay in this case so that is how this this might kind of pan out for for real um So yeah, that's kind of how the assumptions come together. I'm going to pause there. We've kind of like run through the whole thing now, kind of like a first pass. Any questions on how this all kind of comes together? Do I have time recommendations for each step? Not really, because I think this is one of those things which you can spend as much or as little time on as you want. you know if you went and sat down with a piece of paper or you know at a whiteboard or a mirror and did this i think you'd be able to have something that was kind of worth sharing with other people within about an hour or maybe maybe two hours um can you then um you know spend hours and like days and weeks on it yeah absolutely if this becomes the primary sort of document or artifact that you're using with your team to align on your strategy, align on what you're building next, like, then this is something that you're going to keep spending time in. I think that's really the, like, you've got to ask yourself, like, again, this is a framework, it's a tool for alignment, for communication, for decision making. Is this just for you or is it for other people as well? And is this a sort of like one-off exercise that you want to do as a way of kind of... checking your thinking for your plan that you're going to store somewhere else you've got a written document for it right or a roadmap or something or is this like a living document that you want to be using as the primary way your team thinks about discovery and what you're building because both are valid right there's no right way of using it um you just don't want to go to kind of you don't want to kind of like pour two weeks full time into building a super detailed opportunity solution tree and then never look at it again because that's not going to be a good use of time. Do I have advice for scaling or using this with clawed code? I mean, I do in the sense that I saw someone build one of these in clawed code. And maybe I'll even see if I can dig it out really quickly. Maybe that's a task for another day, actually. So I have seen someone build a software version of this in clawed code pretty rapidly, like within a day or two. So if that's your... that's your jam, that's your thing, then yeah, using the latest AI coding tools, you don't necessarily need to do this in Miro. You could do this in, you know, build a kind of like little custom sheet for it. Nastia's asking, how to limit the number of solutions for opportunity if you brainstorm too many? So I think this is, yeah, this is the same when you're prioritizing anything, right? I would think about... Each of these layers here, we've shown outcome one layer, opportunities one layer, solutions one layer. In reality, you can have multiple opportunity layers where you've got a little hierarchy. You can have multiple solution layers. We've got different clusters of solutions. Again, I just think about how useful that is. That's going to be useful if you've got one opportunity and then you've got 100 potential solutions of it. I would think about how do you cluster those solutions into maybe three or four groups and decide which of those clusters are going to be most useful, and then just prioritize the solutions in that cluster first and ignore everything else. If you've only got three solutions, well, don't bother putting two of them into a cluster and having another layer of hierarchy because it's just going to make the whole board more complex. So I hope that answers your question. best yeah so the things that i would say um usually or another good thing about opportunity solution trees is that they help you kind of spot visually some fairly common flaws in logic um that product teams make so for example we talked about this one a little bit if you have a solution you're thinking of building um you're really excited about building a feature but actually it doesn't address an opportunity or that opportunity that does address does not link to your actual you know your objective that should be fairly obvious from from the chain here and that's a really good way of like not building something that is everyone's very excited about because it sounds like a cool feature that isn't actually going to you know get you any closer to the goals that you've got set Melissa's asking, how would you recommend using this with data scientists and machine learning engineers who default to the solution as a model? Yeah, I mean, I think you can generally, like, that may be the case, right? But that's a bit like saying the solution is software. It's like, well, yeah, we're all digital product managers. So, of course, the solution is software. But what are we actually talking about doing here? Because when we're talking about improving a model, we're probably talking about like quite specific changes to the model at the solution level we're going to add more aspects to it we're going to add you know more structured data we're going to do whatever like there'll be some technical things that we we are going to build but that should still deliver against a customer problem or a company opportunity in a way that we expect is then going to deliver against this objective So I think you can still force it through the same logic and say like look we can't avoid this kind of this chain of reasoning even if we think the answer is a model. The answer may well be a model but what we want to make sure is that we're focused on the right problem and the models that we're building we're thinking about the right improvements to the models you know that address these opportunities. We're not we're not just going to like any model. Yeah so Alex you're asking like what happens when you're getting pushback? you know, not everything needs an opportunity. I would, so I guess maybe you can give a little bit more context here. I'm happy for you to come off mute and just talk it over. Are you talking about like, you know, maybe a kind of a salesperson being like, we just need this feature. We, you know, we don't need to go through this whole frameworks thing. Is that sort of situation you're talking about? Yeah, it's kind of like that, Ed. So yeah, senior leadership is very much like, there's this like thing we need to build it. Like it's going to be valuable. And I'll say maybe like, oh, well, we actually haven't seen any customers asking for this thing or any users really hitting that problem. And they'll kind of reply being like, well, just because we haven't found it's a problem doesn't mean it's not a problem. Yeah. Does that make sense? Absolutely. And this is fairly common, right? So I think I'd be quite careful about sharing an opportunity solution tree with... it's like sales and marketing people unless you've already won their trust because if they already you know have a dim view of products or don't kind of like subscribe to product management which a lot of sales people don't they're going to see a lot of post-its on a board somewhere and be like this feels like a waste of time can we go make some money please um so the way to tackle that i think is to be to translate the discussion into their terms and it's less of a kind of opportunity solution tree um then question and more of a how do you work with sales people and a credibility question but in that case i'd basically be like talking to them about you're just feeling out like what makes them convinced that this is uh the right opportunity um right and you don't have to say like in those terms be like oh yeah that's an interesting idea like is this something you've seen in another company is this something that our competitors a building is this something customers are talking about just try and understand their perspective a little bit um because they probably come to that answer to a reason and if they really haven't that's fine as well but you've you've kind of like clarified there's no evidence for this i would just like then translate what is the build time and the opportunity um cost into financial terms and say yeah because effectively the conversation you want to be having is like look i'm not being difficult but you want us to build something that's going to take us four weeks that's equivalent of spending 50 000 pounds of engineering time building something and you have zero you know evidence for this so yeah honestly would you you know give like 50 grand of your your sales budget like on this because if you're really convinced sure maybe we can do that and some things aren't going to be judgment calls but let's just be have an honest conversation about like what financially is at stake in there so that that's the other technique i'd use um is that is that helpful alex yeah that's really great thank you yeah great um and we've got a question you know do we use osts at hustle badger or other frameworks that we find more useful so this this really depends on the um yeah almost like what is the level of strategic question we're answering so I find opportunity solution trees are really good for what I call it, almost like quite high level strategy. Because I can say like, okay, we've got a problem. Maybe we've got a problem. We want to boost our subscriptions. Great. At that level, we can then think about like some quite... different opportunities we might want to address. Maybe we want to put more value into the subscription. Maybe we want to improve our onboarding process. There's lots of different routes we can go there. If we've decided, though, that actually this is really about the onboarding process, if I want to dig into that, I'm probably going to switch to a different tool. I'm probably going to use a customer journey map and actually map out the user experience, like screen by screen or touchpoint by touchpoint. This is a little bit of a personal preference, right? You know, I kind of, for those more tactical, like more detailed discussions, I prefer customer journey maps and a kind of slightly higher level strategy questions. I prefer opportunity solution trees, but this is whatever helps you have the conversation and get to the right answer. Because again, these, like, this is not about having a perfect diagram on a mirror board. This is about kind of building stuff that actually does have impact for your customers. And that means, having the right conversations with your colleagues. Super, happy to answer any more questions. Again I've shared the links in the chat a couple of times so if you do want to get this Miro board you can find it on the Hustle Badger site. You can also just look for it, it's in the Miroverse and so you'll find it there as well. There's a Figma version as well if you prefer FigJam. But we do have as I mentioned briefly like you know articles that talk through this we've got some courses that dive into opportunity solution trees and discovery and strategy more generally so those are worth checking out if you want to go a little bit deeper and then if you enjoyed this webinar we've got more upcoming talks on our luma page which i also shared the link with and the recording for this will be on our youtube channel along with all the other videos that we've got from other webinars so that's worth checking out as well great well if there's no more questions i will finish up there then thank you very much for coming along and hopefully see you soon thanks very much take care bye

In this webinar, Ed Biden, co-founder of Hustle Badger, walks through a practical, step-by-step guide to building opportunity solution trees (OSTs). Designed for product managers, designers, and digital builders, this session covers how to define outcomes, identify and prioritise opportunities, generate solutions, and map assumptions. Whether you're new to OSTs or looking to refine your approach, you'll learn how to use this visual framework to align your team, communicate strategy, and make better product decisions.

*KEY TAKEAWAYS*

* Opportunity solution trees are a visual tool for mapping strategy and discovery, helping you decide where to focus research and what to build
* Start with a clear outcome that combines a qualitative mission statement with a precise metric (baseline, target, and date)
* Opportunities are customer problems or business challenges you could solve to deliver your outcome — prioritise them using evidence from user interviews, behaviour analysis, and market context
* Solutions are hypotheses about what you could build to address a prioritised opportunity — generate them through collaborative sessions with diverse team members
* Assumptions help you identify and test the biggest risks (value, business, technical, usability) before committing to a build
* OSTs are iterative, not linear — expect to revisit and refine each layer as you learn more
* Even incomplete OSTs are valuable for alignment and decision-making; don't over-engineer the process
* Use OSTs to spot flawed logic, such as solutions that don't connect back to a real opportunity or outcome

*CHAPTERS*

00:00 Intro – What are opportunity solution trees and why use them
03:10 The four layers: outcomes, opportunities, solutions, assumptions
06:05 Why OSTs are iterative, not linear
09:01 Defining outcomes: mission plus metrics
12:04 Finding and prioritising opportunities
23:00 Generating good solutions through collaboration
26:20 Mapping assumptions and identifying risks
35:07 Spotting common logic flaws with OSTs

*LINKS AND RESOURCES*

Hustle Badger website: https://www.hustlebadger.com

Webinar recordings: https://www.youtube.com/@hustlebadger
Register for future Hustle Badger webinars: https://luma.com/hustlebadger

Hustle Badger LinkedIn: https://www.linkedin.com/company/hustle-badger
Ed Biden LinkedIn: https://www.linkedin.com/in/edbiden/

Opportunity solution tree template: https://www.hustlebadger.com/what-do-product-teams-do/how-to-build-an-opportunity-solution-tree/ 
Hustle Badger Discovery course: https://www.hustlebadger.com/courses/product-discovery-course/
Hustle Badger Strategy course: https://www.hustlebadger.com/courses/product-strategy-course/

*HASHTAGS*

#OpportunitySolutionTree #ProductManagement #ProductDiscovery #ProductStrategy #OST #TeresaTorres #ProductFrameworks #UserResearch #ProductPrioritisation #DigitalProduct #ProductOps #ProductThinking #StartupStrategy #ProductLeadership #Roadmapping #CustomerProblems #ProductDecisions #ProductTeams #DiscoveryFramework #HustleBadger