What’s the biggest misconception in product discovery today? | Teressa Torres

Today I was listening to one of your talks at Productized. So I want to ask what inspired your deep focus on product discovery? Product discovery is just the work that we're doing when we decide what to build. It's really about good decision making, critical thinking, problem solving, problem framing is a big part of it. What's the biggest myth or misconception about product discovery? One of the biggest misunderstandings is... We don't want to do all the design work or all the engineering work before we know it's the right solution. Use a term called curse of knowledge. What does that mean? The curse of knowledge. Welcome to another episode of Product Founder. I'm super excited today to have Teresa Torres on the podcast. Teresa, can you please introduce yourself? Yeah. Hi, everyone. I'm Teresa Torres. I work as a product discovery coach. That means I help product teams make better decisions about what to build. And I've done that. through a couple different mediums. I started out as a coach where I worked week over week very closely with specific teams as I tried to learn about what should we build. And then over time that evolved to we now have six different online, seven different online courses that people can take. You can learn about those at learn.producttalk.org. And a lot of that came out of just seeing the same patterns over and over again at a wide variety of teams and looking at What skills do product teams need to develop to make good decisions about what to build? And then a lot of what I focus on is just how to keep helping product teams develop those skills. I love it. Today, I was listening to one of your talks at Productized. I think the talk is around eight, nine years old. So I want to ask what inspired your deep focus on product discovery in the first place? Yeah, so I'm in my 14th year of working as a product discovery coach, which is kind of mind blowing. It's by far the longest job I've ever had. I think what really motivated me in this focus is that So first of all, my background is in human-centered design. Sort of came into industry thinking that people, the product teams talk to customers and that they practice human-centered design practices. And that wasn't really the case at most of the companies that I worked at. And so I really wanted to be a part of making that more common. We've definitely seen progress over the last 14 years, but there's still a lot more work to do. So I think what keeps me motivated is just, especially since my book came out. So my book, Continuous Discovery Habits, came out in May of 2021. I regularly hear from teams that tell me they're now interviewing more consistently. They're starting to run assumption tests. And then more importantly, they share what impact that's having on their work. And that's really motivating to just keep going and to keep helping more teams. Definitely your book had a very nice impact, but I want to go back to the book. So what is Continuous Discovery Habits about? Let's pause here for a second. The other day I was looking into our channel analytics and I noticed many of you guys are watching a lot of our episodes, but not yet subscribed to our YouTube page or Spotify. I will ask you as a favor. Please support us by subscribing to our YouTube page and Spotify page and I will promise you I will do everything in my power to make each episode better and better. Thank you. Yeah, I wrote the book to be a very practical hands-on guide for product teams. So one of the challenges with this topic of product discovery, so product discovery is just the work that we're doing when we decide what to build. It's really about good decision making, critical thinking, problem solving. problem framing is a big part of it we all like every product team does activities that fall into this product discovery bucket the challenge is most of us never had an opportunity to like learn how to do it well there's a whole bunch of skills related to how do we do product discovery well and a lot of us just have never been introduced to them and then historically businesses have under emphasized this area so we're not necessarily getting a lot of training in this area And so my goal was to take this very vague nebulous thing and make it very concrete. Give everybody a clear benchmark they can aspire to. I know that change is hard. So I didn't want to introduce it as like, here's all the things you have to do, but rather here's a collection of habits and we can work on one habit at a time. We can iterate our way there. And so my goal with the book was to give teams a very practical guide to here's a collection of habits. This collection of habits is what continuous discovery looks like and then also gives some guidance on how you can start to adopt those habits and change the way that you work. No, I love that because one of the challenges I hear from a lot of product managers is they read a book which is written in the perfect world and they cannot really apply any of the things in the book. through their organization. And sometimes as a product manager, of course, we have a lot of influence, but then we cannot really change the whole organization, right? We can just kind of impact a couple of things. If the organization doesn't want to change, we can't really do much about it. And that creates a lot of frustration. But when I was reading your blog post, I started to notice that a lot of these could be started to be implemented easy and it's not that difficult. And I really... liked that about it. And I want to ask you in your experience, what's the biggest myth or misconception about product discovery? That's a good question. I think there's a lot of misinterpretation and misunderstandings. I don't know that there's a, like, I can think of a primary myth, but I can talk about kind of what some teams get wrong. One of the things we're in the midst of is this transition from a project mindset to a more continuous mindset. There's a lot of misunderstanding in this transition. So when we talk about delivery, so how we deploy software, it's really easy to think about like a batch of code. So a lot of companies used to ship software once a year, once a quarter, and you can imagine that batch of code was really big. All the changes you make in a quarter or all the changes you make in a year. And progressively over the last 20 plus years now, probably 25 years for some of us. our batch size of delivery has gotten smaller and smaller. We see a lot of teams shipping monthly or weekly. Some teams are even shipping daily. This concept of project to continuous is really clear on the delivery side. I think on the discovery side, it's a little more muddled. If I do a project and I talk to a dozen customers and then I synthesize it into a report, it's really clear that's a project. If I talk to one customer every week and I'm synthesizing as I go, It's really clear that that's continuous, but there's a whole bunch of gray in the middle, right? And what I see a lot of teams do is they misunderstand this project versus continuous mindset. And they take old project-based research methods and they try to just do them more often. And the problem with that is that that's big project research. Like we can't do it all the time because we're going to burn ourselves out. Like we have to. also do the rest of our jobs. And so I think one of the biggest misunderstandings is not recognizing that our tactics change. The types of research that we're doing changes. So like one of the biggest misunderstandings is this distinction between whole idea testing and assumption testing. And I would say the vast majority of teams are still testing their whole ideas. And this comes from a project-based world. Whereas like a good continuous discovery team is breaking their ideas down into their underlying assumptions. But to like really understand that, we have to understand what we even mean by assumptions. We have to understand how quick assumption tests are, why that enables good decision making. And so this is, a lot of teams haven't experienced this. And so it's an area where it's easy to have a lot of misunderstanding. So by whole testing, you mean like they're basically testing their whole idea, right? Not an assumption of a part of it, right? Yeah, like a lot of teams, they ask their designers to do, here, design this feature. And then when you're done with all of the design for the feature, we'll go get feedback from customers. So we're getting feedback on the whole idea. We did all the design work up front. Or other teams, like, they rely on A-B testing for all of their discovery. So they build the whole feature, they ship it to production, but they gate it with an A-B test, right? And the challenge with both of those things is we don't want to do all the design work or all the engineering work before we know it's the right solution. Discovery should be saving us time from building the wrong stuff. And so the way that we get there is we take our ideas, we break them down into the particulars that they depend upon. So what needs to be true for this idea to work? And we can generate a series of assumptions and then we can look at which of these assumptions carry a lot of risk, which ones should we test? And that starts to inform, should we build this or not? Should we even do the design work for it or not? And I think this is a new, this idea has been around for a long time. Like Eric Ries wrote about it in The Lean Startup, which by the way, came out 14 years ago now in 2011. I think it was fall of 2011, but it's still, we don't see a lot of evidence of it in practice. And I think it's because this project mindset versus continuous mindset is still really hard for people to grok at when it. comes to discovery yeah that's uh very interesting when i was reading your blog post you use a term called curse of knowledge yeah so first i want to know what does that mean especially for the listeners and how do you coach teams out of that trap yeah so the easiest way to think about the curse of knowledge is that you probably have someone you know that like maybe has a really complicated job and you're not really sure what they do And you've asked them and they can't really explain it to you. I actually experienced this with my husband when I first met him. Right. Like my husband does tomography, which I didn't know what tomography was at the time. He explained it as like a CT machine is computerized tomography. And I was like, OK, well, I know what a CT machine is, but I don't know how it works or what it does. So like I still didn't know what he did. And it took like multiple conversations to like really understand like, OK, X-ray. is getting blasted to an object and how it scatters it helps you figure out what it looks like and there's all this math involved and right it was very complex why was it hard for him to explain what he does to someone who doesn't know anything about tomography well because he's been working in tomography for i don't even know 20 plus years maybe longer and he has the curse of knowledge right it's hard for him to forget to remember what it's like to not have all that knowledge and he's actually very good at explaining things right but it doesn't it's it goes beyond this skill of like how good we are at teaching it's about being exposed to the fact that you know things that other people don't know like we have to be exposed to that so we can see hey there's a gap so the curse of knowledge is basically this bias that says as we develop expert knowledge we forget what it's like to not have that knowledge and then as we engage with other people we engage from our expert point of view, and they don't always understand us. The way this shows up for product teams is that product teams, like anybody who builds products, so product managers, designers, software engineers, probably like literally everybody who works in your company, you build up expert knowledge about your product. You know what functionality it supports. You know where everything lives in the interface. You know exactly how the features were intended to be used. And as you start to make your daily product decisions, they're colored by that curse of knowledge. You forget what it's like to not have all that expert knowledge. And this is why we label things that don't make sense to our customer, or we build features where the mental model matches our expert mental model, but not our customer's novice mental model. And this is the source of a lot of friction, not just usability, but also definitely a lot of usability for friction. Like, I don't understand what I'm supposed to do. but also just the mechanics of how something works if there's a mismatch between the product team's mental model and the customer's mental model. That's very interesting. I think sometimes we miss out that we are the expert and not necessarily the user or the people who are interviewing even have a clear idea of what the company's mission is. I have a funny example of this for my own business. So I often say I run a cohort-based course business. which I'm trying to distinguish it from the edutainment products of information-only courses online. So in an information-only course, you sign up, you get a bunch of videos and articles, you go through it on your own time, and then you're done. Whereas a cohort-based course is, you have a cohort of students that are going through live instruction together at the same time. It's more what we would traditionally call a college course. I teach product managers and designers and engineers, and some of us are exposed to this cohort language because we do cohort-based analytics. But if you don't do cohort-based analytics and you've never heard that term, it's not a very accessible term. Like, what's a cohort, right? And so because I think about types of online courses, I thought this was really clear. But after talking to students and regular people that don't think about online courses, this distinction is not clear at all. So now I describe it as instructor-led live course sessions, right? That's something that we all get that. No, that's very interesting. We had many episodes about the clarity of the vision and how simplicity is power. Also for the users and also across the team and how important that is for you to have like a vision, which is clear and everyone understands. A lot of these big companies today, their vision is very vague. So you as a product manager or people in the company building things, you don't know how you're building toward that vision. So I really like help you by changing the world, how I think impactful it became because now everyone who wants to register, they know what they're signing up for. And obviously it's such a big effort for you to figure out how to explain it. It becomes like an easy word, but it's basically just a couple words. that are being just changed which has a very very big impact i know you talked about product discovery is a decision making process what are some poor decision making patterns you frequently see yeah what's good about framing discovery is decision making is we have like a hundred years of research on good decision making maybe longer and if we include philosophy we have hundreds of years of debate and discussion and research on what makes good decisions What leads to good decisions? So we have a lot of good source material to draw from. We don't have to just rely on people's opinions. I think what's really nice about this, especially in the tech industry, I think we tend to over index on what the big companies do, right? So we get enamored with the Spotify model or we use OKRs because Google uses OKRs. And it's not that we can't learn from these sort of big, large, successful companies. It's that when we base our practices on what they do, we run into a bias called survivor bias, right? We don't know if Google is successful because they use OKRs. We know that Google is successful and that they use OKRs, but there's probably thousands of other companies that use OKRs that weren't successful, right? And so survivor bias is when we over-index on what the survivors do and we attribute that behavior to their success. But we actually don't know which of the behaviors. attributed to their success so what i like about framing discovery is decision making is instead of just looking at like what does google and spotify do we can look at how do we ground our practices in evidenced based decision making so what do we know from decision making research and like one of the guys that i really draw from is an educational philosopher from the turn of the last century so like He wrote most of his like canonical work in the early 1900s, right? This is stuff that has been around for a really long time that people have built on top of, that they've iterated on. I mean, even the scientific method is something that's been around for a long time that like we've battle tested and iterated on. So I like this idea of grounding things in things that are a little bit more evidence-based because it makes sure that we don't just chase the latest trend. So what are some of those things that come from decision-making research? And there's a few big ones that I integrate into my work. One is this idea of comparing and contrasting. So when we're trying to decide to do something, a lot of us in the product world, when we're doing discovery, we frame our discovery as, is my idea good or not? I'm going to go get feedback on my idea. The problem with this framing is that we all fall in love with our ideas. So we suffer from this bias called the escalation of commitment. It's very similar to the sunk cost fallacy. The more we invest in an idea, the more likely we're going to overcommit to it. And then that exacerbates another bias, confirmation bias, where we're more likely to see the evidence that supports our idea and completely miss the evidence that suggests our idea is flawed. So one of the simplest things we can do is instead of setting up this whether or not decision, is my idea good or not? we can set up a compare and contrast decision. Here's three ideas that are all designed to solve the same problem. Which of them looks most promising? Now, this wasn't sustainable in a project-based world where we tested whole ideas, right? We can't design three ideas, we can't build three ideas, but it becomes sustainable when we learn to break our ideas down into their underlying assumptions. Because assumption testing gives us the data we need to support the compare and contrast decision. And that comes right out of like decades of decision-making research. And we know this intuitively, right? Like when you go to look for a new place to live, you don't look at one apartment. You don't look at one house. You look at multiple places and you compare and contrast better location, better layout, better size. Does it meet these needs versus those needs, right? Same with when we're looking for a job. Most of us didn't marry the first person we dated. We know with big life decisions to compare and contrast. But it turns out this carries through to all decisions. Any decision benefits from comparing and contrasting. So that's one example. But there's a lot that we can draw from. There's a lot around critical thinking about can we visualize our thinking? So can we get it out of our head so that we're not relying on working memory? The challenge is our working memory is really limited. So if everything's in our head, we're using most of our cognitive energy to just remember the stuff, which means we don't have very much cognitive energy left over to act on it. But if we externalize the different pieces, so if we put it down on paper, especially in a visual way, now we're not spending any mental energy remembering, and we're using all of our mental energy to act on what we're... on the particulars. So this could be like, which customer problems should I solve? Well, if you're trying to keep all the customer problems you've heard in your head, you don't have a lot of mental energy left over to like compare and contrast them. But if you put them on paper, if you take an inventory of all that you're hearing, now you don't have to remember all of them. You can use all your mental energy to act on them. And a lot of this comes out of like cognitive psychology research. So it's not directly decision-making research, but it's also an area where we have decades, if not, we're getting probably close to 100 years of really good research on cognitive psychology. And so I really like to draw from some of these more evidence-based particulars and then use our industry company practice. So obviously, academics don't build products. I can't just take the study and be like, this is what you should do. We have to combine it with like, how do we apply these ideas in industry and what actually works for teams? And so this is where I think we can look at like these big company best practices and say, are they evidence-based? And then what we want to look for is the intersection of what is supported by the research that we also see evidence of working in industry. That's very interesting. There's a lot to unpack there. And I think what you just said is a great segment to shift to another part of the topic that I want to talk about today is the opportunity solution tree is such a clear visual framework. What was the origin story behind that concept? Yeah, this is something I've had in my head for a long time. It started with my personal experience as a product manager. So I used to not be good at visualizing my thinking. i'm the kind of person where i can hold a lot in my head i make a lot of like inference jumps and i don't realize it and so one of the challenges that i had working with like a designer and a set of engineers so just working with a typical product squad is we would try something and it wouldn't work and so then we would like get everyone in a room and try to problem solve and i would get frustrated because it would seem like an engineer would make a suggestion that didn't solve the problem we ran into. It was like tangential. So it was like in my head, I had this really clear view of like, this is the problem we're trying to solve. These are the solutions we're considering. We just learned this one won't work for this reason. Let's just tweak our ideas to fix that and still solve this problem. But what was happening in the room is that like people would bring up other customer problems or other solutions that had nothing to do with what we had just learned. And it's like we weren't. We didn't have boundaries around the conversation to keep us focused on solving the customer problem. And so for years, I was trying to figure out like, how do I get what's intuitively in my head onto paper? And I played with a lot of variations. So like I used to like enumerate, like here was our implied hypothesis. We weren't good about being explicit about it, but here's our implied hypothesis. We learned that this is not true. So we don't have to throw away the solution. We just have to change the solution to not depend on this hypothesis. And so like I went through all these iterations of like, how do I enumerate this? And I never got to a very good point when I was working full time. I just, you know, I had my own job to do. I didn't have a lot of time and energy to focus on this specific problem. But then when I started coaching teams, I started to see the same problem show up on team after team. And I had one team in particular come to me and say, Teresa, we're learning a lot in coaching, but we don't know what to do when. You always tell us what to do next. And this was like really salient feedback for me because the reason why I worked as a coach instead of a consultant is I really want to help train and skill build and not just do the work for a company. That got me thinking and it got me back to this visual that I had in my head that I just could not externalize. That's really what led to the opportunity solution tree because what it does is it reminds people the scope of your work. We're all driving towards this outcome. We've identified these customer problems. We're focused on this one in particular. We're comparing and contrasting these solutions. We've tested these assumptions. And what it's doing is it's visualizing that missing context. So when we get a faulty assumption test, we know that we're just trying to fix that solution in the context of that opportunity, in the context of the outcome. And then it turns out that same visual has a lot of other benefits. It supports compare and contrast decisions. It supports this idea of alleviating your working memory. It's a really great way to keep a team aligned. because it's visual. It gets into things like, do we fully understand the problem we're solving? It really makes problem framing visual. So I ended up having a lot of other benefits, but where I really started it was just trying to get the shared context out on the paper so that teams could have better conversations about what they're learning and what to do next. So based on your experience, what are some common mistakes teams make when creating their first opportunity solution tree? Yeah, the biggest one is they sit in a room and make up opportunities. And that is, don't do that. That's just garbage in, garbage out. The purpose of an opportunity solution tree is twofold. It's to help us find the best path to our outcome. And it helps us stay aligned as a team as we learn from our customers. So you have to learn from customers. So there's a few prerequisites before you even want to start creating one. First, you need an outcome. I get asked all the time, how do I create an opportunity solution tree if I don't have an outcome? You don't need one if you don't have an outcome. They help you find the best path to your outcome. So having an outcome is a prerequisite. And then another prerequisite is I want you to have at least three or four story-based customer interviews completed before you sit down to start mapping the opportunity space. And this is the one that like, if I had a magic wand and could change anything about the world, it would be this. Like so many teams, sit in a room and just make up opportunities off the top of their head. And they think that it's because like, we've been in this space a long time, we know our customers well, of course I know what their opportunities are. But when we make up opportunities, we don't get specific enough. An opportunity is experienced by a customer in a specific context, in a specific moment in time. We can't make up those details. So I'll give an example, like it's really easy. to make up an opportunity, I want to watch my TV show on the go. It's very different from I'm on a flight on my iPad without an internet connection and I want to watch the latest episode of Breaking Bad. That context and detail matters when we get to the level of designing solutions because no solution can work in every context for every customer. And so getting to the level of specific instances is what gives us what we need to adequately design solutions. So the biggest mistake teams make is they make up opportunities instead of collecting real customer stories. I just really liked when you said that the context matter, because yes, I think as a product manager, if the person is about to watch the Breaking Bad in the airplane, I might try to think about the feature differently than if he's going to maybe have access to the internet much more. Maybe the possibility of having internet is more than being on a flight for five hours without no internet. And I think a lot of product management, maybe they miss out this level of details or they don't want to pay attention to this level of details because everything that you're talking about requires a bit of detailed thinking. You got to think about it. You cannot just... randomly make things up. And I think it also in a way, maybe it also increases the work. I don't know what you think about that. I think there's a few elements of this. So I can go collect 100 stories and they're all going to be unique. So how do I know which ones to solve for? And this is a lot of the pushback. They say, Teresa, I know how to tackle the opportunity I want to watch on my iPad. But this story about someone on a plane watching Breaking Bad feels really idiosyncratic. How do I pick that story versus the 99 other stories I collected? Well, this starts with who's your target customer? What's your vision? So it starts with the organizational context. What customers are you serving? No product can serve all customers in all moments in time. So for a lot of product teams, they're missing that organizational strategic context. And that's what makes this hard. They collect a lot of stories and they don't have a rubric for how do I know which stories matter and which ones don't. So that's the first thing. And if you work in an organization that's missing that strategic context, just define it yourself. Do the best you can based on what you see, the types of decisions being made at your company. No product serves everybody. So that's the first thing I think makes this hard is that we're not being given that rubric. I think the second thing that makes it hard is you're right. It takes a lot of mental energy. to go from a lot of particulars to find the patterns to do the sense making to figure out to go from i could build a custom solution for a hundred different people but how do i find the power in the one solution that covers a hundred cases and that is a really hard skill to teach and it requires more mental effort than i think most of us have time for or experience in business life. And I don't say that because we're not all smart and capable of doing that. It's that the cadence and nature of daily business, all the meetings that we're in, we don't have time for this deep, thoughtful work. And if you don't create the time for that deep, thoughtful work, you're not gonna go from the 100 particulars to the one or two things that you could support. The challenge is if you don't do that deep thoughtful work you're going to build a lot of stuff that doesn't really work for anybody so it's like it feels a little bit like a catch-22 i think for individual contributors you can start small you can find like 30 minutes in your day to just chip away at this problem to just do a little bit more of it i'm a big fan of cal newport's books he has one called deep work and he has another one called slow productivity and he just talks about like if we really want to do work good work we have to create thinking space and i think there's two parts to this you have to be talking to customers and collecting real customer stories and then you have to do the synthesis work to turn those particulars into a theory of how the world works that you can base your product decisions on and that philosopher that i referred to that from the turn of the century turn of the like early 1900s He's the educational philosopher John Dewey. And one of the things he talks a lot about is this back and forth movement between inductive reasoning and deductive reasoning. And those are big words. People don't even know what they mean. But deductive reasoning is looking at a whole bunch of particulars and then generating a theory based on those particulars, right? That's going from particulars to a theory is inductive reasoning. And then starting from a theory and testing. but a particular is deductive reasoning and there's this back and forth movement between the two and that's what we're doing as we interview we're collecting our particular and we're looking at does it support our inductive theory or does it or do we need to revise our theory and then as we test solutions we're testing here's a per we're testing a particular based on our theory so we design the solution based on our theory and now we're putting it in front of a customer and we're testing it And what I like about John Dewey is he tried to get really specific about this is what we do when we're a good critical thinker. We move back and forth between deductive and inductive reasoning. And I think this is really important in the product space because there is this back and forth movement in learning about our customers. We heard a story, we generated a theory. We heard a story, we generated a theory. There's also this back and forth movement in the solution space. We have a theory of the problem. Here's our proposed solution. As we test it, we get feedback and realize our understanding of the problem isn't quite right. And there's this back and forth movement. And so I think we have to develop this like intellectual honesty and diligence to work these back and forth cycles if we want to build successful products. How do you think we should explain to our C-level? That what I'm doing right now, this level of deep thinking, it is required. Especially that maybe the first time they would say, yeah, sure, no problem. Spend some time doing the deep work. And then you do it one time and second time and third time. And maybe what you build will not have the ROI they're expecting, right? So then I'd say, maybe just leave that out. Yeah, I think you have to start by showing that what you're doing today isn't working. And this feels scary because you're basically showing that what your team is building isn't having the impact you thought. But this is a required step. Like for most product teams. they're actually not deciding what to build. A business stakeholder is telling them what to build. So there's a few challenges with this. Like you want time to think about what to build and you're asking someone to give you that time, but that person just wants to tell you what to build. So why would they give you the time to do this work when they already think they know the right answer? So the first thing we have to do is start to expose reality. And reality is even the best product teams. only like 20% of what they do works, right? If you hear anybody that like runs a lot of AB tests and are honest about their results, only about 20% have an impact. And that's a good result. That's a good hit rate, right? And so if that's our reality, and a lot of us, we don't believe that reality because we're not instrumenting anything. We're not following up and measuring impact. We're not having these hard conversations. So it feels like everything we built works. But I guarantee there is no product team on planet Earth that everything they built worked. I think even for most product teams, most of what they built doesn't work, right? And so the first thing we have to do is start to expose this problem. We have to start to expose like, hey, we have 100 features in the product and about 12 of them get used. Maybe we should start thinking about how we decide what to build. Yeah, I can fully relate to this. It feels like shooting yourself in the foot, right? Because the C-level might be like, hmm, but you should do well those features, right? You're the person responsible and I hired you as a product manager. So if you disagreed for that feature to be built, why are you there and said it like three months ago? This is really hard. Like I'll even share from my own personal experience. I run a community for practitioners that are putting the discovery habits into practice. As part of this community, we've experimented with probably at this point over 100 features. So a community feature could be things like we run a book club, we do monthly challenges, we hold community calls, we do member one-on-one matchups, we've tried all sorts of things in the past. And I would say probably 10% of what we try works. And that's with doing continuous interviews, testing ideas, like... It's really hard to find things that engage busy people over time, right? It's not uncommon for your success rate to be that low, even when you're doing good discovery. Now imagine how low it is when you're doing no discovery, right? So it's not, discovery doesn't tell us the right thing to build. It increases the likelihood that we're going to build something that matters. Zooming out a bit. What's one area of product discovery that you're still learning or evolving your thinking on? All of it. None of this is set in stone. I mean, I think all of these practices are still evolving. So I'll give some examples across the habits. When I first started writing about outcomes, OKRs were very much the trend and outcomes being quantitative was really critical. So they would map to a key result. Well, I've worked with so many teams where they literally have zero analytics. So if their outcome has to be quantitative, they're done, they're stuck. And what I've learned over time is that your outcome does not need to be quantitative. Like most of, probably 90% of the value of an outcome comes from the focus it creates. And if you limit it to what you can measure today, you might not be setting the right outcome because the right outcome may not be something you can measure today. So if we hyper-focus on measurable outcomes, we often miss the mark, right? But you can go back and look at my blog post. I've probably said a thousand times an outcome is something you can measure, but it's not always something you could measure. And I've started to write more about the value of directional outcomes that tell you what direction to go in before you can measure impact. Even with interviewing, I teach a very specific format of story-based interviewing, but I'm always learning myself even how to better collect a story. So like I recently read a lot about how an interviewer can help the participant remember their story. So I learned a lot about how memory is encoded and how we can help people tap into their memory in different ways to help them pull out more of the richness of their story. Even assumption testing. So like I talk about identifying assumptions across five categories, desirability, viability, usability, feasibility, and ethical assumptions. Well, I talk a lot about ethical assumptions about the data that we collect and are we responsibly using that data? and about the customers we choose to serve and who we might unintentionally be leaving out. And I had a student ask me about like, what about sustainability? Shouldn't that be a category under ethical assumptions? And I was like, yeah, of course, like the resources our products use and the footprint we're leaving behind. And right. And so that category is constantly getting expanded. Like all of this is a moving target as we learn and experiment and try things. Yeah. And if you were to rewrite or expand continuous discovery habits today. what would you add or emphasize more on? I think the big one would be about outcomes not having to be measurable and about measuring impact can be qualitative. I think when I wrote the book, I wasn't as aware. I think it's something like over 50% of product teams, according to our last CDH benchmark survey, don't have access to any analytics. And that doesn't have to stop you from doing discovery. So I think I would put... Add some options for teams that don't have access to some of the quantitative data that we rely upon. Why they don't have access to data? Like no data at all or for that specific thing? None. How come? Yeah, I don't know. I think companies just don't prioritize it. They don't know. It's a possibility. That's very strange. I mean, I'm very grateful to not work at any of these companies, but it even sounds impossible to have none. Some of it is clearly that the product teams don't have access to the data. We all have access to some data just by doing database queries. I think it's that they don't personally have access to it on a daily basis. I've worked in these environments where to get analytics, you have to ask an engineer to run a query. That's slow and takes forever. It's obviously not binary. I have nothing. I have everything. There's a whole spectrum. But I think I have a better appreciation of how little like telemetry there is for a lot of products. Yeah. I mean, when you earlier talked about, we look at these bigger companies and like Google uses AKR, but doesn't mean that that made Google successful. I feel with a lot of these organizations, we look how they're doing certain thing, like how they're collecting data. And it's so complex and it's so advanced. And I'll be like, hmm, man, I as a product manager and this team of like 10, I can't really do that. So that gap demotivates, I think what I've seen demotivates a lot of product people to not even put like a simple Google Analytics event for the signup button. So then later when you ask like, okay, can you tell me like how many of the visitors are turning to become like a signup user? They don't know that. And I'm like, but then these are very, very. fundamental metrics that you should at least try to track. Yeah, it's funny that you use that example because I just worked with a product manager who they have Google Analytics set up, but it's basically set up as an access logs tool. Like they have zero events set up and she wants to make changes to the signup process. And she was trying to figure out what's our current signup conversion rate. But the problem is they have like a six page signup flow that's all on one URL. So she has no idea what our conversion rate is. and she can't like she doesn't get access to engineers to add events she gets access to engineers to build features so like that's just her reality that's what her company prioritizes so she does yeah they have google analytics it doesn't have any of the data that she needs to make a product decision one of the things that i teach is like you can run one question surveys inside your product to get access to like customer feedback okay most of the tools that allow you to embed a one question survey the way that you implement them is you put one line of JavaScript in the header of your website. For most products, this is one line of code change in one place in your production environment. That is a little more work. Your engineers probably want to make sure it's secure and it's not going to impact performance, whatever. But these tools are pretty mature. We're talking about adding one line of code. in your production environment and maybe if your production environment is based on like seven systems maybe it's one line of code in seven places but it's not we're not talking about a big change i have watched teams wait weeks if not months for this change to be implemented because again most companies think about their engineers as the i.t team that fills orders and the orders they fulfill are building features and this idea of like i need you to do something that's not going to build a feature it's just going to give me some telemetry never gets prioritized it's crazy i just really advise all the product managers who are working in those companies try it out other companies where you can have be more impactful and you can also change things easier trissa i'm definitely loving everything and all the conversations we are having. I know that we are limited on the time. So I want to ask you for the listeners, first of all, where they can find you and also if you have things that you would like the listeners to check out. And we will definitely put the link of the book in the description as well. Yeah. So the book is Continuous Discovery Habits. It's available worldwide. It's in Kindle, EPUB. paperback and audible and i narrated the audible so that's kind of fun if you're not ready for the book which i get it like if this is the first time you've been introduced to me go to producttalk.org we have deep dive guides free completely free guides on things like what is product discovery, how to define outcomes, how to conduct a good interview, how to run assumption tests, how to do it as a cross-functional product trio. So if you're brand new to my work, that's a really great place to start. If you've read the book, if you've heard some things today that have convinced you just want to get a little more hands-on practice or get some experience putting some of these habits into practice, we do have seven online courses. that are designed to build skill quickly. They're all instructor-led, and they're all based on hands-on practice. We have a strong belief in learning by doing, and they're a lot of fun. And we actually have a couple courses. We always have courses kicking off roughly every other month. And our next set, I'm not sure when this is going to go live, but our next set is kicking off in mid-April. Yeah, we're going to go live later with after that. All right, well, we've got some starting in late May, too. Awesome, awesome, awesome. Teresa, thank you so much for joining this podcast episode. It's been amazing talking to you. Thanks for having me. This has been fun. Wow, you made it till the end. I'm very proud of you. Comment down below which part of the podcast did you like the most and who should I interview next? Also, on the screen, you will see a lot of our other great episodes that you should definitely check out.

In this episode, Teresa Torres, a product discovery coach, discusses her journey and insights into product discovery practices. She emphasizes the importance of continuous discovery, the common misconceptions teams face, and the impact of the curse of knowledge on decision-making. Teresa also introduces the Opportunity Solution Tree, a visual framework designed to help teams align their efforts and make better decisions based on evidence and assumptions. In this conversation, Teresa Torres discusses the importance of creating shared context within teams, the common mistakes made in developing opportunity solution trees, and the necessity of grounding product decisions in real customer stories. She emphasizes the significance of context in product design, the challenges of accessing data, and the need for deep, thoughtful work in product management. Torres also highlights the evolving nature of product discovery practices and offers resources for continuous discovery.

Teresa Torres: https://www.linkedin.com/in/teresatorres/
Spotify Episode: https://creators.spotify.com/pod/show/product-founder/episodes/Whats-the-biggest-misconception-in-product-discovery-today---Teresa-Torres-e34jp70
Episode Post: https://product-founder.com/whats-the-biggest-misconception-in-product-discovery-today/

Chapters:
00:00 Introduction to Product Discovery Coaching
01:03 The Evolution of Product Discovery Practices
04:05 Understanding Continuous Discovery Habits
07:10 Myths and Misconceptions in Product Discovery
09:56 The Curse of Knowledge in Product Teams
13:58 Decision-Making Patterns in Product Discovery
21:10 The Opportunity Solution Tree Framework
25:10 Creating Shared Context for Teams
26:36 Common Mistakes in Opportunity Solution Trees
29:48 The Importance of Customer Context
31:41 Deep Work and Thoughtful Product Decisions
34:36 Exposing Reality to C-Level Executives
37:20 Evolving Product Discovery Practices
40:32 The Challenge of Accessing Data
45:18 Resources for Continuous Discovery


#productmanagement  #productstrategy #podcast #productmanager