Why There's No Single Right Way to Do Discovery - Part 2

Hi everybody, welcome to why there's no single right way to do product discovery. It looks like people are joining, so I'm going to give everybody two or three seconds here to find their way in. But we are going to get started right away because we have a full hour planned for you. All right, so I'm Teresa Torres. I'm joined today by Hope Gurion. We're both product discovery coaches with Product Talk. Hope, do you want to? say hello and share a little bit about your background? Sure. I'm first of all appreciative of Theresa you setting this up and of course everybody joining. Theresa and I have worked together for a number of years and when I was heading up product teams at a couple different companies and now I am such a huge fan of these practices to help facilitate good decision making by teams. I want to help more and more teams take advantage of these practices. Yeah great. So hope I'm gonna I'm gonna share a little more of hopes background just because I because I know how great it is hope led a product teams at two different large companies she I met her when I worked with a few of her teams as a discovery coach. I feel like she's one of the most thoughtful product leaders I've had a chance to work with. Really good at bringing change to an organization and really helping teams adopt their discovery practices. If you're on the call and you're not familiar with me, I blog at producttalk.org. I've been coaching product teams around the world for the last six years on how to develop stronger continuous discovery practices. And then Hope and I are joined today by Melissa Cizuno, who is my blog editor at Product Talk. And she's going to be helping with the chat and the Q&A. And we're going to talk about all of that in just a minute. Melissa, do you want to go ahead and say hello? Sure. Hi everyone. I'm Melissa and as Theresa mentioned I help out with product talk the blog content you may have seen some of my writing on there because I tend to help out with the product in practice series and Yeah, I look forward to hearing all of your great questions later. Perfect. Thanks Melissa Alright, so today we are going to be talking about why there's no single right way to do discovery. This is actually the second part of a three-part series. If you missed part one, no worries. We're going to do a quick review to help you get up to speed. I will also share that at the end of all three parts of the series, we will be posting videos so that you can get caught up on anything that you missed. Our goal is to make each webinar awesome in its own right, so don't feel like you needed to have any prior knowledge. Melissa is going to share in the chat a link to register for part three. So part three will be two weeks from today. So if you enjoy today, we really encourage you to come back and join us again in two weeks. If this is your first time using Zoom or you're not familiar with the Zoom webinar interface, there's two things I want to highlight. If you mouse to the bottom of your screen, you should see a couple different options. One is a chat window. To help make sure everybody can find the chat window, I'm going to ask you to take a minute and post where you're joining us from, just to help us get a sense for who's in the room. And then you'll also notice a Q&A panel. That's where we're going to encourage you to ask questions. So throughout the webinar and definitely at the end, we're going to take your questions. So if you would like us to address one of your questions about the content, use that Q&A panel and we'll be pulling questions from there. Oh, it looks like we have folks from all over. I definitely want to give a shout out to Ben from Portland, Oregon, which is where I call home. I'm also seeing folks from Brazil and Portugal and the UK and Spain. Germany. So for our Europe folks, thanks for joining us in your evening. Seeing a lot of folks from across the United States, someone from Mexico City, Croatia. Fantastic. Awesome. Thank you for sharing where you're calling in from. It helps us feel like we're part of a lively international community. Okay. So throughout the content, if something resonates with you and you just want to give us a high five, which we would greatly appreciate. please do that in the chat window. Let us know so that we don't feel like we're just talking to ourselves. If you have a question that you want us to answer, use the Q&A channel and we'll pull from there. All right, Hope, anything you want to share about? Did I miss anything on logistics? I don't think so. But yeah, again, we want to make this interactive like we don't want to just hear ourselves talk. So the more you participate, the better. If we can't answer it live, we'll be trying to find the most common questions and provide help even after the fact via video. Yeah, great point. I did forget that. In part one, we got so many questions we could not answer all of them. So since then, Hope and I have been recording little three to five minute videos answering your questions. We're going to be releasing those as part of the video series as well. So know that if we don't get to your questions today, we're going to tackle the most common ones and release videos in the coming weeks. Alright, so let's dive in. We're gonna review briefly what we went through in part one to help folks get caught up and then we're gonna dive right into the next principles. So the reason why Hope and I decided we wanted to tackle this topic is when we work with companies helping their teams develop continuous discovery practices, inevitably they get to the point where they start to say, shouldn't all my teams work the same way? And Hope and I both believe this is really kind of the opposite of what the Agile Manifesto encourages us to do, which is to allow our teams to find what works best for them and to constantly iterate and take a continuous improvement mindset to the way that we work. But we also recognize teams want to master their crafts and that most companies want to develop a way of doing product. And so what we're trying to do in this webinar series is find the right balance between principles that everybody can aspire to that leaves that gives your teams freedom to explore how to implement those principles. And so in part one, we talked about two different principles, or I'm sorry, three different principles. The first was collaborative decision making. So encouraging your teams to make decisions as a product trio. And how they do that is up to the team, but really encouraging this collaborative model. The second principle we talked about last time was externalizing your thinking. You see here an image of the opportunity solution tree. That's one way to do it. Customer journey map, story mapping, impact mapping, lots of ways to externalize your thinking. So we discussed that. The third concept we talked about was just being outcome focused. How do you help your teams shift from just thinking about outputs, what code did we ship, to moving into what impact did that code have? What metrics did we move? Now I just went through those three principles really quickly, and if you were not here last time, do know we will release that video and you'll get to catch up on those principles. But today we're going to spend the bulk of our time on two new principles. And the way the format is going to work is Hope and I are going to discuss each one for about 10 minutes. Then we're going to take a couple questions on that principle. We'll do the same thing for the second one and then we're going to jump back into all your questions. So we're going to get a chance to explore this pretty in depth. So our first new principle for today is really encouraging your teams to discover opportunities through continuous customer touch points. So just to highlight really quickly what we mean by opportunities. Opportunities are all centered around your customer. So it's what are your customer needs? What are your customer pain points? What are your customer desires? The way that I look at this is where are the opportunities for you to intervene in your customers lives in a positive way. And we talk a lot about continuous touch points with customers because the world is always changing as we just got to experience to the extreme over the last couple of months. And we want to make sure that we're keeping this tight connection. So that's sort of the big idea we're going to discuss briefly and then we're going to take a couple questions. Hope, I know you're a big advocate of this sort of problem framing opportunity space exploration. Do you want to kind of jump in with what you think is important here? Yeah, I think part of the reason that this is so important is because it's so natural for us to want to solve problems and we're so eager to solve problems that sometimes we miss which in fact is the most important problem for us to solve next. And again, the language is awkward. It may not be a problem. It might just be an unmet need. So this is where opportunity tries to help broaden that. But what's also important about this is when you think about what ultimately you're going to need to do to get customers to adopt whatever it is that you will ultimately create to solve for that unmet need. people only understand themselves and their problems and they understand them very very well. So the more that you're putting your framing of decision making into the language that your customer would use to describe those problems, the easier it is for you to have meaningful conversations not only with these customers but with all your other customer facing groups. Marketing, customer support, sales, etc. Because they all can relate to yeah I totally have heard that problem from customers before and now you're giving me a way to help them solve it and that increases adoption and again driving towards your desired outcome so this sort of getting everybody aligned around these opportunities from the perspective of the customers experiencing them it's such a great alignment activity and purpose that's just tons more purpose to your your discovery and of course your solution development Yeah, I think the piece that you just that you touched on that I really want to highlight is how do we know that we're solving the most important problem? And it's really easy. Most product teams are really motivated to meet their customers needs. And so it's easy to fall into the trap of we hear about a problem with immediately solve it. But we don't know that it's the highest impact problem to solve. We don't know if it's the most important problem to solve. And this problem framing is actually limiting in and of itself. Right. So we have lots of needs. as customers but we also have wants and desires and it's easy to forget about these opportunities to delight um one of the best ways to think about this is that like i don't really need a beer but i want a beer at the end of the day right and if nobody was meeting that want my life would be far less interesting than it is now right so you can think about in your own life the things that you desire that aren't really needs but you're really glad that there's somebody out there servicing those opportunities. So it's important, even though the language is awkward, and if I could go back in time, I would probably try a better way to do this. The opportunity language is trying to get you to think broader than just solving problems or meeting needs, but to also dig in and tackle those desires. So that's really why we're talking about exploring the opportunity space. And one of the ways that we encourage teams to do that is to continuously engage with customers through interviewing. We're going to dive into that in a minute, but I want to take stock of the room and get a sense for how often are you engaging with customers today. I'm going to try to launch a poll. If you were with us last time, it only kind of worked. Hopefully, if you see a poll, it looks like people are responding. We're good. I see it. All right. Do me a favor. Just let me know how often you're talking to customers. What we're talking about here is really just discovery interviews. So many of us are talking to customers every day in our sales process or in our customer support process. What we're talking about here is how often are you engaging with your customers just to learn about their context, to learn about their life, to learn about their challenges and pain points and desires. And so if you need to change your answer based on that, feel free. It looks like, I'm going to go ahead and end the poll so we can look at the results. So it looks like a lot of you are talking to your customers weekly, which is fantastic. So for those of you that answered Don't Ask or quarterly or monthly or even weekly was a little optimistic, here's what I like to encourage everybody. For a lot of us, interviewing is new. We don't engage with our customers that often. We rely a lot on our customer-facing teams. If you're never talking to customers, try to talk to them quarterly. If you're talking to them quarterly, try to talk to them monthly. If you're talking to them monthly, try to get to weekly. We really want to apply a continuous improvement mindset even to our own practices, right? So you don't have to be perfect at this. But what we find is that when product teams talk to their customers more regularly, they're more likely to co-create with their customers. They're more likely to see the assumptions that might be wrong. And I know for me... I've been advocating that product teams interview their customers every week. When I first started saying this six years ago, people thought I was certifiably insane. It's now becoming more of a norm. I think that when teams interview their customers every week, it's a habit that fuels other discovery habits. They start to see their assumptions. They start to prototype more. They start to experiment more. Hope, I know you've had this experience as well with the teams that you've worked with and the teams that you've managed. Do you want to talk a little bit about kind of the power of interviewing regularly and maybe also talk about some of the mistakes you see teams make in their interviews? Yeah, well, first of all, let me cover the like making it, making the time for it, right? Like we can find our calendars quickly filling up with meetings. internal facing meetings, our time is precious, you know, we want to try to maximize that time. And the thing that I found to be very powerful with my own product teams, but also with the teams that I coach, is the more that you just sort of lock and protect the time to do this every week, the higher probability that you can do this every week. Like if you have to try to squeeze it into an already full week. it might fall off of your prioritization. The more that you have a set protected time for you to co-discover as a team, as your trio, and automate your interviewing and things that you can do to try to fill up that protected time with meaningful customer conversations, again, the higher probability that you can stick to this cadence of learning from your customers. So that's sort of like the... that I see teams make and I think it's incumbent upon the product leader to help the teams protect that time and make that a priority. It also, I would say in terms of the how to use that time mistakes, it's when people are struggling week to week to try to find people to fill that time that they tend to go back to internal signals as opposed to customer signals. And then, you know, there's There's so much that we could talk about in terms of interviewing. I probably won't get too much into that here. But, you know, what do you most need to learn this week to move forward with good decisions? It's sort of a general how to think about what's going to be a great use of that time this week. Yeah, so I'll touch briefly on kind of what should you be doing in your interviews because one of the biggest mistakes I see teams make is they're using interviews to vet their solution ideas. And we will talk about in our next session, in part three, about how to evaluate ideas. But really, when we're talking about interviews, we're talking about generative research. We're looking to generate opportunities. So we're trying to understand our customers' context, their stories, what's happening in their life. It's about your customer, not your product. And so what we don't want to see people do is say, hey, look at my great idea. What do you think? What we teach is a way of collecting customer stories. So we are encouraging teams to ask questions like, tell me about a time when. We teach a real story-based interviewing format because it's what leads to more reliable answers. And it's also what leads to really understanding unmet needs, pain points, and desires. We will talk at the end briefly about some opportunities for you to dig in and learn more. One of those is we have a... four-week course that teaches teams how to interview using the story-based format. We'll have a link to that at the very end of the webinar. The key takeaway here is in your interviews, you want to spend a hundred percent of your time exploring your customers' context, your customers' needs, and not exploring solutions. We'll later on, like in the same customer touchpoint, you might do part interview, part prototype test, and that's fine. In the next part, we'll talk a lot about how to do those prototype tests. But generally, when you think interview, you want to think discovering opportunities. Hope, anything you want to add? Are we ready for some questions? I think we're ready for questions. All right. Melissa, what do you have for us on interviewing? Sure. So one of the first questions is a very simple one, which is how do you choose the customers that you do the interviews with? Yeah, this is a really good question. I think for teams that are just getting started I would talk to any customer. If you have never talked to a customer, you could talk to a complete outlier and you're still gonna learn great things. As you build your interviewing muscle and you start talking to customers regularly, the thing that I encourage teams to look for is, you're interviewing for variation. So you want to talk to power users, you want to talk to first-time users, you want to talk to really active users, you want to talk to some of your disengaged users, you want to talk to people that use every feature, people that use one or two things only. Qualitative research, you're not going to get a representative sample, you're not going to get statistically significant data, and so what you're trying to uncover in your qualitative research is how much variation is there in behavior. So the wider the breadth of people you talk to, the more... variation you're going to uncover. Now one of the things we teach in our interviewing course and in our coaching is to help teams how to automate the recruiting process. In the early days of doing that you may not have a lot of control on who's coming into your interviews. So this is something that I encourage teams to really get better at over time is to just start talking to whoever's easy to talk to and then over time you can fine-tune it for variation. And if I can add I feel like again customers The language isn't always perfect. Like if we only talk to our existing customers, again, variation is important. Power users, light users, theoretical users, people who maybe paid for the product but yet haven't actually done anything with it yet. So non-users who are customers. Perspective customers, people who fit the profile of a target. customer or user but aren't yet using the product also super helpful to learn from lost customers super helpful to learn from so the customers of your competitor super helpful to learn from so there's like customer it is encompasses a lot you can get a lot of variety and you will learn your tree will get you'll have a rich set of opportunities if you have a rich set of customer discussion The other thing that I'll add just briefly, because I know I'm hearing from everybody, everybody on this. Can we still talk to customers in a COVID world? So I just want to touch briefly on how your discovery might need to change based on what's happening in the world in this moment in time. So obviously this is going to depend on who your customers are. So if your customers are healthcare workers. Yeah, you might not want to be reaching out to talk to them all the time right now Unless right like if they're respiratory nurses and doctors and they're overwhelmed you're probably not going to get their time but if they're an elective cert elective surgeon a surgeon doing elective surgeries that have all been postponed they might actually have a ton of time right now so regard but the thing to think through for doing interviews right now is How are your customers being impacted? and how do you be really human about how and when and where you reach out. I am hearing from a lot of the teams that I'm working with right now that it's actually easier than ever to talk to their customers because they're all working from home, their schedules are really flexible, and they're craving human connection. So don't assume that just because we're in a crisis your customers don't have time for you. And those guidelines applies. I have clients right now that are working with airlines and with hotels and with health care providers. They are having to change the way they reach out and who they reach out to, but they are still finding ways to talk to their customers. Understanding how your customers' context has suddenly changed for some indeterminate amount of time is a very natural reason to reach out to people. You can have a more generative discussion about how their work has changed, their priorities have changed, their work context has changed, their needs have changed. And especially if they're existing customers, it is not uncommon for people to be reaching out to say like, we're here to support you and we want to figure out how to best support you in this time. And, you know, there's also, I've talked to a lot of teams where they may have had contractual obligations to certain customers. And if you don't revisit whether those, you know, obligations are still important, you could be going down a path that misses the mark in terms of your true customer needs, which is why this. you know, frequent touch points with a variety of customers is going to help you make smarter decisions with the product team. Yep. The other thing I'll share is for those of you that are really worried about how things changed given the current climate, I did do a podcast interview yesterday with the Mind the Product podcast team about doing discovery in a COVID world. I believe it's being released next Wednesday. So keep an eye out for that if you want to go deeper on this topic. Melissa, do you have maybe a quick question on discovering opportunities and then we'll come back to more questions on this after we talk about the next principle. Sure, Teresa. One of the other questions we got was about the ratio or relationship between product and design in these interviewing activities. Yeah, I'm not sure I understand ratio, but here's what I will share. I wrote a blog post about this. Last month, I think it's an excerpt from a book that I'm writing about continuous discovery. Here's what I advocate for. I want to have the product trio. So we talked about the product trio last time. That's a product manager, a designer, and an engineer interviewing together. Now the reason for that is because we're going to hear different things in an interview based on our prior knowledge and experience. We know all three disciplines are required to make a good digital product and we want to leverage all three of those disciplines when listening to pain points and desires in interviews. Now, currently, if everybody's working from home and schedules are a little more complicated, you may not be able to get all three people live interviewing together, but you can record your interviews and make sure everybody listens to them. So there's lots of ways to get those different perspectives listening to the same interview material. As far as rate... I might be able to guess at what ratio means. Like if you have multiple designers or multiple engineers, does everybody need to be in the interview? You want to be wary of don't overwhelm your participant. So don't have a panel of people interrogating somebody. But do think about how can you share the audio or the video widely across the team so everybody's building their customer knowledge. Hope, do you want to add on there? Maybe just... It's helpful if you can get everybody on the team comfortable with interviewing. So even if everybody's listening in, you don't want to have one person only be the person, like the only UX person does the interviews or only the product manager does the interview. You want this to be a skill set that everybody is comfortable with and everybody feels confident in it because then in a magical world where you're automating your recruiting, which is not so magical, people do this every day. You can divide and come. You get three customers to show up for the same time slot. Beautiful. You can each have that conversation and come back together to share your learnings. And you don't have sort of an artificial bottleneck on your ability to learn from customers by having to always feed the three of you together. Yep. Yeah, great. Okay, so let's talk about the second principle we have for today. And that is, to really encourage your teams to prioritize in the opportunity space and not in the solution space. So we see a lot of teams have these really complex Excel spreadsheets or Google Sheets where they have a ranking formula and they have a long list of ideas and they're just chewing off the top idea. The problem with that is we see that teams are missing the strategic decisions, which are exactly what Hope opened with in this. conversation, which is what's the most important problem for us to be solving? How do we make a strategic decision about where we want to play before we get into what are we going to build? Hope, do you want to dig in more on this? Yeah, I feel like, again, sort of back to there's no one right way to do discovery. I think there's also some maybe people think that they're doing it right, but then have this an unforeseen problem. So what I often hear from product teams are like, yes, every quarter we pick a problem and then we work on a solution and then we move on to the next problem. And so it feels like you're doing the right thing. We're solving customer problems. But no discussion of we considered 18 problems and this was the one that actually was going to move the needle most in terms of incremental customer value against our success metric incremental. company value towards our success metric. And if you're not able to really understand the relative contribution of solving that problem versus a different problem, you may be solving problems and it may be meaningful to some set of your customers or internal stakeholders, but it may not be the most valuable thing you should be focused on next in terms of incremental value for your customers and your company. Yeah, great. So, We want to dig into this more, but before we do so, I have another poll for you just to learn a little bit about what you're doing today to prioritize. And again, there's no wrong answers here. We've seen everything. We just want to get a sense of kind of where we should spend our time and our conversation based on what you're doing today. All right. Let's see. So it looks like we're getting quite a few replies. If you haven't... I know that some of the options may actually overlap. Just kind of pick the one that you think best represents what you're doing today. I'm seeing a lot of people on the edges. So a lot of people saying we have priorities from management and then also we consider multiple problems. And then a few smatterings in the middle. Here I can share this. Yeah, so... I think Hope and I have seen companies across the board on this. I think the reason why those spreadsheets are popular with ranking solutions and skipping over what problems are most important to solve is that it's implied. Maybe our leaders are dictating what problems we should be solving. And so we're ranking the solutions to those problems. And then I think also it's a language problem, right? It's only recently in the product world that we've started talking about discovering opportunities and prioritizing customer needs. We've all known intuitively to do that, but I think it's only recently that we're explicitly externalizing that and talking about that. The visuals that we're using on these slides are of my opportunity solution tree. I will be the first to tell you, if you're not familiar with this tool, You don't need to be. There are lots of ways to visualize what you're doing. That was one of our tenants from last time. And there's lots of ways to prioritize the opportunity space. We see a lot of people talk about opportunity backlogs and managing and prioritizing an opportunity backlog. That's a great way to do this. What I like about this tree structure is it allows you to The tree structure helps with your prioritization decisions. You don't have to rank all opportunities against each other. You can use the tree structure to prune branch by branch and it helps teams frame the opportunities in a way that gives them structure. And there's a lot of research on problem solving that talks about the importance of problem framing and how do we shape the problem space so we can better solve it. That was one of my goals in designing this visual tool was to help teams learn how to frame the problem. But there's lots of ways to do this. And so I think the key, getting back to there's no one right way, is the principle we're looking for is, are teams structuring the opportunity space in some way? And then are they using that to drive prioritization decisions? Hope, you want to jump in? No, I'm curious to hear what questions people have. All right. Okay, so yes, we have someone was asking if you could explain a little bit more the nuances of outcome framing. Yeah, okay, so let's distinguish between outcomes and opportunities, and I suspect the question was opportunity framing, but we'll just make sure. So the very top of the tree, you're seeing a blue box, which is your outcome. So we talked about outcomes a little bit last time. Outcomes are the metrics you're trying to move. So if you work at Facebook, you're trying to increase engagement. If you work at... Slack, you're probably trying to increase retention, driving monthly recurring revenue. We can go a level deeper into product metrics, like what drives engagement, what drives retention. In the green boxes, the opportunities, this is where we're talking about customer needs, customer pain points, customer desires. Problem framing could be a webinar topic in and of itself, but here's some tips that I like to use. I like to frame the problem from the customer's point of view. So I actually encourage teams to write their opportunities like I want, I need, I wish, I hope, I'm trying to, or to frame it as questions they're asking. I'm working with a company where their customers are farmers and ranchers. And a lot of their opportunities are framed like when should I plant my crop? When should I harvest? Who should I sell to? Should I sell or should I... Should I sell or should I store my grain? These are opportunities that are questions and needs that their farmers and ranchers are experiencing that their products can address. So the key here is that the opportunities are framed from your customer's point of view. And the reason why I think that's really important is that it's easy to disguise a business need as a customer need. So the example that I give for this often is... Amazon probably has a customer need of getting you to spend more money, so increasing the average order price. But no customer would ever say, I wish I spent more money with Amazon. Right? So when you take the opportunity and you reframe it from your customer's standpoint, it'll help you test, is it really customer-centric? Okay, and we've got another question, which is, so basically this person is saying that... They find that some customers are much better at reacting to a list of opportunities I've gathered from other customers and then ranking them based on their own priorities rather than articulating their own pains and needs. Do you have a good way to get customers to open up? Is it still worthwhile to have customers react to other customers' pains and needs, or would that skew the results that you get? I'm happy to pick this one. I have and there's actually a post that that we wrote about how you can actually get customers to participate in your opportunity solution tree at the opportunity level of the tree. What you know what if we missed grab a sticky virtual sticking nowadays. So you're right so some may like on the one hand You want to start without biasing them towards these opportunities. You want to really just take the, be more open-ended in your discussions to really hear what is top of mind for them. But sometimes people have needs that aren't easy, that don't come immediately to the surface. So one technique is yes, like actually go ahead and have them actively participate and say what is missing from the tree. You know, and you know, maybe if there's multiple representatives from a customer that all represent your target customers and users, you might use something like a dot vote to see how they feel about the relative importance. Another technique that I like to use is, again, after we've done some more, you know, general understanding of the customer and their unmet needs and their context and their alternatives is I have, some of you may be familiar with the, like, you know. spend $100 exercise. I do that as a spend $100 to solve a problem. Again, it's not how would you spend it on solutions. It's all those I want, I need, I hate, I wish statements with blank spots for them to tell us which ones we missed. And then they themselves use that $100 allocation so that you can see how they, because again, when you are talking to customers, you write them all down, they seem all equally important. When a customer has to reflect on how would I distribute $100 across these problems, immediately you very clearly see that they are not all created equal in terms of importance. Yeah, I think I'll add, let's distinguish between generative research and evaluative research. So when we're talking about generative research, first of all, we're not asking our customers, what are your pain points, what are your needs? Human beings are really bad at answering those types of questions. We don't really know. We know what our needs are, but we don't know how to articulate them. So I talked earlier about we teach a story-based form in interviewing where we're asking people to tell us a specific story. So I use Netflix a lot in my examples because most of the world is familiar with Netflix. So the way that would look like if I asked you, tell me about your needs related to Netflix. you probably that's a hard question to answer you probably have feature requests but now we're solidly in the solution space and not in the opportunity space whereas if i instead say tell me about the last time you watched netflix and i get you to tell me that story i'm gonna hear as the interviewer pain points and needs that you might not even be aware of right so rather than me asking you what are your needs and pain points i'm asking you to tell me about your life to share your story with me and i'm actively listening for What are the pain points and the needs? That's the generative part. That's how you're populating the opportunities on your tree. There's also, we can do evaluative research to test, did we get it right? Are we working with the right list of opportunities? And that's sort of where Hope is going with her response of, you can use, you can share branches of your tree. You can share lists of opportunities with your customers and ask them to evaluate how you did. But I think these are two really different. activities and that you want to make sure you're doing a mix of both. Okay, great. Do you want to take another question? Yeah, let's do it. Okay, so how can you show prioritization in the Opportunity Solution Tree? Yeah, I wish this visual was of a more complex tree, but I'll try to talk through it. So generally, a real tree that isn't just meant to be illustrative, you're going to have a lot of opportunities. A tree is going to be broad. You're going to have a lot of opportunities that span the width and the tree is going to be deep. So you're gonna have a lot of opportunities that get broken down into smaller and smaller opportunities. And so if you, for example, are using an opportunity backlog, you're gonna have a flat list of a lot of different opportunities. And some of them are gonna be big, some of them are gonna be small, some are gonna be subsets of others. So what we're getting with the tree structure is it's allowing us to group subsets and peers together underneath a parent. And so when we talk about prioritization, we can now prioritize row by row. So instead of prioritizing everything against each other, we can look at just the parent opportunities and say which branch is most important. And then you can visually designate that on your tree. And I've seen teams do this in a lot of different ways. You can just thicken the border of the box that you picked. You can put a little check mark next to it. Some teams like to track which opportunity, like visually track which opportunities they've addressed and which ones are coming up next. So I've seen people use their tree as like a Now next future roadmap, if we're working on this opportunity now, this one next, and everything else is future. And then once you pick a top level opportunity, you can just work down that branch. So you can prioritize its sub opportunities and then its sub opportunities. And you can use the same visual cue to indicate those decision points. And then this artifact becomes a really great way to communicate with your stakeholders. Here's what we considered. Here's the decision points. Do you have feedback on the decisions that we're making? Are we missing anything? And it really opens up that conversation. And that blog post that Hope referred to actually includes a couple of real world examples of how teams are tracking their decisions visually on the tree. Thanks, Teresa. And just for everyone's reference, I was able to find the link to that post and I've shared it in the chat. So if you want to copy and paste it and read it later on, definitely be sure to check that out. Okay, and then Melissa, we're going to switch to taking everybody's broader questions, so you can pull from anywhere. But before we do that, I want to share a couple of resources just for how people can dig in and learn more on these two principles. Hope and I both work as discovery coaches. Our goal is to help teams level up as quickly as possible. We have a lot of ways in which you can do that. So we do have a 12-week coaching program. It's designed for trios to go through that program. You can learn more about it at this URL. We have a number of online courses that you can also learn about that are really great for people working at home. We publish a monthly... article for free every month on Product Talk. We have a monthly newsletter where we share the best of other people's content. And we are, we used to do in-person workshops. We're now doing virtual workshops. So we have a lot of ways to help your teams kind of level up in this area. So if you're interested in learning more, go explore that URL. We have about 20 minutes left. We're going to hang out and take your questions. And remember, if you post a question and we don't get to it today, Hope and I are going to record videos of the most common questions. All right. So one of our questions is about how do you recommend combining design thinking practices with the Opportunity Solution Tree methodology? Yeah, great question. I'm going to highlight before I answer this question. Melissa is going to share the URL to register for part three of this webinar in the chat. So you can make sure you don't miss the third installment. Okay, design thinking and was it, Melissa, was it design thinking and the opportunity solution tree? Yep, that's right. Okay. I started my product practice as an undergraduate at Stanford learning design thinking from David Kelly and the IDEO folks and what later became the d.school. I think the strengths of design thinking are primarily empathy for your customer. really good ideation practices and really good prototyping practices. And we see all three of those infused in today's discovery practices. So the way that I would connect that to the opportunity solution tree is that exploring the opportunity space is helping you to gain empathy for your customer, to really understand their needs, to really do the work to do good problem framing. You're going to see in part three, we're going to talk a lot about ideating. and how to generate a lot of different variations so that you get to better ideas. A lot of that is inspired by the ideation techniques coming out of design thinking. And then next week we're going to dive into prototyping and experimenting. And so really, I think what we're seeing right now, whether it's lean or agile or design thinking or jobs to be done or whatever your favorite framework is, a lot of these are different flavors of doing the exact same thing. And so we're trying, which is why we say there's no right way. right? It's what's the way that's working best for your team. And what we try to do is look at what are the best elements of each and how do we help teams adapt the right mix and match, adopt the right mix and match that's going to work best for them. Hope, anything you want to add on design thinking? No, I think you hit it. I mean, to me, the speed and efficiency and inclusiveness and customer centricity around considering multiple solution ideas and quickly getting feedback. in like a design sprint or something of that ilk, I think is a great combination. Again, when you're at the, we've already identified a problem, we deeply understood our customers' unmet needs, and now we're trying to figure out the best way to solve for that need. I think it's a great tool in the toolbox for sure. I will say one key difference that I see between like some design thinkers or advocates of design thinking and what I think gets taught under the discovery umbrella. I think there's two big differences. We really teach a cross-functional team approach. Some people argue design thinking is what designers do. So we really advocate that collaborative cross-functional approach. And the second part of it is I see some companies that have a strong culture of design thinking get bogged down in endless research. And we, under the discovery label, really try to tie it to driving an outcome and making sure your research is in service of an outcome and not research for research sake. But I think philosophically design thinking has more positive than negative. It's just like everything we see agile in a hundred flavors, we see design thinking in a hundred flavors. Okay, great. Our next question is about when you have a new product and maybe you don't have existing customers or you don't have users or a public facing website. So when you're in those very early stages, how do you find customers or users to talk to? Hope, you want to tackle that one? Sure. So again, this is where a lot of this is if you don't have existing customers talk to because it's a new product or service. you probably have a hypothesis about who the target customer is for this conceived of service and or you know the problem that they're trying to solve. So again we start with a theory or a hypothesis on who that target customer is and having those again back to Teresa's point on the generative research we're trying to understand what exactly Do they do to solve for that need today because usually if it's a new product to service you also have a theory of the problem that your conceived solution is solving for we need to go back and figure out what is it that they truly need so like for most companies I would say they have a concept of a solution that they believe solves for a problem and They're trying to find a market for it or they have deep understanding about a market, a target market, and they're trying to find the best possible solution to drive business, customer growth within that market. So, but you start with a theory on the who and the why. What is that unmet need that they have? And then you need to figure out openly, does anybody even mention this problem that you think is important to solve? And if nobody's mentioning it, It may not be the most important problem to solve so take caution and either you've got the wrong who or it's not a problem that they're actively trying to solve for Yeah, I think to it a lot of a lot of small companies like startups They're founded by somebody who has a strong vision of a thing that should be in the world So they're starting with a solution. I think in an ideal world They'd be starting with an audience and a need to address but we're not there. That's not how most startups are founded So I think the key is that if you're a startup that's really founder vision led and you're working with the solution and you're trying to get in touch with people who might want that solution, work backwards, work your way up the tree. So we love this solution. Why? What problems do we think it solves? Who do we think have those problems? And then go try to talk to those folks and listen backwards, listen your way down the tree. Are they bringing up those problems on the... themselves? Are they important enough to them? Are they spending money to solve those problems and start to do that work? And sometimes when we have a really strong solution focused founder that's driving our vision, a lot of the early work is finding an audience that cares about that problem. And a lot of your discovery is going to be who's the right segment. And we see that a lot with conversations about product market fit. Really a lot of the work is who's the market. Okay, this next question I think is a great one. So while there's no right way, what are the best indicators for discovering when you're going the wrong way with your discovery? Ooh, willing to just brainstorm on this, Hope, because I don't know that everyone thought about this. I've got some thoughts. I've got some thoughts. If you are spending a lot of time with customers and you're not moving any sort of metric, within whatever you consider to be a reasonable case, quarterly, monthly, whatever it is, something is wrong. The outcome metric might be wrong, the customers you're talking to, your way of assessing and prioritizing this opportunity, the way you developed and chose the solution is wrong, something has gone wrong in that process. You might need to diagnose what went wrong and why it went wrong, but that to me is ultimately why that is the top level of the tree. And you need to be diagnosing where do we think, like a five why's, retro, what went wrong if we're not moving our desired outcome metric. Even if we think activity-wise, we're doing the right things. We're having customer conversations. We considered multiple solutions. Maybe it was something in the experiment design. Like I would be trying to retro from the bottom of the tree back up, where do we think we got off course? Did we talk to the wrong customer? Did we not have good criteria for deciding amongst our opportunities? So I can't give you a single reason why you might be going wrong, but that's how I would diagnose. Yeah, I've got one too, which is I see a lot of teams get bogged down in research. They never make a decision. They never release anything. They never choose a target opportunity. They never choose to pursue a solution. So I think one of the challenges with good discovery is how do you balance having confidence in what you're learning to act, to actually ship a product with maintaining some doubt of like, are we getting it right? And I think that tension is a really good tension that good product teams manage well. And when discovery is going wrong, we either ship what we were always going to ship regardless of what we learned in discovery, or we never ship. And I think both of those are equally problematic. And I think the other thing I look for, and I ask my teams every week this question, what did you learn this week that surprised you? If you stop learning things that surprised you, something is wrong with your discovery process. You're falling prey to confirmation bias. You're not listening in your interviews. You're asking the wrong questions. You're not running your prototype tests well. We know we have a lot of data now on how often ideas fail, how often experiments fail. Teams should be failing more than they are. than they're succeeding in a discovery world. You're gonna have a lot of things not work out. And so if that's not the case, if you're not continuously surprised, you got to go back and tweak your discovery methods. And I think just I really want to emphasize that I have also seen teams lose organizational momentum for discovery when they keep doing the things that everybody expected them to do anyway. And so that that's what What did you learn this week that not only surprised you, how are you sharing that surprising insight to your leadership team, to your stakeholders? Because the more that they also are surprised, the more that there is this sort of reasonable doubt and humility that will fuel more purpose-driven discovery. Yep, definitely. Okay, next question is, if you have a good example and thoughts on what makes a good outcome to start with? Yeah, we covered this a little bit last week last two weeks ago So I'm reluctant to dive into this in depth, but hope do you want to just give a brief? Kind of thoughts on this. Yeah, I think I'm oftentimes what the leadership team cares about are these sort of business outcomes which are lagging indicators revenue, EBITDA, market share, something along those lines, lagging indicator, ARR, account growth, something like that. What product teams need to do is link that to the behavior of the people using the product, adopting the product, getting to some critical moment that drives to making it easier to hit those revenue targets, easier to hit the lifetime value targets, easier to hit the retention targets, whatever the business metric is, that's the product outcome metric that links to the business outcome metric. And so that's what we're looking for in a good outcome metric is why is that metric lead to the business outcome in a way that adds value for the users of the product and is something that is negotiated between the product leader and the team so that there's this tension between is it big enough is it aggressive enough to have a meaningful impact and is it something that the team feels they can actually make progress on in the time frame they're given so all of those things contribute to it being a the right outcome metric yeah perfect all right Melissa Yes. Okay, we had questions about engaging with customers and how can you reduce the effort if you are trying to interview people every week? Yeah, the big one here is we teach teams how to automate the recruiting process. So here's the goal. We want every product team to have an interview on their calendar every week without them having to do any work for it to be there. And for teams that have never been exposed to this, that sounds like it's magic and it actually feels magical, but I can tell you I have worked with probably over 100 teams that are doing this now. And I've heard from many more that have taken my interviewing course that have learned how to implement this. I will share a couple of ways to do this. The most effective way to do this, the easiest way to do it, is to recruit people while they're using your product. So you may have seen other companies do this where you visit their product. Somewhere in the flow you get asked if you're willing to participate in research. Your customers are already engaging with you in one way or another, so where can you hook into that flow for them to go ahead and schedule an interview? You want to pair that with scheduling software, something like Calendly, or one of its many competitors, where your customer is getting asked to participate. Once they say yes, they just get to look at a calendar and pick a time. and then that interview gets added directly to the product team's calendar. And the benefit of doing this is that now it's just like any other meeting. It's on their calendar, all they have to do is show up. There are lots and lots of ways to automate the recruiting process. How you do it is going to differ based on your audience, and it will take some experimentation to get it to work right. If you want to dig in more on that, we do cover automating the recruiting process in our continuous interviewing course. We cover, and we also cover it in our 12 week coaching program. But the big idea is what I just shared. Find a way to recruit your customers while they're already engaging with you. Okay, Teresa. And we also had somebody asking if you could just give a little bit more of a definition of opportunity or share about how broad an opportunity should be. Yeah. I define an opportunity as a customer need, a customer pain point, or a customer desire. So it's that simple. Now, one of the mistakes I see teams make is they define their opportunities really vague. So again, this is problem framing. We're trying to frame an opportunity in a way that allows us to address it easily. And so I try to encourage people to frame their opportunities really specific. And one of the phrases that I think really helps is to think about a particular moment in time. So you might hear customers say really vague things like, I wish this was easier to use. Okay, well, that opens the door to all usability improvements. We could work on that forever, and our customers are still going to say, I wish it was easier to use. So how do we reframe that to be a really specific moment in time? And again, if you're collecting stories, you're going to hear about the need in the context of a story so you can tie it to a specific moment in time. So again, because I'm using Netflix as an example, I'm going to stick with that. Maybe it's instead of saying, I wish this was easier to use, it's I can never find where to go when I want to search for a specific show. That's a really specific moment in time. Now, what I don't like about that opportunity is it's really tied to the product and I like to keep the product out of the opportunity space. So I would reframe that even more. And this is where the tree structure can help. As you move up the tree, your opportunity is going to be big. It's going to be a big pain point. Like for Netflix, it might be, I can't decide what to watch. That's the big opportunity. It's still a moment in time. It's the moment when you're trying to decide what to watch. And then as you move down the tree, you're going to break that opportunity up into a series of sub opportunities. So a sub opportunity might be, is this show any good? I can't decide what to watch. Is this show any good? Have I seen this before? Like what are the questions people are asking when evaluating what should I watch? And then is this show any good? You might get more specific. Are there any actors in it that I like? Is the story good? Is it based on strong characters? Right? So you can, as you move from really big, hard problem, what should I watch? You're deconstructing it into more and more specific problems where you get to one like, is there an actor in it that I like? That's a very solvable problem that we can now start to tackle iteratively. Hope, anything you want to add to that? All right. Well, we have one minute left. So here's what I'm going to say. Please join us for part three. This has been super fun. I know Hope and I love getting your questions. I know we did not answer all of them. I will remind you that we will tackle more of your questions in short videos that we'll be posting through the Product Talk YouTube channel. We'll also be sharing them through our social media channels. So if you're following us there, you'll have plenty of opportunity to find them. The third... The third session will be two weeks from today at the same time. So please come join us. We love hanging out and talking with folks. Hope, anything you want to add? Hope is on mute. She might be trying to talk. All right. Well, thank you very much. Thank you, Melissa, for helping us out. Thank you, Hope, for joining me. Thank you, all of you, for joining. And hopefully we'll talk again in two weeks.

This is the second webinar in a three webinar series. 

You can find Part 1 here: https://www.youtube.com/watch?v=ihN8rtjWz3g

Part 3 will be posted on March 17, 2021.