Innovation is important, especially for digital products. However, it can also be an annoyance if a clear focus on customer needs is not present. This is where continuous discovery comes into play, Teresa Torres explains.

In this episode of the Product Momentum Podcast, Sean and Paul talk with Teresa Torres, a product discovery coach and author of Continuous Discovery Habits. Continuous discovery has numerous benefits for companies, product people, and customers, but product leaders must make time for continuous discovery on a weekly basis. Only by talking to customers can real value-producing innovation occur.

Moving away from old-school ways of working can be difficult, no matter what industry your organization is in. Teresa says that you often have more influence than you might think and that a lot can be done if you have the confidence to “rock the boat a little bit.” 

Listen to glean more valuable insights from Teresa, including: 

Podcast: Play in new window | Download

Sean [00:00:19] Hello and welcome to the Product Momentum Podcast. This is a podcast intended to entertain, educate, celebrate, and give a little back to the product leadership community.

Paul [00:00:32] Hey, Sean, how’s it going?

Sean [00:00:33] It’s going great, Paul. Super happy with that recording with Teresa Torres.

Paul [00:00:37] You know, she is a brilliant speaker and author. One of the things that is sticking with me is how continuous discovery is hard because it flies in the face of 100 years of business history, right. We don’t often think about getting things wrong to get to the right destination.

Sean [00:00:53] Exactly. One of the things that she taught us in this podcast was about how just having a habit around continuous discovery can open the door to serendipity and really help us build better products.

Paul [00:01:04] Yeah. Can’t wait to share this with our listeners.

Sean [00:01:07] Yeah, let’s get after it.

Paul [00:01:07] Let’s get after it.

Paul [00:01:11] Well hello and welcome to the podcast. We are excited today to be joined by Teresa Torres. 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 startups to global enterprises, and has taught over 6500 product people core discovery skills through the Product Talk Academy. She’s the author of an upcoming book, Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, and blogs at producttalk.org. Teresa, welcome to the pod.

Teresa [00:01:44] Thanks. I’m excited to be here.

Paul [00:01:46] Awesome. So jumping right in, you know, many of our community are new product leaders and just starting out in their product management and product leadership journey. Can you share, where does discovery fit in this toolbox of product people?

Teresa [00:01:59] Yeah, this is a great question. Discovery is a little bit of jargon, right? I think the term originated with Marty Cagan where he started to distinguish between discovery and delivery, where discovery encompasses the things that we do to decide what to build, versus delivery, is the things we do to ship and maintain a production-quality product. And I think that distinction has been really helpful. It’s a little bit harmful, right? Because people think, “oh, we have a discovery team and a delivery team,” and that’s a model we don’t want to go down. But I think where it’s really helpful is that a lot of companies under-emphasize discovery and over-emphasize delivery, whereas really to create good products, they’re both equally important.

Paul [00:02:38] Yeah, and I think that the way that you phrase it as continuous discovery takes it a little further because, in current jargon and current mantras, we’re used to hearing the term continuous in the context of continuous deployment or continuous development. What does continuous discovery mean, sort of in contrast to those continuous delivery aspects of the game?

Teresa [00:02:59] You know, all of this comes, I think, from sort of agile principles. You know, it honestly even probably predates the Agile Manifesto, but really getting at, how do we shift value to our customers in smaller increments so we get feedback more often and stop building the wrong stuff? And I think with continuous deployment and continuous delivery, it’s that first step of, how do we get the value that our code creates in our customers’ hands quicker and more frequently?

Teresa [00:03:24] And on the delivery side, it solves a lot of problems, right. We don’t have to spend hours or days or weeks, depending on the company, reconciling code branches and we can just write code and get it to our customers as quickly as possible. But if you’re still building the wrong stuff, all you’re doing is getting the wrong stuff to your customers quicker. So discovery just introduces that other piece of, if we’re going to work on a continuous delivery cadence, it needs to be supported by a continuous discovery cadence where we’re constantly looking for, what’s the right stuff to deliver? And I actually think, for digital products, this is particularly important because we see with digital products we’re just never done. It’s not like we’re producing a bar of soap and it goes on the shelf and we call it a day. It’s really that as we introduce new stuff into whatever that digital product is, whether it’s software in your car or an app on your phone, we’re solving some problems, but we’re creating new problems and we’re changing the ecosystem in which people engage with our products. And so it’s sort of this never-ending evergreen challenge that I think continuous discovery and continuous delivery are really well-suited to support.

Sean [00:04:30] Interesting. We always talk about, it’s one thing to build the thing right; it’s another thing to build the right thing. That’s the difference between effectiveness and efficiency. And I do think there has been an overemphasis, I’m summarizing what you’re saying, on continuous delivery, continuous deployment. You know, and we see this across our products, right Paul? Like you get all these ideas that funnel in and you just want to experiment your way to success. But we would get much more value out of figuring out how to continuously discover alongside our delivery. Two questions for you, two-part question: how do you do it and how do you express the value of it in a way which is going to help product leaders sell it?

Teresa [00:05:10] Yeah, these are both million-dollar questions. Let’s see, where should we start? So let’s just start with kind of the how a little bit. So the first piece, and this is where I think continuous is really critical here. So we’re at the point in the industry where most product teams have been exposed to some discovery-like activities somewhere along the line. So what do I mean by that? They’ve talked to a customer. They’ve maybe run a usability test, maybe they ran AB tests. They built a prototype. Like a lot of the activities that we associate with discovery are becoming a lot more common.

Teresa [00:05:43] What I think is less common is the continuous mindset. So we see even teams that work in Agile and are working on sprints or working in Kanban, they’re taking a project mindset to the way they do discovery. So we hear teams say things like, “how do I stay ahead of my engineers? Do I have a design sprint ahead of a delivery sprint?” This is all project language creeping in, right. So in a continuous world, we’re not doing research upfront and then deciding what to build. We’re really looking at, how do we engage with customers on a continuous basis and let those engagements or those touchpoints influence the decisions that we’re always making?

Teresa [00:06:22] And so one of the things I do in the first week when I’m working with a team is we start looking at, “ok, so how do we set up a continuous interviewing process so that you’re talking to your customers every single week, regardless of what’s going on?” And this is very different from a project mindset where we tend to do interviews at the beginning of a project, or we tend to book customer touchpoints when we’re ready to test our final design. But really looking at, “we’re going to talk to customers every week, even if we don’t know what we’re going to ask them.” It’s just, how do we make sure that we have this continuous drip of feedback?

Teresa [00:06:53] And I think the reason why that’s so important is that it really unlocks a lot of magic. Like if you talk to your customers every week and you don’t have a discussion guide, you don’t know what you’re going to talk to them about, it opens the door to serendipity. We get feedback on ideas while they’re still half-baked and easy to change, which is very different from project research. And it really starts to create these really good habits across the team because they’re just talking to customers all the time. And it just kind of reminds them how often they’re assuming things that aren’t quite right. So I think a big piece of the how is literally as simple as just start talking to your customers every week. There’s obviously a lot more to it than that. But I think it’s a phenomenal place to start.

Sean [00:07:34] Love that. And then part two, how do you sell that?

Teresa [00:07:37] Yeah. Oh, this is, this is a hard question. I’m going to start with when we talk about continuous discovery and continuous delivery, we’re swimming upstream from the way that the rest of our organization works. And I think that’s a really important thing to recognize. So like it’s really easy as an individual contributor on a product team to just say, “my boss doesn’t get it, I don’t understand why the company is working this way, everybody’s so dumb.” What we’re not recognizing is that we have over one hundred years, if not more, of business history where the way we won in business was through efficiency and by like specializing in functions and by a command and control top-down structure. You know, we have a lot of people in business that the way that they got to where they are today is because of these older models of working.

Teresa [00:08:24] And it’s probably going to take us, nobody wants to hear this, but it’s probably going to take us another hundred years to really evolve and adopt this new way of thinking. Those of us that work on digital products, I actually think we’re really fortunate. We work in a really fast-paced, ever-changing, super competitive world and we’re being forced to change first. And so I think it’s awesome because we get to work on the new fun stuff and I think this is a better way of working. But when it comes to how do we change the rest of our organizations, I think the first thing is it’s going to be mind-numbingly slow and that we have to just accept that’s the reality.

Teresa [00:08:57] I think the second thing we can do is stop trying to change other people and just looking at what’s in your sphere of influence and what you can do yourself. I never, as an individual contributor, had permission to do this stuff. I just found a way to do it. And I think individual product people dramatically underestimate how much impact they can have just rocking the boat a little bit. And then I think, third, we have really good product instrumentation tools now and I think if we track why we’re doing things, what we expect the impact to be, and then what the actual impact was, exposing that gap can be scary, but it’s also what creates the case for better discovery work.

Sean [00:09:36] Yeah, and I think it’s valuable just to show that you’re learning.

Teresa [00:09:39] Yeah.

Sean [00:09:39] And although it may not result in an economic benefit right away, you know, we’re learning and we’re going to figure this thing out. So that’s good. I think there’s something powerful in the anecdote that you had out there about serendipity. You know, what we’re doing is not all quantitative. There’s a lot of qualitative stuff that we have to work through and figure out. And the more exposure you have to the people that are actually deriving value from your product, the more possibility for serendipity there is.

Paul [00:10:08] Yeah, that’s great, Sean. Teresa, I’ve been a fan for a while. I’ve listened to your talks back in 2016, 2017, and I’ve heard you say things like, “five years from now,” five years ago. Like five years from now, we’ll be talking about a different model.

Teresa [00:10:21] Yeah.

Paul [00:10:21] And it’s true, right. Now we’re talking about things like the Spotify model and remote configurations, but we keep coming back to new ways to do the same things. And that’s sort of the beauty of discovery, right. You’ve created this meta-analysis of how discovery fits into organizations, and it’s sort of this evergreen mindset of mapping and understanding the way things work, especially in digital products and the way that we understand what users need, and taking those bets, right?

Teresa [00:10:50] Yeah.

Paul [00:10:51] Talking to users, finding the opportunities, building the solutions. And one of the things that I find most refreshing about the way that you talk is just a vulnerability, like knowing we’re going to get stuff wrong, we’re going to release something and need to tweak it, and even, we put something out in the wild and we need to kill it, right. It needs to go away. So can you talk about just how do you keep your perspective when you see sort of so much changing, technology moving fast, jargon moving fast, and yet your consistent message has been sort of that we’re reinterpreting the context around us, but applying the same principles? Can you share some of the tools that you’ve used and ways of thinking?

Teresa [00:11:31] Yeah. So I think one of the talks you’re referring to is in 2016 I kind of walked through the history of discovery at Productized and I started back with software in boxes on shelves at Fry’s Electronics, right, for those of us that remember those days and just really like what’s happened in our industry with the rise and growth of the Internet, and a lot has changed. It still feels glacially slow, but a lot has changed. And I actually think it’s really important that we start to understand that history because it puts all of our frameworks and tools into context.

Teresa [00:12:01] So I pretty quickly got exhausted trying to keep up with whatever the flavor of the week was, right. And you know what, frankly, like, you’ll meet somebody who says Jobs To Be Done is the only way to do it, and that’s a pretty phenomenal method, but it’s not the only way to do it. Jobs To Be Done helps us find opportunities and there’s lots of other ways to find opportunities. Design thinking folks will tell you to go observe people. I’m going to tell you to go interview people. It turns out all of these methods are effective. And what’s hard is that teams don’t know what to do when. And so I was challenged by actually a team that I was coaching to solve this problem. They said, “Teresa, how are you making decisions about what to do when? Can’t you teach that to us?” And that actually led to my visual that I now use called an Opportunity Solution Tree. And it’s not magic; other people have similar visuals. But what the question I was trying to answer was, what is the common structure that underlies discovery that all these different methods and fads and trends and…?

Teresa [00:12:58] Our methods should evolve. If they’re not evolving, we’re not getting better, right? But we need a way to put them into context. And what I like about the Opportunity Solution Tree is it really just identifies three key activities. One is, we need to define outcomes. We have lots of ways of doing that. OKRs are pretty trendy right now, but I know lots of companies that use OKRs and they use a different method. That’s fine, right? The key is, how can you be outcome-focused? Once we have an outcome we need to discover, I use the word opportunities, opportunities is a little bit jargon. I define it as customer needs, customer pain points, customer desires. The Jobs To Be Done folks would say jobs. I don’t really think it matters what you call it. I think it matters that it’s fully in the problem space, not the solution space. And then the reason why I use opportunity language is because Disneyland doesn’t solve a problem for me, ice cream creates more problems than it solves, and I break myself mountain biking. But I like all of those things. Like, they create joy in my life. There is a place for those products. And so I like to use opportunities to be more inclusive of the products that really address our desires and not just meet our needs or solve our problems.

Teresa [00:14:02] So that second set of things is we have to explore that sort of problem space or opportunity space world, if we want to do our jobs well, and then we have to discover the solutions that will actually address that opportunity space. And regardless of whether you’re a design thinker, you’re a Lean advocate, you’re a Jobs To Be Done nut, like all of those things roll into that sort of very simple framework, and so I think it helps teams assess when something new comes out: “How are we doing with discovering opportunities? Do we need a new method?” “OK, great, let’s try on this new thing.” Or, “no, what we’re doing now works pretty well and we’re having a lot of success with it; I’m going to ignore that trend for now until I have more mindshare to kind of explore it,” and I think that’s really needed.

Paul [00:14:42] Yeah, that evergreen perspective resonates with a quote that stuck with me in one of your talks from actually one of my favorite authors, William Gibson’s The Difference Engine. But the quote that you used is, “the future is already here, it’s just not evenly distributed,” right. So the next best thing, it’s already here, but we’re figuring out how to use it.

Teresa [00:14:58] And, you know, most of the time that we hear about something like, I’m going to go with the Spotify squad college tribe model, by the time other people started using it, Spotify had moved on from it because it stopped working for Spotify at the stage that they were at. You know, we hear a lot about OKRs and Google, but I’ve worked with some teams at Google that were pretty terrible at OKRs. They had outcome-focused OKRs. And even in a company like Google, that’s known for a thing like OKRs, the future’s unevenly distributed there. Right. And even at a company like Spotify, that’s known for the squad model, the way their squads work is unevenly distributed there.

Teresa [00:15:34] We tend to fall in love with these big brands and how they work because we think that how they work is what led to them being successful. What we forget is that’s, what’s that fallacy? It’s like the survivor fallacy, right? Like they did a lot of things wrong that got them where they are. And so we need to be critical about, is this actually something that helped in their success or is it despite their success? And then even if it helped in their success, it doesn’t necessarily mean it’s going to help us in our success, right, because we work in a different context with different people. So I think it’s actually really important that teams adopt that, again, that Agile principle of constantly iterating on how you’re working because you’re a unique team in a unique context, and you can’t just copy what other people are doing.

Sean [00:16:18] Yeah, that’s definitely been a theme in two years of doing podcasts with product thinkers and leaders that each team has to kind of take their piece of the truth and figure out what’s going to work best for them. Like you said, there’s a ton of fads. There’s a ton of models out there for doing this, that, or the other thing. They’ve all got a little piece of the truth. But let’s face it, we’re building things that don’t exist yet and we’re forging new territories, at least that’s what we’re supposed to be doing building products, right.

Teresa [00:16:41] There’s a lot of ways to do things well. I mean, we see that in all industries, in all fields, in everything, right. This is why we have hundreds of genres of books.

Sean [00:16:48] Right.

Teresa [00:16:49] There’s lots of ways to do things well.

Sean [00:16:51] And if it were easy, we’d all be following the exact same process and doing the exact same thing and getting the same results.

Teresa [00:16:56] And life would be pretty boring.

Sean [00:16:58] It wouldn’t be any fun. All right. I’m going to go backward and pull on another topic that you mentioned that’s kind of close to my heart. You said, “products are never finished.” And actually, I think that products that are finished are finished like it’s the beginning of the end. The minute you say, “I’m done,” is the minute it starts to atrophy. The industry, it just moves too fast. So how do you communicate that? In bigger companies, there’s always this like, “we’re going to make this investment and get this return.” How have you found communicating that in a concise way?

Teresa [00:17:28] Yeah, I want to distinguish something, because actually, as you repeated my words back to me, I was like, “actually, I can think of a product that I wish was done.” And I hate picking on products, but I’m going to do it. Evernote, right. Evernote has sort of been this product that started out phenomenal. It had a ton of growth. They struggled as a business because they really struggled with the freemium model. They just released a new version and I’ve been using Evernote for years and I want to get rid of it. Like, I want to just go back to the old version. I want it to never change again because it’s a product that I depend on. And the changes weren’t for the better, in my opinion. N of one.

Teresa [00:18:00] This is incredibly frustrating as a consumer, right, when our products are constantly changing underneath us and they’re not changing for the better. I believe this happens because we take an output mindset: “digital products are never done, let’s just produce output.” I think this is where this idea of ‘digital products are never done’ is a huge problem. It’s not about producing more output and there’s more features to add and “we can always redesign it.” When I say digital products are never done, what I mean is, when we start to fully address our consumers’ or our users’ or our buyers’ needs, we earn the right to address their adjacent needs. And then the way that we address those needs actually creates new needs, right. So before I used Evernote, I didn’t know that I needed to have a notebook that captured all my thoughts for all of time. But once I had that, now I have a whole bunch of needs, like I want my notes to open quickly and not have to wait three minutes for the text of the note to load.

Teresa [00:18:55] And I apologize to anybody and everybody who’s worked at Evernote. I usually try to avoid beating up on people, but it’s a frustrating experience, right? And so their product development actually created a whole opportunity space in and of itself. And even when we make phenomenal products, our products still open up more of the opportunity space because we realize, like, I didn’t know that I needed to browse the web on the go until I got an iPhone. Right, now, suddenly I have a whole new set of needs I didn’t know that I had. And that’s kind of a great thing about products is they open up a whole new world we didn’t know about. But it means that we get to keep serving our customers and keep serving adjacent needs. And that’s awesome when it works well; it’s frustrating when it creates pain points that we didn’t need in our life.

Sean [00:19:39] I love that. So had they been doing more continuous discovery, they would have been able to recognize the actual opportunities that their current advocates cared about so. It’s not that the product is finished, but it’s like, if you’re going to build a better product, you have to make sure that the things that you’re building into it are the things that the people that are your core advocacy base, the things that they care about.

Teresa [00:19:59] You know, I think we’re touching on a really important topic, which is this idea of opportunity mapping and really understanding, “where should we play?” So one of the things that I teach is to map out the opportunity space. So start with the outcome. How do you get a big picture view of what are the needs, pain points, and desires that you could address, that if you addressed them would drive your outcome? So we’re aligning business value and customer value. But here’s the key, the mistake that a lot of teams make, and not just teams, companies, and I would guess this might be where Evernote kind of went astray other than their business model problem, we hear about all these customer needs and we try to solve all of them. And what happens? We don’t really solve any of them very well and we spread ourselves too thin. We build way too much product and nobody’s really that satisfied, right.

Teresa [00:20:46] And I would argue in the early days, Evernote did a phenomenal job of doing one thing extremely well. But then what did we see? We see them get into, like, taking photos of business cards, and I think they had a food product where you could save recipes and they had… Like they had a million things. They’re trying to be everything to everybody, whereas I feel like they had a really tight focus that if they had just focused on serving that market, they maybe would have done better. But I also don’t want to make Evernote all about the opportunity space, because I do think maybe the root of what went wrong was the freemium model for them. So I don’t want to keep beating up on Evernote, but I do think, if you take the time to map out the opportunity space, it helps you make those strategic decisions about, “we’re going to serve this customer and we’re maybe going to not serve this customer,” or, “we’re going to go after this part of the opportunity space and let somebody else tackle this other part of the opportunity space.” Those are hard business decisions that a lot of companies just kick the can down the road.

Paul [00:21:39] Yeah. And, you know, the counterpoint to this would be the apocryphal Henry Ford quote, “If I asked people what they wanted, they’d say a faster horse.” I’m thinking back to the early days of Facebook when there was no such thing as a feed, right. When they started introducing new things, people balked. There was a revolt, right. But eventually, that became the norm. So I believe you’re right. There is a need to be sensitive to the needs that you’re creating just as much as the original needs that you served. But I do think that there is a place to take those risks and sort of show people, right. The iPhone might not have been invented in creating those adjacent spaces. So I’m still an Evernote apologist. I have transitioned a bit of my external brain to other platforms, but I’m still rooting for them. I love them. I got to put a plug in for them. I think that it’s been a journey watching them just as much as it has been being a user for them.

Teresa [00:22:27] Absolutely. And, you know what, I am completely dependent on Evernote, which is why it frustrates me so much.

Paul [00:22:32] Exactly.

Teresa [00:22:32] So I’m still a user.

Paul [00:22:34] It shows you’re an advocate, right? The pain shows you’re invested.

Teresa [00:22:37] Exactly. Exactly. You know what, let’s pick apart this. You just mentioned the Henry Ford quote and you also mentioned the iPhone. And actually, in my book, I quote Steve Jobs, who quotes Henry Ford. The reason why I do this is it’s really important to put an end to this myth in our industry. So Steve Jobs said, “I’m not going to ask customers what they want; they don’t know what they want.” He said this much more eloquently than I am. And he quoted Henry Ford and the Henry Ford quote is, “if I had asked people what they wanted, they’d want a faster horse.” And then Steve Jobs went on to say, “people don’t know what they want until you show it to them.”.

Teresa [00:23:11] OK, let’s pick this apart. People don’t know what’s possible with technology. So if Henry Ford had asked customers what they wanted, they never would have said a car because they didn’t know cars were possible. OK. When we talk to our customers, we’re not asking them, “what should we build?” That’s our job, right? That’s what Steve Jobs is saying. Customers don’t know what’s possible with technology. That’s different from, customers don’t know what their needs, pain points, and desires are. In fact, that, quote, “if I’d ask people what they want, they’d say a faster horse.” OK, guess what the need is: “I need to get from point A to point B faster.” That’s a clear need. And by the way, a car is a much better solution to that than, say, a horse. So the customer’s job is: “This is my world, this is my context, this is what I need.” The technology team’s job is, “this is the better solution.” And so it drives me nuts when people bring up either Steve Jobs or Henry Ford in the context of research.

Sean [00:24:10] You know, Henry Ford never actually said that.

Teresa [00:24:12] Yeah.

Sean [00:24:12] That’s like one of those quotes that just floats around the Internet.

Teresa [00:24:15] Which is why I quoted Steve Jobs saying that Henry Ford quote so that I didn’t have to take the flack of Henry Ford never just said it.

Paul [00:24:23] Which is why I said it was apocryphal in the first place. So first things last, let me take us to where I think the most important lesson you can teach us today, especially on the dawn of your upcoming release. We haven’t actually defined, using your words, what continuous discovery is. We’ve talked a lot about it. But your definition, and I want to make sure we document this because it’s really, I think, meticulously put. Continuous discovery: weekly touchpoints with customers by the team building the product where they conduct small research activities in pursuit of a desired product outcome. I can tell that you put a lot of thought into crafting what it is that goes into continuous discovery. So as we kind of wrap up our time, what are some of the things that you can point our listeners to that they can take back to their teams who maybe don’t already have a discovery mindset where these tools are foreign or even counter to the culture?

Teresa [00:25:12] Yeah, so the first line, which I’ve actually modified a little bit for the book and now says, “at a minimum,” weekly touchpoints with customers, because I actually work with teams that work with customers multiple times a week. It’s really like, if you’re just trying to get started with this, just increase your cadence of engaging with customers. If you’re not comfortable talking to customers, at producttalk.org, I’ve written probably a dozen articles on how to talk to customers. We actually have a course that gives you, like, really safe, with peers, practice time interviewing. A lot of teams ask the wrong questions in interviews. It’s a little bit of the, “if I asked what people wanted, they would have said a faster horse.” If you don’t ask the right stuff, you’re not going to uncover opportunities.

Teresa [00:25:51] So I think one is if I had to start anywhere, it would be how do you increase the frequency of your customer conversations and how do you ask better questions in those conversations? And then, of course, I have to plug my book. It is called Continuous Discovery Habits. In addition to going in-depth on customer conversations, it actually breaks this definition down. The big part of the definition people don’t know what to do with is, what are those small research activities that will help you drive a desired outcome? And there are things like continuous interviewing, mapping out the opportunity space, working with sets of solutions, so not just testing one solution at a time, identifying the assumptions behind your ideas and then rapidly testing those ideas so that you can compare and contrast to which ones look best. That book is coming out soon. We also have a bunch of courses at learn.producttalk.org that supports all of the habits that we explain in the book as well.

Sean [00:26:45] I think that’s the key takeaway for me is we have to develop a habit around customer discovery. However we do it’s another story, but you’ve got to do it, so…

Teresa [00:26:54] Yeah. I will share, one thing I tell my teams is going from zero to one is the hardest step.

Sean [00:26:58] For sure.

Teresa [00:26:58] Right? So starting interviewing is harder than continuing to interview. And I think the habit mindset is a really good one to keep in mind.

Sean [00:27:07] Alright we have one last question for you. How do you define the word innovation?

Teresa [00:27:12] You know, innovation is a tough one because I feel like people think about innovation for the sake of innovation. So I’d like to define innovation as like something novel. I actually think maybe if I looked it up in the dictionary, it’s going to say something about novelty that creates value. I would argue, for product teams, it’s this simple: can you solve a customer need, pain point, or desire? So can you address an opportunity? In a way that removes that need, pain point, or desire? Fully satisfies it. That to me is true innovation, even if it’s boring. If you can make the opportunity go away, I think you came up with an innovative solution.

Sean [00:27:48] It’s precise, which makes it valuable. It’s an innovative definition of innovation.

Paul [00:27:53] Teresa, thanks so much for taking the time to share your new ideas and the upcoming book. I’ve learned a ton.

Teresa [00:27:59] Oh, thanks for having me. It’s been great.

Sean [00:28:01] To wrap up, you got any books you want to recommend?

Teresa [00:28:04] The first book that I always recommend for product people is Decisive by Chip and Dan Heath. They do a phenomenal job of summarizing the research and decision-making. For people who have heard me recommend that book a million times, I’m going to give you a second recommendation. It’s a book that just came out, well, came out in December of 2020. It’s called Strong. It’s by Petra Wille. She wrote a book for people who manage product managers about how to develop product managers. So here’s what’s great about this book. If you manage product managers, it’s going to give you actionable tips for how to do your job better. If you are a product manager, it’s going to give you a very clear expectation of what you should expect from your leader. And I actually think both sides should read it because we need stronger product leadership.

Paul [00:28:47] Great ad. Thanks so much again and congratulations on the book.

Teresa [00:28:50] Thank you.

Paul [00:28:51] All right, cheers.

Paul [00:28:55] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.