High Performance Leadership Series #5 - Teresa Torres

Hello, I'm Derek Smith and welcome to the next in the High Performance Leadership Series. I'm the Chief Product Officer at the Aberdeen Group and I'll be the interviewer today, helping interview Teresa Torres. So I'm delighted to welcome Teresa to the show. For the next 45 minutes, Teresa will share her experience, insights and passion about how you can build high-performing product teams and organisations. and specifically her work on the art and science of product discovery and how this can be embedded in habits through a company and through her writing and coaches on continuous discovery habits, which she can help us learn. In terms of the flow of the discussion, we'll start with a brief outline from Teresa on her inspiration for the book and the coaching, how she's seen that evolve, and then we'll get into more of the kind of thorny and more interesting questions on the detail on continuous discovery. and how our thinking's evolved as she's worked with companies, now products and markets have evolved. So Teresa, to get us started, what is continuous discovery and what inspired you to focus on it? Yeah, I like to keep things really simple. So first I'll say discovery is just the work we're doing when we're deciding what to build. And continuous discovery is looking at how do we build continuous feedback loops into our work. So continuous feedback loops with our customers. So as we make decisions about what to build, can we get feedback along the way to know that those decisions are actually going to work for our customers? And then there's a lot of kind of tactics and habits that are now associated with continuous discovery. So that could be anything from interviewing and assumption testing. There's a lot of sub components to each of those habits, starting with outcomes, experience mapping. We could get into all those details if desired. And then why did I focus here? You know, early on in my career, I got introduced to human-centered design and I just really naively thought that's how business worked. And when I saw that there's a huge gap between how I thought the world worked and how the world actually worked. And I just probably about 12 or 15 years into my career, I just decided that was the problem worth solving. And I really have just been motivated to try to close that gap, help more teams get feedback continuously. Because I just genuinely believe that it leads to better products for the consumer or even in the B2B world. And I think it also leads to happier product teams. So I just think it's a worthwhile pursuit. Great. And in the book and in your coaching, you often mention the power. and the challenge of creating truly powerful product trios. How do you coach teams to truly collaborate as a trio? And then do you see that distinction blending with the introduction of AI, the tooling and how that product discovery process works? This idea of what is a product squad, like the cross-functional product team look like is always evolving. I know when I started my career. Nowhere I worked had enough designers. There is definitely not a trio. Maybe there was a duo. We've certainly gotten much better at that. And we now have a lot more teams that have dedicated designers. Although I just talked to a company today where their ratio was 10 to two. So they still have a long ways. We're not there yet, right? And then as there's been different trends in the industry, we see additional roles get added. A lot of data heavy products of data analysts. Some companies have the luxury of investing in a lot of user researchers, and they might be embedded in the trio. So I actually have a regret of... When I wrote the book, there were a lot of labels for this concept. I think the agile folks used to refer to the three amigos, the three-legged stool. People started calling it a triad, which I don't love complicated language when we have simpler language. And so when I wrote the book, I was trying to simplify it like it's just a trio of people. The challenge with calling it a trio is that it's not always three people. It's not always the exact roles. It really is flexible. So I think the most common form and why we do call it a trio is it's most commonly a product manager, a designer, and an engineer. But I've seen trios and I'm going to put trio in quote. in all sorts of flavors. I've seen quads, I've seen quints. I think once you're more than five it's getting a little too big. I've seen duos where maybe the product manager has a design mindset or even the front-end engineer who's the lead engineer has a design mindset. I've seen designers who build their own designs and so sometimes they usually need some back-end support but sometimes There's lots of instances where a single person could play dual rules. And I actually did this early in my career. I was both a front-end developer and a designer in my first job. And then in my second job, I was both a designer and a product manager. And I think at smaller companies, that's really common. So it's not a rigid concept. I also think with the rise of LLM-based products, we're seeing a lot of the roles. even change. And so before I get into that, I want to talk about the main idea here. Regardless if it's a trio or a quad, the main idea here is how do we get the people that we need to make a good product to collaborate from the very beginning? And this is really the idea behind a trio, right? We used to not collaborate from the beginning. We would work in our silos and hand things off. And I think there's power in collaborating from the very beginning because we want people in the room that represent usability and viability and desirability and feasibility, right? There's all these risks involved in building a product and we want a team that represents those risks. Okay, well with AI, actually we're seeing the roles change a little bit. Designers can actually implement a lot of their designs now with these prototyping tools that are getting better and better every day. So whether we're talking about Cursor or Windsurf or Lovable or Bolt or Replet. And then, so that's one area that's blurring. We're seeing more product managers be able to direct design with these same tools. We're seeing engineers being able to build way faster. But I actually think the more interesting thing is we're seeing the nature of building good products changes when the product is LLM based. So to build a good LLM product, Now, nothing is deterministic. Output is probabilistic. How do we evaluate a probabilistic product? And this is introducing a new skill set of error analysis, which is really rooted in traditional research methods, evals. And if folks are not familiar with this world, that's okay. Just know that building LLM products is pretty different and that there's some new skills involved. um a lot of error analysis and eval writing and as to the automation of evals spans what a product manager would do what a designer might do what an engineer might do and so i think we're seeing the way these roles collaborate is constantly shifting and changing yeah and i think that from like i'm working with some of your team before i think so even the fundamentals are just in that the perceptions of different minds and how they work especially when you're doing divergent thinking is really important i think that came to life with me of whether it's a trio or multiple people it's not being able to look at visual thinkers written thinkers coders and designers all those different competencies really help you when you're at the start and that's what we're a way to come on to outcomes i think it's that piece of not getting focused on the solution early but allowing that disruptive thinking find that shone through for me. So moving on to that, when you start, lots of you're talking about the start of the problem and start with the outcome in mind, why is that so critical when you're at the start of a discovery process? I think this is a really old idea. In fact, I could attribute it all the way back to Stephen Covey's The Seven Habits of Highly Effective Teams. Highly Effective People, I think is the name of the book. One of the habits he talks about is begin with the end in mind, right? Which is start with where are you trying to get? And it sounds so obvious, but we forget to do it, right? We get sort of mired in starting to do the work that we forget what the end goal is. And if we're not all aligned on the end goal, we're going to take steps in different directions. So primarily we're starting with an outcome to stay aligned as a team. but also to make sure that we're aligning what are often competing forces in a business. So we tend to have our senior leaders that are usually operating at a business level, looking at kind of financial metrics, they're looking at the overall health of the business. And then we have product teams that are operating. maybe more at the customer level and interacting with customers. And in that perfect world, those things are aligned. We create value for the business by creating value for the customer. But we all know in practice, they're not always perfectly aligned and they can be at odds. And we see teams making trade-offs between, well, this would be best for the business, but it's not great for the customer. And so I think a lot of the work that we do in discovery and starting with an outcome is making sure that we're all aligned on where we're headed. that where we're headed is going to create value for the customer in a way that's going to create value for the business so we can alleviate as much of that tension as possible. How do you see that best working? You talked about an output revenue potential leading indicator on business value and then customer outcomes. How do you see that best working in hypothesis driven testing and the outcomes where you're linking? customer value, customer problems to solve and business value at scale. What methods do you use to connect them together or do you link other methods into your process? Yeah. So in the book, I introduced a distinction between business outcomes and product outcomes. Some people do refer to product outcomes as customer outcomes, and that actually might be a better label for it because a business outcome are sort of our traditional financial metrics. right? Are we growing revenue? Are we reducing costs? Really we're focused on driving profit overall. Even if we're a non-profit or a mission-driven organization, we're still going to care about dollars coming in and dollars going out, right? Money is what allows an organization to operate over time, right? So at some level we're looking at both of those things. And so our leaders tend to speak in business outcomes and they the gap that i saw is that a lot of teams as they were shifting to outcomes would be told you know grow monthly recurring revenue and their product team would be like i don't unless they work at an e-commerce company where they're literally like impacting average order size or something like that most product teams are two three four five steps away from revenue generation this is particularly true with subscriptions where we're driving engagement um right it's not that you make a change in the product and dollars go up directly there's some intermediating steps and so what i realized is that product teams need to focus on outcomes that they believe are in their control and so that's what i call product outcomes they're outcomes for the product team where they're measuring a behavior or that occurs in the product or a sentiment about the product and those are things that a product team can easily see that they can impact and they can influence now the key to making this work is we want to set product outcomes that we think are leading indicators of our business outcomes. So if I work on a subscription business and I have a business outcome of increasing retention, increase our average subscription length, I need to have a theory of like what creates value for the customer. If I'm an entertainment subscription business, maybe it's increasing viewing minutes. If I'm DocuSign, it might be increase the number of signed documents in a month, right? We're looking at what's the... What's the behavior in the product that indicates a customer got value from your product? This is sometimes called an activation metric, but we want it to be a leading indicator of the corresponding business outcome. This allows the product team to focus on what they can control, but also ensures that they create value for the business. If you've got a team that you're coaching who hasn't thought in this way before, or there's blockers either at a team level or a leadership level, how do you coach at different levels and how to shift from output to outcome thinking and how they drive and think of value in their business yeah so the first thing we've learned and this surprised us i say me us because it's me and the rest of my instructor team A lot of us have a lot of business experience. We've been doing this for a long time. Most of us has been executives and companies. And so we're well-versed in financial metrics. We can read financial statements. We forget that the individual contributor, the product manager, the designer, oftentimes the engineers don't have that financial literacy. And so when we talk about these business outcomes, it kind of just goes over their head. They don't always know how their product makes money. Maybe they know literally what's on the pricing page, but they don't understand how their free product contributes to the product, the other product that generates revenue. And so a lot of our individual contributors on our product teams are missing the business context. And so the first thing we do is we try to fill that in. We teach them how to evaluate how does your product make money? And if your product is literally free, somehow it has a connection to how your company makes money. So we look at... or it helps your company save money by reducing internal costs. And so we help them make that connection and we teach them how to map out business outcomes using KPI trees. So if people aren't familiar with KPI trees, we teach it by starting with a revenue formula. So how would you calculate revenue? And then deconstructing each of those variables by looking at their inputs. That's a lot of jargon. I'll try to simplify it. If I have a subscription business, my revenue formula might be number of subscribers, times how much they spend every month, times how long they stick around. And then for each of those variables, I can look at what impacts them. So what impacts number of customers? Well, maybe visitors to my website, the conversion rate to sign up, and I can start to deconstruct each. So that exercise is very common. It's called a KPI tree. They're very popular. So we start there and even that's a big aha for a lot of people because they just don't have that commercial experience. and then we ask them for your product team which of these outcomes do you think you impact and we help them connect the dots and that's actually a hard question for a lot of teams in fact we asked this question on a survey and hundreds of people could not answer the question And that was very surprising to us. And we're like, okay, so first we have to fill in this commercialization layer and help them understand the business context. Then we have to help them see how their work connects to that business context. And then only then can they start to think about what's a behavior in the product that's a leading indicator of one of those business outcomes. Perfect. And what about if they are then trying to transform within an existing organization and they're trying to influence leadership? either as peers or above them on the value of an outcome model and how moving output to outcome doesn't take away the accountability for delivery. How about that? Yeah, this output to outcome thinking is really hard. You know, one of my favorite questions is just to say, so what? Hey, we're building a mobile app, so what? Like, why is that important? Like, okay, you have the app, now what? I think for so long we've trained people. I see this even at the leadership level. We've just trained people to be hyper focused on outputs. Some of this I think is the way the brain works. Like we're used to thinking in about concrete tangible things and output is a concrete tangible thing. And I think outcomes require a level of abstraction. So it's really easy. You could think like in the, like right now with AI, everybody on the planet is evaluating. How do I evaluate? How do I how do I integrate AI into my product? Okay. Well, a very output focus would just be, let's just tack on some AI here. So what, right? Like, is anybody going to use it? Are they going to get value from it? Like what happens next? And this is where we can start, this starts to get, gets us into an outcome thinking. It's not, where do we tack on AI? It's what are we trying to do for our customers that creates value for the business? Oh, we're trying to get them to watch more TV because we're an entertainment business. Great. So what are the problems we already see our customers have? They can't find something to watch. Okay, great. Can we use AI to improve our recommendations? We've actually been doing that for decades, but right? Like it's really not starting from the output and starting from the outcome. What impact do we want this to have? And then aligning that with a customer need and making sure that when we integrate AI into our product it's actually solving a need so it gets used and that it actually solves the need not just we don't promise it solves the need but it doesn't right so saying it solves the need get someone to use it if it doesn't solve the need we just created a disappointed customer if it does solve the need now we're starting to drive a product outcome which then in turn drives a business outcome yeah yeah and I find out The link between writing a company strategy for a multifaceted company and a product strategy and then linking the metrics to the two really helps. So that explaining of saying if you're aligned as a top level leadership team on your top metrics and then your product strategy links to that and you then showcase how a product team is taking accountability for contribution to that metric and the customer problem linked to that. I think people can see that and then opening up that discovery process and show and tell in the back of that to really show here's the value of discovery. You know how scientific research works. We're trying to bring that left into the plan. That's helped me with the book and also with the coaching to try and explain that to other people. Yeah, the strategy adds another element because I think strategy showed up in a few places. first of all how you sell your product your revenue model itself is part of your strategy and that's going to impact the business outcomes you care about but where i think strategy really comes into play is when you make that translation from business outcomes to product outcomes i could have two companies that are in the same space that have the exact same business outcomes because they're both subscription businesses but the way that they look at the leading indicators when they move into product outcomes they might look radically different because they have completely different strategies yeah yeah definitely yeah i've seen that again and rapidly new companies are all about the activation and onboarding if you're five to one ratio on upselling existing customers a big buck changes um where you've talked about we talked about iterative using opportunity solution trees going down to taking the problem innovating on the solution That really, that resumes me is how you use that for iterative product development. How do you see continuous discovery working with Greenfield brand new product innovation? Do you see it collaborating with other methods or how do you see it sparking or helping spark that new way to solve completely unsolved problems that customers may not know is a problem that they need to be solved? Yeah. So I mentioned early on in my career, I was introduced to human centered design. I was really influenced by the D school or what became the D school at Stanford. And later I remember that like the day Eric Reese's book came out, The Lean Startup, I was very influenced by that because I was like, wow, finally somebody who's writing about the way like early startups are moving fast and testing things. And I was like, this is great. And then The jobs to be done framework really resonates with me. I really love Christina's work on OKRs. There's so much amazing content out there. And I think when I started working as a discovery coach, I heard from teams and I could feel it myself. There's so much out there. How do we know what to use when? And how do we know which framework is right for us? And so my goal with the Opportunity Solution Tree was actually not to create a new framework. What I was trying to do with the opportunity solution tree is I was trying to look at like discovery is messy. How does the team know what to do when? How do we give structure to this process of discovery? And I started to realize that across all of these frameworks, they share a common structure. And that structure is we have to know what success looks like. We're starting with an outcome, whether it's an OKR or whatever flavor of outcome setting you prefer. We have to understand. And the key here is the outcome represents business needs. And then we do have to understand what customers want or need. And that could be jobs to be done. It could be customer discovery interviews of the Steve Blank School. It doesn't matter, right? Like it just matters that we're learning about our customer and what they need. And then of course, we have to look at what solutions can address those needs. And so my goal with an opportunity solution tree was just to expose that common structure so that when a new tactic comes out, Teams could look at that and go, oh, that helps with this step. And then they can make a better decision about whether they need it or not. Okay, great. And so you talked there about a lot of your thinking originating from how startups are adopting or how you've watched and adopt these types of principles of rapidly build product and find fit at scale. When you've, from your experience, How do you advise large or enterprise teams to introduce and scale continuous discovery habits? What are the top things you've seen that have really helped that permeate an organization, which can be hard when you're trying to come in horizontally or one team at a time? What's your best tips from years of trying to help with that? I realized I didn't really answer your question about zero to one products either. I'll tackle both. My goal in trying to find this underlying structure, I wasn't just pulling this from like, oh, what does jobs to be done do? And what does OKRs do? At the same time, I was actually in a graduate program where I got introduced to John Dewey's work. And John Dewey is an educational philosopher from like the early 1900s. He really focused on civic education. How do we develop good civic minded citizens? And he focused on critical thinking. And he talks about this back and forth movement between inductive and deductive thinking. And those are some big jargony terms. We don't have to get into the details, but he was a big influencer. Second big influencer was this guy, David Jonasson. And David Jonasson started talking about how we solve problems and how so much of problem solving is problem framing and how we frame a problem is... impacts the solution space. We can frame it narrowly and only have very small number of solution options, or we can frame the problem space very broadly. And then it opens up a lot more types of solutions. And so I was reading about both of these things at the same time that I was coaching teams and trying to figure out like, how do we make sense of this mess? And I realized if the common underlying structure was grounded in critical thinking and decision-making and problem solving research. then it would be, it would last the test of time. And that was my goal, right? So the opportunity solution tree is the opportunity space is problem framing. And it turns out it is an inductive theory of how we think the world works. And then as we move into testing our ideas, that is, those are deductive tests. And so we're getting this back and forth movement of critical thinking. We're also following best practices of problem solving framing and trying on different frames and expanding and narrowing the solution space. Okay, that was a very long way of getting to my point, which is I think it equally applies to both zero to one products and big mature products. And I think it's because it's grounded in critical thinking and decision-making and problem solving principles. So if I'm working on a brand new product, the hardest thing is setting an outcome. I don't have any behaviors in the product because I don't have a product yet. And I think the thing that people get wrong, they want to set generic outcomes like product market fit. What I want you to do instead is I want you to imagine your product already existed. You don't know what the behavior in the product is, but you should know what the impact of that behavior is. So an example I give in a blog post I wrote is let's say I want to start a company. I want to help podcasters build an audience. I don't have a product. I don't know what I'm going to build yet, but I know what my value proposition is and I know who my target audience is. That's enough for me to set an outcome. I can set an outcome of increase the average audience size of my customers. Done. It's directional, right? I don't have a product. I can't measure it. There's no behaviors in the product, but it tells me it's my North star. I know where to go. And now I can start interviewing podcasters about What's working? What's not working? I can talk to successful podcasters about how they grew their audience. I can share those best practices with new people. It's going to help me discover what to build. And as I build, I'll start to look for what are the behaviors, the product that increase the average size of their listening audience. and then i think it works at really large companies as well because it's still just a different frame it's just a different scope of problem you have a mature product you need to understand what's working for your customers and what's not working for your customers we're going to start with an outcome we're going to use that outcome to bound the opportunity space and we're going to go explore where can we make improvements okay yeah and i find out of when i've been advising or helping coaching my teams when they've been doing the course i think especially because the products that are B2B2C, it's such a great process for them to understand how their customer is serving other customers. And unless you're in that part of a continuous habit you're doing every week, then you can never know how they're using your product. And if they use five to six products to run their company, you may only ever see one stage of an eight stage process. how can you innovate unless you're living the pain that they feel and positives that they feel across their whole journey so yeah great okay thank you um and when you get into you talk about you mentioned earlier about the different four different product risks in terms of testing and whether you look at different assumption lessons different frameworks when you're looking at those four products you talked about the balance sheet of often people not understanding that risk well enough if they're in a product team maybe they've got a software development degree and they haven't looked at that how do you where do you see gaps in the other risks when you first start to coach teams and how do where how do you focus that to give the blinded view of the importance of those risks through the discovery process Yeah, so there's a little bit of a difference between how I talk about this and how Marty Kagan talks about this, which I just want to call out. Marty talks about four risks. His risks are value, feasibility, usability, and viability. I talk about five categories of assumptions. So desirability, usability, feasibility, viability, and ethical. Okay. Conceptually, it's the same. I struggle with value because it's... I can teach a team how to identify desirability assumptions. I don't know how to teach value assumptions because it seems like a valuable product is a product that's both desirable and usable, and you can feasibly deliver it so it's good enough. Value seems like the emergent property of the five, but that's just a philosophical distinction that only those of us that write about this all day every day care about. With viability, so... Typically we talk about this as different roles in the team have different areas of focus. So an ideal world of product managers focused on viability. And we see that, especially with our product managers that have MBAs. They're very good at viability. But we also have a lot of product managers that don't have MBAs and they're not really focused on the business, they're focused on the customer. And that's not necessarily a bad thing, but it means that team might have a viability gap. We see some teams hyper-focus on usability and forget about desirability. If your engineers are not involved in the discovery process, feasibility often gets left unchecked for way too long. And I think especially right now with LLM-based products, feasibility is one of the biggest risks. Can we make this product work reliably well enough that it satisfies customers' needs? Or are we just frustrating our customers? I've had a lot of frustrating experiences. with like people integrating AI and not very smart ways, right? I'm also building some of my own LLM products and I'm getting a whole new appreciation for how hard it is to get consistently good output, right? So this is, I think the feasibility category is becoming more and more important because for a lot of us, all our engineers did was build really simple web apps. Like I know our products are amazing, but they're pretty much CRUD apps, if you're not familiar with that acronym, it's just the four modes of interacting with the file. They're not complicated. The engineering wasn't the hard part, right? Maybe when we were getting into recommendations or search algorithm, it got a little bit harder, but for the 90% of what we used to do on the web, the engineering was not that hard. I know I might be pissing off a lot of engineers by saying that, but with LLM based products, the engineering just got a lot harder. And I think there's a lot more feasibility risk. I think as you said, especially when you talk about the, whether it's V0, V0, et cetera, it's just how you'd start to coach people differently when they're accepting an output from a black box that they really understand how that's being built. And I know you can't go into that, but it's that behaviors and how you coach people and how they learn is going to transform quite significantly. When, what role do you see leadership playing in making continuous discovery sustainable? as a practice? A really big one. I think if there's anything I could get across to leaders, it's that this is a full-time job. And it's hard, right? Because leaders already have a full-time job. Like, where do they make space for this? This is something I've been thinking about a lot. I do my own discovery interviews. I've been talking to a lot of leaders recently, and I've heard over and over again, I know I need to be helping my teams. I know I need to be helping them develop these habits. I don't know how, I don't have time. I don't know how to do it. It happens in fits and bursts, right? Like we do a two hour learning session and then we never talk about it again or we check in a month later, right? This is like human nature. But I think the reality is if we want to build a strong product culture and we want to build strong discovery habits. the leader has to create the environment for their teams to build new skills. So whether that's external training or whether that's internal events that help them build those skills. I heard so many leaders say, like, I introduced this concept and they're still not doing it. And that's because learning is not a transfer from me to you, right? Learning is a very practice-oriented activity. I know you've seen this firsthand. You've had your teams go through our courses. we do a huge emphasis on doing we learn by doing um and so i think leaders have to create that space it does not have to be through a third party training but there has to be an opportunity for their teams to practice i think leaders have to set the accountability and their accountability rituals of this is the way that we work and so we're going to talk about it in our meetings we're going to talk about it in our one-on-ones it's how you're going to be measured on your performance So I think there's a lot of elements that have to change for leaders. And I think the hardest part is most leaders have actually not worked this way, right? The ground moved from underneath us and suddenly we're trying to manage teams in a new practice that we've never experienced ourselves. And so we also need ways for leaders to experience it and get comfortable with how do they coach their teams on it. Yeah, I think that because that role modeling of it as well. So if you're going to stage your team. that piece of like i use a piece of if we can't spend two hours for our customers a week then why are we here if you're not then doing that and sharing those stories with your teams of who have you met this week what customers what are you hearing and that might be different personas in that company because of how you interact with them but still that important to say well if you're spending that time if you're making sure that's in the rituals of the team as well as in how you operate and how you work i think i think that role modeling of it helps as well for sure and well just since you since you started the coaching is there anything what are the things that have changed and a either how you coach discovery or is there anything else i don't want to go back into ai but in terms of how you coach it and how you've honed that skill for embedding this at scale How has your coaching evolved yourself and the methods and unions? Yeah, quite a bit. I think today I have a much better appreciation about the distinction between coaching versus training. So I used to be a full-time coach. I would work with about 30 teams a year. I'd work with a team for 12 weeks. We would do weekly coaching sessions. And what I learned from that is that a lot of teams have skill gaps where coaching is not the best solution. I can teach you in a coaching session how to conduct a customer interview, but that is not the best way to learn how to conduct a customer interview, nor is it the best way to learn how to run an assumption test. And so I moved into courses because there is a training element, a skill building element that's different from coaching. I think where coaching really shines is I have the skill, like I know how to conduct a good interview. but there's something in my organization that is blocking me from being able to do it. And I need help overcoming that. Or I have some internal fear or resistance to doing it. And maybe that's skill related, but maybe it's not. Like one of the things that we hear a lot is, I'm mid-career. I don't want to be a beginner again. I don't want to learn a new way of doing things. Okay, we could put you in a class, but you're going to have resistance to that class. So you might need some coaching to first overcome that fear to be open to the training. So I look at training as skill building and I look at coaching as overcoming resistance, removing obstacles, things like that. And so we do both. Whereas in the beginning, everything was packaged as coaching and it was the most inefficient way to train teams. Whereas we've gotten a lot better at training teams at scale. And then we do coaching only when it's needed. And I think this is a really important distinction. And then I'm working on my next evolution, which is... I know a lot of leaders are busy and they want to outsource this to a third party to do the training or even the coaching for them. But I actually wholeheartedly believe what Marty Kagan says, which is your direct line manager should be coaching you. And so I'm now starting to experiment with resources for leaders to coach their own teams. And so that's a few different things. It's helping that leader get up to speed on their own skills, giving them playbooks to run internal events for their teams. giving their teams assessments, the leaders know where they are with a skill. And I'm running my first experiments on that in the next year, this coming year. Amazing. Definitely. Big proponent of being able to lead through coaching and supporting the development and master of your team. So that's great. In terms of, is there any one leadership habit you've seen that needs to be unlearned to help unlock the value of moving to a product model overall? I mean, the first one that comes to mind is to stop dictating outputs. It's so hard, right? Like most leaders have years of experience. They've seen things that worked and didn't work. And it's so easy to be like, that won't work here because I've tried it before. Or here's what did work. But the world is always evolving. And even when something worked at your last company, it doesn't mean it's going to work at this company. And just because something didn't work in the past doesn't mean it can't work now, especially with AI. AI changes literally everything. So we should throw out that would never work here as a general rule. But I think the real reason why leaders struggle to let go of outputs is leaders are also held accountable to outcomes. And there's this trust that has to happen. leaders have to be able to trust that their teams can deliver the outcomes that they themselves are being held accountable to and so both teams and leaders have to learn new behaviors teams need to learn how to show their work and show that they are making progress on the outcomes and leaders need to learn how to coach their team so they do make progress on their outcomes and they also need to learn how to ask questions to surface what they need to know and to help their teams come to the right conclusion instead of giving their teams the right conclusion yeah yeah i know you mentioned christian radical focus i think that tells that quote story quite well and a kind of hierarchy of how you talk about what's in discovery and a minimum number of commitments that tie to the the kind of okr but you only do that at a set point in time and not for all your teams so i think that that's helped me with a blend of that when i've been explaining to people okay thank you very much your time if it's okay we're going to move on to the quickfire round if that's okay let's do it cool right first one what's one habit every product team should adopt tomorrow talk to a customer once a week okay for how long forever forever good what's your favorite discovery tool right now probably clod okay okay i mean how do you use that what's the recommendation for someone Okay, I've been really, this is, I shouldn't say this because everybody's going to misinterpret it. I've been really pushing hard on what can AI do with helping with discovery. And I'll be blogging more about this. The reason why I have some reluctance is that I don't want you outsourcing your work to AI. Like it's just not there yet. And also there's something really magical that happens when we get our hands dirty and look at the data and do the synthesis work ourselves. But I also know Designing assumption tests is hard. Knowing the right tools to execute your assumption test is hard. I have seen teams stop interviewing because they fall behind on the synthesis. Even knowing what an opportunity is hard. And so I've been pushing really hard on how can we use AI to aid humans in doing all of these tasks rather than like what I see a lot of teams doing is they're just giving their transcript to one of these LLM tools and saying what are the opportunities. They're not great at that right now. I've been pushing hard. I wish they were great at that because it would solve a lot of our pain points. But I think they can aid in that process. And so I am using Claude and ChatGPT almost all day every day. And I'm just really trying to understand where is it good at this stuff, where is it not good at this stuff. And I'm hoping by July I'll be writing a long form blog post about my experiments. I'll cheat with another sub-question to that then. Post the discovery side, do you use any of them for rapid prototyping yourself? And if so, what's your favorite? I spent about two weeks diving deep on Replet. I built one product like it was an amazing success and I actually still use that product. I basically built a product to help me launch LLM-based teaching tools. and i use that and it's live in my courses right now and i built that in about a week having never used replit before now i will say i do code i have an engineering background i'm not like a crazy super engineer but like i do write code and i don't think i could have gotten the output i got out of replay if i didn't write code like there was a lot of engineering skills required to get there and then i tried to build a second app and it was an utter failure um It just got stuck and I couldn't get it unstuck no matter what I tried. I do want to try Lovable. I've heard really good things about Lovable. I also have a V0 account, but I think I got a V0 account through Lenny's bundle, but I haven't tried it yet. As I say, so do I. So I'll just repeat ones that you've done through that bundle as well. Okay. And final question. What's a book besides your own that you often recommend to product people? Decisive by Chip and Dan Heath. I love Chip and Dan Heath's books because one of them, I don't know which one is which, one of them is an academic and one of them is an industry. And they blend evidence-based business practices, right? So they're looking at academic research, what do we know from the literature, and then applying it in a very pragmatic way to business. And decisive is all about decision making. And it turns out discovery is decision-making. How do we make good decisions about what to build? And if you read Decisive, you're going to see it heavily influenced my work. Great, yeah. So I was looking left because I've got Switch from Chip and Danny. Yeah, Switch is also a great one. Okay, great. So thank you for the recommendation. Teresa, thank you for all your time today. What's the best way for people to connect with you and your work? Two places. So producttalk.org is where I blog. It's also where people can find our courses. They can find the book. So if you want to learn more, there's plenty of free content at producttalk.org. The free content motivates you to pick up the book. It's called Continuous Discovery Habits. It's available worldwide. And then as far as social media, I'm most active on LinkedIn. In fact, we're going to be closing some of our other social media channels here. um in the next week or so just trying to simplify things so linkedin is probably the best place to follow me perfect i'd highly recommend all of teresa's teams courses i've brought them in at two companies i've worked there so thank you very much thank you to everyone for attending if there's any questions please keep them coming in the chat and for anyone who watches back and we'll have a look at them and try to reply to as many as we can um hopefully you've really enjoyed the passion and inspiration that teresa brings the continuous discovery you know i have and for anyone who wants to sign up for our next event it's from silka patel on the 9th of june is a strategic marketing expert and founder and chair of scottish women in technology and she brings 24 years of experience in the technology industry and creating opportunity inclusion and value so really looking forward to watching that myself so thank you for everyone for attending i hope you have a great rest of your day

On June 2, we welcomed Teresa Torres to our High Performance Leadership Series.

Teresa Torres is an internationally acclaimed author, speaker, and coach. She teaches a structured and sustainable approach to continuous discovery that helps product teams infuse their daily product decisions with customer input.

She’s coached hundreds of teams at companies of all sizes, from early-stage start-ups to global enterprises, in a variety of industries. She has taught over 16,000 product people discovery skills through the Product Talk Academy.

She’s the author of the book Continuous Discovery Habits and blogs at ProductTalk.org.

This is another discussion you will want to attend – live, in the moment, authentic conversation.

---------------

Links:

Blog: ProductTalk.org
Community: Members.ProductTalk.org
Product Talk Academy: Learn.ProductTalk.org
Twitter: https://twitter.com/ttorres
Linkedin: http://linkedin.com/in/teresatorres/
YouTube: https://www.youtube.com/c/ProductTalkVideos

---------------
Join us live on LinkedIn: https://www.linkedin.com/company/xlr8delivery/events/?viewAsMember=true
-----------------

High Performance Leadership Series powered by Atlassian and XLR8 

XLR8 is an Atlassian Agile at Scale Specialized Partner.

Specialists in Enterprise Strategy & Planning, guaranteed to accelerate your operating model outcomes.

------------------

✅ Join us live on our upcoming LinkedIn Live Series: 

https://www.linkedin.com/company/xlr8...
✅ Follow Atlassian:  

 / atlassian  
✅ Follow XLR8:  

 / xlr8delivery  

🎧 Music Credits: Kharma 45 - Come On https://open.spotify.com/track/71Ec8T...