Continuous Discovery Habits: Teresa Torres on Customer Insight, Product Tríos, and Outcome-Driven Teams

[Music] Welcome to Leopardcast on Emerging Leadership, am your host, Alexi Movin. Today, I'm excited to speak with Theresa Torres, author of the Infraential Book, Continuous Discovery Habits. Theresa helps product teams add up habits that enable them to uncover customer insights continuously, ultimately building better products. Through our blog, product.org, and extensive coaching, Theresa has reshaped our companies, think about product management and customer discovery. In today's conversation, we'll explore our teams can integrate discovery into their daily routines, make more informed decisions, and consistently create valuable outcomes for their customers. [Music] Welcome to us, Anne. How do you typically introduce yourself to someone you just met? Ah, that's a great question. As far as from a work standpoint, it's always a little bit of a challenge. There's a lot of jargon in our industry, so for folks that are familiar with discovery, I introduce myself as a product discovery coach. For folks that are not familiar with those terms, which is quite a few of us, I say that I help teams that are building digital products to make better decisions about what to build. Okay, I really like that. So how did your journey led you to write the book? Yeah, this is a big one. It took a long time for me to write the book. People ask me, like, how did your book do so well? And I say, well, I let demand build up for a really long time. [Laughs] And it wasn't intentional. So it really goes back to 2016. So in 2016, I was several years into working as a discovery coach. I've been working with dozens of teams. Really just looking at, like, how do they build fast feedback loops as they make decisions about what to build? So are they interviewing customers? Are they testing their ideas? And I mentioned 2016 because I was working with the team and they said, they came to the coaching session. And they said, "Trisa, we really love our sessions, but we're afraid we won't know what to do when you're not here." And that really landed with me because here's the thing. I decided to work as a coach and not a consultant because I want to leave people better off. I want to empower people to do this on their own. I didn't want to build a dependency. So this feedback from this team was a little bit gut-runching for me. And I sat down and I started to think about, like, how am I making decisions about what to do next in discovery? And this was not the first time I had this thought for probably five or six years prior to this, especially working with engineers and working with product teams. Trying to think about, like, what do I hold in my head that my peers don't? That's like keeping us from being aligned. And around the same time I was reading Anders Erickson's book, "Peak," which is all about expertise and deliberate practice and what distinguishes experts from novices. And one of the ideas in the book is this idea of experts have mental representations that are different from what novices have. And this was exactly the insight I needed. I was like, "Okay, what is the mental representation I have in my head about discovery that the teams that I'm coaching don't?" And that's what led to the opportunity solution tree. So for listeners who aren't familiar with this, an opportunity solution tree is just a really simple visual decision tree where the team's outcome is at the top. As they talk to customers, they learn about customer needs, paint points and desires. Those are opportunities. They literally map them on the tree. And then they're looking for what solutions match one to one to those opportunities. And so it's really simple, but what it does is it gives you a visual cue for, like, "Do I know enough about my customer? Does my opportunity space look rich?" And detailed, "Am I actually working on a solution that solves someone's problem in a way that drives their outcome?" And so it was in, I think August of 2016, I introduced this visual to this team for the first time. And it had a huge impact right away, like a right away. And I was like, "Oh, this is a thing. Like, I'm a product person. I know that things don't have a huge impact right away." And so when it did, I was like, "There's something here. This is my very long way of answering your question, which is I was like, "I have to write a book about this." And I started trying to write that book in 2016, but I struggled because books are waterfall. You write the whole book and you release it and hopes people like it. And I refused to operate that way. And so it took me several years to figure out, like, "How do I test the content in the book? How do I know that it's going to be good? How do I know that it's going to be actionable?" And so I spent several years taking all my discovery knowledge, codifying it into online courses, watching students engage with it in both my coaching practice and in my online courses. And then once I felt like it was clear enough and good enough, I wrote the book. Excellent. This is very interesting because I've heard a lot of people saying, "Oh, yeah, we build up a training course because the book was successful, so people wanted to buy training from this." Okay. I went the other way around because I needed a feedback loop. I needed to know what was clear, what was confusing, where did people get stuck. And then I think it really comes out in the book. Like every chapter ends with anti-patterns, like those came from real coaching sessions and real course students. All the activities in the book are things we do in our courses, so they've been vetted and tested with, I mean, at this point, hundreds of teams. So maybe the real answer to how did the book do so well is that I tested all of the content like crazy. But I will say, like in 2016, I said I was going to write a book. And so for five years, people said, "Where's your book?" And I've learned to not put timelines on things, so they had to just keep waiting. Yeah, that's good. I've been terrible to have a kind of a deadline that forces you to publish something that's not good. Early on, you introduced the idea of the product trio. And could you explain why this trio is essential and how those roles effectively collaborate? You know what's funny is that I didn't create this idea. Like this idea has been around for a long time. In the Agile world, they often talked about the three-legged stool or the three amigos. I think the reason why people attribute this idea to me, I did include it in the book, but I also just gave it simple language. So I heard a lot of people talking about like triads. And I remember the first time I heard that word, I was like, "What's a triad?" And so I called it a product trio, and that's because I just really think that language matters. I mean, I've introduced my own terrible language. The opportunity solution tree is a terrible name. So like, I'm not critical of this, but like I tried really hard with this idea of a product trio to just simplify the language. And I think it has helped because it's now a much more popular and much more common idea. It's this idea of how do we cross-functional and how do we really collaborate from the very beginning? And it sounds so simple, but in business, we're really bad at cross-functional collaboration. And we see it up and down the organization. It's why like so many executive teams are dysfunctional, because we don't know how to cross-functionally collaborate. In a lot of ways, business culture rewards us for staying in our silo and like being territorial. But I think we have enough years of experience now, like across the industry to recognize that if we're going to build a good digital product that's always evolving and always improving and always getting better, it really does take a cross-functional mindset. So we need to keep the business perspective and viability in mind. Do we need to keep the customer, of course, in mind? And how do we make it delightful for the customer and how do we make it usable for the customer and how do we make sure that we're building something that satisfies a real need and not just like an aspirational need? It has to be feasible. And you know, for a long time on the internet, feasible was easy. We were just building crud apps. People aren't familiar with that term. It's just like things where you create and update things and delete things. Like it's not really simple, like web pages are just front-ends to databases. Like there wasn't a lot of feasibility complexity. Well, today we're seeing a lot of that change, because generative AI is forcing a lot of teams to debate and discuss what's feasible with this new technology. And so we can define this as roles, like for most companies, a typical product trio is a product manager, a designer, and a software engineer. But it's not that clean. And actually, I think generative AI is making this even messier. We have a lot of designers that have a good human centered, like research background, and they want to be involved in the decisions about what to build. We have a lot of product managers that have MBAs and maybe they're weak on the usability or the desire ability side, but they're really strong on the viability side. We have a lot of product managers that are the complete opposite. Maybe they came from a UX background. Maybe they're just grew up in a consumer product world and they've never had to think about viability. We see the same with engineers. Everybody has worked with that engineer that just had a really good intuitive product mindset or a lot of our front-end engineers have good design skills. So I think it's easy to think about this as fixed roles, but I think the underlying principle is, we need a wide variety of skills to build a successful product. How do we get the right people in the room to make sure all of them are good? all those skills and perspectives are represented. And so what we used to do is we used to silo it, right? The product manager wrote requirements that got handed to the designer, who did the design work, it all got handed to the engineer. And the problem with this is there was a ton of rework. By the time it gets to the engineer, they're like, "This isn't feasible," right? And we have to start over and start, it's like the assembly line gets reset. Whereas I think when we see these roles working together from the beginning, we get much better solutions and we get them faster. It's kind of counterintuitive. - So what are the common challenges team face when adopting the continuous discovery had it? - How long do we have? I mean since we were just talking to team collaboration, I'm gonna say this is a big one. Of course we all wanna be on a team and we're gonna work together. It's really hard. We've been trained to be territorial. Generative AI is gonna make this worse. I've been building my first generative AI product. And it's, I'm starting to learn myself about like, what does it take to make these products good? So I'm starting for people familiar with this process. I'm starting to get into the world of like e-vals and guard rails and like how do we evaluate the success of a non-deterministic product? And that's a challenging question. And this is all like frontier. We're all figuring it out together. Well it turns out like the methods that are starting to arise to evaluate these tools are like required domain expertise that your product manager, your designer, or even your business stakeholders might have. And it requires engineering expertise to like know what's possible with code and how to code up these automated evaluations. And it requires like a continuous process of both. And there's a lot of conversations in this space around who does what does the engineer do this part? Does the product manager do this part? And it's messy. And I think the answer is going to be the person closest to the customer is going to do one part. The person that has the necessary engineering skills might do another part. But who that is from a roll standpoint might change from team to team. Right? So like for myself personally, I've actually spanned all three roles. I started out as an interaction designer and a front-end web developer. I moved into product management. I spent most of my careers a product manager and a product leader. But in the last three years, I've moved back into coding. And in the last month as I've been building this AI product, I took this course on AI eVALs. And I am doing the work of an AI engineer. I just learned. Like I literally implemented my first set of automated eVALs. And I did it in a language I had never programmed in. And I did it in a tool I had never used before. And I did it all in one week. And the reason why that was possible is because ChatGPT guided me through all of it. So like these boundaries are blurring. Like designers can now code and product managers can design. And engineers are going to have to learn some design skills and some product management skills. The product trio concept, like the underlying principle, cross-functional collaboration, stays. I don't think it's going anywhere. But these really clean boundaries we have between our roles, they're getting obliterated. And it's hard for people. We identify with our jobs. Designers identify as designers. Product people identify as product people. Engineers definitely identify as engineers. And those identities are going to get stretched and blurred. And it's going to cause some discomfort for people. So I think that's the first thing. I think like we already see this just with the discovery habits. Forget AI, already with the discovery habits. Collaboration is hard. I think it's going to get a lot harder. It's going to get a lot blurrier and messier. But I actually think that makes it more fun. I like spanning boundaries. I think most people like spanning boundaries. I think there's real organizational challenges. Like our leaders have grown up in a world where they get to tell us what to do. And when we're empowering our teams, they have to learn different ways to have oversight and management without dictating outputs. I think that's hard. Like leaders have to learn how to do that. And then product teams have to learn how to show their work. So their leaders trust their making progress. That's a huge barrier on both sides. Some companies think there's a significant barrier in getting access to customers. In my experience, this is more mental roadblocks. This is more like forms of resistance than it is tangible real barriers to customers. And I'm going to say that even in regulated industries. So all my folks working in regulated industries want to say we have all these rules. Those are just constraints. It's still possible. There are people in every industry doing this. But I would say those are the top three. Like how do we really work as a team? How does the leader team interaction change? And then how do we get over our mental resistance to actually talking to customers? It's very interesting because while you were talking, I was thinking of a team I'm working with. And they are in regulated industry, in the healthcare industry, of course. And they have a lot of good reasons for not being able to do things, which is very interesting. Because when you look crazy in details into it, you realize that maybe you can do a little bit more of that. You know what? Healthcare's a great example. So here in the US, we have a law, HIPAA. It's our healthcare privacy law. Here's the basis of the law. It says that if I tell you my doctor something, you can't go share that with other people. Like it's my privacy. I have a right to privacy in the healthcare ecosystem. Okay, so now you're a product manager working on a healthcare product. That law doesn't say I can't willingly share my healthcare experience with you. It doesn't say that. That's not what the law says, right? But teams interpret it as we have to be HIPAA client. We're not allowed to talk to our customers, right? And so a lot of this is like, yes, we have to understand our regional laws. Yes, we have to understand our company policies. And especially for a lot of HIPAA compliant companies, they have policies that say you can't talk to customers 'cause they don't wanna train them on the HIPAA requirements. So like those are constraints we have to work within, but it doesn't mean somebody who's willing to share their experience with you can't share their experience with you. I've never seen a law that restricted that yet. - I have a question about product managers who struggle to really understand the value of user experience of UX work, especially in that context of the discovery process. What are the misconceptions that you see there? - When it comes to UX, I actually see two extremes that I think both are wrong. So one extreme is, our engineers can just build it. We're not reinventing the wheel. We have a design library that can just throw together some components. We don't need a designer on this. The other extreme is we need a designer on everything. Everything needs to be delightful and perfect. I actually think both are completely wrong. Like most things probably need a designer to at least glance at it, but we don't need every single part of our product to be delightful. And if that was our requirement, we probably would never ship a product. And we see this, like look at the most design-oriented company on the planet. I'm gonna say is Apple, whether you like their design or not, like they're clearly a company committed to design. - Mm-hmm. - There are lots of parts of their website that are horrendous to use. This is true for any product. In fact, I get frustrated with my iPhone on a regular basis. It is impossible to create a perfectly designed product. Now that doesn't mean we shouldn't aspire to that. What it means is that like we have to make prioritization decisions, what are the parts of the customer journey that are most important to get right? What are the moments in the journey where delight matters the most, right? Where can we just not reinvent the wheel and use a common pattern? And so I think it's, I see it with UXers in particular. We go to design school, we learn about the delightfulness of design, and we admire these beautiful products. And we take that and we try to apply it to everything. And like digital products have big footprints, they're constantly changing. It's just not realistic. And then people that haven't been exposed to this design world take it the other way around. Like I still meet companies that have 20 product managers and zero designers. And I'm like, how is this still happening, right? And it's 'cause they just have this belief of like, "Oh, it's just colors on a website and I got a design palette. I paid a agency to give me a design palette. And my engineers can just apply it." Okay, well, you're overlooking information architecture and interaction design. And like all these other elements of design practice and not to mention like your engineers probably don't know how to design that design palette, that color palette in a way that is good visual design. And so I think it's especially if you read like the internet at all, social media in particular, like it's really easy to think the world is these extremes. Whereas I think in almost everything, the right response is somewhere in the middle. It's much more nuanced. But nuance doesn't went on social media. So it's not what we read about. - Unfortunately, I would love that to be more nuanced. We would all learn in the process. You want further as weekly customer interviews. - Yeah. - And the first time I discussed that with the product team, they were puzzled. They are in their mind really a process that seems radically different from that. - Yeah. - So far away for them to even think about it. And the woo would do it was also a concern, which was kind of funny. So you have a very strong opinion on that. And I really love it to hear what you have to say on that. - Yeah. So first of all, let's talk about why I recommend this. and we can get into how continuous there. So the big thing here, for me discovery is about if we want to make good decisions about what to build, we have to get feedback on those decisions, right? Like we have so many examples of products where the people that designed them or built them did not get feedback along the way and they flopped or maybe they didn't flop. Like maybe they had the right idea for a right moment and they took off but they didn't sustain. Clubhouse comes to mind if you remember Clubhouse. Like the beginning of the pandemic it was this like audio, go in a room, chat with people, it was wildly popular for like three months and then it just peed or no, right? We see a lot of products like this and I think some early success can sometimes be problematic, right? Like where we don't get over the crossing the chasm hump, we don't get past the early adopters. And so we got to be really careful about who are we designing for, who are we building for and what are their needs and how many people out there are like those people, right? So this is starting with the ideal customer profile, really understanding the market size, really digging in and understanding what are the needs they care about and are we adequately solving those needs? And that's like the big picture, that's like the strategic stuff. But then, okay, so we've identified there's this need. I'll many stick with Clubhouse as my example, like people are all stuck at home and they want to connect with other people. Okay, great. That is a real need in that moment. It definitely was a real need. But now we need to get into like, okay, as we build this product, we have daily decisions about how it should work. How do we promote what's happening in a room, who's allowed to come in? How many people are allowed to talk at the same time? What happens when people say offensive things? How are we going to handle that? All these things that arise, we make millions of decisions, like constantly all day long everybody on your product team is making decisions. Where's the feedback loop for all those decisions? And when I say feedback loop, I don't mean like I can't change this one line of code until I get feedback from a customer. I mean, we need to have constant exposure to who we're building for to make sure all these teeny tiny decisions work for them. And if we don't have that constant exposure, we're just like in a dark room looking for a teeny tiny thing on the floor. Like we're lucky if we find it. And so the why behind this is the more we talk to our customers, the more we engage with them, the more exposure we have to them, the more likely these teeny tiny decisions are going to work for them. And so if I talk to a customer once a month, that's better than never. But I'm making decisions all day every day. So the more exposure I have, the more likely those all day, everyday decisions are going to fit. And here's the thing. Too many teams use their customer interviews to walk in and say, Hey, here's my shiny solution. I'm working on what do you think? That's not the purpose of these interviews. When I say talk to your customers every week, it's not go sell to your customer every week. It's not go show off your shiny object every week. It's go talk to your customer and learn about their world. Who are they? What are they doing? What are their goals? What are the stories in which those? What are they doing? Why? Collect those stories. Your goal is to understand your customer's mental model of how they approach whatever it is they're trying to accomplish. So if I work at Spotify, I'm going to interview people about the role music plays in their life when they listen to it, where they listen to it, how they're listening to it, where they learn about new music. And I'm going to collect lots and lots of stories about how they engage with music. It's not going to tell me what product to build. It's going to tell me how my customers' mental model of music works. And then my job is to make sure my product matches that mental model. And so all those hundreds of decisions I'm making every day have to be consistent with that mental model. If they're not consistent, it's not going to work for my customer. So it's not that I have to get feedback on every single decision that I make. It's that I have to build a mental model that matches my customer's mental model. And that mental model tells me how to make all those daily decisions. That leads us to the how and who are doing. Who are doing. Okay, so that's the why. So let's get into the how. What I tell people is we get to take a continuous improvement mindset to our own discovery habits. So if you've never talked to a customer, forget that I told you once a week, just go talk to one customer, like just find the first person to talk to. And I don't mean like go join a sales call. I mean talk to a customer about their world, their goals, their context, their stories, not your product, their stories. Once you've done that, I want you to think about how do I talk to my second customer. And then by the time you've talked to two or three, I don't need to convince you you should do it more. You're already convinced you should do it more because so much magic happens in those first couple of conversations. So like if you've like for people listening, if you've literally never talked to a customer about their world. So I don't mean your product. I don't mean a sales call. I don't mean handling a support ticket. I mean, just literally talking to another human and being curious about how they do whatever your problem is, whatever your product is designed to solve. That's it. Just how do you do this thing? After you get it two or three, now you're like wow, this is mind-blowingly amazing. And we need to start to think about how do we operationalize it. So how do we do this on a regular basis? We have to create a continuous pipeline of people to talk to. I recommend people automate the recruiting process. I share tips on how to do this in the book. We also have a course on customer recruiting that shares five different strategies on how to automate your recruiting process with lots and lots of examples. And then you have to learn how to ask the right questions. So how do you make sure you're getting a reliable feedback? We teach a very simple interviewing format focused on collecting customer stories. The reason why I do that is I think any human on the planet can learn how to do it. It's evidence-based. It's grounded in good qualitative research practices. And it solves this problem of like how do I build a mental model that matches my customers? Right? So it doesn't answer every research question you might ever have. We probably still want researchers involved in other types of research. But it allows a product team to close the gap. How do I make sure the decisions I'm making every day match the mental model of my customer? And then once you've worked on your pipeline of interview participant problems, you're starting to practice asking better interview questions. Now you can look at your cadence. If you're talking to someone once a month, try to get to every three weeks, then try to get to every two weeks. I use the guideline of once a week. I think that's our minimum. We definitely like with it. We want to aspire to. Plenty of teams do multiple week. Plenty of teams do every day. Yeah. And I assume that product managers and probably UX people would probably be comfortable discussing with customers or discussing with these real users. Our engineers on the team would benefit from doing it. Yeah. I want every single person who's involved building the product to at least be listening to the conversations. What you're going to find is the more people on your team listen to the conversations, the more they're going to want to get involved in the conversations. But I think you can start with. You can have the person on your team who's most comfortable conducting interviews, conduct the interview and have everybody else observe or watch the video afterwards. But not clips, not just read the transcript, not just read the notes, see the participant share their story. And then I think with time, it does make sense to have multiple people on the team comfortable conducting interviews. It just helps with the resiliency of the habit. If you have a product manager who does all the interviews and then they leave the company, what happens to your team? They go on vacation. You go two weeks without anybody conducting interviews. They're sick unexpectedly. Who's going to conduct today's interview? So the more people comfortable with it, the more resilient the habit is. But really, I want everybody watching the interviews, including our engineers. Yeah. You can see that I'm trying to find the arguments to convince people that it's very, very important. Yeah. And they are all making decisions. And hopefully, as a team, more often than not. And as we are involved in those decisions, having that mental model is critical. So that's an important one. You mentioned the opportunity solution three before. Really beautiful name. Do you have a concrete example to work us through what it is? Really, but with an example, not just saying us what it is. Yeah. So in the book, I use streaming entertainment as my example. And that's because it's available worldwide. Netflix is everywhere. We're broadly familiar with it. Yeah. So let's talk about a tree. The purpose of an opportunity solution tree is to help you as a cross functional team drive an outcome and to stay aligned in your discovery work as you drive that outcome. So the challenge is when we shift from focusing on just building outputs to trying to impact a metric. So driving an outcome, it's messy. We have a lot of false starts. We do a lot of things that don't work. We do some things that do work. We learn a lot from our interviews. It can feel really overwhelming of what do we pay attention to? What do we not pay attention to? As we get into solutions, it's really easy to fall prey to like shiny object syndrome. And we end up working with solutions that don't actually match it. anything we heard in our interview, it just was like a cool application in a new technology. We're seeing a lot of that right now. Right, so the goal with the opportunity solution tree is like how do we keep everybody aligned and how do we help them know what to do when? So when a team is new to driving outcomes, what they don't realize is the whole nature of their job changes. So when we're told to build a thing, it's very deterministic, like it's very narrowly defined. Like yes, there's a lot of decisions to make about the requirements for that thing and how to implement it in the underlying data model. And those decisions all matter. I'm not trivializing them. But what to do has been clearly defined. When you're starting with an outcome, what to do, it feels like a blank page problem. It feels like we could do a hundred thousand things, how are we gonna decide? Is this very open ended ill-defined problem? What I recommend teams do is they start by interviewing customers, they're collecting stories. One of the things they hear in their stories is pain points, friction, unmet needs, does unsatisfied desires, right? So as they collect stories, they're hearing about things that they could help. So those are opportunities. And so the team maps out the opportunities. And then they're gonna choose the opportunity to solve. So let me give the example using Netflix. I'm starting with an outcome and outcome represents a business need. They're typically derived from your revenue model. So Netflix is a subscription business. The types of outcomes they're gonna care about, acquiring more customers, increasing their average monthly spend, increasing how long they stick around. So retention, lifetime value, right? Those are the primary drivers of what drives revenue for Netflix. Now each of those I can further deconstruct. Like let's say I have a team that's focused on retention. Okay, well what are the factors that drive retention? This is almost always tied to the value your product delivers. So what does Netflix deliver from a value standpoint? Well they entertain me. Okay, well how do I know that you're being entertained? Well you might watch Netflix more often. So maybe my outcome is to increase the average viewing minutes per week. Okay, that's my outcome at the top of my tree. Now I, this is, I'm new to this outcome. I don't know why you watch Netflix or how you decide how much to watch or what prevents you from watching more. So I have to go interview customers. And as I interview customers, I'm gonna just collect their story. Tell me about the last time you watch Netflix or tell me about the last time you watch TV. Maybe you're watching a competitive service. And as I collect those stories, I'm gonna hear things like, it took 45 minutes to find a show that I might like. Or my friend recommended this show and I'm checking it out, but I can't tell if I'm gonna like it or not. Or we might hear stories like, I'm in the middle of watching this TV series, but I can't figure out how to get back to it. Or we might hear things like, I was in a hotel on a really terrible Wi-Fi network and it took like seven minutes for the show to load and it paused 14 times during my 30 minute episode and it was a really terrible experience. This is what comes from real world stories, right? So now I can collect those as opportunities on my tree. And I, what I recommend is that people organize their opportunities based on steps in the journey. So the top level of the tree might be, I need to find something to watch. I wanna have a good viewing experience. I don't wanna stay up too late. It's like I wanna go to bed on time, right? And then under I can't find something to watch. I need to find something to watch. We might uncover all these pain points like, I can't find the show I was watching. I can't tell if the show is good or not. I just finished my show like I want a similar show. I wanna know who's in this show, right? These are all opportunities. Just like what does your customer need to be able to find something to watch? And then around the viewing experience, like what do they need for it to be a good viewing experience? Well, they don't wanna wait for it to buffer forever or they wanna be able to rewind quickly and find what they're looking for or they need to be able to pause to go get another beer. Like whatever it is, right? This is what emerges from real stories. So then we collect all these on this visual and we organize them based on steps in the journey. We structure them, some are sub parts of others. And then we get to decide, like we've taken an inventory of what we're hearing across our interviews and now we can make a strategic decision. Like where do we wanna play? Which of these opportunities are most important for us to solve? And this sounds so obvious and trivial, but like what do most teams do? They're reacting to the most recent conversation they heard. Stay cold or pulls them into a customer conversation. Somebody has a pain point. They're like, all hands on deck, let's solve that right now. There's, we're missing this strategic decision about where do we wanna play. And the thing is, the opportunity space is infinite. Like there's a million needs and pain points and desires that are unmet when we talk to customers. We really need to make the strategic decision of what differentiates us in the market, what supports our company's strategic initiatives. We can't do all of this stuff. And so that's a lot of what we get with the opportunity. Solution Tree is it gives us a place to collect all that we're hearing. And it helps with this like overwhelm. We've talked to so many customers, they have so many needs, where do we play? Well, we filter based on our outcome. We make that strategic decision about what has it impact for us as a team. And then we choose a small starting place. And then that bounds the types of solutions we consider. And then we test is our proposed solution and we're gonna actually address that opportunity in a way that's gonna drive that outcome. And then we are able to experiment and really test all our hypothesis. I love it. Oh, thank you very much. That was perfect, quite impressive. You mentioned the importance of outcome and versus outputs and the roles of leaders in changing their language and are changing what they believe they have to do. Do you see other things about the roles of leaders in that way, different ways of working? Yeah, so the first thing I'll say is we've seen three major world events, two major world events that everybody has been subject to and maybe in a third, depending on where you live in the world, that I think is finally teaching organizations that we need to be outcome focused. So the first was COVID, the entire world shut down very quickly. Everybody worked from home, the way we worked changed suddenly. So what does this mean? It means that you could look at your roadmap and you probably had to throw a lot of it away. You probably had to change a lot of it. If you were Zoom, you had to react to a huge new market opportunity. If you were building software for restaurants, you probably lost a lot of customers very quickly, right? Like we all just suddenly had to like adapt. (chuckles) Okay, second major world event, the rise of generative AI. Like we're all going through this right now. Like what does this new technology do for me? How does it work? It's disrupting everybody's road. Like literally everybody's road maps. Third one, and this is really regional, but I think it's affecting a lot more people than we realize is just all the geopolitical climate, right? Whether we're talking about the Russia Ukraine war, now we have Israel Iran, we have our craziness with tariffs affecting the global economic environment, right? There's been like so much geopolitical craziness for lack of a better word that I think companies are really struggling with how do we predict the year? And so I think the combination of all three of these things, and they've basically been back to back to back. I think leaders are starting to recognize. Like we've all set it for decades, right? Like there's all these acronyms in the business literature about like ambiguity and uncertainty, and there's frameworks, but like companies don't work this way. They still come up with five year strategic plans, and they still want 12 month road maps, and they want to know exactly what you're doing when we still operate businesses as if the future is predictable. But I think we're starting to see some cracks in this. I think we've had so much uncertainty and so much chaos and so much craziness over the last five years. The companies are like, okay, like I'm tapping out. Like we're no longer planning five years in advance because I can barely plan next month. I think this is a good thing. This is I think is the silver lining of all of the nonsense that we've been through, is that companies are starting to see we absolutely have to learn how to be adaptable. But it's a whole new skill set across the organization. Like how does my CFO plan if we didn't fund projects for the year? How does my marketing team run marketing campaigns if they don't know launch dates? How does my sales team close deals if they can't say when features are coming? Like literally everybody in the organization has to change the way that they work. And this is why we now have books on transformations and we have billion dollar consultancies on transformations. And we have, you write? And we have like hundreds of solo consultants supporting transformations. Like this is a giant shift for businesses and we don't know how to do it yet. I'll be the first to say we don't know how to do it yet. Like it's still a work in progress. We're still feeling our way through it. But here's what I know from an organizational change standpoint and from a coaching standpoint. Nothing changes until the mindset changes until people believe there's a need for the change. I think what's happened in the last five years is we're starting to believe there's a need for the change. So I'm excited about that. Like I'm not excited we had to go through COVID. I am excited about generaVI. I'm not excited about the geopolitical stuff. So mixed bag, but I am excited that we are starting to see evidence that we have. companies are taking this seriously. - Yeah, that's a strong belief that could help us in getting to that desire to be more adaptable. And yeah, I really love it. I remember discussing about beyond the jetting and being absolutely convinced and bought is incredible. And I was going back to my organization explaining why we needed to get it right thing. And no, nope. (laughing) - That was not so easy to convince all the people. - Yeah, one of my mantras this year is really around organizational change doesn't happen as a big change. It happens through a series of teeny tiny changes. So I like to tell people, don't try to change your organization, just change your own habits. Don't try to change all your habits at once, pick one habit, adopt it, internalize it, make it the way that you work, then move on to the next habit. And it turns out when we focus on our own behavior, when we change our own habits, people around us get curious, hey, you're doing this thing, that's really interesting. What is it that you're doing? And now we have an invitation to share. When we come in and say, hey, I learned this new thing, we're doing everything wrong. What do people do? They dig their heels in, they say, no way. I'm stubborn. That I hate frameworks. Influencers don't know anything. You can't read anything, you can't learn anything from books. You just learn by doing product management is different everywhere. We've all heard these things, right? Absolutely. Yeah, so it's really like, you almost have to be sneaky about organizational change. And like, the hard truth is it starts with yourself. Nobody wants to peer through the problem, right? So like the only way to drive change, I think, is to start with your own behavior and model what you want to see across the rest of the organization. I love it. I believe we should end on that. That's how that was a perfect closure. What do you think? Do you want to share anything else about what you are currently working on you, who give us a glimpse or about anything else? Yeah, I'll share. So if any listeners are new to my work, I do blog at productalk.org. And the book is called Continuous Discovery Habits. I'm assuming we'll add links to those in the show notes. Yep. The other thing I'll share, so I've done a ton of work over the last, we're almost coming up on 15 years, which is crazy to me. About discovery, how to do discovery well, how to build fast feedback loops to your customers. I love all of it. I'm not done. There's still more work to do. There's still plenty of teams not doing discovery. But in this exact moment in time, like for the last four months, I've been diving deep on how to use generative AI to support teaching. So I've been building my first LM-based apps, which has been really fun, and we're already using some of them in our courses. But it also introduced me to this whole new world of how product management is changing when the product that we're building is non-deterministic. And how do we measure quality when the product is non-deterministic? And I'm any blogging way more about this. So like in July, I have a blog post coming out about what role AI prototyping can plan discovery. I'll be doing a blog post about what role, like how cross-functional teams should be doing e-values and guardrails for LM-based apps, and how to navigate that, 'cause it's really not clear who does what. And I probably will do be doing a blog post about how our roles are blending even more than they already have, and how we need to mentally prepare for that. Like if we really identify as one role, how to maybe start to adopt an identity of other roles and build out your toolkit, your skill box, and maybe have that be your focus? So I think we're all going through a ton of change because of the gender of AI. And I've been reluctant to write about this stuff 'cause it changes so fast, but I think after four months of like building with it, I'm starting to develop a point of view and I'll be sharing much more about that at producttalk. It's not a work. - Excellent. I am here to read about that. Thank you very much for all the work you're doing. It's absolutely fantastic. And thank you for having joined the podcast today. - Oh, thanks for having me. This was a fun conversation. (upbeat music)