Justify Your Product Decisions and get Stakeholder Buy in - Teresa Torres Mind the Product SF 2019

We are getting really good at discovery if I've learned anything today. I feel like I have a lot of power because I'm standing between you and your beer, but I promise I'm going to do the best I can to deliver a lot of value in the next 30 minutes or so. I know it's late in the day, but I want you to play along with me. I want you to think back to when you were in elementary school, learning multiplication tables. Don't worry, I'm not going to make you do any math. I was in third grade. We used to do these full-page multiplication tests. They were one minute, you had to go as fast as you can, and you had to get all the right answers. Day after day, I competed with the same boy. He'd win some, I'd win some, but we always finished one-two. I loved the thrill of putting my hand up, hoping I was the first one. Here's the thing. These tests were not just about going fast. You had to get all the right answers. And as a third grader, this really motivated me. I went home and I practiced. I wanted to learn all the multiplication tables because I found comfort in getting it right. Okay, now I want you to fast forward in time to remember learning algebra. Algebra also, again, I'm not going to make you do math, I promise. Algebra also was about getting the right answer. In fact, I loved flipping to the back of the book as fast as I could to see if I got the right answer. And in algebra, I was what my middle school teacher called a half-lesson learner. I was rushing to do my homework before he was done teaching the lesson. But you might remember in algebra, there was more than just getting the right answer. We had to meticulously work step by step. We had to show our work. I wasn't very good at showing my work. My brain moved faster than my pencil and I really did not want to slow down. Just wanted to get the right answer and move to the next problem. Alright, we're going to fast forward in time again. This time I'm in a computer science class in college. And the days of getting the right answers are long gone. Does anybody recognize the traveling salesman problem? Yeah, okay. The problems we worked on in college were too complex. They didn't always have a right answer. Instead, they had better and worse ones. Some of them were unsolvable. They were designed to test our thinking, not to lead us to a right answer. And I remember the first time I tackled one of these problems, I was devastated. And it's not... I didn't realize that there was no right answer. I just knew that I couldn't find one. So hoping for partial credit, I did the best I could. You've probably all been there. And it turns out I did just fine. But I didn't know what to make of this. I really yearned for a right answer. I found comfort in right answers. So if I look back on this journey, starting in third grade, rushing to find the right answer, later in eighth grade, learning that I had to show my work, it wasn't just about finding the right answer, and then finally in college, being introduced to problems that were so complex, there wasn't always a right answer, I realized all of us, every single one of you that's working on a software product, we're going through a similar journey in our own organizations. So I want to illustrate this today using Netflix. I have to start with a few disclaimers because I've never worked at Netflix. As a product coach, I've never coached a team at Netflix. I have no idea what it's like to work there other than I read their 160 slide deck about their culture. I'm using Netflix as my example only because I suspect most of you are familiar with their product. In fact, if I asked you, I bet every single one of you could come up with a list of prioritized improvements to the Netflix product, right? You could fill a backlog full of user stories. You could create a 12-month roadmap, right? After all, this is what we do as product people. We create plans. We plan for the future. We find comfort in being prepared. Now for those of us that are early in our product careers or young in our product practice, we find certainty and comfort in these right answers. We obsess about them. We try to get there as fast as possible, right? We jump to our first solution. We fill that backlog. We look at the empty roadmap and we want to fill it as quickly as possible. And in meetings with stakeholders, we advocate for our point of view. I know we've all been there. And when we get suggestions for change, we resist them. When we get pushback, we yearn for autonomy. And when our boss asks us to build something other than what we suggested, we complain to whomever will listen. We curse the dreaded hippo. After all, we already found the right answer, and it's perfect, but nobody will listen. So we get frustrated, we start to daydream about our next promotion, hoping that when we're the hippo, our perfect answer will finally see the light of day. We're like the third graders, rushing to the right answer. What we don't realize is that we're creating this stakeholder problem ourselves. When we only present our final answers, our backlogs full of user stories, and our roadmaps full of features and release dates, we're asking our stakeholders to give their opinions about our answers. But we haven't taken the time to show our work, to defend our point of view. So of course they're not aligned with our right answers. We all know that when a hippo disagrees with us, the hippo always wins. So as our product practice starts to mature, we realize it's not just about the right answer. We realize, like the algebra student, we have to defend our answers. So we start to use data to bolster our right answer. We talk about total addressable markets, returns on investment. We learn to write business cases. We learn to speak the language of the hippo. We draw a straight line from our business need to our perfect solution. The more sophisticated among us draw a straight line from our business need to a customer need to a perfect solution. And it's beautiful. Just like an algebra problem, we can't wait to flip to the back of the book to see if we got the answer right. Now in this scenario, we're giving our stakeholders more to respond to. They can give us feedback on our numbers. They can question our data. Maybe they can bolster our argument or find flaws in our logic. For example, one of our stakeholders might ask, why do we think we're going to see a 5% of new subscribers create reviews? And if you've listen to anything I've said to you over the years, you maybe even have an evidence-based answer from your discovery work. Our stakeholders also have knowledge and expertise that we may not have. Maybe your boss learned this morning that the lifetime value of a retained user went up from $180 to $220. Great! That means your idea just got better. On the other hand, Maybe a general manager just highlighted that in the history of Netflix, no single feature has had more than a 2% lift in retention rates, suggesting that your 25% estimate might be a little too high. Right? I've been there. Here's what's happening. When we start to show our work, we're giving our stakeholders more to engage with. We're letting them question our numbers. We're letting them question our thinking. Not only are we going to get more engagement from our stakeholders, but our idea is going to get better. But we still have a problem. If our stakeholders disagree with our final answer, we haven't given them any alternatives. We're still going to find us arguing our right answer versus their right answer. Now every stakeholder that's ever existed can create an equally good, if not better, business case for their own idea. They're stakeholders, that's what they do. And there's no way for us to prove that our idea is the one best idea, because there is no one best idea. So again, if our stakeholders like their own ideas better than our ideas, we fall into this mine versus yours trap. And once again, the hippo always wins. Now again, as our product practice continues to mature, we realize it's not just about defending our right answers. Maybe there are no right answers. Maybe there's only better or worse ones. Maybe our jobs as product people is to generate and evaluate options. So instead of going to our stakeholders and saying, here's the one next magical thing we should be doing, we're sharing with them all the options that we're generating and how we're evaluating them. Instead of over committing to our favorite idea, we invite our stakeholders to ideate with us. We learn to leverage their expertise. We co-create with them. Wouldn't the world be a lot better if we could co-create with our stakeholders? Instead of the hippo always wins, we might actually win together. Now I know what you're thinking, because you're like all audience members at any conference talk since the beginning of time. I got this. I already do this. Of course you do, right? Or some of you are thinking, this would never work with my stakeholders. They're too unreasonable. They don't know enough about technology. There's a million reasons to think that the problem is out there. My stakeholders are too stubborn. They won't change. They don't come to my meetings. I want to walk through a really clear example of what it looks like to co-create with your stakeholders. Because in my experience working with teams, this is a giant gap. We're getting really good at discovery, but we still are struggling to bring people along with what we're learning. And I know this from personal experience. As a product manager, I struggled so much to show my work. All right, so let's talk about this. What does it look like? It starts with visualizing our thinking. And in Martin's introduction, he talked about the opportunity solution tree. Of course, we're gonna talk about that. But I am gonna tell you that if this structure doesn't work for you, it's not about doing it my way. It's about finding your way. that allows you to visualize your thinking in a way that invites others to participate with you. Now, if you're not familiar with the Opportunity Solution Tree, we're going to review how it works. It starts with a focus on outputs. Not, I'm sorry, it starts with a focus on outcomes, not outputs. It was awesome. Here's why. When we focus on outputs like new features and functionality, we're focused on right answers in a world without right answers. So instead, we need to work with our stakeholders and say, what are the business outcomes that if we hit them, would create value for our customers and for our businesses? This is a much easier conversation to have and agree on than arguing about what we should build next. So that outcomes are the top of the tree, that blue oval. Now here's the thing, if we're truly human-centered, We can't just focus on our business needs. We have to do the work to understand our customers' needs. I've talked about this a lot. I talk a lot about discovering opportunities. That's all the green ovals. What's an opportunity? An opportunity is a customer need, a pain point, a desire, a want. It's an opportunity to intervene in our customers' lives in a positive way. It's what we do when we create products. Now, I'm actually hearing this language a lot more in the product world. We talk about how many times today we heard what problem are you solving? But I often hear product teams jump to the first problem they identify. They talk to a customer, they hear about a need, they immediately want to solve it. I love the sentiment there, right? We really want to help our customers. But if our job is to generate and evaluate options, we can't work with one opportunity at a time. We need to survey the landscape. We need to map out the opportunity space. We need to be able to compare and contrast where can we have the most impact. There's one quote that I was introduced to several years ago that has had a giant impact on the way that I think about product work. It comes from John Dewey. John Dewey was an American educational philosopher from the turn of the 20th century. He wrote a 150 page book that I spent 15 hours reading because it's really dense and it's magical. I'm gonna share with you that quote today. John Dewey said, to maintain the state of doubt and to carry on systematic and protracted inquiry, these are the essentials of thinking. Now I'm not gonna lie, I had to Google protracted. It means for longer than you're comfortable. Okay, that's awesome. I get chills thinking about this. So we can't, what Dewey is telling us is we can't jump to our first solution. We have to maintain a state of doubt so that we can carry on a systematic search for longer than we feel comfortable. We don't do that very often. But this is what Dewey is saying are the essentials of good thinking. So this is what I like to see when people explore the opportunity space. So again, those are all the green ovals. Can we conduct a systematic and protracted search of our customers' needs so that we're truly human-centered? Now the opportunity solution tree also allows us to communicate. These are the solutions that we're working on. Those are the yellow ovals. And these are the experiments that we're running to evaluate those solutions. Those are the orange ovals. So what we're doing here is we're showing, we're generating and evaluating options. When we share a traditional roadmap with our stakeholders, one that includes a long list of features and release dates, we're showing one road, the one road we're going to take to create value. When we share an opportunity solution tree with our stakeholders, we're showing all the roads we might take. And the conversation changes. It changes from what outputs we care about to what's the best path to reach our desired outcome. Now I want to illustrate how this works using our Netflix example. So I want you to imagine that you've just worked with your stakeholders and you've agreed the outcome we need to work on is improving the minutes watched by your average subscriber. Because for those of you that live here in the Bay Area, we know that we're addicted to engagement. And so now we need to map out the opportunity space because we're good human-centered product managers. So how do we do that? Where do opportunities come from? Steve earlier today gave us a pretty good hint. They come from collecting customer stories. Specific customer stories. So Steve talked a lot about going from the specific to the general. So again, if I worked at Netflix, I don't want to ask you why do you value Netflix? That's general. How do you watch Netflix? That's too general. How about Tell me about the last time you watched Netflix. Now as I start to collect these specific stories, opportunities are gonna start to emerge. Suppose I ask someone to tell me about the last time I watched Netflix, and I hear, I really wanted to watch Netflix last night after dinner, but I couldn't find anything to watch. Maybe I saw a commercial for Good Omens, and I wondered if it was any good, so I logged onto Netflix, and I just couldn't tell, right? By the way, of course it's good. I haven't watched it, but it's Neil Gaiman and Terry Pratchett. Of course it's good. Okay. Or maybe I interviewed somebody else and they said, all of my friends are talking about Avengers Endgame, and so I wanted to go watch it. So I logged on to Netflix, but I couldn't find it. Right? A few years ago, I got addicted to Breaking Bad, and I loved to binge watch episode after episode. Or maybe I just finished Stranger Things because it's summer and the third season just came out. And I hate it when I finish watching a show. because it's so hard to figure out what to watch next. I wish I knew what my friends were watching. Maybe you heard this story that Sunday is Pajama Day in my house, and I like to catch up on Game of Thrones, and I'm only on season two, so I like to watch episode after episode, and it's so annoying that I have to watch the intro over and over again. See how by just collecting stories, I'm starting to see customer needs, customer pain points. Now when you interview, your stories are going to be much longer than this. We only have a little bit of time together. So now you've done a whole bunch of discovery work, you've learned a lot about your customers' needs, and it's time to bring your stakeholders along. What do you do? I see four common things, and they're all a mistake, so let's get rid of those right now. The first, we record our interviews and we email out the recordings. And we say, listen to what I learned. And nobody listens to the interview. Of course not. It's your job to do the research. Your stakeholders have their own job. Your research is way more important to you than it is to them. They're not going to listen to your recordings. Second, you write up these beautiful interview notes and you send them out. Again, nobody reads them. I can't keep up with my email. I'm not going to read your pages and pages of interview notes. So the third thing we do is we spend hours on the perfect research deck. We communicate our themes and our guiding principles and how we're going to make product decisions until the end of time. Nobody comes to your meeting. Nobody really pays attention. They're all on email. Right? Like, this is just not a good way to communicate research. The fourth one is the worst. And whenever I see someone do it, it just causes me so much pain. And that's that the only time they share their research is when it supports whatever argument they're making in the moment. Yeah. And nobody believes you, right? Because everybody has an anecdotal story to the contrary. Here's what's wrong with all of these methods. So earlier today we heard about telling stories and getting exposed to your customer firsthand. We need to do all of those things. But what's really missing is we're struggling to communicate the big picture to our stakeholders. When we talk about one customer need or two or three customer needs, your stakeholders always have a counter example. So we need to work to show the landscape of customer needs. And this is what I like about the opportunity solution tree. It allows us to quickly communicate across all of our interviews, here's what we're hearing. Now again, this isn't about the right answer or even the right visual. If you have another way of doing this, by all means, use your way of doing this. The key here is when we can share the landscape with our stakeholders, we can say across all of our interviews, this is what we're learning. What else would you add? You also have conversations with customers. Is there something missing? Have we missed something? And here's the thing, remember, our stakeholders have knowledge and expertise that we don't have. So if you work on the consumer experience at Netflix, odds are someone in your organization works on the content partner experience. For those of you that work on marketplaces, we know that the two sides of our marketplace never come into conflict, right? So maybe that stakeholder can tell you a little bit about their world and help you map out the opportunity space. So instead of battling about is my solution right or is your solution right before we've even agreed on what problem we're solving, we can work together to map out what we know about our customers and how we might address those needs. Now I know that not all of you have weeks and weeks and weeks to map out the opportunity space, and nor would I recommend that you spend that much time doing it. This is why I teach continuous discovery. We only create value for our customers when we ship code. So we have to build something. So eventually we're gonna have to pick some of these opportunities to address. One of the things I like about the opportunity solution tree is it does help us prioritize. We can use the tree structure to make better decisions. So instead of going to our stakeholders and saying, here's all the things that we learned, what should we do? We can say we found these big categories. Let's look at just the top three groupings. Where do we think we should play? Now remember, we're not presenting the final answer. We're giving them options. We're evaluating options together. And if we pick this middle opportunity, we can look at its sub opportunities. We can ignore the rest of the tree. So earlier today we saw Marty Kagan's long list of how to assess opportunities. If you were to assess every opportunity that you found, you would be answering questions till the end of time, right? So this is helping us have a good conversation about options with our stakeholders without evaluating every single thing that we encounter. It's helping us to align with our stakeholders around what problem we might solve. Great. So now it's time to talk about solutions, which is everybody's favorite place to have big, strong opinions. So again, if we go back to that Dewey quote, we're gonna look at systematic and protracted inquiry. We need to generate a lot of ideas. Now, every product team I've ever worked with tells me they're inundated with ideas. Their backlogs represent the next five years of work. But if you were to take that backlog, and map it out against your opportunity space, you would have a lot of first ideas. Every idea meets a different need. The problem with this is we're not taking advantage of creativity. We know that creativity loves constraints. We know that our first idea is not our best idea. We know we often have to get to that seventh, eighth, 20th idea to really find something that's desirable, viable, feasible. I'm gonna argue usable and ethical. So I really encourage teams to conduct a systematic and protracted inquiry. Generate more ideas than makes you comfortable. Not only is this what makes you a better decision maker, it also allows you to bring options to your stakeholders. It's not about the final answer. It's about generating and evaluating options together. And when you have to decide which of these to pursue, because you obviously can't pursue 20 ideas at once, when you're whittling it down to just a few to experiment with, invite your stakeholders to be part of that conversation. Notice how we're not arguing about my right answer versus their right answer, but we're taught we're together discussing how can we best get to our desired outcome together. I also like to encourage teams as they run experiments. We learned a lot about experiments from David today. to go ahead and put that on the tree. Share your experiment plans with your stakeholders. Capture your results on the tree. Ask them to interpret results with you. So again, you're not coming to them with the final answer, but you're saying, look, here's what I'm learning. What do you think? What decisions would you make based off of this data? Now earlier I said, A lot of your stakeholders have their own jobs. They don't have time for this. So you're going to invite them to ideation sessions and they're not going to show up. You're going to try to send them your opportunity solution tree and they're not going to look at it. That's not how we manage stakeholders. We need to sit down with them face to face or over Zoom like the whole world and walk them through what we're learning. The key is when we have an opportunity solution tree supporting our conversation or whatever your favorite way of externalizing your thinking, it allows you to sit down with them and say, remember, we agreed that what would create value for the business is if we could increase the minutes watched. Do you remember us making that decision? Okay, good. Then we went out and talked to a bunch of our customers. We mapped out the opportunity space. Here's what we learned. Do you want to add anything? Would you change how we grouped things? Notice how you're exposing your thinking so that your stakeholders can question it. You can leverage their expertise. You can co-create together. You can share these are the solutions we're considering. These are the experiments that we've ran. Again, it's not about the right answer. It's about generating and evaluating options. I would love it if we could get here. So there's a few things I want to summarize as we wrap up. It's almost beer time. First, stop fixating on the right answer. Now as I told this story, I told it as if it was something that happened early in your product career. That's not true. I've been doing this for 20 years and I still catch myself every single day fixating on the right answer. It happened today at lunch. Literally every day I catch myself needing to be right, defending something too strongly. You probably hear it in my presentation. I speak with a lot of conviction, right? This is a hard thing to do because it requires that we separate our ego. And here's what I want to share with you, and this is going to be tough to hear because it's not what we want to believe. You are not one feature away from success. It gets worse. You never will be. Never. It's not about there's a right feature. It's not about we're going to do one more thing and then magic happens. It's not about we'll hit this release date and we'll suddenly have product market fit. Product market fit is a moving target. We live and work in a complex world. So we have to let go of there being a right answer. We need to learn to show our work. And I will tell you, this plagued me my entire product career. If you talk to anybody that I worked with, anybody, I was a bull in a china shop, I wanted it my way, I still want it my way if I'm being honest. I could see the potential of what we were doing and I wanted to get there as fast as possible. I was still that eighth grader flipping to the back of the book and moving on to the next problem. And I was frustrated that people couldn't come along with me. And on my worst coaching days, I still do it. I still argue with people about why my way's better. And that's dumb. There's so many ways to do this. Which is why even today, using my opportunity solution tree, which I have totally fallen in love with my own idea, I don't need you to use it. I don't. I'd love for you to try it, but I don't need you to use it. I want you to think about how can you externalize your thinking? How can you show your work? So we learn not just to work with our cross-functional team, we're getting good at that, but with all of our business stakeholders. So we're leveraging all of the expertise in our building. And here's why. The problems we work on are so complex, we need everybody to help us discern the better options from the worst ones. Everybody. Your sales people, yes, all the ones that request their favorite feature every day. Your CEO who shows up to work talking about whatever the competitor did over the weekend. Right? We need all of these people to work together to find the best path to our desired outcome. So here's what I'm going to ask of you. When you go back to work tomorrow, or maybe Thursday, try some of this out. Try to show your thinking. Invite your stakeholders to co-create with us. Here's what I think you're gonna find. Those hippos that drive you nuts, they're suddenly gonna turn into reasonable people. All right, I usually talk about continuous discovery. Today I want to talk about managing stakeholders, because everybody before me on this stage did their job, and it was magical to experience. Please keep this conversation going. You can find me at producttalk.org and on Twitter at ttoys. Thank you very much.

In this closing keynote from #mtpcon San Francisco, product discovery coach Teresa Torres shares her insights on how product managers can co-create solutions with stakeholders and better manage expectations.

Teresa starts by pointing out that we all find comfort in getting the right answer. She points out that product managers typically advocate for their own point of view in meetings with stakeholders, and resist suggestions for change. When we’re asked to build something other than what we’ve suggested we complain to whoever will listen. It means that we create the problems we have with stakeholders. By only presenting the final answers we ask stakeholders to give their opinions about our answers, and not about our work, so it shouldn’t be surprising if they don’t agree with us.

For more incredible product talks from #mtpcon, ProductTank, and #mtpcon Digital, check out our website and blog https://www.mindtheproduct.com/