Why There’s No Single “Right” Way to Do Discovery: Part 1

A few months ago, fellow Product Talk coach Hope Gurion and I sat down to discuss why there’s no single right way to do discovery.

In this first conversation in the series, we discussed three guiding principles of continuous discovery: building a collaborative decision-making model with the product trio, externalizing your thinking, and focusing on outcomes.

You can watch the recording above or read an edited version of the transcript below.

Teresa Torres: Let’s start with some introductions. I’m Teresa Torres, I’m joined by Hope Gurion. We are both product discovery coaches with Product Talk. Hope also does some leadership coaching with her own company, Fearless Product. We’re also joined by Melissa Suzuno, who is going to be monitoring the chat and managing your questions in the Q&A. Melissa and Hope, do you want to say hello?

Hope Gurion: Thanks, Teresa. It’s awesome to see how many people are joining from all over the globe. Thank you so much. Teresa and I have worked together for a number of years. I used to lead product at CareerBuilder. I later joined Beachbody and was their first head of product.

I have been working with the techniques we’re going to discuss today. I recognize the importance of discovery to help people make sure they’re working on the right problems. It is such a powerful way to work—it builds more purpose and meaning in the work that you do. I’m delighted to hear your questions and learn more from each of you today in terms of where you’re challenged and how we can be helpful.

Melissa Suzuno: Hi, everyone. I’m Melissa. I help Teresa out with content for the Product Talk blog. I also help out with these webinars. I’m really looking forward to hearing all your great questions later on.

Teresa: For those of you that are Product Talk readers, Melissa writes our Product in Practice series where we’re sharing stories about teams doing great discovery work, so you may have seen her name there.

Let’s go ahead and dive in. Today we’re going to be talking about why there’s no single right way to do discovery. I know that Hope and I hear a lot from the teams that we work with that most product people are really eager and they’re really diligent. They want to do the right thing. And this is a little bit of a hard concept when it comes to discovery. Hope, do you want to talk about why this is such an important topic?

Why There’s No Single Right Way to Do Discovery

Hope: Everybody recognizes what’s gone wrong in the past and they don’t want to face making those mistakes again or creating products that aren’t used, weren’t valuable, or didn’t solve the problem in the right way. And so they’re looking for a right answer to get everybody in the organization on the same page and know that it’s been blessed in some way. That is really challenging, because there are many right ways to do discovery. We want to help people focus on how it’s going to work best for your organization, for your teams, to make good decisions that drive value for your customers and your companies.

We want to help people focus on how continuous discovery is going to work best for your organization, for your teams, to make good decisions that drive value for your customers and your companies. – Tweet This

Teresa: This is something that I see a lot where somebody reads about a framework or a tool or a technique and they fall in love with it. And they say, “This is the only way to do this. Everybody needs to work this way.”

Another symptom we see is a company will do coaching with us. They’ll come to a workshop or they’ll do somebody else’s training and they want everybody in the company to work the same way. It’s a little bit like, “What’s the product discovery Bible for our company?” There’s this tenet from the Agile Manifesto that’s really important, which is that each team owns the way they work and they’re constantly iterating on it to make it better.

Even if we all share a common starting point, as soon as we start iterating as a team on how to make our work practices better, we’re all going to end up in different places. And that’s not a bad thing. It’s allowing each team to really find what’s going to work best for them. It’s really extending some of the Agile mindset, but also internalizing this continuous improvement mindset and applying it to how we work.

Even if we all share a common starting point, as soon as we start iterating as a team on how to make our work practices better, we’re all going to end up in different places. And that’s not a bad thing. – Tweet This

Hope and I are both discovery coaches, we teach teams how to do discovery better. So you would think that of all people on the planet, we would have a “right way” of doing discovery. We certainly teach specific methods. But something that we’ve recognized working with teams is that every company is unique, every customer base is unique. How you reach those customers is going to change based on who they are, and how busy they are, and what their lives are like.

One of the things we look at in the way that we teach is not “What’s the right method?”, but “What are the underlying principles that we want to see each team move toward?” And then we work with the team to co-create the methods that get them there.

That’s what we’re going to cover in the next three webinars. We have seven or eight different principles that we’re going to talk through. We’re going to tackle the first three today. We’re going to spend about ten minutes on each of them and then we’re going to turn to your questions. Hope, anything that we should be tackling before we bring up the first principle?

One of the things we look at in the way that we teach is not ‘What’s the right method?’, but ‘What are the underlying principles that we want to see each team move toward?’ – Tweet This

Hope: No, I’m just excited to see what questions people have. Whatever the method is, wherever you are on the spectrum of doing discovery within your own product team or at your company, use this time to reflect, “Do I think the way that we currently do it incorporates this principle?” And if it doesn’t, maybe why has it been challenging? Or is it because you haven’t considered it? So I think taking the time to reflect on, “Do I feel like we incorporate this principle in our method of discovery?” will help you gauge whether or not you’ve got a method that is likely to serve you well.

Principle 1: Building a Collaborative Decision-Making Model with the Product Trio

Teresa: Perfect. And we’re going to do a few polls throughout just to get a sense for where everybody’s at. We really do encourage a continuous improvement mindset. So even if you’re just getting started with this, we’ll try to help with outlining some of those first steps. And if you’re well on your journey, we’ll try to give you some of those gotchas to keep an eye out for.

Let’s turn to our first principle. This is the heart of good discovery—building a collaborative decision-making model with the product trio.

The heart of good discovery is building a collaborative decision-making model with the product trio. – Tweet This

If you’re not familiar with this term of a product trio, generally three roles need to be represented to create a good digital product. It’s typically a product manager, a design lead, and a tech lead. And we’re seeing a shift in the industry to more teams moving toward this collaborative decision-making model where this trio works together on discovery and makes decisions together about what to build.

Hope and I are going to dig into why this is important in just a minute, but before we do that, I would love to hear from everybody about where you are on your own journey.

Based on your answers, it looks like we have some folks that are already moving to trios, you’re already making collaborative decisions. I saw a few, “What are product trios?” I saw a few, “Some of the roles are new.” Regardless of where you are in this, Hope and I will talk a little bit about why this is so important.

Hope, you’ve managed a couple of really large product teams. Do you want to talk a little bit about why you think this model is so important?

Hope: I think there’s a beauty in the simplicity and there’s also real challenges in it. The beauty is when you have these people who bring that value to the customer, to the business. They consider usability, making sure it’s delightful, easy to use, easy to adopt. And they consider what’s feasible from the engineering lead, bringing that mindset of, “Creatively, how can we solve this problem from those three different perspectives?” It actually increases your likelihood of landing on a solution—whether it’s a feature or a new product—that has a higher probability of achieving your goals.

I think there’s a beauty in the simplicity of the product trio and there’s also real challenges in it. – Tweet This

And if you have just one person making decisions or you only have a subset of these people making decisions, you’re likely to fall short. You’re likely to learn too late other ways that you may have solved that problem more effectively or created that value sooner. That’s why at the core, this is an important trio to consider. It’s not any one person’s responsibility. Having that equal point of view and collaboration increases your probability of success.

Teresa: I think that’s spot on. This is an extension again of that Agile mindset. So in a waterfall world, these three roles work sequentially, where maybe the product manager works with the business to define requirements, they were handed off to a designer, the designer would design them, and then they were handed off to engineers to deliver.

The reason why we see a lot of teams shifting from waterfall to Agile is that when we go from product manager to designer, the designer sees a lot of problems. And they have to go back to the product manager and we redo some of the requirements and then we finally get to a design that we like, and it goes to engineers, and they find things they can’t build, they misunderstand, or are harder than we thought. We go back to design and then back to requirements.

What we’re seeing with the shift from waterfall to Agile is, “Look, we need all of these people in the room. Let’s have them start and work together. Let’s leverage all of this experience and expertise collaboratively.”

Hope said this is hard. We’re going to give some strategies to help mitigate this difficulty. But I think the key here is it’s saving all that downstream time where you’re going back and you’re redoing work from these handoffs and misunderstandings and designing things that are not possible.

Working as a trio saves all that downstream time where you’re going back and redoing work from handoffs and misunderstandings and designing things that are not possible. – Tweet This

We define the trio as this pretty standard template of a product manager, a design leader, and tech lead. But not all teams look like this. Hope, do you want to talk a little bit about some of the variation you’ve seen?

Hope: One of the more common variations I’ve seen is when people are working on a platform team or an API team, they may not have the design lead. They may have a good data science lead or some other way that they balance out the trio that makes more sense for their product. I think there’s more of a trend toward, “How do we really have integrity in our analytics?” So they may expand it slightly from a trio to a foursome of people who are really helping balance out the quantitative and qualitative to expedite decision-making.

The more diverse skilled expert points of view you get wanting to become part of the core team, there is value in that and there is an overhead and a cost to that risk. The basic principle is, “How do we keep the smallest team that we need to have well-represented perspectives and expertise to make the best decisions as quickly as possible?”

The basic principle is, ‘How do we keep the smallest team that we need to have well-represented perspectives and expertise to make the best decisions as quickly as possible?’ – Tweet This

Teresa: That’s right. The bigger your decision-making team, the slower your decisions will be. And the key here is to distinguish decision-making from contribution. You’re going to have more than just a trio on your team and the other folks should be contributing. They should be contributing ideas, they should be contributing design work, they should be contributing expertise on analytics.

It’s not that the trio is doing all the work and that this is your hero team. It’s more that for any given discovery decision a team needs to make, what are the right roles that need to be represented? What’s the expertise that we need to leverage when making that decision?

We know that generally, product managers bring the view of the business and viability of products. Designers bring design capabilities and knowledge of the usability of products. Some people will argue that designers are the voice of the customer. I think the whole team needs to be the voice of the customer. But definitely, the designer is bringing the usability perspective. Then of course, the tech lead is bringing that feasibility perspective. Some people would argue, “Where’s desirability in that?” If the whole team is making discovery decisions together, they should all be responsible for desirability.

Now, like Hope said, if you have a really data-heavy product, you might have a data analyst here. The question is, do they need to be involved in every decision or just your data-heavy decisions?

Some people argue some products don’t have user interfaces. Do you need a design person for those? I would argue in most instances, you probably still do. APIs need design work. But maybe it’s a more technical designer and not a front-end designer. So this is a principle you’ll need to customize for your team. But I think the basic idea is to balance the speed of decision-making with diversity of expertise. Hope, anything you want to add on that?

The composition of your trio may change, but the basic idea is to balance the speed of decision-making with diversity of expertise. – Tweet This

Hope: No. I think I would love to see some questions.

Teresa: All right. Why don’t we take one or two questions on decision-making?

Questions from the Audience: Building a Collaborative Decision-Making Model with the Product Trio

Melissa: What if you don’t have a full-time design lead? What should you do about decision-making collaboratively in that situation?

Teresa: This is a really great question. I know a lot of teams that are moving toward trios, but they’re not resourced this way yet. Hope, do you want to talk about what you’ve seen?

Hope: Maybe the belief is that we should allocate budget and headcount toward that at different companies. More often than not, I’m seeing teams that don’t have a dedicated design UX lead or they share a visual designer, user researcher, and they’re borrowing or getting split time from those. We do the best we can with the way that we’re set up and what we are aiming toward.

I still think it’s important that you figure out how you make sure you’ve got at least a portion of that person’s time dedicated when you need to make decisions around solving this problem for customers. How do we know if we’ve solved it in a way that makes it easy for them to use and adopt and it’s intuitive to them? You’re going to need that design perspective. You might need to just do it on a little bit of borrowed time.

Teresa: I think we’re often optimistic in how we resource our teams. We say, “A designer can spend 50% of the time on this and 50% of the time on that.” The reality is, we’re not going to make nearly as much progress in either thing as we would have hoped. Some of this sharing of designers is being a little too optimistic about what we can really get done. And what I’ve seen is that if businesses are just willing to make the harder decision to say, “This is more important than this,” and actually just allocate the designer, you’re going to get a lot more throughput. It’s a little bit of that idea of limiting the work in progress that we see from kanban.

I know that not everybody works that way and that may be outside of your sphere of influence to have an impact on. So I think timeboxing and making sure that a designer can dedicate a specific amount of time each week to your stuff. It’s about that continuous improvement mindset. How can you make next week a little bit better than last week? And you’ve got to do that with the resources that you have. Melissa, do you have another one?

Melissa: When you have your trio and you’re trying to make decisions, do you do consensus, majority, or something else?

Teresa: I’m going to tackle this one, because I feel like it’s really a big political one that we see at the top of our organizations, like executive teams that can’t get alignment. The very next principle we’re going to talk about is going to help teams align around a shared perspective.

The reason why we can’t come to agreement as a team is because we’re often working from different data. To get toward more of a consensus mindset, make sure you’re working from the same set of data.

We can’t come to agreement as a team because we’re often working from different data. To get to consensus, make sure you’re working from the same set of data. – Tweet This

People think about consensus as everybody compromises and nobody’s happy with the solution. That’s definitely not what we want. We want to move away from this idea of compromise toward something truly collaborative. To me, the distinction is, the three need to work together to generate a solution that everybody’s happy with.

And if you’re stuck arguing about my idea versus your idea, neither idea is good. You need a new third idea that both people are excited about. That is something that we’re not used to in business, because business is so organized around silos and hierarchy and your boss reconciles differences.

But this is a skill that I think product teams are starting to learn—how to truly collaborate and find options that we’re all excited about. And some of that starts with doing discovery together. As we explore other principles, we’ll unpack this a little bit.

Hope: Just to add to that, you addressed the information asymmetry issue. We were operating from different data sets or different understandings. Having this shared understanding together, collaborating together reduces those odds.

When I hear “majority rules,” it goes back to potential opinion wars, which are not productive and don’t foster a collaborative decision-making environment. It also speaks to the fact that your decision criteria is probably not clearly defined and well understood and agreed to by the team.

The more you can make that obvious to one another, the easier it is to figure out, “Are we lacking options here? Or have we set the criteria in a way that’s impossible to meet or some other challenge that’s preventing us from being able to make a collaborative decision?”

Principle 2: Externalizing Your Thinking

Teresa: That’s a perfect segue to our next key principle, which is to externalize your thinking, and to have the teams do the work to externalize their thinking to make sure they’re working from the same set of data. Now there’s a picture of the opportunity solution tree, which we’ll talk a little bit about. It’s just one way to externalize your thinking.

Take a minute and tell me what you’re doing as a team to externalize your thinking. This is one where we’re starting to see a lot of these practices become more common. Hope and I see a lot of variation and skill around this.

We’ll talk a little bit about what things you can do to help your teams as well. It’s looking like the most common ways people are visualizing their thinking is with prototypes and customer journey maps. A sizable amount of you have said, “Not really.”

Let’s talk about externalizing your thinking. Hope just talked about information asymmetry. I know something you don’t know, therefore, I’m making a different decision than you might. We see this a lot. One of the things that we teach is different ways to visualize your thinking so that as a team, you can look at it, examine it, align around it.

This could be anything from customer journey maps, opportunity solution trees to story mapping—it could just be whiteboarding really rough interfaces together as a team. There’s also a lot of research that supports this. Humans are really good spatial thinkers. Hope, do you want to share a little bit about what you see as teams get started with some of these practices?

Hope: For teams that have never done it before, it feels really awkward. We’ve been having lots of conversations, “Why are we still not on the same page?” And it’s not until either drawing or mapping or collecting examples that they actually realize that they didn’t have the same understanding. Being able to see it versus speak to it really increases your probability of shared understanding.

It can feel awkward, but it actually is going to increase information synthesis for your teams, for your stakeholders, and it will be a new way of working for a lot of people. But if you’re a team that’s already familiar with prototyping, you recognize that what you thought it was going to look like and what was actually created in the prototype are often two different things. And that’s the exact same challenge with talking through every problem to death and not visualizing it in a way that makes synthesis easy.

Drawing out your ideas can feel awkward, but it actually is going to increase information synthesis for your teams and for your stakeholders. – Tweet This

Teresa: That’s exactly right. One of the things I see a ton of is teams fall into this downward spiral of debate. They jump down the rabbit hole and they just can’t get out. They can’t agree, they’re just spinning and spinning. And I’m sure all of you have been in those meetings where you’re talking and talking and nothing comes of it.

What’s hard about making the jump to visually externalizing your thinking is that most of us don’t draw well. We’re not super comfortable sketching. Maybe we have a little bit of sticky note fatigue, because of design thinking workshops. There are a lot of consultancy activities that seem fluffy and we think, “This doesn’t seem worth the time.”

What we’re talking about with visualizing your thinking, it really is more about doing the thinking work. There’s a lot of cognitive psychology that supports when we take ideas and we put them tangibly down—whether that’s a drawing or stickies or even in a digital whiteboard like Miro or Mural—we’re relieving our working memory. We’re basically taking these ideas we’re trying to hold in our head and we’re putting them outside of our head. We’re freeing up our mental energy to think about those things.

When we externalize our ideas by drawing, we’re freeing up our mental energy to think about our ideas. – Tweet This

Instead of just trying to remember those things, we can now work on them. We can arrange them, we can group them, we can examine them. We can think about, “What do I know that Hope doesn’t know? What does Hope know that I don’t know? How do we start to combine and mix and match those things?”

It’s less about sketching this beautiful piece of art and it’s more about using paper and digital whiteboards and real whiteboards as a way of extending our mental capacity. Especially in a group context, so that we’re all able to say, “Wait, did you mean this or did you mean that?” Hope, anything you want to add about using it as an extension of our brains?

Hope: I think you’re spot on in that getting it out of your mind and onto a piece of paper actually frees you up to do higher-level thinking. It’s similar to when you’re having a conversation and thinking about what you want to say next so you’re not actually processing what the other person is saying. That delays your probability of getting to shared understanding, let alone making a decision you’re all happy with. There is power in knowing that your mental representation is there and knowing you can refer to it.

And it is participatory. The fact that we co-created it—we moved the stickies around, we moved the opportunities around on the tree, we grouped them in this way, we plotted these on our two by two risks versus value—that participation in this tangible experience increases the synthesis, memory, and ability to look at the problem from a common point of view.

Teresa: Let’s talk about ways we can visualize our thinking. The visual you’re looking at right now is the opportunity solution tree. I actually designed this visual while working with one of Hope’s teams several years ago. I was coaching one of Hope’s teams at a company called Beachbody. They’re the company that makes the P90x exercise software and a number of other things. They were really feeling lost about how to guide their discovery activities. So their feedback to me was, “You always tell us what to do next. How are we going to make those decisions on our own?” I started to ask myself how I was making those decisions.

What came out of that was this tree structure. It’s a visual that’s charting your path from an outcome—which we’re going to talk about next—through the customer needs that you’re trying to solve, up through what solutions you might build, and then what experiments you might run to test those solutions.

It was designed to guide and give structure to a pretty messy, wandering process. A lot of people ask me, “How is it different from impact mapping?” Impact mapping is another visual that accomplishes a really similar goal. We don’t really care which one you use.

The principle we’re looking for—it’s not about one right way—it’s whether you are externalizing your thinking in a way that works for your team. This could be through customer journey maps. We’re seeing companies do company-wide customer journey maps, getting all the teams involved. That’s really powerful. We see product teams doing story mapping to communicate and prioritize requirements. Hope, can you think of others?

Hope: Empathy maps. Even simple two by twos are ways that people are externalizing their thinking. They have to put something on a board and decide how it relates to something else on the board. All of these help people see perspectives and the fact that these perspectives are not fixed. They’re movable.

Teresa: David Bland’s assumption mapping exercise where you’re mapping out a two by two grid is a great example of externalizing your thinking. If you’re a little bit stuck on, “I don’t draw well,” there’s actually a video that we use in our materials. It’s a TED Talk by Tom Wujec called “Got a Wicked Problem? First Tell Me How You Make Toast.”

He describes a really powerful group activity for how to co-create visual maps. And you don’t have to be an artist to create these. He talks a lot about the nodes and links on a map, which really are just boxes and arrows that we all can draw, but it helps us see patterns and find shapes and understand processes. It’s a really nice stepping stone into visually externalizing your thinking and to build more of a systems view of what you’re trying to tackle. If your teams are brand new to this and you need somewhere to start, I would highly recommend watching that video.

Melissa, do we have any questions on visual thinking?

Questions from the Audience: Externalizing Your Thinking

Melissa: We definitely got a couple about which tools you like to use to externalize your thinking.

Hope: What I’ve seen in the past for teams that are co-located is that it’s very powerful to have a whiteboard they always use that’s near where they work. That way it’s very easy for them to get up and move things and collaborate around that. Again, having that physical tactile experience of co-creating together…

Teresa: In some hypothetical future when we get to work together again?

Hope: Yeah. More and more teams are using Miro and Mural and there may be others. But I feel like those are probably the two most popular for remote teams to be able to create a document and look at it in real time together. Those are very powerful, very flexible tools.

Teresa: If you’re not familiar with Miro and Mural, they’re both digital whiteboard tools. They both support stickies as an object, they both support shapes as objects. So even if your team doesn’t know how to draw, you can create boxes and arrows, you can create a bunch of stickies, move things around. And you get a little bit of that tactile feel of standing in front of a whiteboard with stickies, so those can be really helpful.

I know some teams like to use flowchart tools, so things like Lucidchart or Draw.io. I know a lot of Mac people still use OmniGraffle. It’s challenging, so you can’t all co-create in that document, but if you’re just doing this on your own.

I really like pen and paper. I do a lot of my own individual thinking just with a pen and paper in a notebook. I’m trying to transition to an iPad so that it’s digital. But there’s something about pen and paper that I think makes things flow from the brain to external, much like a whiteboard.

From working with a lot of teams, I’ve seen that different tools fit different teams better. So I think it’s really important to try a variety of tools and really find what works best for your team. Melissa, another visual question?

Melissa: Someone was saying that over time, when you keep adding opportunities to your tree, it tends to get really messy. Do you have any suggestions for how you can make sure that it’s still relatively easy to look at your opportunity solution tree and keep track of all the different pieces of it?

Teresa: Trees should be messy. What you’re learning is messy. Humans are complex, your customers are complex. I think part of the value of the tree structure is trying to put some structure to that messiness. If it’s this big, unwieldy tree, think about what those top-level parent opportunities are. That can give a little more structure to it.

Opportunity solution trees should be messy. What you’re learning is messy. – Tweet This

Most teams should not be working across their whole tree at any moment in time. They really should be prioritizing and picking an opportunity or two to focus on. That allows you to really focus and refine and improve and clean up that part of the tree while you ignore the rest of the mess.

Principle 3: Focusing on Outcomes

Teresa: We are going to move on to our third principle. You might have noticed that the opportunity solution tree starts with an outcome at the top. We are seeing a really strong focus on outcomes right now with the popularity of OKRs and a lot of evangelism around outcomes over outputs.

It’s funny because outcomes feel new but they were really highlighted in the Agile Manifesto—and they even predate that. In the ’60s, we saw Peter Drucker talking about it. Andy Grove at Intel has been an advocate for a long time and wrote about it in High Output Management.

It’s really easy in business—and especially among product teams—to be output focused. We’re focusing on shipping code, delivering features, hitting our roadmap. These are all outputs. “I built this thing.” That’s an output. Shifting to an outcome mindset is more about what impact those outputs have.

It’s really easy in business—and especially among product teams—to be output focused. Shifting to an outcome mindset is more about what impact those outputs have. – Tweet This

I see a lot of confusion around this. There are three distinctions that can be really helpful. One is we have business outcomes, those are usually our KPIs. We all know what those are. For a subscription business, it’s going to be things like increased retention, reduced churn, maybe increased average revenue per customer, and increased lifetime retention.

Then we have product outcomes. We need to translate from our business outcomes to our product outcomes. How is our product going to help us realize our business outcomes? If our business outcome is reduced churn, our product outcome might be increased engagement. By increasing engagement, we’re going to reduce churn.

Then we have a third tier, which is traction metrics. If our product outcome is increased engagement, we might have a whole bunch of features that we believe will drive engagement, and we’re going to have a set of traction metrics that we’re going to measure.

The reason why I think those three levels are really important is because for teams, we don’t want to give them a traction metric as their outcome, because now they don’t have room to discover. What if nobody wants to use that feature? They’re stuck. That’s very output focused.

If you give them a product outcome, now they have a little bit of leeway to explore. If somebody doesn’t like that feature and you can’t get traction going on given a feature, you can try another one.

You also don’t want to give them “reduce churn” because reducing churn is not within the scope of a product team. Your account managers or your salespeople are involved, your pricing is going to have an impact, external factors like COVID are going to have an impact. Thinking about these three layers and making sure that you’re tasking your teams with product outcomes can really help you to set the right scope. Hope, you want to weigh in on that?

Hope: When I was leading product at companies, this happened a lot. They might have business outcomes, like, “Reduce churn” or “We want to hit this revenue target.” I don’t really care how you get there and frankly, I don’t want to be limited in my options of how we get there. When I think about helping teams and companies, I wish there was a Google Translate for this. If I could just put in one side “increase revenue” and have a good product outcome on this side, it would be super useful.

But instead, you have to think about, from the product outcomes, what is the human behavior that is going to be different that is going to lead to more revenue? Is it higher average order value? Higher contract size? More upsells? Is it more customers buying? You really need to think about ways that you can translate these lagging indicators of revenue and EBITDA, maybe even market share changes, to something that is influenceable by the product team and is likely to be grounded in some sort of change in human behavior.

Teresa: I love that you called out that “reduce churn” could be a product outcome. I feel like this business outcome vs. product outcome is a little bit gray and it depends on your company. So if you don’t have a sales team, if 100% of your sales are driven through your website, then reducing churn is probably a product outcome. But if you have a huge 1,000-person sales force and they’re primarily responsible for the customer relationship, the product can contribute to reducing churn, but they’re not 100% responsible for it. There are some contexts where maybe you would need to translate that even further. And that’s why the concepts of business outcomes, product outcomes, and traction metrics are really helpful. But I don’t think there’s clear, delimiting lines between them. And they may even shift a little bit company to company.

The question to ask is, “Does the product team have the ability to move this metric on their own?” And if the answer is yes, that’s probably a good product outcome for that team. But something like “increase revenue” is tricky. Few product teams have the ability to just drive revenue on their own. Other people need to be involved. So now we need to translate that. Part of being outcome focused is understanding how to give the team the autonomy to go after this and find the best path there.

Part of being outcome focused is understanding how to give the team the autonomy to go after this and find the best path there. – Tweet This

I see two sides to this that are very hard for companies. One is on the leadership side, “How do I set a good outcome for my team?” And the other is on the team side, “I have an outcome. Now what?” Hope, do you want to talk about those?

Hope: There are companies where it’s like, “Hey, we have this revenue target. By the end of Q4, we want to achieve X. Go do something.” Or, “I’m going to give you a list of things that I believe will move this metric. Go do those things.” And the product team might believe in them, might not believe in them, might have evidence, or they might not have evidence for them, and so you have this tension that happens.

On the other extreme of this spectrum, it’s, “Let us be totally autonomous. Don’t tell us what to do. We’ll figure it out. Maybe we’ll hold ourselves accountable to some impact metric of some sort. Or maybe just leave us alone, let us do what we want to do.” Neither of those extremes is good for a product team.

The fact that a product leader and a product team do need to have some negotiation around what this outcome metric is, is healthy tension for both parties. Because the product leader has to understand what is truly important to the business. “Yes, we need to hit this revenue target or this EBITDA target. Make sure that we’re getting traction in the market in terms of winning new customers or growing our ideal size, or growing our revenue per customer lifetime value.”

Ideally, if they’ve been doing continuous discovery, they have much more sense of what’s possible, what opportunities could get them closer to that desired outcome. They also have a sense of what may take them longer to figure out and when they need to do a deep amount of discovery to figure out what’s possible. That’s this negotiation that has to happen between the product leader and the product team in the setting of those outcomes. Then looking at those traction metrics to see what progress we’re making or what we’re learning that is getting us closer or moving us farther away from achieving that desired outcome.

Teresa: There’s a lot of skill on both sides of these. We saw on our poll, a lot of you are just getting started with outcomes. Some of you are still trying to define them in a way that you’re not prescribing outputs. This takes practice.

It’s really important to have that continuous improvement mindset. You’re going to think that you’ve got a great outcome and halfway through the quarter, you’re going to realize it bound you into a corner around a specific output and you’re learning that that output isn’t going to work. You’re going to have to reframe that outcome. And it’s going to feel like you did something wrong. But I feel like it’s part of the learning curve. The same on the product team side. They’re going to start working on an outcome and they’re going to realize they’re measuring the wrong thing or what they’re trying to do is impossible.

Know that this does take a lot of iteration. Just start to develop that mindset of, “Our job is to deliver an outcome, not a set of outputs.” Get your teams thinking beyond just, “We ship software.” It’s, “We ship software and then what happened?” It’s really the “then what happened?” that we’re pushing toward. What value do we create for our customer? And did that create value for our customer in a way that created value for our business? I want to take a couple of outcome-based questions.

Questions from the Audience: Focusing on Outcomes

Melissa: Okay, Teresa, so one quick recap question: “It sounded like you had talked about three different types of outcomes. Could you remind us what the third type of outcome that you mentioned was?”

Teresa: We had business outcomes, product outcomes, and traction metrics. The example I gave was a business outcome might be increased revenue. A product outcome might be increasing engagement. And then the traction metrics might be, like if you’re Facebook, the number of customers who uploaded a photo this week, or the number of customers who commented on a post this week. So traction metrics are measuring, “Is anybody using the stuff that we’re building?” And those roll up into, “If people are using the stuff that we’re doing, we should see our engagement go up. And if we see our engagement go up, we should see our business outcome go up.”

Melissa: How do you encourage or guide the companies that you’re working with to make the shift from output to outcome?

Hope: I can give an example of a company that is going through coaching now. In the kickoff, we have an expectation that the outcome is really one of the first things that we focus on. And if it’s a lagging indicator abstract concept of EBITDA, or revenue, or market share, or increase margin, we have a number of conversations with the leadership team and stakeholders to say, “How do we translate this into something that the product team has influence over? What human behavior leads to that lagging indicator outcome? What would be some of the hypotheses that you have?”

We don’t expect that they get the outcome right the first try out of the gate. As Teresa said, it’s continuous improvement. There’s some iteration, there’s probably going to be some learnings and trial and error in setting that outcome. But getting them to translate it from lagging indicator business outcome to product leading indicator, human behavior-based change is the first step. Even if we pick the wrong metric, we can change that at a later time, but we need to have something that is within the product team’s realm of influence.

Even if we pick the wrong metric, we can change that at a later time, but we need to have something that is within the product team’s realm of influence. – Tweet This

Teresa: I think also the other direction is really common, where a team is being asked to deliver a specific output but it has been framed as an outcome. For example, their OKR might be to deliver an Android app.

“We know we need an Android app, just go build it.” So if that’s the case, what we do to help teams reframe an output to an outcome is say, “Okay. Let’s imagine you had the Android app today. What does that get you?” They might say, “Well, our users would be more engaged because they can use this on the go.” We’d say, “Okay, great. Your metric is engagement.”

Because really, if I can find a different way to drive engagement, are you going to be satisfied? If the answer is yes, then the outcome is engagement. Now, sometimes, we do have strategic initiatives. Like we need an Android app not for engagement but because we need it for some other strategic reason. So there are times where a business might need to dictate outputs or constrain output. Solve this problem but with this limitation.

I think the challenge is that we don’t really question whether that’s the right thing to do. So I think a lot of this translation from outputs to outcomes is to use this reframing, “Okay, you need an Android app. If you had that, what would that do for you?” It would increase engagement. “Can we find another way to increase engagement? Is that equally good?” If the answer is yes, set the outcome. If the answer is no, dig into why. And if it really is, you need the output, just manage by output. So it’s not like an all or nothing thing. But I think the key is to start having that conversation around, “Why are we doing this? Why does this output matter?”

Before we dive into more questions, because we are almost out of time, I want to highlight a couple of things. We have a number of opportunities for teams to learn more about this. You can find a summary of all of our offerings here.

Melissa: One of the questions that we have is about convincing management or the C-suite executives to allow a product team to work this way. How do you get them to be bought into this idea of devoting time to things like generative research, customer interviews, brainstorming, all of that?

Teresa: There’s two parts to this. One is I spent most of my full-time employee experience at early-stage startups where there was little product leadership for discovery. And I never had permission to do any of this stuff. I just did it. Now I say that with caution—don’t get fired, don’t do something your boss is telling you not to do. But you do have the ability to do a lot of this work without a formal process in place, without a way of working at your company. Especially if you work at a consumer company, you just go talk to people.

And if you work at an enterprise company, it’s a little harder. You’ve got to make sure you build relationships with your account managers and your salespeople. But don’t look at this as, “This has to be all or nothing, top down, we’re doing all the right things.” There is no right way—remember? Just start doing a little bit when you can.

The second part of it is to instrument your product. Start tracking the effect of everything that you build. Because one of the best arguments for increasing your investment in discovery is recognizing how often what you build doesn’t have an impact. That can be a really painful process, but it is the most effective way to argue to work this way.

One of the best arguments for increasing your investment in discovery is recognizing how often what you build doesn’t have an impact. – Tweet This

Hope: I want to add a couple of thoughts on this. Typically, when teams are feeling like, “We’re not allowed to work this way” or “We can’t work like this. Our leadership wouldn’t support us working this way,” you can reframe it. Instead of using abstract terms, like continuous discovery, you can ask, “Wouldn’t it be better for us to understand what mattered to our customers and make sure that we are increasing our probability of success and de-risking our investments by learning early what’s likely to work and what isn’t?” Very few leaders are going to say, “No, I don’t think that’s important. I think we should just do what I think is best.”

You can even break that down into another layer, which is, “How do I make sure that I’ve got the evidence? How do I add new information to the discussions that we’re having about what we should or shouldn’t do on behalf of customers?” That is information that the people in the room probably don’t know. The more that you’re bringing new insights and information to the table, the more likely that people are going to look to you to be an advisor that has expertise, that helps de-risk investment decisions for the company. Just think about ways that you can reframe it in a way that makes it easy for people to say yes and support without having to know all the dirty details of the methods that you’re using.

The more that you’re bringing new insights and information to the table, the more likely that people are going to look to you to be an advisor that has expertise. – Tweet This

Teresa: Hope, I love that that was your answer. Because I wrote a blog post, “The Art of Managing Stakeholders Through Product Discovery.” It’s all about how if you want to be a part of the decision-making as you move up the hierarchy in your organization, you have to find a way to bring new information that stakeholders don’t have. And most leaders are not going to say, “I don’t want that information.” They’re going to go, “That’s a new piece of information I didn’t already have.” So you just need to get creative about ways that you can do that.

We are right at the hour and I want to respect everybody’s time, so we’re going to wrap up. Thank you, everybody. Thank you, Hope. Thank you, Melissa.

Hope: Thanks, everybody. Great to get so many good questions.

This webinar was the first in a three-part series. We’ll be sharing part two and part three right here on Product Talk in the coming weeks. Subscribe to our newsletter below to make sure you don’t miss them.

Get the latest from Product Talk right in your inbox.

Join 41,000+ product people. Never miss an article.

Subscribe