Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. Last week, I was in Cleveland for the Industry Product Conference. I spoke about the three mindsets that help a team find success as a continuous discovery team. You can view the video or read my slides and the full script below. Enjoy!
Full Script
The following script may deviate from what you see in the above video, as it’s the talk script as written, not delivered.
Becoming a successful discovery team
Product management is changing. We are evolving from managing our teams by outputs to managing them by outcomes.
Product managers are evolving from focusing on outputs to outcomes.
Historically, we’ve asked product teams to deliver a fixed roadmap typically defined by leadership. We’ve defined success as shipping a set of features on time and on budget.
As we evolve toward outcomes, we are asking product teams to deliver performance. It’s not just about shipping features, but about creating value for both our customers and our businesses.
As we evolve toward outcomes, it’s not just about shipping features, it’s about creating value for both our customers and our businesses. – Tweet This
We are giving product teams more autonomy to find the best path toward those desired outcomes. Now this might sound like product nirvana. Who doesn’t want the autonomy to decide what to build?
But this autonomy comes with its fair share of responsibility. We aren’t used to being held accountable to delivering outcomes. And for many teams, we are still learning the mindsets and skills that will help us get there.
It’s easy to focus on the new skills we need—interviewing, prototyping, testing assumptions, and so forth—but today I want to talk about the mindsets we need to become a successful outcome-driven product team.
As a discovery coach, I work with product teams from around the world and I’m starting to see some clear patterns.
I work with teams around the world and I’m starting to see some clear patterns.
Today I want to highlight 3 mindsets that are helping product teams consistently drive strong outcomes.
The first mindset is a collaborative mindset.
The first is to adopt a collaborative mindset. It’s easy to give lip service to collaboration. But working on a cross-functional team is genuinely hard. Let’s start by looking at the team itself.
Most concepts of the product team start with the trio.
It starts with the trio. In most cases, this means a product manager, a tech lead, and a design lead. These are the three roles that are typically required to ship a successful product. And if we are truly a collaborative team, then we want all three roles to participate in key product decisions.
It doesn’t mean the product manager decides, the designer designs, and the engineers code. It means these three roles come together to decide what’s the best path to their desired outcome.
It’s not that the product manager decides, the designer designs, and the engineer codes. All three of these roles should come together to decide the best path to their desired outcome. – Tweet This
Now most of us have more than three people on our teams, so what about everyone else?
You probably have a few more engineers and maybe a QA person or two depending on your dev/ops strategy.
Most product teams have at least a few additional people.
And you may also have a few of these other folks: data analysts, user researchers, product marketing, or customer success folks.
Your product team might also include other folks like the ones included here.
While you do want to cultivate a collaboration mindset, you can’t include everyone in every decision. You’ll move too slowly. But you do want to include the right people for any particular decision. Use your best judgment.
So for example, if you work on a data-intensive product, your trio might become a quad. You may want to invite your data analyst to participate in most key decisions.
But don’t fall into the trap of including everyone just to avoid hurting anyone’s feelings. Collaboration is not consensus. Get the right people in the room to allow you to move quickly while still leveraging the right expertise on the team.
Collaboration is not consensus. It’s about getting the right people in the room so you can move quickly while still leveraging the right expertise. – Tweet This
Now that we know who should be collaborating, let’s turn to what collaboration looks like. Or rather let’s start with what it doesn’t look like.
Avoid opinion battles or deferring to the highest paid person’s opinion.
To start, we want to avoid opinion battles. We’ve all been there—sitting in a conference room having an endless debate about the right thing to build. This is the wrong way to collaborate and it’s the wrong way to make product decisions.
Collaboration doesn’t mean advocating for your point of view. It means exploring everyone’s points of view and using those disparate perspectives to create a new combined point of view.
Avoid hand-offs and break down silos.
We also want to avoid hand-offs. We need to break down our silos. It means we don’t let the product manager make all the decisions. We don’t limit designers to designing screens and engineers to writing code. We come together as the human problem solvers that we are and we work together to co-create solutions.
I’m not telling you anything new. The Agile crowd has been telling us this for years. But hand-offs feel efficient, which is why we are attracted to them. We assume they’ll go well. But far too often, they don’t. So skip the hand-offs and work together.
The best way to facilitate team decisions is to base them on a shared understanding of our business, our customers, and the solutions we might build. We need to all work from the same starting point. Too often we disagree or resort to hand-offs because we don’t do the work to reconcile our different perspectives.
We let the product manager be the voice of the business, we let the designer be the voice of the customer, and we let the engineer be the voice of what’s possible with technology. Instead of combining our knowledge, we argue over which voice gets precedence.
Collaboration requires that we integrate this knowledge and integrate these voices. Collaboration is hard because language is vague. It’s easy to think we are aligned when really we each walking away thinking something slightly different.
Collaboration is hard because language is vague. You might think you’re aligned when really each person is walking away thinking something slightly different. – Tweet This
We need to develop a shared understanding of our business, our customers, and the solutions we might build.
I want to give a quick shout out to Jeff Patton for this image. It’s one of my favorites and it comes from his book User Story Mapping: Discover the Whole Story, Build the Right Product.
We can avoid this fate by developing our skills as visual synthesizers. Maps force us to get more concrete, more specific. They help us build and maintain a shared understanding.
You can use experience mapping to get aligned on what you know about your customer.
Experience mapping helps you align around the customer context.
You can use an opportunity solution tree to get aligned on the best path to your desired outcome.
Opportunity solution trees help you align around the best path to your desired outcome.
You can use story mapping to get aligned on specific solutions.
User story mapping helps your team align around specific solutions.
There are many types of maps. You want to use the right map for the right context.
Use maps to help you create and maintain a shared understanding. These are living documents. The maintenance work is just as important as the creation work.
You’ll find that if you invest in building and maintaining a shared understanding, your team decisions will go more smoothly and you’ll be on your way to becoming a truly collaborative team.
Let’s look at the next mindset.
The second mindset is a continuous mindset.
The best teams foster a continuous mindset. This means their discovery is never done. Their delivery is never done. They embrace continuous iterations.
This is different from what many teams do. Too often we take a project mindset where we start with a little bit of discovery, do a bunch of delivery, ship a feature, and then move on to the next project.
Over the years, we’ve defined a clear picture of what continuous delivery looks like, so I’m going to focus on continuous discovery. Let’s start with a definition.
This is how I define continuous discovery.
I define continuous discovery as weekly touch points with customers, by the team building the product, where they conduct small research activities, in pursuit of a desired product outcome.
Continuous discovery is: weekly touch points with customers, by the team building the product, where they conduct small research activities, in pursuit of a desired product outcome. – Tweet This
Every word on this slide matters, so let’s dig into why, starting with weekly touch points with customers.
We have the opportunity to make product decisions every day.
We make product decisions every day. Some of them are big decisions like what opportunity to go after next, others are small decisions like what to label a button. But they all matter.
With a continuous mindset, we want to infuse as many of those decisions with customer input as possible. That means we need to reduce the cycle time between customer touchpoints.
I recommend engaging with customers every week.
We want to engage with customers every week. We don’t want to save up all of our questions for a monthly interview. That overwhelms our customers and it holds up our product decisions. If we want to move fast and we want to be customer-centered, we need to engage with our customers every week.
Engaging with customers every week allows us to co-create with them.
This cadence allows us to co-create with our customers. Too often we take a validation mindset with our customers. We think we’ll solve their problem and then validate with them that we got it right. But if you engage with your customers early and often, you’ll start to develop a co-creation mindset, where you’ll invite your customers to participate in your team decisions.
This doesn’t mean that we are looking for our customers to tell us what to build. But it does mean that we work to collaborate with our customers, integrating their perspective into our team perspective.
This is how I define continuous discovery.
So back to our definition. Weekly touch points with customers, by the team building the product.
Your product team might look something like this.
We’ve already defined the team.
This is how I define continuous discovery.
Where they conduct small research activities
In pursuit of a desired product outcome.
These last two lines are going to take some time to break down. I often see teams who are great at research, but don’t meet their outcomes. Some don’t even ship a product. That’s because their research isn’t in service of a desired outcome. Let’s talk about how to avoid that.
Here’s a basic version of the opportunity solution tree.
I mentioned earlier that an opportunity solution tree can help us map a path to our desired outcome.
It’s important to start with defining a clear desired outcome.
It starts with defining that desired outcome. This is a quantitative business outcome. If you are using OKRs, it’s a key result.
Next, you can focus on discovering opportunities that drive to your desired outcome.
We then want to discover opportunities that will drive that desired outcome. Opportunities are customer needs, pain points, desires, wants. We aren’t going to include every customer opportunity we hear about, only the ones that if we addressed them would drive our business outcome. This is how we can reconcile the tension between business needs and customer needs. We start with a business need and only consider customer needs that will drive that business need.
Next, you need to discover solutions that deliver on those opportunities.
And of course, we need to discover solutions that will deliver on those opportunities.
As a reminder, here’s the opportunity solution tree.
So with this as our starting point, let’s walk through how product teams can use a continuous stream of small research activities to reach their desired outcome.
The desired outcome should be set by a two-way negotiation between leadership and the product team.
Discovery is only as good as the outcome you set. I recommend this be a two-way negotiation between the leadership team and the product team. Too often, product teams are told what outcomes to drive, or product teams set their own outcomes without input from the business.
Since the outcome is a business outcome, we want leadership to provide input on what creates the most value for the business and we need the product team to provide input on what’s feasible in the given time frame.
Use generative interviews to understand the customer’s context.
We then want to use our interviews to discover opportunities. Remember, opportunities are customer needs, pain points, desires, and wants. The purpose of a generative interview is to understand your customer’s context well enough to identify opportunities that if we addressed them might move our desired outcome.
Interviews help us map out the opportunity space.
Remember to generate multiple solutions for the same idea or opportunity.
We also want to generate multiple solutions for the same target opportunity. Most teams consider a lot of ideas, but we consider a lot of ideas for different problems. Instead, we want to generate multiple solutions for the same problem or opportunity.
Avoid asking yourself questions like “Is this a good idea?”
This helps us avoid “whether or not” decisions. When we ask, “Is this idea good or not?” we set ourselves up to fall prey to confirmation bias. We only see the evidence that confirms that our idea is good and we overlook the disconfirming evidence.
Ask yourself which of the solutions best addresses the target opportunity.
Instead, we want to set up compare and contrast decisions. We want to ask which of these solutions best addresses the target opportunity. This sets up a relative decision.
I often get asked, “How do I know if my prototype feedback is good enough or if my experimental results are strong enough?” These are absolute questions that are impossible to answer. When we compare and contrast solutions, we can make a relative judgment by asking, “Which of these ideas looks most promising?”
Let me give you a visual that will help you remember this.
Imagine that you saw Usain Bolt, the world’s fastest 100m runner, running around a track by himself. Could you answer the question, “Is he fast?” Fast relative to what?
But if you saw Usain Bolt running against other runners, suddenly it’s a much easier question to answer. Usain Bolt is fast relative to other runners.
When you see Usain Bolt running against other runners, it’s much easier to say whether or not he’s fast.
So remember, consider more than one idea to solve the same problem so that you can make compare and contrast decisions.
We need to be able to prototype and test our solutions.
Finally, we want to prototype and run experiments to test those solutions. We need to test “Are they usable and feasible?” but we also need to test, “Do they deliver on the target opportunity, and do they do so in a way that drives our desired outcome?”
The opportunity solution tree reminds us to test all of our connections, ensuring that we are addressing real customer needs while also driving a desired business outcome.
Now you might think this process is linear. First, you define a desired outcome, then you conduct interviews, and finally, you generate and test solutions. But that’s not the case.
This is what the process of continuous discovery looks like.
This is a continuous process. As we explore solutions, our understanding of the opportunity space evolves. As we learn about new opportunities, they inspire new solutions. And as our understanding of the opportunity space evolves, we learn more about whether or not our desired outcome is feasible. The links on the tree move both directions: up and down.
So we want to continuously build along the whole tree. This is what a continuous mindset looks like.
Moving through the opportunity solution tree is not linear. We build all parts of the tree at once. This is what continuous discovery looks like – Tweet This
The third mindset is an experimental mindset.
Finally, we want to develop an experimental mindset.
You’re probably already familiar with these concepts thanks to The Lean Startup.
Thanks to The Lean Startup, this probably isn’t news to you. However, we have a problem with the current state of product experiments.
Bloodletting is a practice that has a legitimate purpose in a very small number of instances, much like A/B testing.
Most of us are running experiments like 17th century scientists. This is a photo of bloodletting, a medical practice that has a legitimate purpose in a very small number of instances. However, doctors incorrectly used it in far too many medical cases. Our equivalent of bloodletting is A/B testing.
A/B testing is a fantastic measurement tool. It tells us if our code changes had the intended impact. However, it is rarely the best discovery tool. It’s too expensive. It requires that we build almost everything before we learn whether or not that was the right thing to build.
So we need to expand our repertoire of experiments to include prototyping, smoke screen tests, Wizard of Oz tests, concierge tests, and so on.
But this isn’t the only experimental mistake we make.
We can’t assume that we’re going to be successful.
Too many teams, when choosing which experiments to run, assume success. We assume our product ideas will work, so we skip over the obvious experiments. We assume people will want our solution. We assume they’ll know how to use it. We assume they’ll know where to find it. And so on.
I can’t tell you how many times I’ve heard a team say something like, “What will we have learned from that experiment?” Because they are focusing on the success case. We don’t run experiments to learn from the success cases. We run experiments to learn from the failed cases.
Karl Popper embodied an experimental mindset.
Karl Popper advocated for this. He argues, “Good tests kill flawed theories; we remain alive to guess again.” This quote embodies an experimental mindset. We need to design our experiments to help us learn from the failed cases.
In order to make better decisions, we need to be prepared to be wrong.
Chip and Dan Heath, authors of Decisive, agree. They summarized the research on good decision making and argue, to make better decisions, we need to be prepared to be wrong.
Wisdom involves balancing between confidence and doubt in what you know.
Karl Weick, an organizational psychologist at the University of Michigan, defined wisdom as the balance between having confidence in what you know and doubting what you know. We need to have confidence to move forward, but we need to leave room for doubt, so we can recognize when we are wrong.
It’s important to maintain a state of doubt to carry on an inquiry.
John Dewey, an educational philosopher agrees. He talks about maintaining a state of doubt so that you can carry on a systematic and protracted (for longer than expected) inquiry. He argues this is required for good critical thinking.
The opportunity solution tree will help you conduct a systematic search for the best path to your desired outcome. An experimental mindset will help you conduct a protracted inquiry.
Dewey describes the back and forth movement between creating an inductive theory and using experiments to deductively test it.
Dewey further describes critical thinking as the double movement of reflection. He talks about the back and forth movement between creating an inductive theory and using experiments to deductively test that theory. Now don’t worry too much about the labels induction and deduction, here’s what matters: As you learn about your customers and map the opportunity space, you are developing an inductive theory about how your customer’s world works and how you might intervene. Our prototypes and experiments are deductive tests that allow us to test that theory.
And again, this isn’t one-directional. As we run deductive tests, we learn what was right and wrong about our inductive theory, and our inductive theory evolves. As we explore solutions, our understanding of the opportunity space evolves.
So we’ve got Eric Ries, author of The Lean Startup, Karl Popper, a philosopher who drove a significant evolution in how we practice science, Chip and Dan Heath, the authors of Decisive, a book that summarizes the research on good decision making, Karl Weick, an organizational psychologist at the University of Michigan, and John Dewey, an educational philosopher, effectively all saying the same thing.
To experiment well, we have to be prepared to be wrong. We have to introduce doubt into our decision making. We have to focus on the learning that comes from failed experiments. This is what it means to have an experimental mindset.
To experiment well, we have to be prepared to be wrong. – Tweet This
And since this is a long list of white dudes, I’m going to add myself to the list.
I took the liberty of adding myself here since otherwise it’s a long list of white dudes.
Let’s sum up.
The three mindsets that you’ll want to cultivate.
As you return to work, these are the three mindsets that you’ll want to cultivate.
- A collaborative mindset: Do you have the right people involved in each decision?
- A continuous mindset: Are you continuously discovering opportunities and solutions?
- An experimental mindset: Are you prepared to be wrong?
Grab your copy of the opportunity solution map on Product Talk.
And finally I want to leave you with a parting gift…
If you’d like a copy of this map of continuous discovery activities, you can grab one here.
Stay in touch!
Thanks everyone!
Grateful and thankful for your insight. So needed to bring about the change needed to delight the customer.
Hi Teresa,
Great speech! I am happy to see how the Opportunity Solution Tree evolved to a Continuous Discovery Map!
I am a Group Product Manager at Catho, a jobs marketplace in Brazil, and we have been implementing a continuous discovery approach for 6 months. We still have a lot to evolve but it has been a great journey. And the opportunity solution tree has been part of it.
I have one question: The continuous discovery approach focus on customer interviews as the main way to map opportunities and I agree with that, but I also believe that quantitative analysis on how a product is being used can also be very useful to map opportunities. Do you agree that quantitative analysis should be considered in parallel to customer interviews? If so, do you have any recommendation on how to add insights coming from this source to the opportunity solution tree?
Hi Rodrigo,
Your data analytics can be good inspiration for opportunities, but I would still vet them with customer interviews. Your analytics will tell you what people are trying to do, your interviews will tell you why they care about that.
Teresa
Thanks for your answer! It makes total sense.
I really enjoyed this speech, it hit on so many things that we are trying to work out on our team right now. In your opinion where does consumer experience strategy come in?
Very helpful presentation, thank you! How have you seen company’s overcome the fear of bugging clients/users too much with continuous interviewing? Do you establish a group of clients that have opted into hearing from the product team? If you have written about this before, please share your blog post. I’m interested in your insight here. Thank you!
Hi Tracy,
In my experience, most customers are more than willing to talk to companies if they are getting value out of the product. They want to help make it better. You do have to respect their time, compensate them, and close the loop with them on what you are doing with what you learned. For very small markets, you might need to consider how often you go back to the same people over and over again. But generally, as long as you are respectful and you act on what you learn, most folks are happy to help.
By the way, I cover recruiting interview participants in my Continuous Interviewing course: producttalk.org/course/continuous-interviewing
Very helpful, thank you so much for sharing!
In my company, we are in the midst of adopting Spotify structure, specifically building squads for each product or large features. Do you think continuous delivery can work within each squad?
Hi Joseph, Yes absolutely!
Loved the article. Thank you so much for writing about your insights and experiences.