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

Hey everybody, welcome to Why There's No Single Right Way to do Product Discovery. I'm going to give everybody about 30 seconds or so to kind of get situated. If you're new to Zoom, we'll do a quick little Zoom tutorial. I'm Teresa Torres. I'm going to be joined by Hope Gurion. We'll get into introductions in just a minute. As you're kind of making your way in, there's a few things I'll highlight. So if you're new to Zoom, If you scroll to the bottom of your screen, you should see a few options, one of which is a chat window. What I'm going to ask is, as you join, to just go ahead and type in the chat window where you're joining us from. It'll help us just get a sense of just who's here and help us not feel like we're talking to an empty room. And then that will help me a ton. And then the other thing I want you to look for is at the bottom of your screen is there's a Q&A window. So if you want to go ahead and open that. At the end of this webinar, we're going to open it up to questions and we're going to take our questions from that Q&A panel. So if you want to, as you hear things, if you think of a question, just go ahead and type it in there. It'll queue up for the Q&A portion at the end of the session. If you do... It looks like we have people all over the place. This is fantastic. It's fun to connect with people all over, it looks like the country, all over the world. We've got someone from Brazil, Slovenia. Fantastic. I think especially now with so many people staying home, it's really nice to see so many folks joining us. So thanks for that. We can see Hope just popped on and shared your video. Welcome, Hope. So here's what we're going to ask. As we go through the material, if something really resonates with you, do us a favor and just share that in the chat. So what's hard about webinars is you can see us, but we can't see you. So if you're willing to, in the chat window, share where you're coming from, things that resonate with you, just so we know you're there and you're listening, that would help us. And then the Q&A window is for... Anything you ask in the Q&A window, we're gonna queue up for the session at the end of the call. Okay, so that is our housekeeping. I will share that we are recording this session. We are not going to share the recordings publicly until we're done with all three webinars. So this is a three-part series. We will release the whole series at the end after the third webinar. We will share at the end of this webinar how you can join the second one. So stay tuned for that. Okay, so let's go ahead and dive in. I'm trying to make sure I didn't forget anything I don't think I did. So let's start with some introductions. So I'm Teresa Torres. I'm joined by Hope Gurion. We are both product discovery coaches with Product Talk. Hope also does some leadership coaching with her own company, Fearless Product. We're also joined by Melissa. Melissa Suzuno who is going to be monitoring the chat and managing your questions and Q&A Melissa and Hope do you want to say hello? Yeah, thanks Teresa. It's awesome to see how many people are joining from all over the globe and so many different time zones. So thank you so much Teresa and I have worked together for a number of years and as I was leading product at CareerBuilder I was their chief product officer and I went to another company Beachbody and was their first head of product I have been working with the techniques and have recognized the importance of discovery for people to find meaning in their work to make sure they're working on you know the right problems which we're going to talk a lot about rightness in our session today but I really feel like it is such a powerful way to work it's such it builds more purpose and meaning in the work that you do and delighted to hear your questions and learn more from each of you today in terms of where you're challenged and how we can be helpful. Yeah, perfect. And Melissa, you want to say hello? Sure. Hi, everyone. I'm Melissa. I help Teresa out with content for the Product Talk blog, and I also help out with these webinars, and I'm really looking forward to hearing all your great questions later on. Yeah, for those of you that are product talk readers, Melissa writes our product and practice series where we're sharing stories about teams doing great discovery work. So you may have seen her name there. All right, let's go ahead and dive in. So Hope and I, the way this is going to work is Hope and I are going to introduce some topics. We're going to talk about them. You're going to share what's resonating in the chat and you're going to ask your questions in the Q&A. And then after we introduce a few principles and talk through them. then we're going to turn to your questions. So make sure you capture your questions in that Q&A box. So today and in the next two webinars, we're going to be talking about why there's no single right way to do discovery. I know that Hope and I hear a lot from the teams that we work with that most product people are really eager and they're really diligent and they want to do the right thing. And this is a little bit of a hard concept when it comes to discovery. Hope, do you want to talk about why this is such an important topic? Yeah, I think you hit on it, right? Everybody wants to, they feel, they recognize what's gone wrong in the past many times, and they don't want to face making those, you know. mistakes again or creating products that aren't used weren't valuable didn't solve the problem in the right way and so they're looking for a right answer to get everybody on the organization on the same page and know that it's been blessed in some way and that is really challenging because there are many right ways to do discovery and what we want to help people focus on is the way that it's going to work best for their organization, for their teams to make good decisions that drive value for your customers and your companies. Yeah, this is something that I see a lot where somebody reads about a framework or a tool or a technique and they fall in love with it and they say, this is the only way to do this. Everybody needs to work this way. So I think that's one symptom we see. Another symptom we see is a company will do coaching with us or they'll come to a workshop or they'll do somebody else's training. and they want everybody in the company to work the same way. It's a little bit of like, what's the product discovery Bible for our company? And I think actually there's this tenant from the Agile Manifesto that's really important, which is that each team owns the way they work and they're constantly iterating on it to make it better. And so even if we all start from a common starting point, as soon as we start iterating as a team on how do we make our work practices better, we're all gonna end up in different places. That's not only not a bad thing, it's also a really like it's allowing each team to really find what's going to work best for them. So I think it's really extending some of that agile mindset, but also just really internalizing this continuous improvement mindset and applying it to how we work. Okay, so we... It's funny for us, so Hope and I are both discovery coaches. We teach teams how to do discovery better. So you would think that of all people on the planet, we would have a right way of doing discovery. And we certainly teach specific methods. But something that we've recognized working with teams is that every company is unique. Every customer base is unique. How you reach those customers is going to change based on who they are and how busy they are and what their lives are like. We all probably have seen huge disruption in that in the last couple of weeks with COVID. So one of the things we look at in the way that we teach is not what's the right methods, but what's the underlying principles that we want to see each team move towards. And then we work with the team to co-create what are the methods that get them there. And that's what we're going to cover in the next three webinars. So we have, I believe, eight different principles, seven or eight different principles that we're going to talk through. We're going to tackle the first three today. We're going to spend about 10 minutes on each of them. And then we're going to turn to your questions. Hope, anything that we should be tackling before we bring up the first principle? No, I guess I'm just excited to see what questions people have. But I think one thing, just as you, whatever the method is, wherever you are on the spectrum of doing discovery within your own product team or at your company, you know, maybe use this time to reflect. Do I think the way that we currently do it incorporates this principle? And if it doesn't, maybe why has it been challenging or is it because you haven't considered it? So I think taking the time to reflect on do I feel like we incorporate this principle in our method of discovery will help you gauge whether or not you've got a method that is likely to serve you well. Yeah, perfect and we're gonna we're gonna do a few polls throughout just to get a sense for where everybody's at And one thing I will encourage is we really do encourage a continuous improvement mindset So even if you're just getting started with this We'll try to help with what are some of those first steps and if you're well on your journey We'll try to give you some of those gotchas to keep an eye out for for more advanced folks Alright, so let's turn to our first principle. The first one, I think this is the heart of good discovery, is really building a collaborative decision-making model with the product trio. So if you're not familiar with this term of a product trio, it's just this idea of for digital products, we know that generally three roles need to be represented to have a good product. So it's typically a product manager, a design lead, and a tech lead. And we're seeing a shift in the industry to more teams. moving towards this collaborative decision-making model where this trio works together on discovery and makes decisions together about what to build. And Hope and I are going to dig into why this is important in just a minute. But before we do that, I would love to hear from everybody about where you are on your own journey. Let's see if I can do this. I might be having technical problems. I hope you're seeing a poll is asking you about are you organized by product trios? If you are, give me a favor and just go ahead and respond. I'm seeing a lot of no's. Let's see how I can fix that. I saw one person voted. I bet it was just delayed. I think we were delayed. Are people okay? Maybe not. We might be having a problem with polls. How about this? In the chat, do me a favor. Here's your options. Are you organized by product trios? You can respond with, what's a product trio? We're trying to get to product trios. We work in product trios, but we aren't making collaborative decisions yet. And we excel at this. And feel free to abbreviate those as you type your answers. Okay, so it looks like we've got folks across the board. Mm-hmm good. Okay excellent Yep, that's echo. Oh, it looks like it like launched all of my um I'm over it. I'm over pulls I I similarly had a poll challenge 20 minutes ago. Oh now I see the results though I think I think I think zoom is doing a fantastic job keeping the internet working So I'm gonna I'm gonna move past polls forgive Yeah, I'm going to forgive them on polls and we're going to move on. Okay, so based on your answers, it looks like we have some folks that are already moving to trios. You're already making collaborative decisions. I saw a few what are product trios. I saw a few some of the roles are new. Regardless of where you are in this, Hope and I will talk a little bit about why this is so important. I know, Hope, you've managed a couple of really large product teams. Do you want to talk a little bit about why you think this model is so important? Yeah, I think... There's a beauty in the simplicity and there's also real challenges in it. The beauty is when you have these people who bring that value to the customer, to the business, the usability, making sure it's delightful, easy to use, easy to adopt, and what's feasible from the engineering lead and really bringing that mindset of creatively how can we solve this problem from those three different perspectives. it actually increases your likelihood of landing on a solution whether it's a feature whether it's a new product something that has a higher probability of achieving your goals and if you have just one person making decisions or you only have a subset of these people making decisions you're likely to fall short on or miss and learn too late other ways that you may have solved that problem more effectively or created that value sooner. So I think that's why at the core this is an important trio to consider and to get really that it's not any one person's responsibility but having that equal point of view and collaboration just increases your probability of success. Yeah, I think that's spot-on and I think also we're also this is an extension again of that agile mindset, right? So in a waterfall world these three roles work sequentially where maybe the product manager works with the business to define requirements. They were handed off to a designer. The designer would design them and then they were handed off to engineers to deliver. What we saw in that model, the reason why we see a lot of teams shifting from waterfall to agile is that when we when we go from product manager to designer the designer is doing the design work and they see a lot of problems and they have to go back to the product manager and we redo some of the requirements and then we finally get to a design that we like and it goes to engineers and they find things they can't build they find things they misunderstand they find things that are harder than we thought we got to go back to design and then back to requirements whereas really what we're seeing with the shift from waterfall to agile is look, we need all of these people in the room. Let's have them start and work together. Let's leverage all of this experience and expertise collaboratively. Now, Hope talked about this is hard, and we're going to give some strategies even in today's call and definitely in the upcoming calls to help mitigate why this is hard. But I think the key here is it's saving all that downstream time where you're going back and you're redoing work from these handoffs and misunderstandings and designing things that are not possible. One other thing that I will highlight about this concept and I know hope you've seen this on some of your teams is We define the trio as this pretty standard template as a product manager a design lead and tech lead, but not all teams Look like this So do you want to talk a little bit about some of the variation you've seen? Yeah, I mean I think one of the more common variations I've seen is when people are working on like a platform team or an API team or something like that they may not have the design lead they may have like a data science lead or you know some other way that they balance out the trio that makes more sense for their product I think there's also you know there's more and more trend to well how do we really have integrity in our analytics and so they may make they may expand it slightly from a trio to you know a foursome of people who are really helping balancing out the quantitative the qualitative again to expedite decision-making and so there is obviously the more diverse skilled expert points of view you get wanting to become part of the core team there is value in that and there is an overhead and there is a cost that you risk. And so it's, you know, again, even the trio, I think, is a principle. How do we keep the smallest team that we need to have a well-represented perspectives and expertise to make the best decisions as quickly as possible? Yeah, that's right. I think the bigger your decision-making team, the slower your decisions will be. And I think the key here is to distinguish decision-making from contribution. So you're going to have more than just a trio on your team, and the other folks should be contributing. They should be contributing ideas. They should be contributing design work. They should be contributing maybe expertise on analytics, right? So it's not that the trio is doing all the work and that this is your hero team. It's more about thinking about for any given discovery decision that a team needs to make, what are the right roles that need to be represented? So what's the expertise that we need to leverage when making that decision? And so this idea, the trio, comes from we know that generally product managers can bring the view of the business and viability of products. We know that designers bring sort of design capabilities and the usability of products. Some people will argue that designers are the voice of the customer. We'll talk a little bit about this in our future webinars about why I think the whole team needs to be the voice of the customer. But definitely the designer is bringing sort of the usability perspective. And then of course the tech lead is bringing that feasibility perspective. Some people would argue like where's desirability in that? And that's what we're going to talk about. If the whole team is making discovery decisions together, they should be all responsible for desirability. Now, like Hope said, if you have a really data heavy product you might have a data analyst here the question is do they need to be involved in every decision or just your data heavy decisions you might have a pro some people argue some products don't have user interfaces do you need a design person for those um i would argue in most instances you probably still do apis need design work um but maybe it's a more technical designer and not a front-end gui designer right so this is um a principle you'll need to customize for your team but i think the The basic idea is to balance speed of decision making with leveraging of diversity of expertise. Hope, anything you want to add on that? No, I think I would love to see some questions. All right. Yeah, why don't we take one or two questions on decision making and then we'll take more at the end. But Melissa, I know I just changed up the format on you. But if you have a question or two about decision making, we'll take a couple now. Okay, I'm just looking through to see if there are any that are specifically decision-making related. So here we've got one which is, what if you don't have a full-time design lead? What should you do about decision-making collaboratively in that situation? Yeah, this is a really great question. I know a lot of teams that are moving towards trios, they're not resourced this way yet. Hope, you want to talk about what you've seen? Yeah, this has been a hard one, I think just from a like... labor market, maybe the belief that we should allocate budget and headcount towards it at different companies. So I would say that it's probably more often than not that I'm seeing teams that don't have a dedicated design UX lead to their teams, or they have a share, maybe visual designer user researcher and they're borrowing or getting split time from those. So it's definitely, it does happen. Again, we're speaking and we gotta make do the best we can with the way that we're set up and what can what are we aiming towards but I still think that it is important that you figure out how you make sure you've got at least a portion of that person's time dedicated when you do need to make decisions around how are we going to approach solving this problem for customers how do we know if we've solved it in a way that makes it easy for them to use and adopt and it's intuitive to them you're gonna need that design perspective. So you don't want to, you might need to just do it on a little bit borrowed time if they're not dedicated. Oh, sorry. I'm not trying to tell you to wrap up, Hope. Just a little too trigger happy on the slides. Yeah, I think we're often optimistic in how we resource our teams. We say, oh, a designer can spend 50% of the time on this and 50% of the time on that. I think the reality is, is we're not going to make nearly as much progress in either thing as we would have hoped to. So I think some of this sharing of designers is being a little too optimistic about what we can really get done. What I've seen is that if businesses are just willing to make the harder decision to say this is more important than this and actually just allocate the designer, you're gonna get a lot more throughput. It's a little bit of that idea of limiting the work in progress that we see from Kanban. I know that not everybody works that way and that may be outside of your sphere of influence to have an impact on. So I think time boxing and making sure that designer can dedicate a specific amount of time each week to your stuff. But again, it's that we're probably going to say this a dozen times on the call. It's about that continuous improvement mindset. How can you make next week a little bit better than last week? And you got to do with that with the resources that you have. Melissa, do you have another one? Yeah, we've got another one which is when you have your trio and you're trying to make decisions, do you do consensus, majority, or something else? Yeah, I'm going to tackle this one because I feel like it's really a big political one that we see even at the top of our organizations, like executive teams that can't get alignment. The very next principle we're going to talk about is going to help teams align around a shared perspective. So one thing, the reason why we can't come to agreement as a team is because we're often working from different data. And so we're making decisions based off of different data and we can't come to agreement. So one is, I think, to get towards more of a consensus mindset is to make sure you're working from the same set of data. But two, I don't think the goal is, like consensus kind of, people think about consensus as like, Everybody compromised and nobody's happy with the solution. That's definitely not what we want I think we want to move away from this idea of consensus to more of what's truly collaborative and so what by collapse to me the distinction is the three need to work together to generate a solution that everybody's happy with and if you're stuck Arguing about my idea versus your idea Neither idea is good. You need a new third idea that both people are excited about And that is something that we're not used to in business because we business is so organized around silos hierarchy your boss reconciles differences But this is a skill that I think product teams are starting to learn of like how do we truly collaborate and find options that we're all excited about and some of that starts with doing discovery together So I think as we explore some of the more principles will impact this a little bit And just to add to that like I think you you you address the information asymmetry issue right like we're operating from different data sets or different understandings having this shared understanding together collaborating together it you know reduces those odds when i hear majority rules it like to me it goes back to like a potential opinion wars which are not productive don't really foster a collaborative decision-making environment um and it also speaks to the fact that you're probably your decision criteria is not clearly defined and well understood and agreed to by the team. And the more you can make that obvious to one another, the easier it is to figure out, are we lacking options here? Or have we set the criteria in a way that's impossible to meet? Or some other challenge that's preventing you from being able to make a collaborative decision? Yeah, and that's a perfect segue, I think, to our next. kind of key principle here, which is to externalize your thinking and to really have the teams do the work to externalize their thinking to make sure they're working from the same set of data. Now this picture is of an opportunity solution tree, which we'll talk a little bit about. It's just one way to externalize your thinking. But before we dive into this, I'm going to try to do another poll. See how it goes. I see it. Okay. It works. Somebody says. All right, so if you want to just take a minute and tell me what you're doing as a team to externalize your thinking. Now this is one where we're starting to see a lot of these practices become more common, but I know Hope and I see a lot of variation in skill around this. So we'll talk a little bit about what things you can do to help your teams as well. Okay, so it's looking like... If you haven't responded, I'm going to ask that you go ahead and do it, but it's looking like... The most common ways people are visualizing their thinking is with prototypes, with customer journey maps. A few of you have said not, a sizable amount of you have said not really. I'm going to go ahead and share this. Okay. Thank you for that. That's definitely going to help us as we move forward here. Zoom is moving things around. Bear with me just one second. All right. So let's talk about externalizing your thinking. So this is something where Hope just talked about. uh assim like information asymmetry i know something you don't know therefore i'm making a different decision than you might um we see this a lot um and so one of the things that we teach is lots of different ways to visualize your thinking so that as a team you can look at it examine it align around it um this could be anything from customer journey maps opportunity solution trees um story mapping um it could just be whiteboarding interface like inner really rough interfaces together as a team. We see a lot of evidence of this. There's also a lot of research that supports this. Humans are really good spatial thinkers. Hope, do you want to maybe share a little bit about just what you see as teams get started with some of these practices? For teams that have never done it before, it feels really... awkward like like we we've been having lots of conversations why are we still not on the same page and it's not until either through drawing or mapping or collecting examples that they actually realize that they didn't have the same understanding and so being able to see it versus speak to it really increases your your probability of shared understanding so that's it can feel awkward But it actually is going to increase information synthesis for your teams, for your stakeholders, and it will be a new way of working for a lot of people. But if you're a team that's already familiar with prototyping and seemed like that was a majority, you recognize that what you thought it was going to look like and what actually was created in the prototype are often two different things. And that's the exact same challenge. with talking through every problem to death and not visualizing it in a way that makes synthesis easy. Yeah, you know, I think that's exactly right. So one of the things I see a ton of is teams fall into this downward spiral of debate. Like they jump down the rabbit hole and they just can't get out. They can't agree. They're just spinning and spinning. And I'm sure all of you on this call have been in those meetings where you talk and you talk and nothing comes of it. I think what's hard about making the jump to visually externalizing your thinking is that most of us don't draw well. We're not super comfortable sketching. Maybe we have a little bit of stickies fatigue because of design thinking workshops or whatnot. There's a lot of sort of consultancy activities that maybe have some fluff and we're like, this doesn't seem worth the time. What we're talking about with visualizing your thinking... It really is more about doing the thinking work. So there's a lot of cognitive psychology that supports when we take ideas and we put them tangibly down, whether that's through drawing or stickies or even in a digital whiteboard like Miro or Mural, we're relieving our working memory. We're basically taking these ideas we're trying to hold in our head and we're putting them outside of our head and we're freeing up our mental energy to then think about those things. Instead of just trying to remember those things, we can now work on them. We can arrange them. We can group them. We can examine them. We can think about what do I know that Hope doesn't know? What does Hope know that I don't know? How do we start to combine and mix and match those things? And so it's less about sketching this beautiful piece of art, and it's more about using paper and digital whiteboards and real whiteboards as a way of extending our mental capacity, and especially in a group context so that we're all able to say wait did you mean this or did you mean that um hope anything you want to add about just kind of using it as an extension of our brains I think you're spot on in that like getting it out of your mind and onto a piece of paper actually frees you up to do higher level thinking as opposed to I'm I'm having a conversation and I'm thinking about what I want to say next so I'm not actually processing what the other person is saying and again delays your probability of getting to shared understanding let alone making a decision you're all happy with so I do think there is power in just knowing that it's there knowing you can refer to it and frankly one other thing is the more that it is participatory not just visual and that it was an artifact that we can refer to but the fact that we co-created it we move these stickies around we move the opportunities around on the tree group them in this way we you know plotted these on our two by two of you know risk versus you know value that participation in this tangible experience again increases that synthesis memory and ability to make sure that you truly are looking at the problem from a common point of view yeah that's i think this is just so spot on so let's talk about ways Things we can visualize. So the visual you're looking at right now is an opportunity solution tree. I actually designed this visual while working with one of Hope's teams several years ago. I was coaching one of Hope's teams at a company called Beachbody. They're the company that makes the P90X exercise software and a number of other things. And they were really feeling lost about how to guide their discovery activities. So their feedback to me was... you always tell us what to do next. How are we going to make those decisions on our own? And I started to think about what was, how was I making those decisions? And what came out of that was this tree structure. And it's really a visual that's charting out your path from an outcome, which we're going to talk about next, through what are the customer needs that you're trying to solve, through what solutions might we build, and then what experiments might we run to test those solutions. And so it was... It was designed to guide and to give structure to what's a pretty messy wandering process. This is one visual we teach. I know a lot of people ask me how's it different from impact mapping. Impact mapping is another visual that accomplishes a really similar goal. We don't really care which one you use. I think again the principle we're looking for it's not about there's one right way it's about are you externalizing your thinking in a way that works for your team. Other ways to externalize your thinking is customer journey maps. We're seeing companies do company-wide customer journey maps, getting all the teams involved. That's really powerful. We see product teams doing story mapping to communicate requirements and to prioritize requirements. Hope, can you think of other, have I forgotten, empathy maps? Yeah. I mean, again, even simple like... two by twos are ways that people are externalized and thinking where they have to put something on a board and decide how it relates to something else on the board. I think all of these help people see perspectives and see that these perspectives are not fixed. They are movable. Yeah. David Bland's assumption mapping exercise where you're mapping on a two by two grid is a great example of externalizing your thinking. I think the key here is Again, for teams that are new to this, and if you're a little bit stuck on I don't draw well, there's actually a video that we use in our materials. There's a TED talk by Tom Wujek called Wicked Problems. And the subtitle is something like, if you ask me to solve a wicked problem, I'll first ask you how to make toast. And so what's great about that is if you just Google how to make toast, you're going to find the video. And it's... He talks, he explains in the TED talk a really powerful group activity for how to co-create visual maps. And you don't have to be an artist to create these. He talks a lot about the nodes and links on a map, which really are just boxes and arrows that we all can draw. But it helps us see patterns and find shapes and understand processes. And it's a really nice... stepping stone into visually externalizing your thinking and to build more of a systems view of what you're trying to tackle. So if your teams are brand new at this and you need somewhere to start, I would highly recommend watching that video. Again, just Google how to make toast and you should be able to find it. Hope, anything you want to add? Nope, I think you've covered it. Alright, Melissa, do we have any questions on visual thinking? If not, we'll move on to our next topic and tackle all the questions at the end. But if you see one or two, we'll take some now. Sure, yeah. We definitely got a couple about which tools you like to use to externalize your thinking. So if you have a couple of recommendations you want to share, I think a lot of people are curious to hear that. Yeah. I think in the past what I've seen is Teams that are co-located, it's very powerful that if they have a whiteboard that they always use and that it's like just right near where they work, it's very easy for them to get up and move things and collaborate around that. And again, have that physical, tactile experience of co-creating together. So in some hypothetical feature when we get to work together again? Yeah. More and more teams are using Miro and Mural, and there may be others. But I feel like those are probably the two most popular, again, for remote teams to be able to create a document together, to be able to look at it, you know, in real time together, whether they do it on Zoom, whether they just do it because they're all using the same board at the same time. Those are very powerful, very flexible tools to use. Yeah. So if you're not familiar with Miro and Mural. They're both digital whiteboard tools. They both support wikis as an object. They both support shapes as objects. So even if your team doesn't know how to draw, you can create boxes and arrows. You can create a bunch of stickies, move things around, and you get a little bit of that tactical feel of standing in front of a whiteboard with stickies. So those can be really helpful. I know some teams like to use flowchart tools, so things like Lucidchart or draw.io. I know a lot of Mac people still use OmniGraffle. It's challenging because you can't all co-create in that document, but if you're just doing this on your own. I really like pen and paper. I do a lot of my own individual thinking just with pen and paper and a notebook. I'm trying to transition to an iPad with a pencil so that it's digital, but there's something about pen and paper that I think makes things flow from the brain to external, much like a whiteboard. We get asked a lot about tools and I don't recommend specific tools usually because from working with a lot of teams, I've seen that different tools fit different teams better. And so I think it's really important to try a variety of tools and really find what works best for your team. Melissa, another visual question? Sure. So someone was saying that they're curious about over time when you keep adding opportunities, it tends to get really messy. And so do you have any suggestions for how you can kind of, once you've been doing this for a while, make sure that, you know, it's still relatively easy to look at your opportunity solution tree and keep track of all of the different pieces of it? Yeah, it, um, a few things. So trees should be messy. What you're learning is messy. Humans are complex. Your customers are complex. I think part of the value of the tree structure is trying to put some structure to that messiness. So if it's really this big unwieldy tree to think about what those top level parent opportunities are that can give a little more structure to it. The other thing is most teams should not be working across their whole tree at any moment in time. They really should be prioritizing and picking an opportunity or two to focus on, which we're going to talk about in our next webinar. And that allows you to really focus and refine and improve and clean up that part of the tree while you ignore the rest of the mess. So you'll see as we move into some of the other principles in the next webinar, we'll talk a little bit about how do you manage this ever-growing messy opportunity space. So come join us in two weeks and we'll have a more in-depth answer. All right. We are going to move on to our third principle for today. Don't worry if you have questions on decision making or visual thinking. We will come back to them at the end. But first, we are going to talk about being outcome focused. So if you were an astute viewer on that last slide, you might have noticed that the opportunity solution tree starts with an outcome at the top. We are seeing a really strong focus on outcomes right now with the popularity of OKRs, with a lot of sort of evangelism around outcomes over outputs. I know Josh Seiden has a book out that I think is that title. Let's do another quick poll to get a sense for are you managing your teams by outcomes? Okay, we're getting responses, which means it probably worked. Okay, so we're definitely get we're again all over the place. I like it. I like the diversity of our audience here. So a small number of you are saying you excel at this. A small number of you are saying what's an outcome? And most of you are somewhere in the middle where you're starting out with outcomes, but you're still struggling to stay away from outputs. Okay, let's go ahead and talk through this a little bit. So You know, it's funny because outcomes feel new, but I also think they were really highlighted in the Agile Manifesto, and they even predate that. Right in the 60s, we saw Peter Drucker talking about it. Andy Grove, Intel's been an advocate for this for a long, long time and wrote about it in High Output Management. I think that's the name of his book. Here's the idea. It's really easy in business and especially among product teams to be output focused. We're focusing on shipping code, delivering features, hitting our roadmap. These are all outputs. I built this thing. That's an output. Shifting to an outcome mindset is more about what impact did those outputs have. And I see a lot of confusion around this. In fact, I was just slacking with a student about this earlier today. So I want to introduce three distinctions and then hope I'm going to ask you about. how you see this on the teams that you're working with as well. So I think there's three distinctions that can be really helpful. One is we have business outcomes. Those are usually our KPIs. We all know what those are, right? For a subscription business, it's going to be things like increased retention, reduced churn, maybe increased average revenue per customer, increased lifetime retention, right? Then we have product outcomes. And we need to translate from our business outcomes to our product outcomes. So how is our products going to help us realize our business outcomes? So a product outcome, like if our business outcome is reduced churn, our product outcome might be increased engagement. By increasing engagement, we're going to reduce churn. Then I think we have a third tier, which is traction metrics. So if our product outcome is increased engagement, we might have a whole bunch of features that we believe will drive engagement. And we're going to have a set of traction metrics that we're going to measure those. And the reason why I think those three levels are really important is because for teams, we don't want to give them a traction metric as their outcome because now they don't have room to discover. What if nobody wants to use that feature? They're stuck. That's a very output focus. Whereas if you give them a product outcome, now they have a little bit of leeway to explore. If somebody doesn't like that feature, and that you can't get traction going on a given feature, you can try another one. You also don't want to give them reduced churn because reducing churn is not within the scope of a product team. Your account managers or your sales people are involved. Your pricing is going to have an impact on that. Just external factors like COVID is going to have an impact on that. So by thinking about these three layers and making sure that you're tasking your teams with product outcomes can really help to set the right scope. Hope, do you want to weigh in on that? Yeah, I think what I see, and again, when I was leading product companies, this happened a lot, they might have business outcomes, like you mentioned reducing churn, like that actually would be something that might be easier to work with. Usually it's, we want to hit this revenue target, we want to hit this target. I don't really care how you get there, and frankly, I don't want to be limited in my options of how we get there. So when I think about helping... teams and companies. I wish there was like a Google translate for this, right? Like, just put in one side, increase revenue, and have a good product outcome on this side. It would be super useful. But instead, you have to think about, for the product outcomes, what is the human behavior that is going to be different, that is going to... lead to more revenue? Is it higher or average order value, higher contract size, more upsells, is it more customers buying, like your price times quantity? So you really need to think about ways that you can translate these lagging indicators of revenue and EBITDA, maybe even market share changes, to something that is influenceable by the product team and is likely to be grounded in some sort of change in human behavior. Yeah. You know, it's funny. I love that you called out that reduced turn could be a product metric or a product outcome. I feel like this business outcome, product outcome is a little bit gray. And it depends on your company, right? So if you don't have a sales team, if 100% of your sales are driven through your website, then reducing churn is probably a product outcome. But if you have a huge thousand person sales force and they're primarily responsible for the customer relationship. The product can contribute to reducing churn, but they're not 100% responsible for it. So I think there's some context where maybe you would need to translate that even further. And that's why this, I think the concepts of a business outcome, product outcome, and traction metrics are really helpful, but I don't think there's clear delimiting lines between them. And they may even shift a little bit company to company. But I think the question to ask is, Does the product team have the ability to move this metric on their own? If the answer is yes, that's probably a good product outcome for that team. If the answer is like, well, it's messy, like increase revenue, no product team, few product teams, some do, few product teams have the ability to just drive revenue on their own, right? Other people need to be involved. So now we need to translate that. So I think part of what's being outcome focused is how do we give the team the autonomy to go after this and find the best path there? Hope, I see two sides to this that are very hard for companies. One is on the leadership side. How do I set a good outcome for my team? And the other is on the team side. I have an outcome, now what? Do you want to talk about those? Sure. So many times, I think there are companies that are in this extreme where it's like, hey, we have this revenue target. By the end of Q4, we want to achieve X. go do something or I'm going to give you a list of things that I believe will move this metric go do those things and the product team might believe in them might not believe in them might have evidence for them might not have evidence for them and so you have this tension that happens on the other extreme of the spectrum it's let us be totally autonomous don't tell us what to do we just what we'll figure it out maybe we'll hold ourselves accountable to some impact metric of some sort or maybe just leave us alone let us do what we want to do so neither of those extremes is good for a product team and so the the fact that a product leader and a product team do need to have some negotiation around what this outcome metric is is healthy tension for both parties because the product leader has to Understand what is truly important to the business. Yes, we need to hit this revenue target or this EBITDA target, make sure that we're getting traction in the market in terms of winning new customers or growing our deal size or growing our revenue per customer lifetime value. And the product team that knows very well, ideally, if they've been doing continuous discovery, they have much more sense of what's possible, what opportunities could get them closer to that out. that desired outcome or may take them longer to figure out or they are lacking ideas of how to get there and they need to do a deep amount of discovery to figure out what's possible. And so that's this negotiation that has to happen between the product leader and the product team in the setting of those outcomes and then looking at those traction metrics to see what progress we're making or what we're learning that is getting us closer or moving us farther away from achieving that desired outcome. Yeah, definitely. And this is, I think, There's a lot of skill on both sides of these. So one is, we saw in our poll a lot of you are just getting started with outcomes. Some of you are still trying to move, like define them in a way that you're not prescribing outputs. This takes practice. So I think this is where it's again really important to have that continuous improvement mindset. You're gonna think that you have a great outcome and halfway through the quarter you're gonna realize it bound you into a corner around a specific output and you're learning that that output isn't gonna work. and you're going to have to reframe that outcome. And it's going to feel like you did something wrong, but I feel like it's just part of the learning curve. And then same with for the on the product team side, they're going to start working on an outcome and they're going to realize they're measuring the wrong thing or what they're trying to do is impossible. So just know that this does take a lot of iteration, but just starting to develop that mindset of our job is to deliver an outcome, not just a set of outputs. will get your teams thinking beyond just we shipped software. So we shipped software and then what happened? And it's really the then what happened that we're pushing towards. What value did we create for our customer? And did that create value for our customer in a way that created value for our business? All right, we have about 10 minutes left. So I want to first take a couple outcome-based... questions and then we're going to turn to just the giant pool of questions and we'll stick around as long as you guys are here with us okay teresa so one quick recap question which is it sounded like you had talked about three different types of outcomes and could you remind us what the third type of outcome that you mentioned was yeah so we had business outcomes product outcomes, and then traction metrics. So the example I gave was a business outcome might be increased revenue. I think I had originally said reduced churn. I'm going to say increased revenue to make it clear. A product outcome might be increased engagement. And then the traction metrics might be, like if you're Facebook, a traction metric for engagement might be number of customers who uploaded a photo this week. or a number of customers who commented on a post this week. So traction metrics are measuring, is anybody using the stuff that we're building? And those roll up into, if people are using the stuff that we're doing, we should see our engagement go up, right? And if we see our engagement go up, we should see our business outcome go up. Okay, great. And then how do you encourage or guide the companies that you're working with to make the shift from outcome to output? Output to outcome. Hope, do you want to take that one? Yeah, I can maybe give an example of a company that is going through coaching now. And the first thing is, is like in the kickoff, we have an expectation that the outcome is really one of the first things that we focus on. And if it's... a lagging indicator abstract you know concept of you know EBITDA or revenue or market share or margin increase margin or something like that we have a number of conversations with the leadership team and stakeholders to say like how do we translate this into something that the product team has influence over and is more likely to be a human behavior what human behavior leads to that that lagging indicator outcome. What would be some of the hypotheses that you have? We don't expect that they get the outcome right the first try out of the gate. As Teresa said, it's continuous improvement. There's some iteration. There's probably going to be some learnings and trial and error in setting that outcome. But getting them to translate it from lagging indicator business outcome to product leading indicator, human behavior based change. is the first step. And again, even if we pick the wrong metric, we can change that at a later time, but we need to have something that is within the product team's realm of employees. I think also the other direction is really common, where a team is being asked to deliver a specific output, but it's being framed as an outcome. So like their OKR is to deliver an Android app. Right. And just trust that it will lead to more Engage. Yeah, like we know we need an Android app. Just go build it, right? So if that's the case What we do to help teams reframe an output to an outcome is okay, let's imagine you had the Android app today What does that get you? Oh, well our users would be more engaged because they can use this on the go. Okay, great Your metric is engagement because really if I can find a different way to drive engagement, are you going to be satisfied? So the answer is yes, then the outcome is engagement now sometimes We do have strategic initiatives, like we need an Android app not for engagement, but because we need it for some other strategic reason. So there are times where a business might need to dictate outputs or constrain outputs, solve this problem, but with this limitation. I think the challenge is that we don't really question whether that's the right thing to do, right? So I think a lot of this translation from outputs to outcomes is... to use this reframing. Okay, you need an Android app. If you had that, what would that do for you? It would increase engagement. Can we find another way to increase engagement? Is that equally good? If the answer is yes, set the outcome. If the answer is no, dig into why. And if it really is, you need the output, just manage by output. This isn't an all or nothing thing. But I think the key is to start having that conversation around why are we doing this? Why does this output matter? Alright Melissa, before we dive into more questions, because we are almost out of time, I want to highlight a couple of things. One is, we have a number of opportunities for teams to learn more about this. So if you want to learn more about those training opportunities, you can go to producttalk.org slash learn. I did mention in the beginning, this is the first of three webinars. So I also want to make sure that we get that webinar registration link, so you have the first chance to register for... our webinar two weeks from now. Melissa, do you want to go ahead and put the URL for the next webinar in that chat channel? So you can use that link to go ahead and register for the next webinar. I wanted to make sure we covered both of those before we're done. And now we'll turn back to more questions. All right. So yes, I've just put both of those links in the chat panel so everybody should be able to see them. Let me know if it's not showing up for you, but you should have a link both for producttalk.org slash learn and then also to sign up for the next webinar and that's a Zoom link. So Teresa and Hope, one of the questions that we have is about convincing management or the c-suite executives to allow a product team to work this way basically how do you get them to be bought in with this idea of devoting time to things like generator generative research customer interviews brainstorming all of that yeah i think there's two parts to this um and i'm i'm gonna I'm going to also have Hope answer this one too because we might have different, probably similar, but maybe slightly different perspectives. So one is I spent most of my full-time employee experience at early stage startups where there was no product leadership or there was very little product leadership. And I never had permission to do any of this stuff. I just did it. Now I say that with caution. Don't get fired. Don't do something your boss isn't telling you to do. But you do have the ability to do a lot of this work without a formal process in place, without a way of working at your company, right? So especially if you work at a consumer company, just go talk to people. If you work at an enterprise company, it's a little harder. You got to make sure you build relationships with your account managers and your salespeople. But don't look at this as this has to be an all or nothing top down. We're doing all the right things. There is no right way, remember? So just start with doing a little bit when you can. The second part of it that I would say is instrument your product. Start tracking the effect of everything that you build. Because one of the best arguments for increasing your investment in discovery is recognizing how often what you build doesn't have an impact. And that can be a really painful process, but it is the most effective way to argue to work this way. I'm going to add a couple of thoughts on this. When there's sort of a not belief or probably more likely understanding at the leadership level of a company and teams are feeling like we're not allowed to work this way or we can't work this way or leadership wouldn't support us working this way. If you reframe it instead of using like abstract terms like you know continuous discovery or whatever as wouldn't it be better for us to understand what mattered to our customers. And make sure that we are increasing our probability of success and de-risking our investments by learning early what's likely to work and what isn't. Very few companies are gonna say, or leaders are gonna say, no, I don't think that's important. I think we should just do what I think, you know, my idea is, right? And then you can even break that down into another layer, which is how do I make sure that I've got the evidence? How do I create How do I add new information to the discussions that we're having about what we should or shouldn't do on behalf of customers? That is information that probably the people in the room don't know. And the more that you're bringing new insights and information to the table, the more likely that people are going to look to you to be an advisor that has expertise that helps de-risk investment decisions for the company. And so just think about ways that you can reframe it in a way that makes it easy for people to say yes and support without having to know all the dirty details of the methods that you're using. Yeah, you know, it's funny, Hope. I love that that was your answer because I read a blog post called Managing Stakeholders something or another. If you search Managing Stakeholders Product Talk, you'll find it. And it really is all about this idea of... If you want to be a part of the decision-making as you move up the hierarchy in your organization You have to find a way to bring new information that they don't have and most leaders are not going to say I don't want that information They're gonna go. Oh, that's that's a new piece of information I didn't already have and so just getting creative about ways that you can do that I am noticing that we still a lot of people on the line It is we are right at the hour and I want to respect everybody's time. So here's what I'm going to do I'm gonna go, I think we're gonna wrap up. I know there's a lot of questions that we did not answer. So what I'm gonna recommend is that we're gonna go ahead and wrap up for today so that we stick to our schedule. Definitely grab that registration link in the chat for the next webinar, which is in two weeks. It's gonna be on Wednesday instead of Thursday. And I'm gonna talk with Hope about maybe we'll add a fourth webinar. We'll see how schedules work out where we tackle the questions we didn't get to in the individual webinars and see if there's a way we can kind of can keep the conversation going. All right. Thank you, everybody. Thank you, Hope. Thank you, Melissa. Great to get so many good questions.

Parts 2 and 3 will be released in February and March 2021.