 Hey everyone, my name is Vincent and I will be speaking today about a topic that I find very, very interesting as a product manager, which is making good decisions as a PM. This is a very important topic to discuss as a product manager because you'll often hear that PMs are at the intersection of the customer, engineering, and design. So which means you'll be making a lot of decisions. I think this is a very interesting topic for a lot of you who are aspiring to become PMs or already PMs, but I do want to highlight that making good decisions is important for everybody in every industry in any discipline. For example, if you are a chef or a firefighter or an architect, an airplane pilot, you'll be making decisions. So I think this framework will be very useful for many, many people. Today the topics that we will be discussing over the next 20 to 30 minutes will be decision making. First, I will give off an introduction of myself. Then we will move into why decision making is important as a product manager. We will cover some of the main problems that I see product managers face today as it relates to decision making and then how we can use some tools and frameworks to make decision making more accessible and more logical for product managers. And last but not least, I'm going to go over my favorite framework for decision making and go through an example with all of you. This is a slide a little bit about me. My name is Vincent. I'm based in Toronto in Canada. If some of you don't know where Toronto is, it's just north of New York City in Ontario, in the province of Ontario. I moved to Toronto when I was very young from Hong Kong and China and I grew up studying accounting and finance at York University and then I did an exchange semester in Singapore where I studied marketing and strategy. My career has spanned over a decade now working in several different functions. I was an accountant. I was in M&A. I was in venture capital. I was in product marketing and finally I am now in product management. And my career has touched on various different industries. So I've worked in banking, in payments, in startup, in B2C and in B2B SAS. And product management is somewhere where I landed after 10 to 12 years of kind of finding my way around different places and seeing what was interesting to me. So this line on the left of the screen is kind of how I see my career. It just wasn't linear at all. And I found product management through some trial and error. On the personal side, I love traveling. If it wasn't this day and age, I would still be traveling a lot. I love seeing mountains. I love deserts. And since it's COVID right now, I've found passion in other things. I love reading. And so if you'll often find me reading a book about entrepreneurship, about technology, about, you know, self-help books, about decision-making, I love to eat. I'm sure a lot of you will agree with me that food has been a great place to find an interest these days. I like video editing, very amateur about it. And last but not least, I like hanging with my toddler and my wife. So not only am I a product manager, but I'm also a husband and a father. Great, let's go into the next part of this presentation about why decision-making is important. So product managers sit at the intersection of engineering, design, the customer, marketing, the overall business. Decision-making is at the very core of the product management function. Let's go over some areas that PMs have to make these decisions. The first one is, of course, the product. What is the product? What is the strategy that you're going after in the next ten years, five years, three years, one year? What do we do first and what do we do second? Next, you have to work with your design counterparts to understand what does the customer want and then design the user experience. Should the customer go straight to step two or they go with the step three, go to step one? What does that overall end-to-end experience look like for the customer? Next, you have to work with engineering. So PMs will often be deciding with the engineers. What is that version one of that feature, version two, version three? What is our MVP, which we commonly called it, and then how do we build it? Next, you have to work with marketing and sales to decide if your product or feature is launched to a certain target audience. Who is the target audience? What is the demographic? What is the way that we communicate our value proposition? Et cetera, et cetera. Aside from the business, PMs are often making decisions for the entire organizations, something we call organizational design. Do we need more designers or do we need more engineers? How should we structure the team? Do we have a six to eight ratio from engineers to product managers? Do we need one product marketing manager or two designers? Organizational design is something that PMs will often have to influence as well. Needless to say, decision-making is a very critical part of being a product manager because it helps make your delivery team very, very efficient and very, very effective. I think if you look at various product management books and resources, you'll see that PMs not only have a delivery deliverable, but you also have to make sure that your team is unblocked. And what does unblock mean? It means that you as a product manager need to make decisions fast enough and good enough so that your design, your engineering, your marketing, and sales teams can go do their job. Let's give you an example here. Let's say that as a product manager, you need to design a feature A. If your engineering team is sitting there waiting for you to make a decision on what the design should look like as a PM, you are not doing your job because now you're blocking the engineering team from doing their job. As a product manager, you need to understand all the facets of that particular product and the strategy so that you can work with your designer so that by the time engineering is ready, the design is also ready so that everybody is passing the baton to the next person very quickly, very quickly. That is a very important part of being a product manager, unblocking your team. Let's talk about what should a good product manager do. A PM should be competent in multiple facets. The first one is navigating complexity. Product managers are involved so early in the product development cycle so you'll find yourself often in ambiguous situations. The problems that PMs have to navigate are often very shrouded and clouded in a fog of war. It's important for a product manager to kind of cut through the ambiguous situations to make sense of it all. For example, if somebody, if a customer comes to you and says, I need this, as a product manager, you need to understand what exactly is that customer looking for, dissect it and communicate that back to an engineering and design team that did not directly talk to the customer. So it's very important for a product manager to see through with clarity and transparency what a customer actually is looking for, prioritize whether that's important and then communicate that. Next, a good product manager needs to proactively plan. And what does that mean? Proactively planning means kind of like what I mentioned in the previous slide about making sure that your delivery team is unblocked. You need to kind of see three steps or two steps ahead. You need to look at the problems, assess the prioritization of certain things and decide what should go first. For example, let's say you talk to a customer and they say, I need three things. Is the priority in which you're designing engineering team doing these three features? Is it one, two, three, two, three, one or three, two, one? Which goes first? If you choose one over the other, what are you trading off? A product manager needs to make a decision on prioritizing and the only way to do that is understanding the big picture and the strategy and then planning the sequencing in which your delivery team will move forward. Next, of course, as a product manager, you need to de-risk delivering. Product managers at the end of the day responsible for delivering results, delivering features to deliver outcomes. This ties back to the earlier theme that we talked about, about unblocking teams. As a product manager, you need to make sure that your engineering and your design teams are moving quickly, like a machine. To make sure that they can deliver quickly, you need to make decisions fast enough and good enough that they can proceed and deliver on time within budget. Let's say that your executive team or your stakeholders expect you to deliver a certain feature by June of next year. If your team is trailing behind, you're not making the right decisions, your June delivery date may stretch to July to August to the end of the year and that may have a ripple effect throughout the organization that could impact business results like revenue and active user growth. It's very important for a product manager to be good at making decisions that keep delivery on schedule. Next, a product manager needs to be very, very clear. A product manager is talking to all these disciplines, engineering, design, and the customer and it's important and critical for a product manager to understand the opinions of all these stakeholders so that you can communicate back to each of these other stakeholders who are not necessarily communicating understanding all aspects of the business problem so that they understand why. Why is one of the most important things that a product manager can provide clarity on? Why is going back to the motivation in which a business needs to achieve a certain objective? For example, this pair of glasses I have, if you're working with engineering design to design this pair of glasses, it's very important for a product manager to communicate to the engineering design teams of why these glasses are designed a certain way. You can't just tell them design glasses that are circular, can attach to ears. It's critical for a product manager to talk to a customer and tell the engineering design teams why glasses have to be designed a certain way so that they understand the problem in which the customer is facing so that they can go design it properly. This communication will allow for a more complete and coherent team that's working towards a common goal and a product manager is the glue that helps all the stakeholders work together nicely. And last but not least, managing relationships. A product manager needs to make sure everybody in the organization is working coherently, working happily and very, very efficiently. When decisions are made, oftentimes the product manager is making that decision. It's the job of the product manager to get the perspectives of all these teams, understand the different opinions and data and the trade-offs before making that final decision and communicating that decision to everybody. Not everybody is going to be happy or agree with the decision you made, but they should understand why you made that relationship and the PM is the center of that, where you need to manage the expectations and the stakeholder relationship so everybody at least understands why a decision is made. Next, we're going to discuss what is not okay in decision-making today. These problems I've seen very commonly face product managers across the board, either early in their career or later they're in their career. These are the problems that frameworks and decision-making tools can help you fix. The first four areas that I see product managers face are poorly defining a problem, not having enough data or decision principles to make a decision, ignoring stakeholder opinions and kind of jumbling the options. Let's go into each of these. Poorly defining the problem. When you need to make a decision, the decision needs to be hinging on a core problem set. If the problem is not clearly defined, it is very difficult to find a solution. We're going to cover this in example in the next slide so we can hold off on this one. Lacking decision criteria and data. This one is probably less common, but when product managers and any stakeholder make decisions, they need to make sure that it is founded on certain principles. Kind of like a pros and cons criteria set. Is this criteria more important than another criteria? When you communicate to stakeholders around the decision you made, they will ask you how did you decide on this decision based on this criteria? It's important to lay out the criteria for your stakeholders so they understand how you got to that answer. Ignoring broader perspectives is another common problem where I see product managers not soliciting a wide divergent opinion base. This gets into multiple, several following problems. For example, people feeling left out of the decision, people getting blindsided, or the product manager not having enough details and data to actually assess the options. It's important to solicit opinions broad and wide so that the product manager can consider engineering, marketing, sales, data science, design considerations before coming up with the final decision. Last large problem that I see with decision making today is jumbling options. What does that mean? Decisions have to be made based on assessing multiple options that are available. For example, if you have to make a decision on whether a certain feature needs to look a certain way, you need to have option 1, option 2, option 3, and option 4. All of these options need to have pros and cons. They need to be distinct from each other. Enough that decision 1 is different enough from the second one. We can cover that in the next couple of slides as well. Some of the other problems that I see with decision making today is defaulting to the highest paid person in the room and executive in the room, who may not be close to enough to the problem, but just by mere fact that they are an executive or a senior member of the company, they make a decision. This is very, very wrong because it impacts morale above all else, but this executive may not be even close enough to the problem to understanding the trade-offs. We can, wanting consensus is another problem that I see where there is a reluctance to make a decision because not everybody in the room is happy with a certain decision. This bullet particular I've seen in many, many companies outside of software and incumbent companies whereby everybody sits in a room and out of 10 people, the decision is not made because all 10 are not voting yes to a certain decision. This is incorrect because it slows down decision making, which impacts delivery. This makes it too long to make a decision or actually not making a decision when you leave the room. These problems will be eventually solved with the framework that I will outline next. The framework that I want to talk about today is the Spade Framework, a very common framework that we see every single day at Square and companies like Amazon. This Spade Framework, the S, P, A, D and E is an acronym that stands for Setting, People, Alternatives, Decide and Explain. We're going to go over each of these topics in the next couple of slides with an example, but you'll see that it's very simple. It seems very obvious, and it encompasses a lot of other frameworks that you might be very familiar with during decision making. This is one of the frameworks that I'm recommending, but by no means is it the Bible for decision making. This is just the one that I want to talk about today, but please feel free to use the one that you're most familiar with. Let's go into an example. S stands for Setting. What does Setting mean? Setting is helping the reader understand what is the problem that we're solving. That's context. Somebody is reading this decision one week from now, one year from now. They understand, I see, this is the context and situation in which this decision was made. It also tells the reader why is this problem important? Why are we deciding to look into a solution for this problem now? Imagine setting as the preamble or the introduction to the problem. Let's go into an example. Imagine that you are a product manager for a video streaming service. I'm not going to name any particular service, but just imagine the video services that you did. This video streaming service has a membership or monthly fee plan, and if you sign up for the membership plan, you get to skip ads. As a product manager, your goal is to increase the number of subscribers to this monthly subscription. That is the problem that we're trying to solve. We're trying to increase the number of subscribers to the membership program. The specific objective that we want to achieve with this decision and what we're trying to weigh is to optimize for net news subscriber growth through ad placement. I've highlighted in green here the key points here. The problem that we're trying to solve for is increasing number of subscribers. Why is this important? It is important because we want to optimize for new subscriber growth through ad placement. This is a very good setting because it's really a problem what we're optimizing for and what we're trying to do. Let's look at the flip side. What is a bad problem statement? A bad problem statement is we want to increase revenue but also want to reduce turn. We can do this by either increasing price, adding subscribers, or finding new ways to engage users. This is a poor problem statement because it does not define the core problem that we're trying to solve. We're trying to solve too many things. In the first sentence, we are both trying to increase revenue but reduce turn. Why is this a bad problem statement? It's because we're trying to do too many things. Which one are we trying to do? The next sentence says that we can either do this by increasing prices, adding subscribers, or finding new ways to engage users. Again, there's too many problems in here. Increasing a price, adding subscribers, and engaging users those are all different problems with different stakeholders with different data, different analytics, and different possible solutions. This is a bad problem statement because we're trying to do too much. We also don't know why this is important. I want everybody to focus on, obviously, the good example here. The bad example is just for you to see how we could make a bad problem statement very easily by jumbling too many things into one sentence. Let's move to people. P stands for people and people is defined as the core working group that makes the decisions. We can use a simple RACI for deciding who the people are that are involved in this decision. R stands for responsible. The responsible person is the person that gathers the information and also makes the decision and recommendation. This is often the product manager. A in the RACI stands for approver. In the approver, you can imagine as the person who is likely more senior than the responsible person and has the ultimate ability to veto the decision. Let's say the product manager is responsible and makes a decision and the next person that they report to, let's say the head of product is the approver. That head of product needs to have the ability to ultimately veto the decision. If somebody more senior than that person or the CEO can veto this decision from the head of product for the person who's approving, we have to switch the approver. The approver must be the person who has the final decision to say no or yes to the ultimate decision. C stands for consulted. Consulted is a group of people. It can be many people that provides data information and opinion so that the person responsible has enough information on hand to make a final decision. The consulted can be design. It could be engineering. It could be data science. It could be sales. It could be marketing. It could be legal. All these stakeholders will provide information to the person responsible to make a decision. But the people in the consulted group are not responsible and they're not clearly accountable for making and following through with the decision. Last but not least, I stands for informed. Informed you can imagine is the fire hose which is sending it to anybody and everybody who needs to know but is not directly providing information and is directly not responsible for that decision. This could be partner teams. It could be the marketing teams. It could be anybody in the organization that is interested but does not have direct impact into our accountability into this decision. Here's an example. A good racy would be something like this where the product manager consults with engineering design the data team and the legal team recommends a certain decision and head of product will approve of it. Remember that the head of product because this person is in the A or the approver section the head of product must have the final veto power. If the CEO or the chief risk officer or the CFO has the final veto power. This head of product will now move from A to consult it. And then the person who has the final approval authority will move into A. There can only be one A. In last but not least informed. Informed is just sending it to every other product manager in the organization who wants to know and your general manager or your GM so that they have the information on hand and understand why a certain decision is made. People may seem like a small topic but it's very very important. This speeds up decision making because you can see that the product manager is directly responsible and it's accountable for making that decision. This people section negates some of the problems that I've mentioned in the previous slides around who is making a decision is it the most senior person people not making decision fast enough. People this section right here solves for that where the product manager was responsible the head of product that proves it decision making continues on quickly and efficiently so that the rest of the teams can be unblocked. It's very clear who makes the decision under this section of people. A stands for alternatives. Alternatives is super easy to explain. These are just the options in front of the product manager when they have to decide on a certain decision. A very important aspect of this alternative section is that just the options must be mutually exclusive or collectively exhaustive or Misi. Misi just means that option one is distinct enough from option two and is distinct enough from option three that somebody looking at option two and three will obviously see that they are two separate options and not two of kind of similar but not very different options. Let's look at an example based on our video subscription example. The first option to increase net subscriber growth is to place an ad on top of the video player on the website. We list out pros and cons. This alternative is super easy to build takes only three weeks and protects the user experience. The downsides of this option is that it does not incentivize signups. It decreases the subscription value because if you put the ad on top of the video player it's not blocking anybody from viewing the video. A second option is putting the ad inside the video player. You can very clearly see that alternative one and alternative two are extremely different. Alternative one it has the ad on top of the video player. Alternative two has the ad inside the video player. These are clear, clearly different options. And this option obviously has pros and cons as well. In your example, in your job feel free to use multiple options. Option one, option two, option three, option four. Don't go more than three or four because it makes people very, very confused. Put your top three or four options, lay out the pros and cons and move on. The last part of the spade framework is decide and explain. This is super, super straightforward. You just have to pick one of the options, make a decision and tell people why. In our example, we proceeded with option two to put the ads inside the video player. Although this option requires a little bit more engineering effort. This aligns with our aforementioned goal of increasing the video subscribers to our membership service. You can see here in highlighted in green that we chose a specific option that we laid out. Then we explained why we acknowledge the pros and cons that we laid out in the alternatives table and we decide we acknowledge this but we are choosing this because it aligns with the goal that we set out in our settings, in the setting, in the context section of the spade. Before you communicate this decision out to relevant stakeholders, make sure you clarify and you clean up the document. You get perspectives and divergent opinions from the broad group of people that you're going to consult, your lawyers, your data science team, your engineering, your design team. Make sure that they are following along with the decision. Get feedback. Give them access to this document that lays out the options, the facts, the opinions from everybody else. Make sure that your engineers can see the opinions of the marketing team. Make sure your marketing team can see the opinions and data of the data team. Make sure that this document is fully communicated and transparent and public before it's communicated out for everybody. Just like any decision, there's going to be people disagreeing with whatever you decide. Whether you pick option one or two, there's going to be somebody having a different opinion and that's okay. We don't need consensus. We just need a good decision. And a good decision does not mean consensus. A good decision means you looked at all the facts you considered and you weighed the pros and cons, the trade-offs, and you decided based on decision and the facts that you have on hand at that time, this is the best path forward. I remember an anecdote that I read in a book saying that it is silly to make a decision with 40% of information, but it is too late if you wait until you have 70% or more. So the best decision is to make when you have anywhere between 40 and 70% of the facts. Remember that making a decision does not mean that the outcome needs to be as you expected. We need to decouple making a decision and the final outcome. You can make a good decision with a bad outcome and you can unpack that a little bit more. Why is that the case? Let's say we decide to proceed with option two today. Six months later, we proceed with option two and actually the outcome was it was not the best decision. Our goal of increasing subscribers to the video service actually did not go up. We did not actually goal. That's okay because as of now, we only had this much information. We made a decision. We stuck to it. We commit to it. We execute and if it doesn't work out, that's fine. We'll just learn to iterate for the next time. A bad decision is that we don't make a decision. We get into this series of analysis paralysis. That's a bad decision. For the purposes of this discussion, I want to make sure that everyone decouples decision making and the outcome. There are two different things. Of course, we want to make a good decision to have a good outcome, but that's not always the case and that's okay. Address the disagreements in your document and then communicate it. That's the example I wanted to cover today around spade, but there's a lot of other frameworks out there just like voting, a very democratic vote with your team on making decisions. You can weigh a pros and cons tables, but I particularly like to spade because I use it very often. It's a very, very widely accepted framework in the software technology industry and it's very useful. It's very simple, but it makes it so easy to see all the facts to communicate it, to address disagreements and get into the cadence of making the repetitive decision making muscle in your body. So the three takeaways that I have for you all today is get used to decision making. As a product manager, you'll have to make a lot of decisions that I mentioned earlier. You have to make decisions around product, engineering, design, marketing. Get used to it. If you want to be a good product manager, you'll have to do it. Use frameworks like spade to ensure that you have a good logical structured way of making decisions. You don't have to use frameworks, but the frameworks, when they're embedded into your psyche, it makes it so fast to make decisions that eventually you'll become second nature. The last takeaway is apply judgment. Frameworks just like any type of textbook or acronym or whatever shortcut you use or heuristic you use, it's just a framework. You need to apply your own judgment, your own business acumen above all else and intuition to make sure that you are making a good decision for you and your team and your customers. Blindly following a framework is not the way forward, but it can help you. Decision-making frameworks in general help you scale yourself and your organization. As you go from 5 to 50 to 500 to 5,000 people, decentralizing decision making is the key to making yourself and your organization go faster. For example, let's say you have a startup with five people. You can be involved in every single decision, but when you get to 5,000, there's no way you can do that or you're going to be the bottleneck of that entire company. So use frameworks to train your team to make really good decisions so that you don't have to. Decision frameworks also help decentralize decision-making so that your team is happier. They feel that they're accountable for results and they feel like they own that strategy. For example, if one of your team members is able to decide, they're more likely to follow through because they made that decision. But if you make the decision and you expect your team to follow through, but they don't understand why, they're one step away from making that decision, chances are they're not going to feel like you really understand their perspectives and you're not really investing in their career. So give them the ability to make that decision and let them run with it. And last but not least, decision-making frameworks just provide structure and really ambiguous situations. One of the skills that I see good product managers make is that they apply frameworks and structure not just in large and complex situations but also in very simple decision-making. When there is a very minor problem, I can see good product managers go through a framework so that they consider every aspect. A decision framework like SPADE can help you do that with big and small decisions so that on a daily basis, you get into like a decision-making mode and you come off as someone who is structured and a business and product leader. That covers the webinar that I want to discuss with you today. Again, my name is Vincent Liu. I'm a product manager here at Square. If you want to reach out to me, feel free. This is my LinkedIn profile and I hope you enjoyed that talk.