Continuous Discovery in Product Management: The What, Why, and How (with Teresa Torres)

Okay, let's go ahead and get started. Hello, everyone. Welcome and good morning. My name is Robin Brooks, and I am a strategic advisor and trainer here at 280 Group. Thanks you so much for joining us this morning. And today we're discussing the what and why of continuous discovery. I am excited to introduce Teresa Torres with Product Talk. Teresa, please tell our listeners a little bit about yourself and why you're so passionate about this topic. Yeah, first of all, thanks for having me. I'm really excited for this conversation. I work as a product discovery coach. I've been doing that for about the last 10 years, and I've really been fortunate to work with teams all over the world, all different sizes, in a lot of different industries. And what's fun for me is I get to sort of collect and refine practices that work in a lot of different contexts to then help other teams kind of find their continuous cadence. to discovery. And what's really fun about that for me is just really helping teams unlock better products so they can better serve their customer. Wonderful. And as I mentioned, my name is Robin Brooks and I'm a strategic advisor here. My background is in product management, particularly in the education technology space. And we have a lot of synergy between 280 Group and Teresa. And so we're really excited to have her here today to talk about this really important topic. So let's go over just a couple of housekeeping items for the webinar. After the webinar, you can continue to stay engaged with the product management community here. Being in an online community can really help you feel connected. So join your peers by joining our LinkedIn group. Use it as a forum to chat about best practices and tips. We'll also paste the URL into the chat here shortly, so you'll be able to access it. But there's a short link there on the slide. Now, during the webinar, please ask questions. Our team is standing by to help. So at 280 Group, we really love interacting with you. We encourage you to ask questions or give feedback. You can use the questions box on the right of your screen. We see it here to type in questions or comments at any time. And we will leave time for Q&A at the end of the webinar. So if we don't get to your question as we're rolling here, we will make sure to try to answer as many as we can at the end. And our most popular question is, can I watch this webinar later? And the answer is yes. All attendees will receive a link to view the webinar recording after it has ended. So with that, let's go ahead and talk a little bit just briefly about 280 Group. Our mission is to empower product professionals with the knowledge and tools to build products that matter. So we are so excited to have you here today to talk through this. Unlike other companies, we're focused on just the needs of product professionals. So whether you need help as an individual growing your knowledge and skills, or you're working towards improving your team's effectiveness, we have the experience and services you need. So check us out at 280group.com. And now let's get on to the meat of the webinar. So take it away, Teresa. All right. Excellent. So thank you, Robin. So like Robin mentioned, we're going to talk about the what and why of continuous discovery. I already gave a little bit of a background. So what I'm going to touch on here is really just highlighting that the framework and the tools and the tactics we're going to talk about have been tested in a lot of different environments. I know what it's like to sit in an audience and think, oh, this is only going to work at the Amazons and the Netflix and the Googles of the world. And so what I want to encourage you to do is flip that a little bit and think, oh, odds are this has worked in an environment like mine because I've probably worked with a company like yours and see if we can start to look at how might you bring some of these ideas to your own workplace. All right. So I want to talk a little bit about just what do we mean by discovery? So level set a little bit. It's this simple. Discovery is the work that we're doing to make good decisions about what to build. We often contrast that with delivery, which is the work that we're doing to build, maintain, and ship, or build, ship, and maintain a production quality product. And the thing, the reason why these definitions are becoming much more prevalent in our industry is we see a lot of companies put a huge emphasis on delivery and often underemphasize discovery. Thankfully, that's starting to change. Although what I see is a lot of teams adopt... project mindset to discovery and that's because most of us sort of grew up in a project world and we're seeing a shift towards a more continuous mindset and so today we're going to talk about what does continuous discovery look like i'm going to give you a pretty clear definition of that that we're going to walk through over the course of the talk um but before we dive into that we're going to start with a quick poll um which robin is going to walk us through yes so this is a poll to determine kind of what how much do you know about continuous discovery today so nothing at all a little bit but i want to learn more trying to implement it we're doing it but want to get better as you're thinking about your options there's no wrong answers here right like all of us are on a continuous improvement journey trying in fact what we're going to talk about today is really giving you a benchmark to aspire to absolutely i think no matter how much we've done this there's always room to get better because it's always changing um and i know that from following teresa's work for the last few years uh we learn we grow and uh and that's that's that's what it's all about we're continuously discovering right exactly yeah we don't just continuously discover our products we also continuously discover our methods which is a lot of fun absolutely okay so we have our responses in thank you everyone who responded And the biggest section here is almost 50% said, I've heard a little bit, but I want to learn more. So I think that's pretty typical. Yeah, that's not surprising. It looks like the next big chunk is trying to implement it. For those of you that said nothing at all, you're going to get a pretty good foundation today. Yeah. So we'll level set you pretty quickly. And for those of you that even said we're doing it but want to get better, We're also going to get into, I often hear people say, wow, I've been doing this for a long time and I still got some really good takeaways. So I think regardless of where you fall on this poll, hopefully there's something you'll be able to take away from today's talk. Absolutely. Okay, great. So let's get into, I talked about the rise of discovery versus delivery, how a lot of us are starting with a project mindset and that really what we're going to talk about is how do we get to a continuous mindset. So let's start with, what do I mean by a project mindset? So most of us work in a world where we pick up a project or we pick up an initiative. If we're lucky, we start with some user research. We do some customer interviews. We create a research deck. We rely on that as we make decisions throughout the project. And then maybe at the end of the project, we do some validation research. We validate, did we get the design right with usability testing? We validate, did we get the delivery right with A-B testing? There's nothing wrong with project-based research, right? Especially if you're involving your customer that's better than no research. But what we're seeing is the best teams are adopting a more continuous cadence because we're starting to recognize that we actually could benefit from having the customer involved throughout the entire process. So I'm going to start with just a quick definition of continuous discovery. This definition comes from my book, Continuous Discovery Habits, which we'll talk a little bit more about at the end of the talk. I define continuous discovery as weekly touch points with customers by the team that's building the product where they're conducting small research activities in pursuit of a desired product outcome. Now this is a mouthful. We're gonna break it down line by line as we go through the talk. So I wanna start with this first line of just weekly touch points with customers. Why is this cadence so important? As product people, we're making decisions every day. Some of them are big strategic decisions, like which customers should we serve? What opportunities should we go after? What are the big rocks that go on our roadmap? Others are just daily or weekly decisions that have an impact on our product, like what do we label this button? How do we expose this feature in the interface? How should this workflow work? Or how should the underlying data model work? Most of us know that those big strategic decisions need customer input, and that's usually where our project research shows up. All those daily and weekly questions can also benefit from customer input. And the best example of this is odds are, if you have a phone nearby, if you pick it up and just scroll through your pages and pages of apps, you probably have dozens of apps that you were excited about one day, you installed it, you started using it, and it fell short of your expectations. It didn't engage you over time. And that could be for any number of reasons. It was missing a key feature. It didn't match your mental model. It just wasn't good enough. When we see that happen, oftentimes a team gets a key idea right, but they don't follow through. They don't infuse those daily decisions with customer feedback. This is really critical because product teams suffer from a curse of knowledge. The curse of knowledge is a bias that basically says, as we develop expertise in something, in our case, our product, how it works, what functionality is available, we forget what it's like. to not have that knowledge. And so as we're making these daily decisions, we're making them from our expert point of view, which means we often make decisions that don't work for our customers who don't have that expert knowledge. So one of the easiest ways to overcome this is just to increase the frequency in which you're talking to customers and to engage with them every week. Now, this is a benchmark to aspire to. So if you've never talked to a customer, I want you to just focus on talking to your first customer. If you're talking to customers quarterly, try to get to monthly. If you're talking to a monthly, try to get to every other week. So don't look at this as if you're not talking to them weekly, you're doing something wrong. Instead, take a continuous improvement mindset of can we make next week, next month look a little bit better than last week or last month. By increasing the frequency in which we engage with our customers, we're increasing the number of opportunities where we get to see this gap between how we think about the product and how our customers think about the product and this is really important this is what's going to help make sure that more of our decisions work for our customers it also starts to unlock what i call a co-creation mindset so we already talked about a validation mindset where we're validating our design with usability research we're validating our delivery with a b testing a co-creation mindset allows us to get feedback much earlier in the process we can our customers can give us input on what problems we should be solving they can give feedback on our pencil drawings when it's super inexpensive to change direction this really unlocks a lot of magical um out like our products really we can iterate on them quickly when we're getting feedback frequently from customers now whenever i talk about co-creation with customers somebody in the audience is thinking about either the steve jobs quote where he said customers don't know what we want until we show it to them or the henry ford quote where he might have said um where he might have said if i had asked customers what they wanted they would have said a faster horse so i want to be really clear right i want to be really clear we're not going to ask customers what do you want that's the wrong question when we're talking about co-creation with co-creating with customers the goal here is to combine our knowledge of our product and with technology and what's possible with our customers knowledge of their world, their context, their needs. So when we talk about co-creating, we're talking about synthesizing those knowledge bases so that we get better products. Okay, so we've tackled this first line. Why are we trying to get to this weekly cadence? Again, it's so we can close the gap between how we think about the product and how our customers think about the product. It also is gonna unlock this co-creation mindset. It's really critical, however, that it's the team that's building the product that's engaging on this weekly cadence. So let's start with, who do I mean by that? This really is this idea of a product trio. So this is a product manager, a designer, and a software engineer being jointly responsible, collaborating from the beginning on their discovery decisions. So remember, discovery is the decisions we're making about what to build. so we're getting these three roles in the room to jointly make these decisions this is different from what we've historically done right historically a product manager writes the requirements to hand them off to the designer who does the design work and then it gets handed off to the engineers who write code what happens when we have these sort of stage gates handoffs between these three roles is we see a lot of rework right we get requirements that go to the designer the designer runs into a design constraint they can't design for the requirements we got to go back and rewrite requirements we eventually do that back and forth we get a design we think is going to work we hand both off to the engineers and they run into a limitation right maybe the data model doesn't support what you're trying to do maybe a user story gets an estimate of 20 weeks and you thought it was going to take two weeks and we got to redo the requirements redo the design this process of handoffs and stages between groups is what leads to projects being over budget, underscoped, and late, right? This is the epitome of why companies are shifting from a waterfall process to an agile process. However, most of us that work under an agile framework are still essentially doing mini waterfall, but we're still handing off. So the trio is trying to break this model and say, look, let's get these three roles collaborating from the beginning, working together on making decisions about what to build. And because they're the ones making decisions about what to build, they're the ones that need to be engaging with customers on a weekly basis. So they're overcoming that curse of knowledge. Agreed. That happens so often. I once asked an executive to describe for me what he thought Agile was, and he basically described waterfall faster. Yep. Waterfall faster. Very common. That's not how any of this works, right? Yeah. I apologize. I'm in Central Oregon right now where we are inundated with smoke. Fire season has come early, so I'm having some tough allergies today. Okay, so most of us have more than three people on our team. So let's talk a little bit about what role does everybody else play. We probably have more engineers. Depending on your DevOps strategy, you probably have some QA folks on your team. Depending on how you interface with the rest of the business, you might have... data analysts, user researchers, customer success folks, feel free to insert your favorite role. I am not trying to leave anybody out with this slide. Here's the idea. We've learned from experience that the three roles represented in the trio are the most common roles responsible for building digital products. And so the idea of the trio is we want them collaborating from the beginning. Based on what roles are available at your company, this concept can flex. So for example, if you have a user researcher that's embedded full-time on your team, they're probably part of your trio making a quad, right? The other way that this idea can flex is you can pull people in for different types of decisions based on their expertise. So if you're working on the discovery for your go-to-market strategy, you're probably inviting your product marketing manager to be part of that. So the idea of the trio is not meant to exclude. It's meant to flex. so that you're balancing the speed of decision making, the fewer people involved in each decision, the faster you'll go, with the quality of decision making. When you have the right cross-functional roles represented where we get to leverage everybody's expertise, we make a better decision. So you will have to do a little bit of translation for your own team and for the types of decisions that you're making, but the idea is instead of doing these handoffs, how do we get a cross-functional group together to make a better decision? Okay, so we've tackled the first half of this definition. We're looking at weekly touch points with customers. Yeah. Hi. So a couple of questions coming from our audience now that I think maybe for the first two lines of this continuous discovery that maybe you can help clarify. Sure. Puneet asks, what will you get every week from customers? You would not have developed anything. So I think they're asking about this maybe in the pre-1.0 aspects of your product. Yeah, so we're just about to get into this. So if we look at the second half of the definition, we're talking about small research activities in pursuit of a desired outcome. We're going to talk about two research activities that you're going to be doing on a weekly basis to help make sure that you're driving your outcomes. And that will help create a clear picture of how are we using these customer touch points. Great, great. And then Mandeep asked a question, product discovery is led by PM, UX, or equal involvement. Product discovery is a joint effort between your product manager, your designer, and your lead engineer. It really is led by that trio. And I know this is different from what a lot of people see, right? At a lot of companies, maybe your designer is the voice of the customer or your product manager is taking the charge. Here's why we don't want that. We want to leverage the cross-functional expertise on our team. Let's say we get a product manager, designer, and engineer together to make decisions about what to build. And only the designer has talked to customers. What happens when the designer says, yes, but this is what the customer wants. That's like a trump card. Nobody else on the team can react. We're not going to leverage anybody else's expertise. So the idea of the trio is we want them doing research together. So they're building a shared understanding of who their customer is. And that shared understanding allows them to truly cross-functionally collaborate and leverage each other's expertise. rather than one role being of the voice of the customer. And we just let that person dictate what to build. I really can't overstate the value of having your UX and your technology leads involved in customer conversations. I've seen so many cases where just their expectations shift because, yeah, you can have, you know. Predo personas, right? Proto personas that are, you know, just like, here's a Noel and she's a nurse. But that's all, that doesn't have any reality. It's not grounded in reality and it can be laced with bias, as I've heard Teresa talk about in the past. So talking to real customers, starting to put together sketches of real customers, it shifts. And then you start to see some of those biases fall away and that gets you to better products that are meaningful for your real customers. Yes, absolutely. And we'll definitely get into the details of this as we get into the second half of this definition. Go for it. Thanks. Okay. So let's talk a little bit about these last two lines work together, right? So our goal, we can't do our project-based research and try to crime it into a continuous cadence. So our goal is to do small research activities that are sustainable week over week. And the key here is we're not doing research for research sake. We're doing research to derive a desired outcome. So I'm going to introduce this visual. It's called an opportunity solution tree. If you've never seen it before, we'll walk through how it works. This visual is designed to help a team chart the best path to their desired outcome. So we're going to start talking about what do we mean by outcomes? Why is this important? So historically, we've managed product teams by outputs. We give them a roadmap and we say, go build these outputs. What does that assume? It assumes that we know up front the right things to build. It assumes we can predict the future. And if we learned anything in 2020, I hope it's that the world is far more uncertain and ambiguous than we possibly could have imagined. And hopefully we don't go through another global pandemic in our lifetime, but we do see the world change radically when competitors enter our market, when technology disrupts our market. Even every time we make a code change to our own product, we're impacting our customers in a way that shifts their needs. So with an outcome focus, what we're saying is we're not sure what the right outputs are, but this is the outcome we need you to drive. And in my model, I want you to think about the outcome as measuring business value. It's where your business leaders are saying, this is how you can create business value for the company. I'm going to give you an example of this. I use Netflix in my examples, not because they sponsor me or I've never even actually worked with them, but because everybody is universally aware of Netflix and generally how it works. If I was a business leader at Netflix, the metrics I'd be looking at, my financial metrics would be things like customer acquisition, subscriber retention. I'd be looking at lifetime value of a customer. That's a key driver of our revenue. So I might give a product team an outcome of increasing subscriber retention. So that's an example of how they're going to create business value. Now we want to also be customer centric and look at how do we create customer value. And we do that by discovering opportunities. So opportunities are customer needs, customer pain points, customer desires. And we're looking for the opportunities that if we addressed them would drive our outcome. And this sounds so simple, but there's a lot of power here because in a lot of companies, customer value and business value are at odds. And what we're doing here is we're starting with business value. We have to start with business value because if we don't, we run the risk of creating unsustainable products that will lead to us going out of business or our product being shut down. So we're starting with business value, but we want to create business value in a customer-centric way. So we're then exploring through opportunities how we can create customer value. We do, of course, have to look at outputs and discover the solutions that will address those opportunities, creating customer value in a way that drives that outcome and thus creating business value. So what this visual is helping us do is it's helping us identify solutions that will create customer value in a way that also creates business value. So we're going to talk about how this works. It starts with defining this business outcome. So I gave you this example of a Netflix leader saying we need you to drive subscriber retention. The product trio needs to translate that to a product outcome. A product outcome is a metric that measures a behavior in the product. In the Netflix world, that might be increasing viewer engagement. You have this theory that if people watch Netflix more, they'll retain longer, right? So we're doing that translation from a business outcome to a product outcome. Once that's in place, the first small research activity we're doing on a weekly basis is we're interviewing our customers to discover the opportunity space and this is critical many people think about interviewing as a way to evaluate solutions i want you to think about interviewing as a way to discover needs pain points and desires and we'll get into the how behind that in just a minute but first we're going to do another quick poll okay great So this poll is all about what you think the biggest barrier is to getting continuous discovery going. Is it assembling the team that you need? Is it putting the right processes in place? Is it recruiting customers to talk to? And that could include internal barriers to talking to customers. And also understanding the results of your customer interviews. How do you organize them? How do you really turn that into things that are actionable? And for many of you, it could be multiple. So pick the biggest barrier. Okay. Looks like we have majority of folks that have weighed in. So let's see the results. Okay. It looks like a pretty close between putting the right processes in place and recruiting customers. But we did have quite a few that also feel that assembling the team is a barrier and understanding the results. uh fairly even between the two middle and the top and the bottom so what are your thoughts about this teresa yeah this is so this is really common you're gonna we're gonna get into this barrier of recruiting customers in just a second here um but all of these i see on a regular basis a lot of us aren't working in trios already um but you can even if you're not in a durable trio you can start building those cross-functional relationships A lot of us don't know where to get started from a process standpoint. Hopefully this whole talk will help you with that. And then understanding the results of customer interviews, the methods that I'm going to give you today will also set you on a good path for that as well. So we'll tackle all of these, which is great. Great. Okay, so let's get into this first one of just the biggest barrier to interviewing on a regular basis really is recruiting, right? If we're hustling to find someone to talk to, we're not going to do it every week. So the key to unlocking a continuous cadence is really to automate your recruiting process. Now this is going to sound magical. I want you to wake up on Monday morning, look at your calendar, and there's already an interview there, and you didn't have to do anything to get it there. So I'm going to give you three strategies for how to do this. All three of these strategies are going to work with, we're going to find a way to recruit people, and you're going to combine it with scheduling software to automate the back and forth of finding a time to meet. So the first strategy is you can recruit people while they're using your product or service. This works really great for B2C companies. It also works really great for recruiting B2B end users. The idea here is you're recruiting people while you already have their attention. So this needs to live somewhere within your product. You can do it as an interstitial as you see here. You can do it as a pop-up. You can embed it in a newsletter. There are lots of ways to do this. If you pursue this strategy, you need to think about it like a product funnel. It will take some experimentation and optimization, but I will share most of the teams that I work with use this strategy for automating the recruiting process. If you're in a B2B context and you need to recruit buyers, you can use your customer-facing teams. So this is your account managers, your sales teams, your support teams, and the people in your company who are already on the phone with customers all day, every day. And you can define triggers for them. You can say, if you talk to a customer who has this need, please ask if they'll do an interview with the product team. And then you send them to your scheduling software and it shows up on your calendar. The vast majority, I'm talking 98% of the teams that I work with, are using one of these two methods. so i would recommend almost everybody on this call should be looking at one of these two methods there's two exceptions i've worked with companies where their total addressable market is teeny tiny an example of this is a company that worked with us-based movie studios there's six of them so i'm talking teeny tiny total addressable market the second exception is when your customers our high worth or their time is extremely limited now we all think our time is extremely limited so i'll give you two examples think fortune 500 ceos right where they're booked double booked triple booked all day long or think respiratory icu physicians and nurses during the height of covid so i'm not talking about your average b2b customer we're talking about extremely high worth folks This is where you want to build long-term engagements with a small number of customers that you can go back to time and time again. The risk of this for a regular market is that you're going to build a product for a subset that doesn't work for the whole market. So you really need to use this one carefully. And even when you do use this one, I want you to mix and match it with some of the other methods. The idea here is not that you're treating your advisory board as a focus group. It's that you're inviting a number of customers. to then do monthly interviews with your teams so if you have three product teams you might invite 12 customers to be part of your advisory board that gives each and you and you encourage them to do a monthly interview with your product teams so they each have a weekly interview on their calendar the vast just about every single team that i've worked with has had success with at least one of these three methods most of the teams that i work with are mixing and matching them so they have a really robust recruiting automation Once we have customers in the room, we now need to ask what are the right questions to ask. This gets a little bit about how do we do effective interviewing. And our goal is to avoid speculation. So a lot of our defaults, we think we just want to ask what we're trying to learn. So again, using our Netflix example, I might want to know, Robin, what do you like to watch? Where do you watch? How do you choose what to watch? Who do you watch with? But I don't want to ask you these questions directly because this is where cognitive biases interfere. And Robin's answers, not because she's being deceptive, but just because of the way human brains work, may not reflect her actual behavior. For example, if Robin aspires to watch documentaries and she recently watched a documentary, I'm going to hear all about the documentary. But if she recently also watched Trailer Park Boys, I'm not likely to hear about that because most of us don't really want to admit that we watch reality TV. Again, she may not even remember that she watched the reality TV, so it doesn't even require this active posturing of I want to present myself as someone who wants to watch a documentary. It's simply how our brain works. Her brain is going to give her a fast answer, and the fast answer is going to be more likely to be what she aspires to than what she actually does. So the problem is when we build products based on what people aspire to, We get all these mobile phone apps that we really wish we meditated every day, but we stopped using it because it didn't really support the fact that we aspire to meditate every day. We don't actually meditate every day, right? So we want to build products based on what people actually do so that we can help them become their aspirational self. And the way to do that is in your interviews to ground them in specific stories in the past. Now, if you've read anything on the internet about interviewing, you've probably read, ask open-ended questions, don't ask leading questions. That's good advice. It's not enough. I could say, Robin, tell me about your experience on Netflix. It's open-ended. It's not leading. It is, however, still speculative. So instead, I want to ground my question in a specific instance. I can say, tell me about the last time you watched Netflix. Tell me about the last time you had to choose a new show to watch. Tell me about the last time you watched on a mobile device. I can collect all kinds of stories. But the key is if I ground Robin in a specific instance, her answer is much more likely to reflect her actual behavior. The other value of this strategy is needs, pain points, and desires, also known as opportunities, are going to start to emerge from Robin's stories. And I can start to hear about areas where I can help. in the context of a specific story so I get all the nuance and all the detail. Now, once we have this, I want to choose a target opportunity to explore. I'm going to dive deep on a target opportunity. I'm going to generate solutions, and my goal is to compare and contrast solutions against each other. Again, I want to highlight this is different from what most teams do. Most teams hear a customer need, and they jump to their first solution, and they say, is this idea good or not? You've probably done this because I've done this myself, where we ask a whether or not question. The challenge with this framing is that it sets us up for two biases, the escalation of commitment and confirmation bias. Escalation of commitment, the more we invest in the idea, the more we fall in love with it. The more we fall in love with it, the more likely we're to see the evidence that supports our idea and not see the evidence that refutes our idea. That's confirmation bias. The easiest way to avoid these two biases, is to frame it as a compare and contrast question to work with a set of ideas and say which of these ideas looks most promising. This compare and contrast idea is important enough I'm going to give you a visual to help you remember it. We're coming up on the Summer Olympics which I'm pretty excited about. This is Usain Bolt. He was once the world's fastest 100 meter runner. If I asked you is he fast or not I want you to hear a whether or not question. This is like asking is this a good idea or not. How do I answer it? Is he fast relative to what? Is he fast relative to a cheetah? Probably not. Is he fast relative to a Tesla? In the first hundred meters, I would pay to see that race. Is he fast relative to other humans? Absolutely. What we're seeing on the right is a compare and contrast decision with a clear front runner. This is what we're looking for. when we're comparing and contrasting our solutions against each other. Now the reason why we don't do this, we do project-based research. We can't do project-based research for three ideas at once. We don't have time. So we need to change our research activities. The second small research activity you're going to do on a weekly basis in addition to interviewing is you're going to break your solutions into underlying assumptions and you're going to rapidly test your assumptions. Assumption tests we can run in a few hours to a day or two. Most solution tests take weeks, right? We got to do a lot of design work. We got to schedule a bunch of prototype tests. We got to get feedback on big ideas or we got to build the whole thing and A-B test it. We're not going to do that. We're going to do small assumption tests to rapidly collect feedback so we can identify a clear front runner. So I'm going to walk you through a quick example. We're going to stick with our Netflix example. We're going to imagine we have interviewed a bunch of Netflix folks. They all said, I want to watch sports. We're brainstorming three solutions. One is we're going to integrate local channels. A lot of sports here in the U.S. are on ABC, CBS, NBC. If we just integrate those channels, you can watch sports on those channels. Second solution, we're going to partner with NBC, I mean, sorry, the NFL, NHL, NBA, MLB, and we're going to license games directly from those sports leagues and integrate them into Netflix. Third solution is we're going to say we're Netflix. We're not really good at... sports, we're going to partner with someone like Fubo who is. So how might we evaluate these solutions with that good compare and contrast decision? The key is to break them down into their underlying assumptions. Assumptions come in a lot of categories. We have desirability assumptions. Does anybody want our solution? Desirability also covers are our customers willing to do what we need them to do in order to get value out of the solution. we'll see what that looks like in a minute viability assumptions is will this solution create value for the business if we're an outcome driven team it's this simple will it drive our outcome feasibility assumptions can we build it is it possible i'm going to add two more categories one we're pretty good at usability assumptions can um can our customers use it can they find it do they understand it are they able to do what we need them to do this is also where we can bring in accessibility What assumptions are we making about our customers' ability? The last category, sadly, is an industry we're pretty terrible at and we need to get a lot better at, and that's ethical assumptions. This is where we need to look at the data that we're collecting, how we're storing it, how we're using it, who we're selling it to. Do our customers understand that? Are they comfortable with it? Are we creating harm by those practices? It's also where we can look at diversity and inclusion and ask, are we replicating the social inequities in our communities, in our products? Most of us are not doing this intentionally, but it's happening because we're not explicitly asking these questions. Knowing these five categories will help you generate assumptions, but we're often blind to our own assumptions. And so I'm going to give you an activity that can help you surface assumptions. It starts with story mapping. If you've never story mapped before, that's the yellow boxes on this slide. So I'm going to walk you through it. With story mapping, we're going to assume our solution already exists. So in this case, we're going to assume Netflix has already integrated local channels into their service. And we're going to ask the question, what does our subscriber have to do to get value out of our solution that was designed to meet the need, I want to watch sports? So first, our subscriber has to decide. they want to watch the game right then they need to choose a streaming service we're hoping they choose netflix then they need to open that streaming service then they have to choose the local channel because remember we're not integrating the specific game we're integrating the local channel and then they need to watch the game so it's a very simple story map the value of doing this is what i'm doing in the gray boxes below is i'm asking for each step what needs to be true for my subscriber to be able to do that step. And this is what's going to help me identify my assumptions. So when I say what needs to be true for my subscriber to decide to want to watch a game, they have to want to watch a game. They have to be a sports fan. This assumption is the heart of my opportunity. I want to watch sports. The next step, choosing a service. We want them to choose Netflix. What needs to be true for that to happen? They don't just have to want to watch sports. They have to want to watch sports on Netflix. That means they have to have a solution. They have to not have a solution they're already satisfied with. Next, we're going to jump over to choosing a local channel. What needs to be true there? They need to know what channel the game is on. If they don't know what channel the game is on, this solution doesn't work for them. We need to know that we can partner with that local channel. We need to know that when they choose that local channel, the game won't be subject to a local regional blackout. We have sports fans in the audience. You've probably experienced this. It's incredibly frustrating, right? In order for them to watch the game, we need to be able to effectively stream the live sport. And this is not trivial, right? Netflix focuses on TV shows and movies. You can buffer those. And if you're on a weak internet connection, it's fine. Live sports, if we have to do a lot of buffering, I'm watching the game at home, Robin's watching the game at home. If she gets to see the goal before me and she texts me, guess what? My viewing experience just got pretty terrible and I'm pretty upset with Netflix, right? So sports is a whole different game, completely different feasibility assumptions. What does this allow us to do? Some of our assumptions are gonna be shared across all of our ideas. For example, our subscribers wanna watch sports. If we test those assumptions and we find problems, we can rule out sets of solutions. We can decide that's not the right opportunity. That's very quick testing to determine, is this even going to have an impact on our outcome? Is this the right opportunity? Some of our assumptions differentiate our ideas. All these assumptions around who we can partner with, whether they know the channel, whether they'll be willing to install a FuboTV app, they differentiate our ideas. That's what allows us to rapidly collect compare and contrast data. We can start our week on Monday, generating three solutions, and end our week on Friday with some good compare and contrast data starting to look for a clear frontrunner. Okay, we just covered a lot of ground, so I'm going to do a quick recap. We started with setting an outcome at the top of the tree. Remember, our goal is to engage with customers weekly, but that trio is engaging with customers weekly. where they're conducting two small research activities on a weekly basis in order to reach that outcome. The first is they're interviewing every week, collecting specific stories with the goal of discovering opportunities, discovering needs, pain points, and desires. Once we choose a target opportunity to pursue, we're generating multiple solutions, setting up a compare and contrast decision. The way that we're collecting data is by testing our specific assumptions. Our assumptions come in those five categories, desirability, feasibility, viability, usability, and ethical. And we're using story mapping to help us see those assumptions. Now, I know we covered a lot of ground. My goal in this talk was to inspire you to start this process. If you're looking for somewhere to start, I strongly recommend you start with this interviewing habit. If you want support as you're doing this, I do have a new book out. It's called Continuous Discovery Habits. I wrote it to be a hands-on practical guide for teens to put this process into practice. So I would start with the book. Now I know most of us, we read books and we still have a hard time transferring them to what we know. So we also have a number of... products and services that will help you as you're trying to put this into practice. We have a community that can help support you as you're putting this into practice. We have courses that cover each and every habit. So if you want to learn more about that, go check out producttalk.org. And then I think we're going to do one more poll before we turn to questions. Let me pull that up. Okay. So what we really, this is just for us. We'd love to find out how useful this webinar was for you. particularly around giving you actionable tips to help you shift from a project mindset to a continuous discovery mindset. Okay, let's go ahead and start with our Q&A. Let's open up Q&A while folks are still voting here. Okay, so I have a question that actually came in ahead of time that I'd like to kick off with here, Teresa. So as a product manager, We all have so much to do. What do you recommend? Is there anything you could recommend that we do less of or shift priorities or talk to our leadership about adjusting our priorities in order to make time for these weekly checkpoints with customers? Yeah, this is a great question. So oftentimes one of the biggest barriers to getting started with discovery is just time. And this is a huge advantage of continuous discovery. If you have 30 minutes in your calendar every week, You can kick off your continuous discovery process. You might have to first automate your recruiting process so you have somebody to talk to in those 30 minutes. But it's literally that simple as you just need 30 minutes on your calendar. Now, I have worked with teams that are double booked all day long. They don't have 30 minutes. If that's your situation, you need to ruthlessly evaluate where your time is going and what meetings you can drop. I promise you. you don't need to be in every single bug prioritization meeting you don't need to be here's the thing product managers in particular get invited to a lot of meetings it feeds our ego we want to be part of every conversation but if you want to do your job well you need first-hand exposure to customers and you need to find a way to fit that in so i would start with there are probably many meetings that if you stopped going to them nothing bad would happen so if you need to make room for it start there by asking what are those meetings Yeah, that's really critical. It's hard to let go, right? But we have to recognize there's only one of us. And it also may be challenging to free up schedules for your design and your technology lead. But, you know, to Teresa's point, if it's a 30 minute conversation, most of the time we can make time for it. It's just a matter of clearing out that 30 minutes a week. and then commit to it right don't over don't schedule over it and this is the power of automating your recruiting process if there's a customer waiting you're not going to cancel on them yep okay so we've got a couple of other good questions that that came in here um so From Ferry C, is the outcome for this, then the solutions or idea that comes out of this, is that stored in the product backlog or does it go through another interim step? Yeah, great question. So while you're assumption testing, you're evaluating, where you're looking for that clear front runner, you might find a clear front runner right away and you're ready to build it. And some of that is going to depend on how do you make that judgment call of what goes in the backlog. Here's the way to think about it. Whether you're doing any discovery or not, everything that goes in your backlog is a bet. The better your discovery, the better the bet. But it's still a judgment call. So as you assumption test, you're evaluating how much risk is there in this idea and how much risk can my company bear. And you're doing just enough discovery to mitigate that risk. And as soon as you've done that, you can put it in your backlog. Now one of the keys that we did not get into in that much detail in the talk is opportunity mapping. So if you map out opportunity space using this tree structure, you're breaking big opportunities into smaller and smaller opportunities. This is a big key of what unlocks the continuous cadence. if you do that you're always working on a small opportunity which should help you work in smaller batch sizes which will really help you get away from this big project mindset so you're not you're not doing discovery a ton of discovery on a big project doing all this assumption testing and then dropping a big project into your backlog it's more think about it as you're working on small opportunities you're pushing those opportunities your backlog moving on to the next one Okay, great. I also had another really interesting question here. Is continuous delivery a prerequisite for continuous discovery or vice versa? Yeah, this is a really good question. So continuous discovery and continuous delivery obviously go hand in hand. You can start with either. In fact, I would recommend you push on both at the same time. So what happens when they're out of sync? so if you're delivering continuously um usually you're you have this problem where your product and your your discovery is trying to stay ahead of delivery and there's a lot of this scurrying if your discovery is way ahead then you end up getting this big backlog of stuff that's going to delivery so ideally they're really aligned but depending on where your company is at and what your release structure looks like it might take a lot of work to get to continuous delivery. And same with on the discovery side. So most teams, these processes aren't fully lined up, which is why it's still hard for us to imagine what a truly continuous process looks like. But I would recommend you really push on both at the same time. Great. So I've got a good question here from Chris S. how do we break through the org silos that believe engineering is a back-end function that doesn't or shouldn't interact with customers yeah this is a hard one this is the it mindset right you're just an order taker build what i tell you to build so if you're a product manager working on a team like that i would just look for opportunities to invite a customer don't fight the ideological war right don't coming on your horse saying, hey, we got to do this. This is the right way. You're not going to get anywhere. I would look for small opportunities to expose your engineers to customers. So that's from a focusing on your work standpoint. In parallel, I would look for how do you start to expose the gaps that come out from this IT mindset. So a good way to do that is to have your business leaders, when they give you a project, start to work with them to document why are we building this with the expected impact. And then after you release it, measure that impact. What you're doing is you're starting to expose the gap that a lot of our initiatives fall short. This might sound a little bit risky because they might blame you, but it is the most effective way to start saying, hey, we could learn about this gap earlier before we build the product and save time and build better versions of it if you let us do these things. And speaking of what Teresa said about taking a bet, sometimes you have to just take a bet. if you have a tech uh if you are a technical owner or you have a technical owner that is interested in talking to customers hasn't talked to a customer maybe ever and you can have that conversation and they learn something then you have evidence that this is really valuable um so if you're in a situation where you can do that obviously don't go directly against one of your leaders you may have to have other other methods of trying to prove the case here Um, but it is so critical and it is really valuable if you can kind of start to break through those cultural barriers to, uh, um, to continuous discovery. Okay. I think we've got time for, for one or two more here. Okay. So this is a great one. Um, from here on P how do you, how do really big hairy projects or opportunities that might require three to six months feed into this discovery process or vice versa? Yeah, this is where opportunity mapping is really valuable. So I'm going to give an example of this. If we take Netflix again, you could imagine that in every interview that Netflix conducts, they probably hear an opportunity that sounds like this. It's hard to find something to watch, right? If you are a Netflix subscriber or really a subscriber of any streaming entertainment service, you've probably had the experience of like scrolling through a million things, trying to figure out, should I watch this or not? Okay, that opportunity is evergreen. if you work at your streaming entertainment company you are never fully solving it it is going to be a need forever the value of opportunity mapping is you can start to deconstruct it into smaller and smaller opportunities based on what you're hearing in your interviews so why is it hard to find something to watch maybe a sub opportunity is i can't decide if this particular show is good or not maybe another sub opportunity is i have a specific movie in mind and i can't find it right maybe another sub opportunity is I can't remember which service this show is on. I have that problem a lot. That's why the Roku search is magical. So now I can take one of those opportunities, like I can't decide if this show is good or not, and break it down into even more sub-opportunities. How do people decide if a show is good or not? Maybe they ask questions like, who's in this show? That's a sub-opportunity. Or is this like another show that I've watched? or do i have any friends that are watching this show so as we interview we can start to learn about how do people evaluate is this show good or not and all those sub opportunities become even smaller problems to solve and so if we get to an opportunity like who's in this show that's something we can solve in a couple of weeks we can tell you the cast we can tell you who's who right we can tell you what who else what else they've been in when we solve that we don't totally solve this top level opportunity of, I can't find something to watch, but we partially solve it, right? And if we keep doing that over time, we chip away at the bigger and bigger opportunities, but we do it in a way where we don't have to do this six month project before we deliver any value. So the key to a continuous cadence is really taking the time to understand the opportunity space and to really structure it well. Great. Let's do one final question. This is a great one to close out with. How long on average have your clients taken to demonstrate improved results from implementing continuous discovery? Is it a few sprints, a few releases, a year? Obviously, there will be some variance, but they want to manage the expectations of their leadership team as they go to implement this. Robin, you broke up a lot during that question. Oh, no. Were you not able to hear me? Let me try that again. So basically, how long does it take to see results from implementing continuous discovery on the order of weeks, months, a year? And what does success look like? Yeah. Okay. So I think I heard it. You cleared up at the very end. How long does it take to implement continuous discovery? Yeah. And then what does success look like after a month or a year of doing continuous discovery? Yeah. Okay. So when you're new to this process, you have to understand there will be a learning tax for you individually as a team. It's going to take time to get well-versed in the process and to do it well. There's some infrastructure you'll need to have in place to help you do it. Things like automating the recruiting process. With assumption testing, you might want to have access to unmoderated testing tools and one-question surveys and things like that to help you run fast assumption tests. There's a little bit of a time tax just to get that set up, and I go into more detail on that in the book. Once that's up and running, the first time you go through the process, it's going to feel slow and it's really heavy. It's a lot of work. The second time you go through it, it's going to go faster. The third time you go through it, it's going to go even faster. And by like the third or fourth time, you're going to be like, wow, how do we ever work any other way? So that's the first thing is adopting the process will take a little bit of time. So you need to know that going in. What does a successful team look like? I would say you're starting with an outcome. You're quickly uncovering the opportunity space. And in a matter of a couple of weeks, because you can start mapping the opportunity space after just three interviews. Now, you're not done. Opportunity mapping is a continuous activity. you're continuously understanding, mapping out, adjusting the opportunity space, you can choose a target opportunity and get assumption tests live by like week three. And if it's taking you longer than that, it's because you're either still learning, which is fine, you will take a learning tax, or you're just not going fast enough. And so a lot of this is we're pushing the pace because most of the learning is gonna happen in your assumption tests. So think about it as interviewing is giving you inspiration for which problems to solve. but assumption testing is really testing do we have the right solutions is this the right opportunity thank you so much for uh for those answers uh this has been a really really informative uh webinar uh just to help close us out here um if you want to learn more about how to implement a lot of the discovery techniques that teresa talked about definitely pick up her book i want to give an extra plug for that i've read it it's phenomenal And if you need help implementing a lot of the things around continuous discovery, that's where 280 Group can help. We have our two flagship courses, Optimal Product Management and Digital Product Management. Optimal Product Management will help you put a really great framework around your product management practice as a whole. Digital Product Management is a lot more focused on cultural transformation moving from that project to product mindset as a whole so both of these courses will really help along with teresa's wonderful book uh to help you implement all of these things so thank you so much for coming today and uh we'll hopefully see you soon thanks everybody thank you

What is continuous discovery—and how do product teams actually make it sustainable?

In this Productside webinar, Robyn Brooks is joined by Teresa Torres (Product Talk, author of Continuous Discovery Habits) to break down the “what” and “why” of continuous discovery, and how teams can move from project-based research to a continuous cadence of customer learning.

You’ll learn how weekly customer touchpoints, small research activities, and outcome-focused thinking help teams make better decisions about what to build—while reducing rework and improving product results.

What you’ll learn:
• Discovery vs. delivery: what each means and why it matters
• What “continuous discovery” is (a clear, practical definition)
• Why weekly customer touchpoints reduce the “curse of knowledge”
• How co-creation works (without asking customers “what do you want?”)
• The Product Trio: PM + Design + Engineering doing discovery together
• How to recruit customers consistently (and automate recruiting)
• How to interview for opportunities (not solutions)
• Why you should generate multiple solutions to avoid idea bias
• How to test assumptions quickly (desirability, viability, feasibility, usability, ethical)
• Using Opportunity Solution Trees to connect discovery to outcomes
• Practical Q&A: time constraints, silos, big projects, and leadership expectations

Featured speakers:
• Robyn Brooks, Strategic Advisor & Trainer, Productside
• Teresa Torres, Product Discovery Coach, Product Talk

Chapters:
00:00 Welcome & housekeeping
03:00 Introducing Teresa Torres
08:00 Discovery vs. delivery + the project mindset
11:30 Poll: your experience with continuous discovery
15:00 Project-based vs. continuous discovery
19:00 Weekly touchpoints + the curse of knowledge
24:00 Co-creation mindset (and what NOT to ask)
28:00 The Product Trio (PM/Design/Engineering)
41:00 Outcomes vs. outputs + Opportunity Solution Tree
46:00 Poll: biggest barriers
49:00 Automating customer recruiting
54:30 Interviewing for opportunities (not solutions)
01:05:00 Assumptions + story mapping + fast tests
01:12:00 Continuous discovery loop recap
01:16:00 Q&A
01:33:00 Closing & next steps

About Productside:
Productside (formerly 280 Group) is an outcome-driven product partner helping teams connect strategy to measurable business results through training, consulting, and advisory services.
Learn more: https://www.productside.com

Follow Productside:
LinkedIn: https://www.linkedin.com/company/productside
Instagram: https://www.instagram.com/productside_/
X (Twitter): https://x.com/productside_
Facebook: https://www.facebook.com/Productside/