Creating value with continuous discovery—a discussion with Teresa Torres (Part 1)
How do you build products your customers use and love? You won’t know unless you ask them. And it doesn’t work to ask them once when you start a new project. You need to have regular touch points with customers so you never go too long without seeking their input.
The practice of continuous discovery creates a regular cadence of interaction between the product team and the customers they’re building for.
Teresa Torres is an internationally acclaimed author, speaker, and coach. She teaches a structured and sustainable approach to continuous discovery that helps product teams infuse their daily product decisions with customer input.
In a recent webinar, host Scott Baldwin did a deep dive into continuous discovery with Teresa. In Part 1 below, they discussed the mindset shift required to transition from project-based discovery to continuous discovery and some of the key steps you can take to build a continuous discovery practice in your organization. In Part 2, they covered how to get leaders and engineers bought into discovery and how Teresa applied the continuous discovery framework to the process of writing a book.
In case you missed it, here’s an edited version of the conversation.
For those who aren’t familiar with continuous product discovery, can you give us an overview?
At a lot of companies, it’s really easy to put emphasis on delivery—to get products out there on time and on budget. And we’re seeing that companies are starting to realize that making decisions about what to build is equally as important.
Product discovery is just: How do we do that? How do we make good decisions? Hopefully we’re doing it in a customer-centric way. And the continuous bit is instead of taking a project mindset to discovery, how do we infuse our whole development process—all the way from deciding what to build to shipping it—with fast feedback cycles with customers. It’s not rocket science; it’s just the mindset shift from project to continuous is a tough one. A lot of us haven’t really seen what continuous looks like, so it’s hard to wrap our heads around it.
In your book, you summarize continuous product discovery as “at a minimum, weekly touchpoints with customers by the team building the product where they conduct small research activities in pursuit of a desired outcome.” I imagine a lot of teams have pieces of that but aren’t sure how to get there. What are some of the common points where teams struggle?
I worked with a lot of teams who would say, “Teresa, we already do continuous discovery and we just need your help fine-tuning.” And then as we worked together, I realized they were doing discovery activities on a regular basis, but from a project mindset. The outcome piece was missing.
So many teams these days are using OKRs, so it feels like we’re outcome-focused, but a lot of OKRs get written as outputs. Just as the project to continuous mindset shift is difficult, so is the output to outcome shift. If your outcome is “Build an Android app,” that’s really an output. We see a lot of vanity metrics in outcomes like, “Get X number of reviews on the site.” That’s still very output-focused.
The team that’s building the product needs to be engaging with customers—you can’t rely on other teams to hand you research. If we’re involved in the research, it’s more believable to us and we’re more likely to act on it.
Product teams work on a cadence that’s really different from the rest of the organization. We’re trying to ship software every week. We have teeny-tiny questions that we want to get fast answers to. Your centralized research teams are not going to be able to support multiple product teams with a whole array of questions every single week. Product teams need to be equipped to go get fast answers themselves.
We need to balance creating business value and customer value. The opportunity solution tree is designed to balance both. The outcome at the top of the tree is your business value. As you explore the opportunity space, that’s your customer value. We’re trying to resolve the tension we often see between that business value and customer value.
You’ve spent 7+ years educating the product community about product discovery, and I feel like I’ve seen you speak about this at about 50 conferences. Why do you think we’re still struggling with this as product teams?
Here’s the reality: Business culture evolves really slowly. I can go back 100 years to Taylorism and measuring efficiency and how fast processes are. Even just going from Taylorism to the 1950s/1960s Michael Porter/Henry Mintzberg strategy world, we still see a lot of companies with that efficiency mindset over a strategy mindset. And the Porter strategy was introduced 70+ years ago.
Now we’re taking a step even further and saying the future is uncertain. A lot of our business practices are designed around predicting the future. We have five-year strategic plans and we budget for projects on an annual basis.
If there’s any silver lining to this horrible global pandemic we’ve been through, it’s that a lot of companies had to learn how to pivot and we got a dose of what it’s like to respond in an uncertain environment. And maybe that will teach us how to adapt our practices and step a little bit more into this agile world where we can’t predict the future and we have to limit our work in progress. We have to work in smaller chunks, we have to get feedback along the way.
Marty Cagan did a great job giving the foreword in your book. He talks about how product leaders often want to improve but lack the hands-on experience and knowledge to coach their people. How do you overcome those limitations when introducing continuous discovery to a team?
What’s happened is the world has changed really rapidly, our discovery methods have evolved, and there are a lot of product leaders who did product management in the traditional waterfall way when they were individual contributors. They want to manage empowered teams, but they’ve never seen it work in practice. They don’t know how to lead those types of teams, and so this is a real challenge.
How do you manage a team when you haven’t worked that way? Thankfully, we have a lot of resources to help. Marty’s book, Empowered, and Petra Wille’s book, Strong Product People, are fantastic. There are a ton of people working as coaches now, so a lot of those leaders can bring in a coach to help.
Here’s what they shouldn’t do: Hire a coach and consider it done. One of the things I’ve been telling people is, “Yes, you need to train your teams, and your teams need to build the discovery skills to start with the outcome and know what to build, but so do the leaders. The leaders need to understand the process their teams are going through inside and out.”
Don’t just send your team to Marty Cagan’s workshops—go yourself. Don’t just buy a book for your team—read it yourself. It’s really easy to think the problem is the team, whereas it really does take everyone moving in the right direction.
You mention in the book that the purpose of customer interviews is to discover and explore. How can product teams improve their customer interviews?
In the book, I talk about two primary research methods—interviews and assumption tests. They play different roles. Interviewing is primarily a generative activity, where we’re trying to generate opportunities (customer needs, pain points, and desires that would drive our outcome if addressed). Think about interviewing as a strategic decision of what we are going to go after.
Assumption tests are how we’re going to evaluate potential solutions. It’s also how we’re going to evaluate if we picked the right opportunities. Teams tend to confuse these two.
In both research methods, teams need to build skills in understanding what leads to reliable and valid research. And this is a really big gap in the industry because we’re not academic researchers. We can’t just take academic research methods and apply them ibecause they happen in different time frames. Academic research happens over decades and industry research needs to happen on a day-long timeframe.
One of the things I try to do is develop research methods that work on the timeline of a product team but increase the reliability and validity of what we hear back. For interviewing in particular, the key that I teach is to keep the majority of the interview grounded in specific stories about your customer so it’s not about your solution; not inviting them to speculate about their own behavior, but keeping them grounded in telling you about what they actually did in specific instances.
In your book, you have lots of advice on how to automate the customer recruiting process, like targeting customers while they’re using your product, getting customer-facing groups involved, setting up customer advisory boards, etc. Any favorites that you can recommend?
My goal was to design a discovery framework that was sustainable and structured. The opportunity solution tree gives structure to how we reach our outcome. The sustainable piece is that it has to be something we can do as part of our work 50 weeks of the year—or 48 if you have more vacation time than the average American.
And this is important because we have really good discovery activities that are occasional activities. Design sprints are amazing, but we can’t do a design sprint every week of the year. People just don’t have time for that.
So what I try to look at are methods that are sustainable. The only way interviewing is sustainable week over week is if you automate your recruiting process. And what I mean by that is you show up on Monday morning and you already have an interview on your calendar and you didn’t have to do anything to get it there.
This sounds magical to people, but the vast majority of teams that I work with get there. The three most common ways are the ones that you mentioned. The first one is how 80% of teams automate the recruiting process, and that is to recruit people while they’re using your product or service. It’s going to take some experimentation. You’re not just going to launch something and it’s going to magically work. You’re going to have to experiment with what you ask for, how much time you ask for, when you can schedule the interviews, what you offer as an incentive, where you place the ask. There are a lot of variables to play with.
The other 20% is when you’re in a B2B product and you want to interview your users, but you also want to interview buyers who may not regularly be in your product. Or you need to interview people who are super time-constrained, so that could be Fortune 500 CEOs or right now, respiratory ICU doctors and nurses, etc. There are some people with audiences that are really hard to reach and that’s where some of the other tactics are going to be important to experiment with. No matter how you automate your interview process, you have to take a continuous improvement mindset. It will take iteration and experimentation.
