How a unicorn is using OSTs to scale Product Discovery - Airtime webinar with Stephan Beyer

People are coming in. I'm just going to say a few words in the beginning to get us started. And then I will let Stefan take it away. So a couple of words about myself. I'm Akos. I'm the CEO of Airtime. And Airtime is a user engagement platform for small and medium-sized tech companies to validate user needs rapidly so you can improve your product adoption. One of the books, I just brought it for myself, that I came across in the last years, and I think it made a lot of impact, and I'm sure many of you have it on your bookshelves, is Continuous Discovery Habits by Teresa Torres. And she has this amazing framework about opportunity solution trees. And when I read the book, I thought it's awesome. And what would be more awesome is to see this in practice. Now, lucky enough for me, Stefan is someone I know, I'm acquainted with, and we even worked at one point together in the same company. And when I heard Stefan is a big fan of opportunity solution trees, and that's something that he implemented at Grover, I thought this is the right moment to hear about the behind the scenes stories, what works well, what doesn't, what are the pitfalls and things to look out for. So I did a lot of talking now for the introduction. I hope everyone's here. one admin stuff there's a in the lower right corner there's a chat icon if you have any questions even during the webinar feel free to post it there when stefan is through we will go go into a q a session and i will throw these questions on the on the screen for stefan and we'll we'll pick his mind jointly so without further ado stefan it's a pleasure and honor to have you here and I hand over the virtual mic to you. Awesome. So thanks, Elkos. Hi, everyone. It's definitely a pleasure to be here. I hope you can hear me all very clearly with the mic. Otherwise, just please let me know. No, it's a pleasure to be here. Just very, you know, just 30 seconds briefly about myself. I've been basically been quite involved in product discovery over the last couple of seven years with really different type of organizations. So ranging from a venture builder, a company builder. to a big tech company and now a scale up and yeah, product discovery. I mean, this is a topic and opportunity solution trees where we would definitely need more than 30 minutes, but it's something I'm really excited about. And as Echo said, there are definitely a lot of pitfalls, a lot of learnings along the way. And honestly, first of all, I think there is no silver bullet when we speak about product discovery or opportunity solution trees. And I think this is so important to understand. I just for myself had a lot of meaningful learnings and best practices by actually leveraging OSDs on a day-to-day basis, ranging from, you know, you need to solve a couple of critical problems, which are more essential and you need to expand your mindset about them, but also how you can embed it into an organizational structure for product teams. So in the next 30 minutes, I will give you a couple of examples on how we have been using them, what's working well for us, where I've seen a challenge. um what is an opportunity solution we also very briefly with an example because i think we have a couple of people who might have who are not so familiar yet with this topic and then we're ending up with a few examples on how you can also operationalize them because there's a big jump between opportunity mapping and opportunity management and we also recently started to actually roll out jira discovery across all product teams so i will give a couple of learnings from that and we will see how far we get um with the time so having this said let me share my screen and jump right into the context So this is coming up guys. Can you see it? Super. I assume so. Yeah. All right. So just first things first, you know, why are we actually talking about product discovery in the context of opportunity solution trees and why should we care? So I think there's something really important to understand. And if you just zoom out high level, and I think many of you are familiar with it, let's imagine you're building and launching a new product, right? You have a couple of cycles and stages you're going through. You start now with the why are we actually building this, right? What do we want to achieve? What are we building to actually how are we delivering it? So there are a couple of phases, you know, ranging from product vision, strategy. to product discovery, making sure you understand what you're building and making sure you're building the right thing to actually delivering it. And if you look into practice, by speaking to colleagues, looking into different type of organizations, what actually comes more and more often to my mind and what I see is happening is basically that in practice, this stage is quite often neglected or completely skipped. And this is something which we actually find a lot of very interesting data about it. What Intercom has done, for instance, they have taken a look. into different startups and scale-ups and they wanted to understand how 100 units of work are split across the development cycle and what they figured out by looking into that is basically that a typical startup is spending a bit of time in prioritizing the problem defining it designing the solutions and some startups actually spend zero time on it so when we talk about discovery there's basically you know like maybe 20 of the capacity spent on it and the majority goes straight into building a solution and why does this matter I mean, you know, if you take a look at the number one reason why companies are failing, like startups or tech companies, we actually see it's related to not achieving a market need and not creating value for your customers or your business. And that's an interesting one. So if you go to see the insights, really recommendable to reach for the top 20 reasons why startups are failing. And I mean, why is this the case, right? The truth is, and I typically love to show this picture because I think it's just simply true. No one of us is a palantir, right? So we simply can't predict if a product which we're going to build is going to work out in 8 or 12 months from now. So what is going to happen if we launch in 8 or 10 months without validating it properly and rushing through discovery? We will face very high costs if we are wrong, right? And as a job, as a product manager, I think it's quite simple. You need to maximize the value creation for both your customers and your business with the resources you have available based on all the opportunities you're getting exposed to. So you need to pick the right ones. And this is something extremely difficult. This is not easy. And the problem is, right, if you launch at a very late stage with your validation, things will get very expensive. The alternative to that is obviously, and I think many of you have done it in the past, I think we have a lot of people in product and design here in the call, which is great, that you obviously try to validate things as early as possible. And if you fail, that's also right, because then you at least learned very early on that you're on the wrong track and you can reprioritize the opportunities you are actually. um putting putting at the center of of your strategy so talking about osts and why this matters uh first of all just disclaimer i this is really important to understand there is no silver bullet and i actually love what marty kagan said with people are always searching for silver bullet but there is no silver bullet and invariably they've figured it out and an opportunity solution we snide a silver bullet and this is important for everyone i think you really to embrace um also at grover you know not every team of us is working with osts we have a lot of product teams who are using them on a continuous basis and doing that at scale in a fantastic manner but i also had a chat with a product manager last week who said hey you know actually it's great i see the value of how teams are using it but for me personally you know actually i'm not so uh convinced and confident in using an ost and i have an alternative setup on on how i'm actually breaking my opportunity start which is absolutely fine right it's not about the process it's about the value creation and this is one tool which worked really well for myself and this is what we're going to cover in the next uh couple of minutes um why i think it's important um if you take a look at some of the challenges you know on product discovery which we just discussed across different scale-ups or type of organizations i get kind of the impression it boils down to three reasons one is like you know it there's a lack of the proper structure and process and muscle also from for the teams you know to drive product discovery at scale and it always feels like hey broad discovery isn't that easy and truth is no doing this properly efficiently with a high quality is definitely complex and you need time and experience you know to learn it it starts you know with user research to experimentation to opportunity mapping stakeholder management so there are a lot of competency you need to master and if you don't have the structure to do this very effectively and efficiently that you also your team is aligned to it it will be a challenge one of the biggest challenges at all what i've seen is like the organizational mindset right so if an organizational mindset is not there you know to talk about outcomes and make sure you have a north star based on outcomes you will have a hard time and last but not least achieving fundamental stakeholder alignment so when i started in product i was reading a lot about the skill set and you know which i need to acquire and i remember when i was thinking about hey stakeholder management comes always as top priority i was wondering isn't that the easy part like you know isn't stakeholder management a soft skill which you are easily able to acquire but the truth is you know um if i've seen people failing then majority of the reasons it was related to stakeholder management so what i see what ost what opportunity solution trees are doing is you address those challenges actually in a very natural manner because what we are doing is like we make a desired outcome on north star so we're not talking about outputs we're not talking about features we talk about the real impact which we want to achieve and we have a visual representation of our opportunity space And this visual representation is really, really important. And I will dig deeper into that in a few minutes. And you also have a structure in place, which is encouraging that you have continuous touch points with your user. It's encouraging that you're expanding your opportunity space. So we're not talking about one feature, one solution for the problem or to reach our outcome. There might be multiple opportunities. And we also encourage continuous experimentation. So opportunity solution reaches one-on-one very briefly. What is it? How does it work? And what are the learnings on that? So, I mean, for those of you who have not seen and have not used it, an opportunity solution tree really comes in all type of visual representations and forms. And quite often people react to that and say, hey, this is actually quite messy. And I mean, I've seen mirror boards where we have like hundreds of opportunities mapped. It's getting quite huge over time. So it definitely becomes messy. But the structure is actually not messy at all. The structure is actually very clean and very structured. You start with something, and I'll just quickly go through that before we jump into an example. You start with a desired outcome. So it's the most important part. This really becomes your north star. So you define clearly what you ultimately aim to achieve and what success means. And here we don't say, oh, we need to ship a product. Here we say, oh, we want to increase user retention. We want to increase user engagement. So we define a clear value creation of what we want to achieve based on a real outcome. Then we have opportunities. So here we are leveraging our standing from our customers like, hey, what are their needs? What are their pain points? what desires do they have? How could we potentially address this desired outcome? And the important point here is we already see that a lot of people are getting confused. There's a difference between an opportunity and a solution. And this is really, really important. And with the next example on the next slide, which you will see, I hope it will get more clear. But based on this opportunity, which is more broader on purpose, you can think about what are the solutions like? How might we actually deliver upon that? What is the concrete solution which comes into our mind? How can we test this solution? in a very simple and swift manner in order to generate data. And let's see if this data is actually having an impact on our desired outcome. This is in a very swift manner now we're rushing through it, a bit of the structure from opportunity solution tree. The most important part though, what you have to get right is this understanding, the outcome and the opportunity. And this is where everyone like always reacts to all this is the easy part. It's easy to understand, but honestly, it's really difficult to master and practice. And I'm not sure how many of you have been running a lot of workshops, you know, with OSTs, with stakeholders and teams, and then try to break it down. And you will see it takes time to build the rationale about it and this understanding. Let's go for a quick example. And this was for me one of the most inspiring one, actually, which I came across six or seven years ago. It's actually from Stanford School, so definitely not my credits. But it made so much sense to expand a bit on this concept. So if you look at this picture, and I would ask you, like, hey, what does the girl need? What would be you know what would come into your mind? I'm not sure now if we have a check there Arcos or if you want to do a guess yourself Do we get something on this so on the on the chat feel free to guess someone's guessing Groceries good, okay, but we can take this already the groceries because this is a fabulous example Yes, the typical answers which are coming in this for instance groceries. She needs a snack. She needs a letter. She needs a lower shelf, right? So the interesting part here is, you know, guys, all of that is actually a noun, right? And let's try to replace a noun with a verb. And then you try to answer the same question again. What would that be? And then suddenly people start to think. And it might be, for instance, you say, she needs to reach. What is this difference? Why are we talking about verbs and nouns now? With a verb like she needs to reach, it could be a letter. It could be a snack. It could be a shelf, it could be a rocket, I don't know, you know, we could brainstorm in this group and we'll come up with 50 different examples. But if you say it's a ladder, it's a ladder. We're done here, right? We're solutionizing. We will build the first thing, it's a ladder. If you say it needs to reach, we are completely opening up our solution space. And this is the important part to understand, you know, people are not buying this quarter inch drill, they're buying a quarter inch hole. And this is the benefit, what I see, you know, on a day-to-day basis, when you need to solve a very complex problem from stakeholders or business challenge. that you can clearly define the outcome and you can break it down like what are the we start with a mindset that there's more than one solution to this problem and we will go with the most effective opportunity to address our desired outcome because if we go ahead and we say hey it's an output it's the quarter inch drill our solution will be a quarter inch drill right if it's a quarter inch hole we will say oh it could be a quarter inch but you know what there are five alternatives to that so this is important to understand you are widening your opportunity solution space basically or the opportunity space tremendously just bearing that in mind when we talk about outcomes and opportunities so let me give you a very brief example and i cannot break everything down into all details because then we would need to spend way more time on it but let's imagine you're building a banking app right and you say hey we receive a business target we need to grow our customer base by x percent and then you go down and you set yourself a target could be an okr whatever you want to call it and then you say here our desired outcome is we want to improve the registration completion ratio right we're not talking about a feature we say hey because it's important if people who are getting more efficient how people are onboarding themselves we will grow our user base and then you can break down all the opportunities you have let's imagine we talk about uh we identify one where we say it's improving the kyc because the kyc you know like the verification is something what people don't like you need to speak to an agent it takes time very well-known problems so let's imagine you've done some user research. You speak to your customers, you look at the data, you look at your onboarding funnel, and rather than starting with solutions, you again, you break this opportunity into sub-opportunities. And you realize, hey, a couple of people actually are voicing their concerns that they don't have time to do it. They would expect a bit more flexibility when they can complete this KYC. Then you also realize, you know, we see a lot of people are starting it and they're dropping off again. So, hey, we could actually remind them of it. right and another alternative might be oh a lot of people tell us they don't know how much time they need to dedicate to it is this you know this conversation with an agent taking five minutes 20 minutes so it would be great that they understand the length of it so here we are basically again opening up the options what we can do but we are not limiting us to a complete feature this is starting the next space where we can say oh what can we do to provide customers with more flexibility we potentially for instance can do something like oh let them snooze the video kyc so they can come back to it later Oh, reminding customers, what can we do? Oh, we can send a push notification, we can send email reminders. There will likely be seven other solutions to this need. We can enable them to understand the length of it. Let's create a visual brokers bar, right? So you understand exactly where you are in the onboarding flow and so on and so forth. Then we can define an experiment, for instance, hey, let's test multiple push notifications to see what is performed best. And then we see again if we're hitting our outcome or not. So this is just to give a bit of an example on how we can break this down. This layer here is the one where really your user research and your continuous discovery is coming in. So think about the word versus noun thing, what I just explained. Here you can look at the data you're seeing, the conversations you have with your customers, and this is something which is continuously growing. So this is important to understand. This is not like a one-stop thing, hey, let's get together in our team, we create an opportunity solution tree, and then we are done. Ideally, this tree is growing, and you can go back to it. And why is it so important for stakeholders? We will cover in a minute. But it's a continuous process. You keep on learning, you keep on growing your understanding of the opportunity space and the respective desired outcome. It's actually, and I think coming back to stakeholder alignment, for me, opportunity solution trees have become kind of a superpower, you know, in your product arsenal, how you can drive stakeholder alignment. And the reason for that is the following. And let's be honest, I'm sharing two examples here. And maybe people can react to it if they feel they have seen this already in the past. So the first one is, you start to work with stakeholders or with your team or the wider team related to your squad. And then you actually feel, hey, we're all on the same page. We discussed this or that, right? But then in the end, you figure out, hey, people have completely different understanding on what they want to achieve or what the purpose of a certain product is. And there's another situation, right, where everyone of us is coming in with his own bias, with his own experience, with his own concerns. with his own expectations. So we're looking at an opportunity or an outcome, for instance, from completely different angles. So it's very difficult for people to get this big picture on actually where are we going and how can we make sure we are aligned. And the important part is like, you know, we're humans and it's quite simple. We are all very visual. And this is why it's so imperative that we are outlining something in a way that's easy to digest and that we explain the why. So think about a backlog. This is just an exemplary screenshot from the web. But it doesn't matter if you use your backlog. A roadmap, obviously, is way more meaningful. But in the end, it's not so easy for a stakeholder to immediately understand what is the big picture behind it. And also for your team, like, why are we doing this? Where are we going with that? And with an opportunity solution tree, you provide a structure which is a bit more easy to digest. It's a bit more self-explaining. And also, you have an overarching purpose in how you can break it down. If you don't have a structure and I will go about talking about how you can embed that potentially in your planning cycle in a second, you will see that you run an experiment, for instance, but not suddenly you will be able to connect it to the bigger picture where, you know, stakeholders or your team might question, hey, why are you doing that? And then you have all of the blue structure, which is easily to follow. Oh, we are running this experiment because we believe it's important to see if we can validate the solution. If the solution is going to work. we will impact this desired outcome. If this desired outcome is impacted, it has an impact on our business strategy. So you basically have a red line on how you can connect with us. And yeah, honestly, I think also PMs sometimes, as PMs, we make our life too easy by, for instance, arguing like, hey, stakeholders don't understand. And I've heard this term quite often. And there's always a different case, right? And there might be a case which is valid, of course. But think about the following example. You are like the VP of a critical business function. And you have an great idea for a feature request and actually you're sponsoring this initiative and then you approach the pm so you walk to the desk and say hey guys listen um i have this idea i think it's so important we need to work on this now um everyone will love it and so on and so forth and then let's imagine you respond to the stakeholder and say hey you know we've already defined our roadmap that's not part of it sorry like you know we're done here with this reaction like you know you will likely not have a very constructive setup with this person because again the problem is You might have already done all of the comparison work and the opportunity scoring and the sizing, but this person doesn't know, right? So this is the difficult part, also with a roadmap, because they believe or might think, hey, you're missing out on something really, really important. So the alternative to that is, let's imagine, you know, there's a PM, you say, hey, thanks for sharing this. Let's take a joint look at what we ultimately aim to achieve and which opportunities we have already identified. And then you can, you know, compare those a bit more clearly and say, hey, you know, we actually have an alternative opportunity. which would hit the same target, the same outcome, but we actually believe it has more impact and it's only half the effort. And then the conversation becomes a bit more structured and more constructive and you can compare opportunities at a certain level. And also honestly beyond stakeholders, I think there's a little more demotivating for engineers, for instance, to be told, hey, you know, let's, we need to build that, go and build something. I mean, this is something we obviously shouldn't do, but the issue is like. quite often you know it might be the case that engineers are lacking the context um and what i see beneficial here from an osd perspective is the following that you again start with a desired outcome you know so you start with something where you provide the rationale you help the team to understand and ideally you keep your team involved when you're mapping that in the early in the early innings and explain to them hey this is really important to achieve you have might use your data you know on the left side of mirror bring it up share the context share the strategy share the rationale on why this outcome has been selected and why it matters for your business. And then you can break it down and think about how can you break this outcome into opportunities? How can we again, you know, what we discussed, what we covered before, how can we exactly address that in the most effective way? On the other hand, you also have a path again, so we can tie something back. If you need to argue and articulate, hey, why are we working on that? Why does that matter? It's again an alternative to a backlog. So you can more easily, more visually connect it to what are you ultimately aiming to achieve. Talking briefly about organizational aspects, like how can you connect an opportunity solution tree to a planning cycle, for instance, or OKRs or your strategy which you're working on. So I think, again, there is no right or wrong. And every company has its own approach. Every company has their own resources, their own constraints, their own planning structure, their own culture. What just helped me personally is to basically break the whole planning structure a bit into three cycles or three structures. can show visually that there's an opportunity space at the bottom so for instance you know think about a company company planning cycle you might have you know you have your vision of your mission you as a company not as a product team we come to that you have your business strategy what what what you need to go um where you want to go in the next for instance 12 or 18 months and you set annual objectives like hey this year we need to uh grow our revenue we want to expand into new countries and so on and so forth And then you have the product layer, right? Where you start to begin with, hey, what is the product vision? Why are we ultimately building this? What is like the change we're going to bring to our customers? And so on and so forth. Then you connect it to the product strategy where you set the right targets and where you define clearly what are you going to do and not based on your understanding, what's the market? What are the constraints? What is the competition doing? What are the resources you have? And how are you ultimately going to realize your product vision, right? And then you have ideally something where you have your outcome layer. so we're not talking about what are we going to ship again we talk about hey in order to be successful um we need to inform what does a successful outcome look like so in order to deliver on our strategy and based on that and behind that you have your opportunity layer where you visually just structure and map that there's more than one solution to the problem so just you know how we can connect a bit the dots to what i mentioned earlier that we are able to connect an experiment again up to actually up to a clear target and this is basically a desired outcome you know we can call it okrs we can call it objectives whatever it is and then you have the opportunity space where we are outlining visually that this is how we want to realize our desired outcome one important part though to learn or to understand there is product outcomes versus business outcomes so here i've seen honestly quite some confusion happening and also that this was not completely understood to give you an example um i think it's important you need to understand clearly distinguish between being able to distinguish between both of them but they are connected so you typically start with you know and you should have a business outcome you need to know what success looks like for your business and the product outcome is something where you say hey how can we enable and contribute to this business outcome so let's go for an example you know your business outcome might be hey by end of the year we want to reduce our customer acquisition costs by x percent and then depending on what are the team you're working in what you know the respective squad the respective group you need to set the targets like how are you going to achieve this outcome right so for instance as a checkout team you might say hey we want to improve the checkout conversion rate by x percent because we know if we are more effectively turning the trial traffic on our on our landing page into customers we will naturally reduce the customer acquisition costs and then we can think about oh what are the opportunities behind that again to realize our desired outcome So some of the questions then, honestly, what I've seen, have been hearing a bit was like, but why should we actually care as a product team about the business outcome? Isn't our job purely to optimize for the customer? And I think the best answer, honestly, to that has already been given by actually Teresa Torres herself. Echoes mentioned the book in the beginning, highly recommendable. Read it. I was reading it twice already. And actually the second time, there were even more learnings for me. What she said actually was an interesting one. There was an interview a few months ago, which is that the product's team job is to create value for the customer while you're creating value for the business. So if you're ignoring the business value and you build a product or solution, which is, for instance, not commercially viable over time, then you might have the problem that your product might be shut down or even worse, your business might be shut down. But if this is going to happen, you're not creating any value for any customer. So in order to maximize the value equation for your customer, you need to consider and start with the business value. so this is just a bit to connect the thoughts so make sure that you keep this in mind and it also will help your stakeholders to clearly understand the structure and how you break it down last but not least looking at the time i will give like just a very quick um impulse on how we are for instance operationalizing that and everyone i mean again there's no right or wrong there are a lot of different techniques and structures what you can use but one of the topics which was important for me to understand and embrace is like the difference between opportunity mapping and opportunity management so opportunity mapping something you know what every one of us has already done right you go into a workshop you set for instance the desired outcome you provide the rationale and you break things down properly and then you might end up with you know a huge opportunity solution for it this is just one screenshot one example but typically it's quite broader than that and but then you need to think about hey if this is going you know this is growing you need to find a way to effectively manage the opportunities which you're identifying which you are prioritizing and make them comparable on an easy way for your team, for the engineers, for your stakeholders. And what we started to use is something which is called Zero Discovery. I think many of you have already seen it or used it potentially. So we started, for instance, to use that in each of our teams. And we are using that actually for opportunity backlog management in the sense of that we can understand what are the opportunities we have identified, how can we prioritize them and how can we assess them? So I will give an introduction, just a very brief one. And the screenshots I'm sharing is a demo project I've briefly created because I cannot unfortunately share all of our Grover detailed boards with you. But it might give you an understanding on how you can use it, really in a high level example. So I said you can use this for capturing ideas, to assessing it, and also planning the roadmap. So there's really a lot what can be done because it's basically 100% customizable. But let's go for an example. Let's say you guys have mapped your opportunity solution tree. And then you click in one of those post-its where you say, oh, this is the one where we consider it as a high impact priority. So there's a Jira integration, which is nice. So what you can do, you can push this post-it, click on push to Jira to create an opportunity with it. And then I can link it, for instance, to the respective opportunity solution tree I have set up in Jira Discovery. And then it is ending up in my inbox. So how does it look? What I'm doing with that, I'm quickly switching to the tool. to do a brief demo on it so i hope you can still read it or it's not too small but what you see here is my opportunity inbox and again there are hundreds of ways how you can set it up and honestly also our teams have a completely different style and structure and setup how they are precisely using it which is fine right you shouldn't enforce a detailed standard. Every team is to identify on their own how they can create most value with a certain tool or framework. But here an example, I just have pushed this checkout idea what I've shown to my opportunity inbox. And the benefit here, what I can do is, I have here my inbox, which I'm basically going through on a weekly basis as a PM, and I can re-arch it and I can assess it. So let's imagine we have a new opportunity identified, the example we've shared earlier. like let users smooth the kyc so i can actually link it here to an outcome where i say oh this is actually related to what we discussed before oh the outcome is reducing cut we want to improve the verification ux this is the opportunity solution to your opportunity we might have a component for our product which could be checkout and then we can go into a proper scoring right with um our team just make an example here which will affect my score And if I go into it, obviously, I want to make opportunities comparable, which is very important because in the end, think about the example with the stakeholder, you will have those conversations like A versus B. So you can use, for instance, here, predefined templates. For instance, you can create your own one like what I did to give a bit more structure where everything can use. You can fill this out and basically you're done. And then you can say, oh, it's assessed, right? So you have assessed an opportunity in a structured way, which is a bit more easy to follow than a huge mural tree. and it's not lost so we have it here in our opportunity background and this is what you know here i can structure it like i want like there are all options given i can for instance here filter it based on the opportunity improving verification ux so if i come up with a new solution to a certain outcome i know precisely hey what are the topics i've already looked at and what is actually the impact and what is the data we've gathered over time so let's imagine you know stakeholder knocks at your door again says hey you know i want to build a or b you can actually even go here to something which is an opportunity map where you see oh what are we talking about or we talk about let's you know improving verification ux so i can filter here for instance for the opportunity solution tree i say let's go for improve my verification ux and then i basically see here based on the impact and the effort and the confidence I have about this opportunity that we already identified, you know, that showing the onboarding progress bar is even more impactful for us based on the data we have gathered. This is just a quick example of set. We can spend way more time on that. This is highly customizable. In the end, it's another tool. It's important how you use it and that you find your own structure for your company. So wrapping this up quickly, I think we're also on the last slide for that. You know, make sure that those frameworks are working for you and not the other way around it's great if you follow the book and it's a great book as i've already mentioned i'm a huge fan actually um but also your organization is unique every organization right you have every organization has to a certain extent their own culture they have their own processes they have their own resources so it's important that we take like you know a bit of the the learnings we have from a book for instance or course whatever it is but we apply it for our own setup that is working and i've seen what people were honestly What I've seen failing was when people tried to be perfect to the book and say, hey, if something is not for exactly like it's described here or there, we shouldn't do it. And I think it's not correct. You should take the learnings which are working for you, iterate, test it out, improve it, and keep it flexible. Keep it flexible for your team. So quickly wrapping this topic up, a couple of key takeaways. I said, if we don't have a plan here, we can't afford to skip product discovery, especially not for impactful and critical products, outcome versus outputs. Think about the works versus noun topic on how to prioritize. Use OSTs as a stakeholder alignment superpower, right? So make sure you can visually structure it and help them to understand, you know, what are you ultimately aiming to achieve? And there's more than one solution. And if they come up with one, it's great. But put it into context, make it comparable. Make the opportunity space collaboratively. So ideally, you keep your team and stakeholders involved. So we've done this multiple times, honestly, and it was working for me really well. The only learning I had was you need to prepare it. to a certain extent. So just starting with a blank space saying this is the desired outcome, people will get confused with opportunities and solutions. I've seen this over and over again. So prepare a couple of examples that you can show, hey, this is what we already were coming up with. And then you open it up with the rest for ideation with your team. And define a standard, how you manage those opportunities. If you don't have a standard, what I've just shown, for instance, interior discovery, like what is the score we are buying, how we're defining, how we are, you know, how we're adding confidence and how we're adding data. It's difficult that you make them comparable again. So a standard really matters. And yeah, last but not least, there is no silver bullet. I'm also not able to provide a silver bullet. Those are my learnings, which I had across a certain period of time. And everyone has their own approach. And I think it's important that you find your own way based on all the sources and the content you're gathering. I think we are almost on time. So thank you a lot for the attention. I think we can open it up if we have any question. So we have a number of questions already in the chat. And let me just see. I'll let everyone just take the next seconds. If you have any further questions, just throw them in. To give them time, I have one which I wanted to ask up front. Like Grover, it's a big company. You have hundreds of employees, multiple product teams. when i imagine and visualize this tree in front of me what it must look like for grover you end up with a lot of experiments right so how can you how can you work yourself through that um how can you do it efficiently do you have like some sort of automations uh or or or tools that uh that are particularly helpful for you no i think i think it's a good question um so we have each team is basically running their own opportunity solution to a certain extent quite often it's getting shared we also figured out sometimes hey one or two teams we're almost you know addressing the same outcome and then they were exchanging the ideas but you can think about every team is running their own and as said we have a couple of teams who are not running an opportunity solution today so it's not like a requirement we need to see it we want it we're going to see it but yes we're running a lot of experiments We're actually looking to a couple of options. Is there a way for us to be faster, be more efficient in order to, for instance, can do even more directly in production without engineering support to a certain extent? So we're using a couple of different options on what are we putting behind the flag, are we not putting behind the flag? We're, for instance, spending a lot of time also to validating additional products which are going beyond physical subscriptions. We're talking about digital add-ons, but we're also figuring out, for instance, hey, what's the fastest way for us to... realize is there a need for a customer or not so you start for instance with a fake blood test which you launch very quickly you get a little kicks so i think we don't have yet defined a standard what we're discussing right now for instance we have something introduced which we call like pm master class where we have internal knowledge sharing sessions but we also have external guest speakers so we just had someone i'm not sure if she's on the call we had her last week about experimentation where we learned hey actually maybe we need to use an experimentation calendar to just align ourselves yeah so we're just trying to basically get better in what we're doing. Yeah, yeah. And let me use your last sentence as a segue to one of the first questions asked. If you could get some examples of experimentation, and we could do like a separate webinar, but just some of the ones that you at Grover most frequently use successfully. I think it's a great question. I think, as you said, we likely can spend way more time for another webinar on that. Maybe a few also where I've recently been involved in. But for instance, one of the experiments were was not a major effort but the impact was tremendous was related to a copy so you would be surprised what's the impact of content design you know or to which degree where we had an offer which was very important for us due to business reasons and we had to figure out hey how do people react to it which was a bit more tricky because it involved a lot of for instance um also contractual and compliance work so you always will have this balance between making as sexy as possible for the customer but being combined uh at this point in time we tested different also you know push notifications to a certain extent to figure out hey what is working best what is not working best we actually are also running a couple of experiments at the moment you know so when you go and order something sometimes we're testing are people actually interested for instance in a digital add-on to figure out you know is this something you would click on in the basket because if you're not clicking on it why should we actually build it coming back to the example building something for eight months if people are not clicking on it and i can test it in four weeks maybe it has a quick experiment very good example i have another tactical question here uh about the tool where your opportunity solution trees live and jira discovery and do you do you have like uh links between the two you uh so i i need to look up what exactly the integration is but if you google like shira uh just uh shira mirror integration this is the one and then typically you are able to filter based on how you define it you can filter for um your jira discover report and there you i mean i would just recommend use the proper abbreviations so for instance you can add ost or something to it and then you easily find it but google mirror jira integration and then you can push it from mirror for instance to jira discovery okay okay got it um i have another question um about revisiting uh the opportunity solution tree how often do you do that i think this is a great question from jonathan um every and here every pm has really their own style every team has their own approach honestly so we have what we are seeing is like on a quarterly basis we get together also with stakeholders and we even started sometimes when we're doing our quarterly planning that we also even visualize the targets and what we can do in form of an opportunity solution case like how we're breaking it down just to get into this mindset there are more options to it but the real opportunity solution tree um we had teams you know who were visiting it that partially four times a day we had a challenge um where we wanted to understand a certain behavior on for instance the crowbar card which we were building and we were mapping out a huge a huge opportunity solution free um and that we spent like i think four or five times a day we partially opened it we were checking back into it we learned something new it also depends on how often are you learning something new so we have phases where we sometimes interviewing customers on a weekly basis but not every team is doing that And it's also a lot of effort. It's not so easy. And it's the same with data. How often are you checking your dashboard? You learn something new. Someone is dropping here. It triggers an idea. But it's typically up for the PM. And every PM has a bit of their own approach on how they want to use it. But we are not enforcing something. OK, thank you. Jonathan has another intriguing question about complexity of testing solutions and how you consider that when you prioritize. I think this is an extremely difficult one and another great question on that. Also, when you read the book, when you spend time on it, there's a bit of an advice you should prioritize opportunities over solutions. I personally honestly found it difficult. And why did I find it difficult? It's like the following. An opportunity might give me a very rough thing. Oh, can I do that or not? how should i assess effort on something where i don't know yet how solution looks like right so this makes it a bit more difficult um again every team is running here with their own approach we are quite often going what we learned over time was go with something simple honestly you know just to get started and quite often we are buying an ice or rice framework to that just to go for a solution which we believe hey this is our assumption this makes more sense and then we start to s do a rough estimate first before we go into the detailed detailed assessment But I think the nice part, just as a follow up on that is, in Jiro Discovery, what I've shown is like, you move it through pipeline, right? You then add it, you have assessed this opportunity. You can say, oh, let's add it to our discovery backlog. And then you will likely spend more time on the predefined data which you have gathered. It's just, I think, it's the process. Your scoring is not done. It's not an event. Hey, this is the final score, like you learned something new. And then you can reassess it. Thanks so much. I have a question from Anna I want to throw up here, which is assessing your confidence in a solution. I think it's not a good question on that. Let's say, let's put it like that. I think you also gather data over time. So we're just running, for instance, an initiative where we started. Let's run a survey. We started with a survey, 1,000 users. Then we know our confidence in that it's great. It gives us an indication. Our confidence was not so high. we started we followed up with an ap test effect or test in production again for instance so we launched with a survey confidence was not so high but we said oh we need to run set up an ap test but the difference is the ap does just takes more time to be prepared properly so while we're preparing it we were going ahead with the survey so your confidence score is basically uh growing based on the likelihood on the impact you expect that this solution is going to have okay so if you're not convinced by the experiment if the experiment doesn't have like a clear falsification or support of your solution then you'll just continue and pick another way to test it an experiment exactly also i think you know it's difficult to get 100 you never get 100 clarity right great indications and sickness where you're going and you can learn a lot from an experiment but um quite often we also have been running multiple tests or experiments for a certain project yeah uh jonathan just uh linked in i'm gonna put it there for everyone to to see a good book on it's called confidence meter which is exactly focusing on the question that anna asked um i have a last question from stefan um it's about the tooling uh if you have experience with um alternatives of jira discovery In the ClickUp, no, a great question again. So it's great also to reflect on all of that. So I think Stefan, maybe he's referring to the ClickUp, the Chrome extension on the top where you can capture something. I'm not sure if you can give thumb up or thumb down if I get it right. But if you're referring to this topic, because there's one option where you can say, hey, you're reading something and you push it to an opportunity. This is where I have not used it to a certain extent, to be honest. Yeah, he just commented that there's a tool called ClickUp, which I assume he's considering or using it. Not yet, but it's important to comment. So maybe we can connect afterwards. I'm happy to learn about it. Thanks so much for being here today. Thanks for sharing all the stories. I will remember. the girl trying to take groceries. I was thinking of groceries and then afterwards I thought it was good to stay silent, but I should have said groceries as well. Anyhow, thanks so much. Super insightful and wish you the best of luck with Grover and your teams. Carry on with the OSTs and I hope to see you around. Totally. Thanks for having me. And thanks, guys, for the question. So really, really exciting and engaging. Thanks, everyone, for the engagement. Yes, big thanks to you and the quality of questions. Hope to see you around as well. Take care, everyone.

What are opportunity solution trees (OSTs) in the firs place? How to use them to run an efficient Product Discovery process? 🤔

Stephan Beyer, VP Product of Grover, took us on a journey how he implemented and used OSTs at the European unicorn "Grover" 🦄

What we covered:

1. Why should you care about Product Discovery and what are the challenges?
2. OSTs 101
3. Creating an Outcome-first product organization
4. How to be an OST champ: mastering the usage and impact of OSTs
5. Asking anything - our usual Q&A section

What you can learn:

Ready to use tips how to get your organizations to see the value of OSTs. Also, a practical guide how to overcome hurdles in the implementation and make the most out of OSTs. 

About Stephan

Stephan is an experienced Product Strategist who specializes in Digital Product Management and FinTech.He has gathered multifaceted experience in running and scaling Product Discovery in both, big tech companies, and scale-ups.He is currently responsible for Product at the Berlin-based unicorn Grover, Europe’s leading consumer-tech subscription platform.