Creating value with continuous discovery—a discussion with Teresa Torres (Part 2)
Continuous discovery means you prioritize regular interactions with your customers and use what you learn in those interactions to fuel your product strategy. While many teams agree with this concept in theory, they can find it hard to implement a true continuous discovery practice.
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, our host Scott Baldwin did a deep dive into continuous discovery with Teresa. In Part 1, 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 below, they discussed 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.
Watch the webinar on-demand
How would you advise teams to make the shift from outputs to outcomes?
There’s a bit of a spectrum with how empowered teams are. Some teams are given customer problems to solve, which is giving them an opportunity and asking them to go explore solutions. That’s fine, but that’s less of an empowered team than one where you say, “Here’s the business value we need you to create, go explore the opportunity space and then explore solutions.”
When setting outcomes—if we’re focused on business value—we’re almost always starting with financial metrics like “increase revenue” or “increase market share.” Or maybe there’s a strategic initiative, like “We want to be the number one browser in China.” That’s fine. All of that ties to revenue in one way or another.
The important thing is if a product team can realize that ultimately a business is trying to increase revenue or decrease costs, we can break that down and ask how the product supports that goal. We can have a theory about how the product is going to support the customer in a way that will drive that business outcome. This gives the product team the context they need for how their product is supporting the business. And this is missing in a lot of organizations because a lot of companies don’t take the time to define how the product should drive business outcomes.
Some people get uncomfortable when they hear me talk about this because they wonder if it’s really all about increasing revenue. They’ll ask, “Isn’t it about pleasing the customer?” But if you just focus on the customer and you don’t create business value, you’re going to go out of business. That’s the reality. You’re earning a paycheck by creating business value. Yes, we want to be customer-centric and we want to serve the customer—we have to balance both.
We’ve all worked for leaders who have a hard time giving up ownership. What can teams do to move away from that and start co-creating?
I think about this as a trust gap and it’s completely understandable. A leader is being held accountable to their own outcome. Even if they completely believe in empowered teams and give their teams sub-outcomes that they’ll be responsible for, this works until it looks like someone’s not on track to meet their outcome. What’s that leader going to do? Under stress, we fall back to what we know. And most leaders understand the command and control, hierarchical, dictating outputs approach. Leaders tend to jump in and say, “You’re not getting to where I need you to be. Let’s just do this.”
The key is that both parties can adapt to help prevent this. We have to overcome the trust gap. Teams need to be communicating on a regular basis. They need to learn to show their work. And what’s great about discovery is that if you’re working as a cross-functional trio, you need to be externalizing your thinking visually to stay aligned. And those same artifacts—whether they’re experience maps or opportunity solution trees or story maps or assumption maps—all of these are visual activities that can be used to bring your stakeholders along.
And the more you’re communicating the learning journey and not just your conclusions, the less likely your boss will helicopter in and say, “Here’s the solution I want you to build,” because they’re going to have the full view of what you’ve been doing.
Most people don’t take the time to visualize their thinking. It all stays in our heads, and we fall back to these opinion battles. Thankfully, your discovery activities are going to force you to externalize your thinking and those exact same visual artifacts can help you with managing stakeholders and closing that trust gap.
You talk a lot about product trios. What I’ve seen in the past is that engineers don’t really get involved in the interviews. How can teams overcome that problem and truly get to work as a trio?
We have this really strong belief that the value an engineer creates is code. And we have to just kill that. Engineers are humans. They’re some of the smartest people in our companies, and we need to treat them like that. We don’t want to just say, “Go be a code monkey.”
We’ve trained engineers to be order takers, so we can’t just say, “Hey engineer, come be a part of discovery, we want you to be a part of the decision-making.” Because we have a trust gap with them, too. They don’t believe us, because they’ve had opinions for years and we shoot them down. So we have to take time to rebuild that trust.
You’ll also hear a lot of engineers say, “I don’t want to be a part of discovery.” And that’s because a lot of engineers want to sit in front of their computers and write code. And we’re telling them, “Come talk to this customer.” For a lot of them that’s scary, so we have to remove the unknowns. We can start small. We can give them a recording and ask them to watch it and tell us what they think. Ask them to join the next one live and take notes.
We need to create an onboarding ramp—just like we do with customers—for our engineers into discovery. While I’ve met lots of engineers who don’t want to be involved in discovery, I’ve never met an engineer who didn’t have an opinion about what they build. Engineers push back on requirements all the time. They have very strong opinions about what they should be building and how it should be built. So you have to create a culture where you make decisions about what to build based on what you learn during discovery. If you want to have an opinion about what we build, you need to be part of the discovery process.
A lot of people are struggling to become better storytellers. What does that shift to becoming a better storyteller look like and what are some tools that could help?
Product teams have to influence. That’s just the reality. Your job is to communicate what you’re learning about your customer and how that’s going to affect your plans as a team and what’s going to ultimately drive the outcome.
Some people think of this as, “I got into product management because I don’t want to sell. I want to leave that to the salespeople.” Everybody sells. In fact, Daniel Pink has a book I love that’s called To Sell Is Human. That is true. Every single person sells. You sell at home with your spouse about who’s going to do the dishes after dinner. We’ve got to let go of thinking of sales and marketing as this dirty thing.
I like to frame it as, “My job is to tell the customer’s story.” And if I’m collecting customer stories in my interviews, I’ll have plenty of material. It’s less about the fancy bells and whistles and it’s more about being human and telling human stories. How are we always making sure that the customer has a spot in the story? And that dramatically simplifies what your job is. If you’re using user experience maps and opportunity solution trees and story maps and assumption maps as part of your discovery work, those same artifacts do a great job of telling your customer’s story.
It really puts it back on product managers being advocates for our customers. I got to see you speak at ProductCamp Cascadia a few months ago and I really enjoyed your talk about justice, equity, diversity, and inclusion, or JEDI as you called it. What inspired you to start considering product work from that framework?
Here in the US over the past few years, it’s become a lot harder to ignore social inequities. 2020 turned that up significantly, with the George Floyd death and all of the protests in response to that. In Portland, Oregon, where I live, homelessness is a massive problem.
As a product person, my inclination is, I’ve got to get involved in my community. How can I be a part of the solution? And it just seems like an intractable problem. I always start with: What’s within my sphere of influence? How can I have a positive impact? And I’m very fortunate in that I have a voice within the product world. And I don’t know how to use that voice to address the homelessness problem—I hope that someday I will—but right now I do know how to use that voice to help us make better products. And we see these exact same social inequities show up in our products.
I gave a few examples in that talk, like why do all of our voice assistants have female voices? And why do we build medical devices that don’t work for people with dark skin? There’s example after example. And these product teams were not nefarious. Hopefully, they were not intentionally racist or sexist. But those outcomes are showing up in their products. We’re replicating the social injustices that we see in our communities in the products that we build. So I just wanted to start a conversation around how we can fix this. What role can we play in the sphere that we influence? And my hope is that if I start practicing in the realm I understand, I will find a way to have a broader impact on the communities that I live in.
Reflecting on your past 7+ years as a product coach, what’s the accomplishment that you’re most proud of?
Right now I’d have to say my book, Continuous Discovery Habits. I have been trying to write this book for five years and the fact that I wrote it during COVID is pretty phenomenal in my mind. The response has blown me away.
Someone wrote a review on Amazon that basically said, “A lot of books feel like they’re an advertisement for a workshop and this book feels like it is the workshop.” And that was my goal. Most people read books and don’t know how to apply them, which is why I have coaching, courses, and other resources. But I wanted to write the book for the people who do have the ability to apply the learnings, because I really think if everybody worked this way, we’d have much better products and we could be a part of positively impacting the world we live in.
And this was a new skill for you—writing and self-publishing your first book. Any advice you can give to aspiring product folks looking to write their first book?
It was a lot harder than I thought it was going to be. I made the mistake of announcing in 2016 that I was going to write a book. Maybe it wasn’t a mistake, because by the time I released the book there was so much anticipation that it was really fun. But that was not by design. I really did intend to write a book in 2016.
What I ran into was, a book is a product, but it’s very much a waterfall product. You write the whole book before you get any feedback—and that’s just not who I am. I needed customer feedback, I needed to iterate, I needed to test, I needed to experiment.
I realized I was really uncomfortable with the way books get written. So I shifted and started designing online courses. I took my coaching curriculum and flipping the classroom where my coaching students watched videos and read content before they came to coaching. That allowed me to test the content. I was testing what works in a lot of different contexts, because I know it’s easy for people to read something and say, “That will never work in my organization.” I wanted to make sure that the methods would work in a lot of different environments.
And then, at the end of 2019, I started to see that a lot of my coaching teams were getting a ton of value even before they came to the coaching session, so then I felt like it was time to write the book.
I self-published mostly for business reasons. I talked to a number of publishers and none of them could convince me why I should give them 80% of my profits. They don’t do anything to market your book until you have 1,000 readers. Even then, they just market through traditional channels. I knew that through Product Talk and my social media channels I could reach product people and I thought I could reach them better than through a traditional publisher. And it’s been phenomenal. I paid an agency to do all the work that a publisher would do in terms of cover design and copyediting and things like that, and I was number one in a number of categories for many days on Amazon. So I don’t think I needed a publisher. I think it’s worked out just fine.
