Jason Knight  0:00  
Hello, and welcome to the show. I'm your host, Jason Knight. And on each episode of this podcast, I'll be having inspiring conversations with passionate product people. I'm not sure if you're an old friend or if you've just discovered this podcast for the first time. But in either case, I'd love for you to continue to listen. So why not pop over to the website OneKnightInProduct.com and check out some other fantastic episodes with product management thought leaders and practitioners, sign up to the mailing list or subscribe on your favourite podcast app. And make sure you never miss another episode again. On tonight's episode, we go deep on product discovery and find out why it's so important to do it continuously. We talk about building a strong product feedback loop, how much product discovery is enough and how often you have to do it to be successful. We talk about how to defeat cognitive biases - not just your stakeholders, but yours too, including how to get past the terrifying sounding curse of knowledge. For all this and much more, please join us on One Knight in Product.

So my guest tonight is Teresa Torres. Teresa is a renowned author, speaker and coach specialising in the art of product discovery. Teresa started out studying symbolic systems at Stanford before heading into interaction design and into product and beyond. Passionate about the great outdoors and a keen snowboarder, Teresa also says she reads up to 100 Books In an average year. This makes it even more impressive that she's also found time to write a book, the recently released Continuous Discovery Habits, a book that aims to help you discover products that create customer and business value. Hi Teresa, how are you tonight?

Teresa Torres  1:33  
I'm doing great. How are you?

Jason Knight  1:35  
I'm fantastic. Admiring the stack of books behind you as well. So first things first, obviously, regarding the book, congratulations on getting that out. It's been out for a couple of months now. How has the reception been? Have you had any good feedback so far?

Teresa Torres  1:49  
Yeah, it's been amazing. I am completely humbled and blown away by how people have reacted to this book. I, like... my productivity has gone out the window, because I'm just reloading Twitter and LinkedIn and engaging with people and answering questions and seeing people post pictures of them reading the book at the beach, which I think is the perfect combination, do a little work reading while relaxing at the beach. It's been incredible.

Jason Knight  2:12  
And obviously, I mean, I have been seeing some of that feedback myself. But I don't want to lead you, which is obviously good for discovery purposes... But I've seen some glowing reviews from some of the well known thought leaders in the community, obviously as well, giving it the thumbs up. And that's obviously fantastic. But have you had any specific feedback for maybe lesser known people that has really kind of warmed your heart a little bit that you've sort of seen something that where they've looked at that, and it's really made a difference to them?

Teresa Torres  2:40  
Yeah, so somebody wrote, most books feel like an advertisement for the workshop. And this book felt like the workshop. And that was really meaningful to me, because in all of my writing from day one with Product Talk, I really wanted to write content that was actionable enough that you could start putting it into practice tomorrow. And so the fact that the takeaway was this felt like I went through a workshop is pretty phenomenal. That was my goal was to give product teams, literally a handbook that they can keep on their desk and guide their work.

Jason Knight  3:08  
Yeah, I think that, unlike what some authors have apparently said in the past, it's really good to have practical playbooks and not just have theoretical books, you know, something that you can sit and look at, hopefully empathise with and really put into action. So I think that's a really good, for me, that's actually much more exciting than a book about, you know, pie in the sky stuff. You know, it needs to be something I can do stuff with.

Teresa Torres  3:32  
I will say that I also tried really hard to interweave the why and the theory behind what we're doing. Because I do think we have a lot of product books where it's just here's how big name company does product, or here's how I'm a big thought leader. Here's how I do product. And I just, I don't love those types of books, because I want something a little more evidence based. A little bit more, like, how do we know that works? Why does that work? Why is this the best practice? So I also tried... my primary goal was make it actionable. But my secondary goal was try to dig into the why do these methods work? And so I tried, I know not everybody loves sort of the theory. So I tried to keep the book content itself really just engaging and accessible. And then for people that want to nerd out on the theory, they should go explore the footnotes.

Jason Knight  4:20  
Yeah, it's interesting. I think that I've spoken to some people who say that those very theoretical, idealistic books can be a little bit depressing sometimes if you're not in a situation as exactly like that. So I completely get where you're coming from there.

Teresa Torres  4:32  
Yeah, this piece of like, I talk a lot about, everybody writes about product management in the ideal setting, and the challeng is none of us work in the ideal setting. And I really took that to heart when writing this book, because I'm also writing about kind of the leading edge of what product teams should be doing. So I also want to do acknowledge that 90% of product teams have never worked this way, have never seen a team work this way. It still feels really foreign. And so I also wanted to make sure that I could write the book for those teams as well and give them a really clear place to start.

Jason Knight  5:05  
And if you had to summarise what Continuous Discovery is, either as a book or as a general concept, in a nutshell, maybe to sell the idea to a sceptical CEO of a not discovery led organisation, how would you summarise it?

Teresa Torres  5:20  
Yeah, so I think it's this simple. When we talk about discovery, we're just talking about how do we make good decisions about what to build. And when we talk about Continuous Discovery, in particular, we're talking about how do we continuously engage with our customers to ensure that we're making good decisions about what to build. And this has become so critical lately, because with the speed at which things change on the Internet, whether that's new customers entering your market, technology  disrupting things, a global pandemic, completely shifting the world... hopefully, we don't see that one too often! We just see that customer needs are constantly shifting. And so good teams and good companies, if they want to continue to create great products, even if they have a great product today. They want to continue to create great products and have great products, I think they have to have their ear to the ground and create that continuous feedback loop with their customers.

Jason Knight  6:12  
Yeah, we'll come back to the discovery topic shortly specifically about how that works in many actual companies. But before that, the book obviously talks a lot about - clearly -  discovery and product discovery. Is the book primarily aimed at product management practitioners, or is it aimed at product leaders? Or is it maybe even aimed at the people that manage or the exec team in the company to try and persuade them that this is a good idea? Like who's it pitched at?

Teresa Torres  6:41  
Yeah, so my primary audience for the book was a product trio, so a product manager, a designer and a software engineer. And that's those are the types of people that I coach in my coaching practice. And there's a couple elements to this as that as a primary audience, one is helping them break down that it's not about a product manager does this, the designer does that an engineer does this, but more about how do we collaboratively make good decisions? If, for a lot of us, we don't have experience with cross functional collaboration? Not truly, like we do kind of in name, but not really. We always fall back to who's the decision maker? And how do we escalate this? And so I wanted to give them a handbook for how do you do the work to actually be able to cross functionally collaborate successfully. And then my secondary audience is... I hear from leaders all the time, who basically say something like this, "I get that the world has changed, a total believer in these new methods, but I never worked this way. So how do I manage teams that work this way?" So, I also wanted to give those leaders a really clear picture of what good looks like so that they can start to build their skills around coaching teams. Now there's better tools, like Marty Cagan has an amazing book out, Empowered, that's really for leaders on how to coach teams, this book Inspired is probably the best book for convincing senior leadership that there's a whole new way of working. So I wanted to, I didn't want to create another book that already fills that same need, that really the gap I saw was, tell me, what is this look like practically day to day?

Jason Knight  8:13  
Yeah. So when you say leaders, though, are you talking specifically product leaders? Like maybe VPs of Product or Heads of Product, rather than, say, the CEO or something like that? Or you kind of talking to both in that?

Teresa Torres  8:24  
Yeah, primarily, primarily, I mean, that VP of Product or CPO, but if it's an early stage startup, it could be the CEO.

Jason Knight  8:31  
Yeah, it's just interesting, talking about, obviously Empowered and Inspired. I remember when I spoke to Marty about those books, it was interesting, because there's this whole concept that potentially a lot of the people that you might be pitching this at, and those books at as well, you're kind of preaching to the choir to some extent, right, because they might not know how to do it yet, but they're definitely interested in doing that. They know that that's probably a good thing. But if they're in an organisation where they're being blocked from doing that, by, you know, maybe laggardly, exec teams who don't know that, and they haven't read the books, that they can still find somewhat of a challenge in actually putting some of these ideas into practice. I guess a question that comes off of that would be, is that something you come up against a lot in your coaching? Or is that something that you've managed to not have to confront, because of the types of organisations and teams that you're dealing with?

Teresa Torres  9:20  
Both are true. So usually, for my coaching practice, I'm brought in by the Head of Product, the Chief Product Officer, the VP Product, they've already drank the Kool Aid themselves, which is why they're bringing in a discovery coach, but that doesn't mean that their CEO has or the rest of their leadership team has or the rest of the organisation has, so you get a little bit of a mix. And then I have through the Product Talk Academy where we do a number of online courses. I engage with students all the time where the individual student chose to invest in their discovery skills. And they don't ... most of those students don't work in a context where the leader is saying you have capacity to to work this way. So it was really important to me when before I sat down to write this book, I looked at what are the books that we already have. And we have some pretty phenomenal product books, right? And I felt like Josh Seidon and Jeff Gothelf wrote a pretty great book Sense and Respond that was aimed at business leaders, like, here's the philosophy for business leaders. I feel like SVPG is really phenomenal at being the missionaries and Inspired and Empowered are really motivational, like he named those books well, right? They're just, they're gonna get you fired up about a new way of working. Melissa Perri, writing Escaping the Build Trap, really phenomenal, well rounded, "here's how product management works". So I didn't want to replicate what any of those people were already doing. I wanted to build on top of that. So the gap that I saw was, a lot of us and especially individuals at companies, we've been to the conferences, we read the blogs, we've read all those books, we know we should work this way. But we're swimming upstream in our organisational context, like our organisations are pulling us to do all the wrong things. So I really wanted to create a very clear framework for... "okay, so I really want to do this. And I'm getting pushback everywhere. What's step one? What's the very first thing that I do?"

Yeah, I think taking that first step is really important. And I think that one of the things that's come up a lot is you can't just wave a book at them or hit them on the head and just say, well, this is the way it should be. And in fact, I've been having some interesting Twitter discussions recently, with people saying like, "Well, yeah, actually, the more buzzwords you put into a conversation, the less likely you are to land that message with that sceptical leadership", because actually, all they start to hear is someone who's maybe read a book and remembers some of the buzzwords rather than that they think that this is actually going to lead to any positive business outcomes. But I guess the question really is like, what is that first step ... I mean, I'm sure there are multiple different types of first step depending on the specific problems. But are there any specific pieces of advice you would give someone who has read the book wants to land that with potentially a sceptical leadership team that would help to maybe defuse some of the most common objections that they have? Or is it so context dependent, that it's impossible to give generic advice?

Ye§§ah, so at the very end of the book, I give a guide for like, here's how you can get started. And it's this simple. A lot of teams are waiting for permission. And I really recommend you just not wait for permission. Right? So and I definitely recommend you don't fight the ideological war. Because here's what happens. You're exactly right. Like when you go to your leaders, and you throw all these buzzwords at them, all they hear is this individual contributor who's lower than me in the hierarchy is telling me about a new way of working, but I know what's worked for me and it's not that. That's a losing battle, like, you're not gonna win that argument 98% of the time. So what I recommend people do instead is really just focus on how you individually work. So it's all about show not tell, right? It's create success in your local context. And people have a lot more agency than they realise. And so the first place I recommend people start is to first regardless of your team structure, to just start building those cross functional relationships. So if you're an individual product manager, even if your designer changes on every project and your engineer changes on every project, you can still create this sort of product trio. Even if it's fluid, even if one week you're working with one trio. And the next week, you're working with another trio, I really encourage teams to start increasing their frequency in which they engage with customers. And sadly, a lot of people feel like they don't have permission to talk to customers. But the reality is, all of us, no matter what our organisational context is, we can make friends with an account manager or a sales rep or a customer success person, and just get a little bit more exposure to the customer. And most of us have our customers in our personal networks, right? So there are ways to make it happen. It just requires that we stop waiting for permission and waiting for organisation to say "yes, do this", and just start doing it.

Jason Knight  13:58  
It's that same old cliche of ask for forgiveness, not for permission, right?

Teresa Torres  14:03  
Yeah. Now in an organisational context, we have to say within reason don't get fired.

Jason Knight  14:07  
Yeah, I guess I don't want to go too crazy. But obviously, you've been a product discovery coach for some years now, I think around about 10 years, give or take. And I imagine that you've seen a few things in your time, as you've been going around all these different teams and organisations. And I can imagine why that would make you want to write a book. But why was now the time to write that book. 

Teresa Torres  14:29  
Yeah, I really look at the content in the book as a product in and of itself. And it's been this way for a long time. So basically, what happened was, in 2016, I was working with a team. They felt stuck. They felt like I was always telling them what to do. The reason why I coach instead of consulting is I really don't want to create a dependency on me. So I shifted from consulting to coaching early on, because I wanted to leave organisations better off not just give them work as output. So it really hit hard when this team said, "Hey, Teresa, we don't know what to do when you're always telling us what to do next". And that really encouraged me to think about, like, how am I making those decisions, like what's guiding my decisions about what to do next. And that led to my opportunity solution tree, which is just a visual that helps teams sort of guide their discovery. And in 2016, I blogged about that, because it was having a huge impact on the teams that I was working with, and I announced at that time that I was going to write a book. That was both a mistake and a good thing. So the mistake was, I wrote a book in 2021, not in 2016. And so I constantly got hammered over the last five years, when's the book coming out? When's the book coming out? When it finally did come out why it wasn't a mistake, there is so much anticipation that was fantastic. But the reason why I didn't write the book in 2016, was because I started to write the book. And I realised that book writing is the epitome of a waterfall process. Like you sit by yourself, and you write a book, and at the end, you hope it's going to be good. And I just, that's antithesis to like how I think. And so I started to think about how can I test the content in this book. And because the content came from my coaching practice, I started codifying it as a course for my coaching students. So instead of doing all the teaching, in our live coaching sessions, I flipped the classroom basically, and had them watch videos and read articles. And then they did a team activity. And then they came to coaching. One,  it made my coaching way better, because we got to focus on the things that were really unique to that team, but also helped me see how do they go through this on their own? And then I work with sets of teams at a time so I could track cohort analytics on how quickly could they move through it, and where do they run into trouble. And I basically just got to a point where if I thought about this curriculum as a product, by the end of 2019, I was feeling like it was ready to be codified in a book, it had been well tested. And so then over the course of 2020, I wrote the book, and I still build in a feedback loop. I launched early readers programme, and had a group of about 60 people reading each chapter as I wrote it. And that was really invaluable. Because it was the first time I was getting feedback from people that didn't go through my coaching programme. Right? §So readers who didn't have access to me to ask questions, they had a really positive impact on the book, like every chapter ends with anti patterns that was suggested by my early readers, they really pushed me to include more customer stories. So the book really is far better because of that programme. And I see it in the feedback like people are raving about this book. And I do not think I could have written as strong of a book without having those feedback loops throughout.

Jason Knight  17:31  
Yeah, I think that point about waterfall processes and kind of locking yourself in a cabin and coming back later with something that you're not sure is any good is it is interesting. And I guess the way that you framed it, and the way that you said that you did it, there is very much it's kind of a testament to the concept of discovery itself, right? Because you're sitting there and you're getting that feedback loop constantly and making sure that you are building the right thing. So it's kind of an interesting parallel there. But in your career, before coaching, you've obviously worked in a few different areas and a few different companies. So you've worked in interaction design, you've been a VP of Product, you were the CEO of a startup at one point, you were VP of Operations. And obviously product as a practice has lots of different angles and ways that you could go, you've touched on that yourself. Like there's lots of, for example, books out there that cover all these different things. But even before the book, you've obviously then decided to double down on product discovery and become a coach in that. What was it that attracted you to the concept of product discovery in the first place? What gave you the passion to make that specific part of product management, your passion?

Teresa Torres  18:35  
Yeah, you know, I was lucky because as a college student, I was introduced to human centred design at Stanford. And this was before the D school at Stanford. But it was right at a time when the computer science department had a HCI Human Computer Interaction programme. And the mechanical engineering department had a product design programme, and they were so David Kelley was in mechanical engineering, and Terry Winograd was in computer science. And they were just starting to talk to each other about a like, universal design programme. And so I went through one of the earliest kind of design studio programmes as part of that. And I really thought that's just how business worked. Like I thought I was gonna go as a 22 year old and get my first job. And then I would get to do human centred design, and then I would get to interview customers and then I would get to test my designs and wow, was I rudely awakened when I got my first job. And then I thought maybe this is just the first place I work and then the second place was like that. And then the third place was like that. And I just... I'm pretty stubborn. Like I just... I saw the value of keeping customers close and including customers in the process. In fact,  I include this story in the book, my very first design project and my very first job, the customer we were... it was a client situation and the client hated my design. And I read like very like two weeks out of school first job, and I got this terrible feedback. This woman that worked at Oxford University Press, I remember like it was yesterday because she did not pull her punch. She goes "This is horrible". And that was like the first feedback I ever got on my first professional design. And I looked at that, and I was like, what went wrong here? And I realised that I had gotten requirements from my sort of account manager who had talked to a client who had talked to her. And it was a game of telephone, like I was four degrees away from ... and she was the client, she wasn't even the end user. And so I just, it was really eye opening for me to recognise like, I can't be a designer this way, I have to have first hand exposure. And then I carry that all the way through the whole rest of my career. So I always worked at really early stage startups, which allowed me to play lots of roles. And it also allowed me to just carve out my own way of working and developing my own point of view. But it was really strongly influenced from my college days of just being introduced to human centred design.

Jason Knight  20:48  
So it's always been there, and your disappointments over the first part of your career have amplified that to the point where it became unstoppable. 

Teresa Torres  20:54  
Yeah. And then the other piece of the puzzle is that I just noticed that the same problems exist everywhere, like ever I worked at a lot of different, like, the companies that I worked at, were very different from each other. Like one was part of the Stanford libraries that published and STEM journals, one was a B2C shopping portal. One was, like a community provider for universities to engage their alumni. One was recruiting software lik... just radically different, right. But it didn't matter, I saw the exact same problem everywhere. And that's the product teams, and especially the executives did not spend any time with customers, And it drove me nuts, like I just didn't understand how you could possibly create for somebody, without spending time with that somebody.

Jason Knight  21:41  
But that leads on to another interesting point. And something that you've touched on yourself with the telephone game as well, this idea that you have people in the organisation, effectively designing solutions for problems that they think that customers have. And one of the reasons, or one of the things that you hear is like, especially from someone who may be used to work for that type of company. Like "I am the client, I know where... I know what the client wants, I know what the customer wants, because I worked in that type of company or one of those companies for 15 years" or something like that. And of course, they do know what that specific customer would want, if they were still there, but they don't know what all the other types of companies that maybe work completely differently to that... what they would want. But it's obviously a really common bias. I wonder if you've ever had any situations in your career where you've managed to actually overcome that, and slap down that biased person in the room who basically is almost immune to reason because they're so confident in their own understanding of what they think the problem is?

Teresa Torres  22:43  
Yeah, so there's a there's a few dimensions to this. So first of all, all humans do this, right? We're all fallible in this area. And that's that we should draw from our experience our experiences what, especially for people later in their career, it's what's leading to your success, right? The challenge is, as we learn from Daniel Kahneman and Amos Tversky's work, all humans are also really susceptible to cognitive biases. And what are cognitive biases? They're just... our brains make fast inferences. And sometimes those fast inferences go astray. Right? And so what we forget is, okay, so we hear about a problem in our business. And it sounds a lot like a problem we faced somewhere else in our past career. And we, our brains, make that fast inference of "this is exactly the same", when we forget to ask is "how is it different?" So that we can be a little bit more surgical about what are the elements that are the same? What are the elements that are different? How do we adjust our ideas and our understanding, to reflect this unique situation? So that at the individual level to avoid this is to remember that every single situation is unique. And I even encourage people when interviewing that your job is to uncover as much of the uniqueness of this person as possible. So you don't fall prey to confirmation bias and say, "Oh, I've heard this before. I know what you mean".  When you're a product team, and you have a stakeholder who's doing this, you have to be gentle, right? You can't just tell your stakeholder like, Hey, you're making bad inferences, or this isn't exactly the same. I think there's things you can do with them to help them see their own gaps. So one of the activities I talked about in the book, usually what happens is these stakeholders come to us with their favourite solution, like here's exactly what we should do. I've seen this before, right? And the challenge is, they're not product people. So they haven't written all the requirements they haven't thought everything through. It's still a really vague idea. So one of the ideas in the book, to help teams kind of collaborate and be on the same page about what these vague ideas mean, is to just start story mapping your ideas. This isn't a new idea. Jeff Patton popularised it and he'll even tell you, he didn't originate it. It's been around for a long time, but it's a great way of getting a group of people, whoever they are, aligned around "What do we mean by the solution?" I also like it as a way to surface underlying assumptions. The more we get specific about an idea, the more we can start to see the assumptions that rests upon. So I think this is a really great exercise to do with the stakeholders that when someone comes to you and says, "I've seen this before, we need to build this idea". If you just get them to whiteboard with you a story map, and now that we're all virtual, you can do this in like Miro or Mural or any other digital whiteboarding tool, and just have them do the work to think through how might their idea work. And most of the time, that's enough, right? We've all had this experience where we think something's a great idea. And then we start to figure out how it might work. And we go, this is garbage, you in, throw it out, right? So usually, sometimes story mapping is just enough. If it's not, you can go one step further, and then just go step by step through your story map and  say, "Okay, what needs to be true for this step of the story map to work?", and then start to surface assumptions. And then you can ask the stakeholder, do you see any risk in these assumptions? And collaborate with them on where do we need to test? Whereas what we usually do is we just go stakeholder, your idea sucks. That's... we're never gonna win there.

Jason Knight  25:58  
Yeah, I think some people, certainly that I've experienced in the past are very attached to their solutions, even in the face of reason and story mapping and stuff. But I think that at least laying out in front of everyone, as you say, sounds that at least is out in the open then. Right? And if they still decide to railroad you in any way, then at least you've gone through a process, right? You're not just saying them and either telling them to go away, or worse still just doing everything that I say just because they said it.

Teresa Torres  26:25  
So I have worked with one particular stakeholder in early in my career, who came from another industry that was similar to ours, he was a product manager, he knew how to think through whole ideas, I still thought his ideas were garbage, it was really tough, right? And so here's the thing, like, you might still story map, the whole thing, you might surface assumptions. And your stakeholder might still say, "I love this idea, build it". And if you still think it's the wrong thing, you're a little bit stuck, you have to build it. However, if you also instrument it, and follow through with impact, either you're going to learn something or they're going to learn something, right.? So either the idea is gonna work, and you're gonna learn, you made a misjudgment early on, and you're going to be able to see exactly which assumptions you hold that are faulty, or it's not going to work. And you're going to have data to bring back to that person and say, "Hey, this fell short of our expectations. Let's work through how we can iterate on it." And so that story mapping and assumption generation, whether or not it has an impact on the short term decision, it's going to lay the foundation for down the road learning, was this really a good idea or not? And if it wasn't, who had the blind spot? And how do we overcome it.

Jason Knight  27:32  
But also, continuous discovery, or indeed, any type of discovery obviously requires talking to users, and talking to the customers that we've been talking about in this interview. And obviously, if you've got a massive pool of customers, that can be fairly straightforward, but you've got a big addressable market, you can... especially if it's B2C... you can pretty much pick anyone off the street. But in some companies, obviously more, say B2B companies, people serving the enterprise, people with relatively small user bases, in real terms, might actually find it a struggle to find enough engaged people that are basically prepared to be either interviewed or continuously interviewed, especially over the course of say, a contract. Do you think that continuous discovery can work with that type of organisation? Are there any approaches that you use yourself to try and make that still a thing and not get that fatigue from the customer side?

Teresa Torres  28:25  
Definitely. So every team I've worked with, regardless of who they are, and I will even say, I worked with teams at a large retailer here in the US, where they were B2C, and they thought their customers were hard to get in touch with, like, literally, like, you can't find an American that has not shopped at this location, right? Like, literally, it's not possible. So here's what I'm going to say everybody thinks their customer base is really hard to get in touch with. I have worked in some really challenging environments, like people whose audience like I worked with a company where their customers were six US based movie studios. It's a teeny, tiny total addressable market. I've worked with an organisation where their total addressable market was Canadian medical schools. So they have maybe a couple dozen customers and their total addressable market. I've worked with businesses where their customers are Fortune 500 CEOs, those are people that have no time, right? They're not exactly going to be jumping through hoops to go talk to their vendors. I've worked with companies where their customers are healthcare clinicians during the height of COVID. Right? I've worked with companies where they're interviewing people about really sensitive topics like erectile dysfunction in men, and reproductive ... like rights for women, right? So I've worked in some really challenging areas as far as like, how do we, how do we set up the infrastructure to interview regularly? I've never worked with a team that wasn't able to increase the frequency in which they engage with our customers. Not everybody gets to weekly... I will be up front about that. I encourage everybody to try to get to weekly and the vast majority of teams can get to weekly. Some instances like I worked with a team where their customers were investment bankers. Not only are they super busy people without a lot of time, but they're also really secretive about how they work. They didn't get the weekly, they did get to a regular cadence, but they didn't get to weekly. The vast majority of can get to weekly though. And the idea is, you have to think about your infrastructure for supporting regular interviews as if it was a product in and of itself. So you got to think about it as a funnel. You got to optimise the funnel, you got to experiment, you got to find what works for your audience.

Jason Knight  30:38  
Yeah, that's really interesting about the frequency. Is there a frequency beyond which you think maybe it starts to fall apart? Like, you know, is monthly OK? Is quarterly OK? Like, how frequent does it have to be before... Or how infrequent does it have to be before it starts to dissolve?

Teresa Torres  30:55  
Yeah, so talking to customers, any customers is better than talking to no customers, right? However, the longer you go in between customer touch points, the more decisions you're making without their feedback. And this is pretty dangerous. Like, it seems like, it's really easy on a product team to feel like, we know our space, we know who our customers are, it's probably fine. We suffer from a bias called the curse of knowledge, where we forget what it's like to not have the expert knowledge we have about our product, right? And so we make all these decisions from our product expert point of view. And we forget that our customers don't have that same point of view. So if you're only talking to customers quarterly, there's a lot of risk there, you're making a whole quarter of decisions without customer input. So I do really encourage a weekly cadence. I personally in my career, almost always talk to a customer every day, which a lot of people think is crazy, I will tell you that I was a startup CEO. During the 2008 economic downturn, we got... we were a company in crisis, we were down to just six employees, I literally played seven roles. Like, I was the CEO, I was the VP product, I was our primary product manager, I was our salesperson for two sides of our marketplace. So that was two different roles. Like I literally had more roles than I could possibly manage. And I still ... not just talked to one customer every day, I talked to one customer on each side of our marketplace every day. And the reason why I did that, even though I was insanely busy and completely overwhelmed was because I that was the only way I knew how to get out of that crisis was I have to figure out how to create more value for my customers. And the only way I know how to do that is to stay close to them.

Jason Knight  32:30  
But some people might sit there and say, That's okay, we've got product analytics, we can see how people are using our tools. We know what people are doing and what they're... what areas they're dropping off at, and stuff like that. And I guess there's always room for analytics in any discussion. But I guess you're gonna say that anyone that's doing that is probably missing at least half of their story, but probably way more right?.

Teresa Torres  32:53  
Yeah, so analytics matter. And we ... a good product person, a good product trio is going to know their analytics inside and out. And analytics often points us to a problem area. Where analytics excel is an optimising an existing product. Where they don't excel is where's there an adjacent opportunity that could create exponential value for your customer? Where's their risk in your market, that is an indicator that you're losing ground to your competitors? Maybe you see that customers are doing some odd behaviour in your analytics, but your analytics aren't going to tell you why they're doing that, or help you understand the context and the nuances of why they're doing that. Right? So analytics are a really powerful sort of arrow in our quiver, but it's not the whole quiver. We have to complement it with qualitative research, we have to spend time with our customers and really do the work to understand their context and their needs.

Jason Knight  33:45  
You talk obviously a lot about the product trio... engineers, product managers, designers. There's obviously a cliche of engineers just sort of sitting in a basement, listening to music on their headphones, head down, typing away. Do you think it's essential to get engineers into the continuous discovery loop as well? Or do you think that it's kind of okay, and they can come if they want to? How important is it to get them in as early as possible up front? In your eyes?

Teresa Torres  34:10  
I think it's essential that there be at least one engineer on the team is part of discovery from the very beginning. And there's a reason for this, right? Like when we work in a waterfall world. We do handoffs, from product managers, to designers to engineers, and we see a tonne of rework, right? So a product manager hands off requirements to designer, they run into problems, they rewrite requirements, they redo the design, it all gets handed off to the engineers, they run into problems, maybe the data model can't support what they're trying to do. It goes all the way back to rewriting requirements redoing design. It's super inefficient. So that's one problem. Second problem is engineers when they're implementing have to make a million decisions, right? How should I implement this? How should this data model work? Should I abstract out this part or this part? All of those decisions if your engineers have no exposure to customers are being made it from their point of view, not your customers point of view. And this is why teams constantly find themselves in, they hear about a customer need, and they can't address it because their architecture doesn't support the actual solution. Third reason why it's critically important, our engineers know the most about what's possible with technology, and a product manager or designer, when they're even just looking for the right problems to solve. They're gonna hear certain types of problems that are different from what an engineer might hear. Right? So a product manager without even being aware of it might filter out customer needs, because they might feel like, there's no way we can address that, that's impossible. Whereas the engineer might hear that need, and start to think about, like, oh, we could use this new technology to address that. And so I think it's really critical that we have in the engineering perspective, be part of the entire discovery process.

Jason Knight  35:52  
I 100% agree and if there are any engineers listening to this, make sure you get on your next customer call. What's one piece of advice you'd give to any struggling product leader to get started with discovery today? We've obviously talked about first steps before but imagine there's someone sitting there head in hands right now. They're just listening to this podcast. What should they do next to move along in the world of continuous discovery?

Teresa Torres  36:14  
Yeah, find a customer to talk to. It's that simple. I think it's... the first thing I think everybody should focus on is increase the frequency in which you engage with customers. And the metric that I like to look at is to reduce the cycle time between customer touch points, because teams will make mistakes will say, well, it's we're going to talk to 12 customers this quarter. And that sounds great. It sounds like you're going to talk to a customer weekly. That's not what happens. We ignore it for the first eight weeks of the quarter. And then we pile in 12 interviews at the end, right? So really think about it as cycle time, try to reduce the cycle time between your customer touchpoints.

Jason Knight  36:50  
I'll try and do that myself as well. And where can people get in touch with you if they want to speak after this and find out more about either your coaching or your... obviously the book or anything else that they've heard about on this episode?

Teresa Torres  37:01  
Yeah, so ProductTalk.org is a good starting point. You can learn more about the book there, you can learn more about our membership programme that supports the book. And you can also learn about the courses that we offer. If you're a product leader, looking for training for your team, we have a variety of options there that you can learn about there as well. And then if you have questions, or you just want to reach out, I'm pretty easy to find on the online @ttorres on Twitter. I'm also available on LinkedIn. I will say that LinkedIn inbox is kind of a nightmare. So Twitter might be a better way to reach out, but I'm doing my best to respond when people reach out.

Jason Knight  37:34  
I'm sure you'll be on Tik Tok before we know it as well. That's been a fantastic chat. So thanks very much spend the time. Obviously wish you all the best with the upcoming promotional activities for the book and hope that it continues to get as much good feedback as it has so far. Hopefully, we can stay in touch but yeah, as for now, thanks for taking the time.

Teresa Torres  37:52  
Yeah, thanks so much for having me. It's been a lot of fun.

Jason Knight  37:57  
As ever, thanks for listening. Hope you found the episode inspiring and insightful. If you did again, I can only encourage you to pop over to the website OneKnightInProduct.com, sign up to the mailing list or subscribe on your favourite podcast app. And make sure you share with your friends so you and they never miss another episode again. I'll be back soon with another inspiring guest. But as for now, thanks and good night.