102 Gokul Rajaram: The Super Angel on Speed, Small Teams, Product Management, and Decision Making

Gokul Rajaram, it is a huge honor to have you on Outlier Academy to talk about all of your work investing and all of your great advice and, and, uh, experiences. Thank you so much for the time. Thanks so much for coming on.

Thank you, Daniel. Great to be here.

I know it's been many years since we crossed paths at Square, so it's good to see your face again. I wanted to start by just having you share a quick overview of your background because you've done a lot. You've done a lot of really impressive stuff. I want to, I guess, give— paint a little bit of a picture for people of kind of, um, your journey and your experiences so Gokul Rajaraman: Cool.

Let's start chronologically. I have a couple of degrees in computer science. So I grew up in India where I got a bachelor's degree in computer science. Like many people, I came to the US to go to graduate school. So I got a master's in computer science and then joined a startup called Juno, which was an early ISP, as a software engineer. After a few years, I realized— and that was a great experience, I learned a lot, but I wanted to be a product manager. There was no role called called a product manager at Juno. So I decided in order to change careers, I had to go to business school. So I went to business school, and then I moved out to the Valley where I found my way to Google, which was very young back then. It was, I think, 600 or 700 people. So I was employee number 700 or 800 back in 2002, late 2002, early 2003. I joined Google. It was also one of the few companies that was hiring back then because it was the post- dot-com bust era where most of the once-promising internet companies had essentially stopped hiring or were dead. And so Google was a great environment, met with a lot of— worked with a lot of great people there, and was lucky enough to work on some good products. And stayed there for 5 years and decided to start a company, which I did with my brother, who was my co-founder, for over 2 and a half years. The company did okay, but we went through the 2008 recession, which was challenging. And at the end, decided to ultimately sell the company to Facebook. And so we all— all of us joined as part of the team. We were a 10-person team. Most of us joined Facebook and stayed at Facebook for a few years, and then got a call from Square. It sounded really interesting, so I joined Square for a few years. Was there actually for 6 and a half years working on a bunch of things, working on the merchant side of Square, and then worked on a business called Caviar, a food delivery service. And then ultimately Caviar was bought by DoorDash, which is how I joined DoorDash 2 years ago and have been at DoorDash for slightly more than 2 years and enjoying it here. And in addition to DoorDash, I sit on a few boards, sit on the boards of Coinbase, Pinterest, a company called The Trade Desk, and also angel invest in companies and entrepreneurs. And yeah, the classic Silicon Valley trike of operating and investing and doing some board work. And hopefully all of those, each of those helps me become a better version of the other. So investing, I think, helps me become a better operator. Operating helps me become a better board member. And being a good board member helps me become a better investor. So hopefully nice virtuous cycle there.

I love that point because I always like to think that's the case. But, uh, anyway, anyways, but it's, I love when people can think of those things as kind of self-reinforcing. I want to talk for a second about your focus and approach to investing because you're a prolific investor. And am I right to kind of describe you as basically a solo capitalist? So you're just investing your own money kind of as an angel investor. Talk a little bit about what interested you about investing in the first place, what you love about it, and also just kind of any, any notes around strategy, number of investments.

For me, my angel investing career started 2007 when a lot of Google colleagues were leaving to start companies. So for me, investing started out first and foremost as a way to support friends or people I knew I had worked with who were going off to start something, and it was my way to support them. And I think that has stayed with me. I realized the type of investing I like most is investing in great people and investing in founders. So I have a very founder-centric view of investing. I think there are investors who believe that markets trump founders, but I've found that great founders, if faced with a challenging market, either pivot to a new adjacent market or create their own market. And so I am a big believer in founder first, market second, and I try to adhere to that. So if I find a great founder, however, who's inspirational, who's extremely determined, gritty, is going to walk through walls, regardless of the market they're focused on, I would like to invest in it. I end up hopefully most likely investing in them.

I want to ask one question, just kind of going back to your background. You know, so you have this degree in computer science and you spend a little bit of time doing that and then realize you don't really maybe enjoy that or love that, or you feel called to product. What did you learn and appreciate from your time as an engineer, as a computer scientist? And then what do you think that added to the transition as you started to focus on product?

Yeah, I think it's a great question. For me, I, uh, at the company I worked at, Juno, we didn't have a product role. So as a software engineer, I was able to, uh, I basically played a biz dev role, product role, a design— we didn't even have designers. I even designed the software I wrote, and then I actually wrote software. So I got to basically experience the entire product troika, or quartet actually, in one person. And I, so I got to, I think the biggest learning with, uh, with software engineering for me was it was more personal that I felt I would be a very good software engineer but not a great software engineer. And also I felt I enjoyed it, but I enjoyed figuring out what to build much more than how to build it. And so I realized that what to build is, you know, one of the things that product managers work on. And that's why I decided to move into product. I think what is interesting is 15 years ago, if you had asked me, I would have said, well, computer science or being a software engineer is the best way to be a product manager. But I no longer believe that. I've seen multiple paths to becoming a product person. Engineering is one path, design is another path. For example, Adam Mosseri, the CEO of Instagram, used to be a designer. Marketing is another part. Fiji Simo used to be a product marketer. She's the CEO of Instacart. She was a product leader at Facebook. She used to be a product marketer at eBay and then at Facebook, moved into product. And then finally, analysts, which is data-driven folks. Business analysts, product analysts are another great way to get into product. I have some of the best folks I've hired. A person called Jeff Iacono, who led product for Caviar, was essentially a product analyst before that. So I feel there's at least 4 and maybe even more, because you can't train to be a product person. A lot of it is intuition, creativity, pattern matching, analytics. It's a unique thing which only comes with experience. And you just— as long as you have— and I believe in the growth mindset, so I believe anyone can become a product manager if they essentially put the effort into learning the various components of it and get exposed to enough reps doing it.

What do you attribute that change to? You know, you talked about early on, you know, this kind of point of view that you had to have an engineering background. Is that because, you know, because I guess my sense is product in a lot of ways has become more formalized, and I think maybe a little bit more universal and a little bit more institutionalized. Am I right there? Am I wrong there? What's your—

I think you're absolutely right. I think the reason is because the earlier, earlier software products were somewhat esoteric, like they were operating systems, and they were quite esoteric to build. So the Microsoft back in the '80s and '90s, which is when some of the first product managers working on Sun Microsystems, they were extremely technical environments, and the products are also used by techies. They were not— or people who were in technology. They were not really broad-based products. With companies like Google, Facebook, etc., those are products that everybody could use, universal technology products. And so at that point, you— you, just like with any other profession, you have a much broader range of people who can bring different kinds of insights and skills to designing these products because they're universal.

Yeah, that's a great way of saying it. So I want to, you know, spend more time and dive into product a little bit, a little bit more, because one, You know, just from my experience at Square, I think you had a massive impact on how we approach product when we were there. And, you know, I think that you have a lot of just fascinating— I think, I think full of wisdom kind of thoughts around product. I wanted to just start with at a super high level, you know, what does a— what does great product vision and leadership look like? And I think what I'm looking for there is your experience not only at Square, Caviar, DoorDash, kind of being an operator in some particularly amazing companies, but also your experience as an investor. You've now gotten to see hundreds of companies potentially, you know, iterate and operate.

It's a great question around what a great product vision looks like. Let's start off with the vision. I think a great product vision has 3 or 4 characteristics. One, it has to be customer-focused because ultimately your customers are the whole reason for your product. If they don't exist, your product doesn't exist. A lot of product visions are company-centric versus customer-centric, so you need to be customer-focused and you need to talk about what problem you're solving for the customer. Second, vision should be a bit of a stretch but not unrealistic. Your vision needs to be attainable. If it's too much of a stretch, you'll have a hard time rallying your team around the vision. And so things like be the best, that's kind of a little bit lame. Get to the root of what you mean when you say be the best. Be the best on what dimension? Be the most about what dimension? In how, what way? Third thing is you need to show differentiation. Something in your vision should explain why your product is different. Why does it serve the customers differently than everyone else? So what aspect are you going to be different in? The remarkability part of it. And then look, look, you got to end a vision, look a few years down the road. So ideally 5 years, I would say you want people to say blank about your product. So your product vision doesn't need to state each of these parts, but being customer-centric, being stretched but not unrealistic, being differentiated, and, and looking down the road a few years out. It's, it's basically, I think those are the 3 or 4 things that we need to have in a product vision.

Yeah.

In terms of product leadership, I think if you think about product leaders, the best product leaders, first, they care about impact. They know that launching a product, ultimately, what's the goal of launching a product? It is to solve customer problems and drive outcomes for the business. So they don't set up feature factories where they don't say, here's the accomplishment we had, we shipped XYZ feature. They talk about the product organization's impact in terms of impact on the business. What business impact did we have? What impact did we have on customers? Second, they recruit amazing teams. They don't just leave recruiting to the recruiting team, but they step in, figure out, and figure out how to help recruit not just amazing PMs, but also most of the great product leaders I know help recruit amazing engineers. Business folks, marketers, et cetera. So they feel a sense of ownership to recruiting across a company and building, because ultimately product only succeeds if it's surrounded— if the product function is surrounded by great colleagues. And product leaders recognize that. Third, they're a culture setter. They understand the kind of culture the founders want to set in the company because they work closely with the founders, and they influence that and are champion of that culture. Fourth, they themselves are the model of execution. Many leaders, I think, sometimes once you get to a certain level in your career, you start delegating and you don't get involved in execution that much. But I think great product leaders or great leaders show execution, show that they can roll up their sleeves. And especially in things like how meetings are run, how planning is done, how to communicate, how to run product reviews, how to set delivery estimates. They step in and coach people and show them how to execute, how to operate. At a company. They're essentially— they can be a model IC. They need to demonstrate how— I think some of the best product leaders actually have 10% or 20% of the time where they're IC product people on certain projects to show the rest of the team how, at least from their point of view, a great product should be built. And then finally, they're coaches and communicators. They coach, they figure out who the diamonds are in the rough and across the company, whether it's product again, The best product leaders coach people across the company, not just in their team, and help develop them into the future leaders of the company.

Mm-hmm. Hearing you walk through that, I mean, it's— one, it's incredibly thorough and thoughtful, I think, the way you articulated that. It also starts to sound a lot like almost a CEO role of a particular product or of a particular function. Is that kind of how you think about it? Because it's this mix of vision, execution, discipline.

I used to think, again, 15 years ago, if you had asked me, I would have said the product person or the PM or the product leader is the CEO of the product. But I've realized that's the wrong way to think about it because the CEO ultimately does manage the company and everyone reports to that person. But with the product person or even the product leader, the engineering leader, design leader, all of these people don't necessarily report to you as a product leader. And so I think of the product person as a facilitator first and foremost. And as you know, we used to call product managers editors at Square, but their job is to edit, to facilitate conversations between the builders. I think product leaders recognize that the people who actually build the product are the designers and the engineers and the analysts who provide the data to enable building. And their job is to figure out there's no hurdles in the path of these, these builders. And they realize that. So I think, in fact, PMs who think of themselves, or product leaders who think of themselves as CEOs and are dictatorial, or command and control almost end up with dissatisfied teams and poor products. So you've got to have a servant leadership mindset. So they are leaders, but they're servant leaders and facilitators more than CEOs.

Yeah. It seems almost like the role of like, well, quarterback on a football team. And, you know, just, I don't know, just trying to be an exemplary example of what everyone on the team should bring is an interesting way to think about it.

Yeah.

Okay. I wanna talk for a second about product managers versus product analysts. And, you know, this was inspired in part by, you know, you talked about, and we'll talk about in a second, this idea of a product team quartet and having an, you know, an engineer, a designer, a product manager, and a product analyst. But I want to talk for a second. I think everyone's very familiar with the label product manager, but product analyst is, you know, I think new, unique. How do you think about the differences between a product manager and a product analyst? And then maybe a second question would be, what dimension is an analyst really delivering a ton of value on?

Yeah. It's a great question. And to be honest, till someone works with a product analyst, one doesn't know, one doesn't realize how powerful a role a good product analyst can play in product development. But a product manager's job, I think, first and foremost, is to figure out which customer problems are most important to solve in order to accomplish the desired business outcomes. So what do product managers do? Take business outcomes. We want to accomplish X as a business. And they then figure out how to translate those outcomes into customer problems, which are really around customer behavior changes. What customer behavior changes? Because what's the goal of a product? It is to drive a change in a customer behavior. If a product is launched and a customer behavior doesn't change, the product basically might not have launched at all. And so we've gotta figure out what customer behavior changes, because ultimately all the business outcomes, whether it is revenue, profit, whatever it is, are a result of customers changing behavior. Customers were not a customer, this person was not a customer, they became a customer. They were a customer that was only using the product once a month, now the behavior changed, they're using it 5 times a month. They were not paying, they went to paying. If you think about it, almost everything we think of is actually a change in customer behavior. The product manager's job is to figure out what customer behavior changes will lead to that business outcome, and then to figure out what the best solutions are. What are the best ways tactically to basically change this customer behavior? So that's at a high level. I mean, it's a very, I guess, abstract way of thinking, but I think this framework is a good framework. Business outcomes, customer behavior changes, and then tech features, which are really hypotheses around what things can move customer behavior. A product analyst role is really to deliver insights that help make these product decisions, that make these decisions around customer behavior changes. I think, I think they do at least 3 things, if not more, very well. One, Opportunity sizing. So there's many different ways. It could be a certain behavior. For example, I said a customer is using us once a, you know, we have 20% of customers use us 2 times a month. We want those people to use us 5 times a month. How do we change that? Now, there are many different ways that you could do that. What the product analyst helps do is try to figure out with each of these ways, what is the size of that opportunity? What is the impact of it? So can we predict it based on what we know about our customers? Based on what we've done in the past, can we predict the impact of these 5 different ways? Because ultimately, you've got to prioritize, you've got to sequence. And so which is the most— which could be the most impactful based on what we know? That's one. So it's almost a compass that tries to directionally estimate which direction to go in. Second, experiment design. And I think we'll hopefully get a chance to talk about that, but really designing experiments to prove hypothesis. Once you say, let's run this experiment, this is the best experiment, this is the best way, this is our hypothesis around the best way to move this customer behavior. How do you run an experiment? How do you design it? How do you then run it and make sure it's statistically significant? The third is quantifying, and this is a constant thing, quantifying underlying business relationships. There is something called an output metric. An output metric is, well, something, for example, revenue is an output metric or even retention is an output metric. What are input metrics? Things that we control that lead to changes in output metrics. For example, if you're a delivery company, it's likely that if you can somehow improve the number of orders that you deliver within a certain period of time, if you can improve delivery times, it's probably going to result in an improvement in retention. But what is that improvement? Is it going to be— because it's expensive to lower delivery times— is the— what is the actual increase in retention Is it worth, you know, putting the energy, effort, money in to reduce delivery times in order to improve retention? So you need to know the relationship. Similarly, you— if you lower price, almost certainly people will order more. But what's the relationship? How much should you lower price? Should you lower price all the way to zero? Obviously you can't do that. But where's— what is the relationship between price and demand, for example, or retention? So these are all the relations between input metrics that we control and output metrics that are changes in customer behavior that we observe. And if we don't know the relationship, we can't make good trade-offs around what to do. And we have to constantly— good analysts are constantly trying to run experiments to figure out, or use data to figure out, what's the relationship between things we control and things we observe later, which are the output metrics. So those are the 3 things. And then I think they also help us set goals. So help product teams set goals around, hey, you know, we have, say, 1,000 people who are using us frequently, daily. If you want to grow it to 10,000 people, is that realistic or not? What do we know from the past, what we've done? So what is a realistic goal? Is it 5,000, 10,000, 100,000, et cetera? So they are indispensable. Again, I think in the past I've been in situations where analysts have been used more for dashboarding, where they use post-facto reporting. They create great BI dashboards, Looker tables, whatever it is, whatever that tool of choices. And that's— I think they get disgruntled ultimately because that's not what is the best use of their talents, I think.

It's very low leverage. It sounds like all you're doing is putting together a dashboard.

Exactly. They don't feel that they are actually influencing product decisions. And so I think you'll find instant productivity change. Therefore, therefore, I think the dashboarding work should either be just moved to self-serve where people can create their own dashboards, roll them out, with tools like Looker and so on, or there should be dedicated BI team whose job is to just build these dashboards easily. But using analysts, product analysts, to create dashboards, I think is maybe a 10% part of their job at most.

Yeah, yeah. Well, I love that point because I think the meta point I've, uh, observed there that's felt very profound to me is, yeah, if you're focused on productivity, you need to give people sizable, meaty roles and responsibilities, and you need to make sure that they feel some ownership somewhere. And if they don't, then you shouldn't be surprised that you have performance issues or they don't feel completely bought in. And yet it seems like that is confusing generally, which I'm always surprised by.

Exactly.

One, one point you brought up that I want to go back to for a second is I love the way you outlined the relationship between inputs and outputs. And one of the questions I want to ask there is kind of a follow-on was, you know, there's this concept, uh, that I've been thinking about a lot lately that Jeff Bezos talks about, which is focusing on controllable inputs as opposed to outputs, and that all of your work should be focused on controllable inputs. And so it seemed, you know, I really like that framework. It seems like if I take that and then I layer on what you just said, focus on inputs, but also know how inputs correlate to outputs, seems even better. Is that generally how you think about that? And any advice on what to focus on?

That's exactly right. I think you need to— this is where the analysts come in. The great analysts really constantly try to figure out what, which inputs to focus on, because, and then what the correlation between inputs and outputs is. Because if you focus on the wrong inputs, you might end up doing a lot of work but not actually move the output you care about. Therefore, you can control them, of course, but if they're not the right high-leverage inputs, you're not going to influence the output. So you need— that's probably one of the most, most high-leverage things that an analyst or data team could do: figure out which inputs matter. There could be 100 inputs, but which inputs truly matter, which inputs truly Because time is our enemy always, because we have to deliver stuff within a certain period of time. We don't have 10 years to figure it out. We have probably 10 days or 10 weeks or something like that. So in 10 weeks, what is the— because sequencing is one of the— look, you and I, any smart person given a product can brainstorm 100 things to improve the product. But the question is, what is the one highest leverage thing we can do this quarter to move the needle on this product? And that's where the input comes in. That's where, which is the highest leverage input that we control, that we should focus on. Is it price? Again, I always go back to delivery because that's the world I live in. Is it price? Is it speed? Is it quality? There are many different things you could do on each of them, but if you don't know the right input to control or to focus on, you could end up doing something that doesn't move the needle.

Yeah, I love that note and just the emphasis on answering the hard question, which is what one thing to focus on, which most people shy away from and is generally just brutal to answer.

Even personal life, right? We have— we could have— we are all a fan of checklists around doing stuff. But if you think about it, if I ask someone, what is the one thing you need to complete today? People struggle to answer because— and they also shy away from it because it's sometimes a hard question that maybe you don't want to confront. But the reality, they say eat the frog first, right?

Yes.

Which means, you know, you've got to just do the hardest thing first if possible in the day.

Yeah, it reminds me of— I've been listening to Frank Slootman's Amp It Up, which has a bunch of great notes inside there. But he has one, you know, one of the pieces of advice that he shares is going to his team in one-on-ones and basically saying, if there's only one thing you could work on for the rest of the year, what is that one thing? And you know what, what an amazing question that is.

That's a great question. I love that question.

So I want to now talk about experiment design because I want to make sure we don't miss that. And I love that you brought that up. Talk about that. And I think just generally, one, I think it'd be great to cover why experiments matter, how to design experiments, and then just talk about how experiments are run on a team and who's working on them and just any notes around that.

My philosophy of product development has changed dramatically over the last 15 years as I've learned more. And I've really come to the conclusion that a product or a feature actually, or even a product is essentially a hypothesis around change in customer behavior. It's essentially saying if we do X, Customer behavior will change in way Y. The problem is that most product teams don't articulate that very clearly. We just launch features without articulating what do we expect from this feature. Like we discussed earlier, just launching a feature is basically not success. Success is changing customer behavior. If you think of a model where a feature is actually a hypothesis, If you go back to our days in primary school and whatnot, how do you validate a hypothesis? You run an experiment. Basically, in order to validate whether this hypothesis is actually going to move customer behavior in the way we think it's going to do so, we have to think of a feature launch as basically an experiment. I firmly believe that some of these experiments should not even involve engineering. Some of the fastest, best ways to get directional input on the hypothesis efficacy is by using no-code tools, is by using essentially even manual stuff without any tools, where you can have either the product person or the ops person, whoever it is, just email customers and just manually do stuff. They call it concierge testing or smokescreen testing or Wizard of Oz testing, where it's just a person behind, might look like a product, but it's just a person.

With a bunch of no-code tools.

No-code, exactly. No-code tools, exactly. No-code tools, exactly. People, essentially. And so I think what you want to do is you want to take a population, you want to— first of all, you need a clear hypothesis. You want to say, for example, that we believe that the number of customers using our product daily, or using this, this thing daily, will— using our service daily will go up from, you know, will go up by 50% if we do X, and whatever that X is. And so we've got to now test whether or not that's true or not. And so, we have to have a statistically significant experiment. And you start by essentially taking that population and then you have a control group where you, in the lightest possible way, without— again, the goal of the experiment is to really see if the needle is moving. And then if the needle is moving, then you can build the full product out. And so, you've got to really brainstorm with the team to figure out what is the lightest possible way in which you can show that doing X is going to move the needle on this customer behavior? And that's where— and how many people do you need to see the behavior changing before you can infer that, yes, it is going to, at the whole population level, change that behavior? So you create success metrics, and, and then some of them also have check metrics. I think most experiments start with a success metric, but they also want to make sure that, like I said, for example, you know, you could lower the price on a product. And of course, you lower the price to zero, demand will go up, but you have a certain gross margin imperative at the company level. So that might be your check metric where you have to keep the gross margin or overall volume, whatever it is, overall profit at a certain level. But then the behavior change has to be a certain way. So you then run the experiment and then you report back. I think the key here is that— and then you also list your assumptions. And the key here is that even if the experiment doesn't— you've got to really articulate ahead of time what your success metric is. Say customer, the percentage of people using our service daily goes up by 20%. Assume it only goes up by 10%. It's very important to then dig deeper and understand why we thought it would go up by 20% and why it didn't go up. And I think it's very important to learn why that delta was there or why it went up by 30%, not 20%. Because that learning is what really makes the product development team better. Once we understand why were fewer people— is it because they didn't see the message? Is it because they didn't act on it? Where did the disconnect come? And then the best teams then say, great, we learned enough, so we are going to run this experiment again with a more refined approach because we've learned this. Then they run it again. And a third time, or whatever it takes to get to that 20% number, or change the 20% number based on what they learned, and they declare it a success. But you, you cannot give up an experiment. Just like if a scientist gave up an experiment after one, one run, we would not see anything happen. So as a product team, if you truly believe that this is a high leverage thing, and you're doing— because you're not going to do an experiment for low leverage things, hopefully you already prioritize what's the highest leverage is— then you should be focused on, look, we cannot stop experimenting because the high leverage input being able to move. And so, you've got to try this experiment and test it out and try a few different ways of running it till you see that move. And every time you run it, you basically send an email out to your stakeholders, which could be the company or it could be a broader team, whatever the case may be, reporting on, "We're going to launch this experiment. And then after the experiment runs probably for a couple of weeks, here's the results, here's what we learned, here's the next steps." And you keep doing that rinse and repeat till you conclude success on the experiment or it hit the success metrics.

Yeah, I love it. I mean, you covered a bunch of great points, both in terms of tactically how to design a good experiment, making sure you have that check metric, just realizing that everything obviously isn't siloed, everything's interconnected, everything's going to influence other, other things, and including some that you probably don't expect. And just the focus on, on learning there. I wanted to ask kind of one, I don't know, maybe going from there and going slightly higher. This, I think it'd be interesting for a second to talk about why thinking in terms of experiments is so valuable. Because I think that's something that, you know, in my experience, I think data-driven companies and just generally the best product teams, the best companies, I think really have a culture of experimentation because they realize, I think, one, there's some intellectual humility that comes with embracing experiments of just saying, we don't, you know, we don't know what we don't know. And our goal here is to basically be like scientists always trying to move this forward. And so we should always be doing experimentation. But the question I want to ask is, one, if you could just talk about why experimentation is so important culturally and including in product. But also, is there an approach where it's like experiment, an embrace of experimentation versus a deterministic view of product design? Is it deterministic plus experimentation? I don't know. Talk a little bit about how experimentation fits into just the bigger picture.

I believe that you talk to— good product development teams do two things. Continuously talk to customers and they continuously run experiments. I think talking to customers and really interviewing them and trying to better understand their life, their stories, not trying to nudge them one way or the other to bias them, but just open-ended questions that understand, you know, how their life is, especially as it relates to the product. How do they last use the product? Not even use the product, how do they last perform a certain action? If the product is designed to fulfill helps us uncover customer pain. Experiment. So I think, how do you uncover what are the biggest pain points and needs of the customer? By talking to customers. And then how do you actually validate? So that's the customer pain points. But then there are many different ways that you could solve this customer pain point. How do you then validate that solving this pain point, this is the best way to do it, is running an experiment? Because if you don't run an experiment, you don't know, because there's so many other things that happen. You give too much credit to the product launch then as having solved that pain. Assume you launch a product and assume something moved. Did it move? Because what happens many times if you don't have an experiment culture, the product team takes credit for, oh, well, we launched it. Look, retention improved, ergo, it should have been this product launch. While it was just rain, it was just raining that week, or the weather just turned whatever, or there was something else that happened with secular trend, the Fed eased interest rates or something that changed. And so I think without experiment, you can never truly understand the impact of— and most good product teams want to understand what the real impact was. And you can't really understand whether the features you're launching are having an impact or not. And, uh, you basically get suckered into believing your own— drinking your own Kool-Aid because you just believe correlations. And so there is impossible to really understand causality without running experiments.

Yeah, no, it's really well said. So run experiments both, I think, to better understand ground truths and reality and just make sure you're not, you know, kind of seeing things in a distorted way. And also run experiments because you may, you may know what needle you want to move. You may know what problem you want to solve. It doesn't mean, you know, tactically how to go about and do it. So run experiments to figure that out. It's almost like coarse graining versus fine graining. Okay. I want to talk for a second about editing versus managing, because obviously we both spent time at Square. There was, you know, just for a quick bit of background, and then please correct me, add to this, Gokul, but at Square, largely, you know, push of Jack Dorsey, he really wanted everyone that was involved in product at Square to think of their role as editing and that that's different than managing. It's much more like you have a story or a narrative you're trying to tell and you're shaping it. You know, I think shaping is maybe another interesting word instead of editing. Talk about about what, what you think is valuable in this concept of editing versus managing, and just anything that you took away from that idea.

I think it's, uh, when I first joined, I was struck by this word editor. And, um, we did over the years get lots of resumes from content editors for this product editor role, so it caused a lot of confusion. But there is a profound truth in it. The word product manager, many, many young product managers gravitate towards. Unfortunately, it's become a It is part of the lexicon, so it's hard to get out. But it seems to imply that the PM manages the product. Somehow, even it seems to imply that they manage a team, which is not the case. Like we discussed, the best product leaders are facilitators. They know that the real builders are the designers, the engineers, the people who are building the product. Their goal is to really make sure the problem is clearly stated and the people who are building the product They facilitate a great brainstorming of different approaches to solve this problem, and they run experiments to figure out which of these approaches is the best one. The role of editing, I think, is really to focus on doing less, not more. Because like we talked about earlier, instead of going after every single input, you want to focus on a few inputs. And so you want to edit down the inputs to the highest leverage inputs, edit down the features to the highest leverage ones. The best product leaders also focus on— I mean, Jack is an epitome of that, right? I think if you look at every product he's been involved with, whether it's Twitter, Square, Cash App, the products are whittled down to just simple elegance. You can, of course, unlock more complexity. But when the first time a customer— I mean, look, the point of sale, most point of sales used to have training sessions for baristas or cashiers to use them. Square, you can download it from the App Store. And use it instantly, a point of sale. When you can take a point of sale and build a product which is completely intuitive, it's like using essentially any simple consumer app. That shows you the power of editing. It's really focusing on the small number of things, small number of features, inputs, whatever the case may be, that make that product remarkable. It's, I think, an exhortation to think of oneself as as going for a minimalistic approach. And really, a— and really, prioritization is what I think of. Prioritize the things that matter and don't worry about— look, Square was not a perfect point of sale, but it focused very heavily on the things that matter the most and less on things that matter less. Instead of trying to be everything to everyone, stand for something.

Yeah, so distill down, focus. Yeah, you spend an inordinate amount of time on prioritization And just making sure that you're focusing on highest leverage thing. And basically, you know, it's— it really is. You're trying to create a forcing function to make sure that you're, you know, it's basically a check and balance just to make sure that you're, you know, investing those resources in the right way, which I think, you know, generally a lot of companies don't do well. I want to talk briefly about decision-making in Spain because you have this framework that you came up with that has, you know, taken off and people have shared their own stories about how it's been helpful at them for making decisions. So I want to talk about that for a second, and I want to start with the origin story of Spade. And, you know, my, my understanding of it was it kind of started in this 2006 Google review session you were in with the senior leadership team. Just share that story and then how that led to the creation of a different decision-making framework.

Yeah, it's, uh, it's a crazy story. 16 years ago, I was working in product at Google, and, uh, we were doing a review with Eric Schmidt, the CEO back then. I was on the ads team. It was something around display advertising. But what I remember very clearly is Eric asked— there was a particularly contentious topic we were discussing and we were arguing different sides of it. There were some other product managers in the room also, and Eric asked, who owns this decision? And literally, I kid you not, 3 of us simultaneously raised our hands at the same time. And so when he looked around and he saw 3 of us raising hands owning the decision, he said, well, 3 people owning something means nobody owns it. So I'm ending this. He was very good at ending meetings. I'm ending this meeting now. Go back and then don't come back until you figure out who owns this decision. And so it was a pretty sobering thing where we had gone in essentially trying to make this point and then here the meeting was shut down. Because of a lack of a clear owner of the decision. And really what it brought to me, and countless other episodes confirmed later, is that consensus doesn't work. Consensus doesn't work as a decision-making tool, especially for very important decisions, and actually for most decisions, because there's no owner. There's no clear ownership. There's a very famous metaphor or a story, actually, of this sadhu, who's a holy man on a mountain. I think this climber wrote this story. Where they come across this holy man. He's shivering. They're trying to reach the summit, but he's shivering. He's almost dead. And so basically there's a group of them and none of them takes ownership. So at the end, they end up leaving him behind because they all have different other things. And all of them takes— each of them takes ownership of some part of it. And I think it's a very powerful metaphor for decision-making, I think, because most decisions without an owner, without someone whose goal is to make that decision, is they languish and they don't get done effectively. There's no driver. I always believe that it's true for any project. You can't have 50% ownership. You've got to have someone 100% on it, otherwise it's 0%. Anything you want to get done, you've got to put someone 100% on it. And then at Square, a few years later, we basically— when we did a survey of people, survey of employees, one of the top— I think maybe the top thing in 2014, I think it was, or '13 or '14, the top thing that people were dissatisfied with was the decision-making, that the transparent— they didn't, they didn't feel the decision-making was transparent, and they didn't understand why decisions were made. So at one of the town squares, which is the All Hands Square, as you remember, Dan, someone asked this question because I think we were reviewing the employee results survey at that, and Jack suddenly said, well, Gokul Rajaram is going to come back in 2 weeks or 3 weeks with a, with a, with a with a solution.

Had you talked with him about that before he said that?

No, I hadn't. And so he suddenly said that. And so literally we had 3 weeks to figure out what to do. So I basically got some people together and all of us brainstormed and our own experiences with high-quality decisions. We looked at literature, we looked at what had worked for us, and then we talked to a bunch of people across the company and came up with this framework, which we refined over the next few months. But it was a good start where it really started out with the notion that the decision should be owned by someone. We call it the responsible person. And then it actually was going to be called PSADE or something. It started with a P, but then we said acronyms mean a lot, so we just moved the setting up front and we called it SPADE, which is easier to remember than PSADE.

Yeah, yeah. And it's a very thorough framework. So for anyone listening, check the show notes. I'm going to make sure to link to— Gokul, you have many amazing interviews we'll link to. You have many amazing pieces. That you have writing and just kind of ideas that we'll link to. So for anyone interested, I mean, this is something we could spend 30 minutes chatting about. I just want to ask one more question here, which is, can you just at a high level talk about what each of those letters stands for and just kind of string together, I think, yeah, string together, I guess, what you're focusing on when you're going through a decision in the SPADE way, kind of SPADE process.

So SPADE, S stands for setting. P stands for people, A stands for alternatives, D stands for decide, and E stands for explain. So setting is essentially the context for the decision. The setting helps figure out what the decision actually is. The precision of that is important because in many cases it's not clear what the decision is. For example, when we say, well, we are launching, we want to launch internationally, the decision is how to launch internationally. Precise decision. Your decision is figuring out when we want to say, okay, the actual more precise definition is figuring out what the next country is to launch in. But even that is not precise enough because if you have multiple products, then it's not just what decision country to launch it, but what product to launch and what country to launch it in. So there's more decisions that— more dimensions to any decision that with the S you can articulate. The S also includes things like timeline for the decision. When do you need to make the decision by? As well as probably the most important part of the S is the why. Till we understand why, which is the objective, why are we making this decision? What are we optimizing for? And I'll give you an example. I think it was from Square where one of our teams, there was a big discussion around pricing for a certain hardware product in a country. And I think the reason we basically, they came to our management team and we essentially realized after discussing that the marketing and the product teams were on different pages. The marketing team was trying to optimize for profit while the product team was trying to optimize for market share. So of course, if you optimize your two completely different things, the price you come up with— the decision was actually what, how to price a certain product— would be completely different. So the first thing we did was to send them back and say, "Come back to us with a very clear why, objective as part of the S." So we hadn't yet implemented SPADE and it really forced us in that case to get them to implement SPADE. But it was one of the early implementations where we saw the impact of it, clearly articulating the setting. The next thing is the people, which like I said, should have been the first thing. It's the number one thing. It's really the horse part behind executing a decision. It's really 3 pieces. One, the folks who are consulted and give input towards the decision. The next is people who approve the decision. Most importantly, the person who's responsible for ultimately making the call. You have responsible, approver, and consultant. I think the big question that comes up is, who should be responsible? You go with various ways to think about it. In my opinion, and I think it works well, is that the person who's accountable for the consequence of the decision should also be the person responsible for making the decision. Why? Because it creates ownership, it creates empowerment, it creates fulfillment. Because imagine the last time you were given that decision, handed down decision to implement, which you had no role in making. That's one of the least empowering things.

Yeah, you need skin in the game and that alignment of incentives. Like, if you're going to deal with the consequences, then yeah, you should get to own it.

Absolutely. Exactly. You own the decision. The third one is, we talked about S, P, and then A, which is the alternatives. Once you define the setting and you assemble the participants, your next step is to outline the alternatives. An alternative is a view of the world. It's essentially a different way. You could argue that when we are talking about product development, a decision or an outcome you want to get to is customer behavior change. Each alternative here is a different feature or a different way of doing things that could result in the same customer behavior change. So alternatives should be feasible. They obviously— you can't have impractical alternatives. They should be realistic. They should be diverse. In other words, one of the big mistakes I see folks making is people have alternatives, but they're all exactly very similar to each other. They're not very different. And so, for example, if you think about pricing, you know, the alternatives people come up with could be, well, Charge $5, charge $6, charge $8. They're all kind of very similar. That's not really what the goal is. The goal is, is $5 better than charging 2% than charging $5 plus 2%? Those are 3 completely different ways of thinking about it. Is a fixed price better, percentage better, or some blend better? And then once you figure out that, then you can actually micro-optimize it as $5, $5.56, et cetera. And so you want to have a diverse set of alternatives. And then finally, the D is the decision phase. Once you have these alternatives, the thing you have to do is really do structured brainstorming. And there's many ways to do structured brainstorming, but really structured brainstorming to outline how each of these alternatives impacts the decision or impacts the outcome. So really, ideally, quantitatively model it out or come up with a list of pros and cons with some, with some data behind it to understand If you go with this outcome, with this objective you're trying to get to, which of these alternatives— what are the pro— every alternative has pros and cons, and what do you care about the most? I think M&A is where companies do this the best because every acquisition decision has alternatives. You want to accomplish certain acquisitions done to accomplish certain business strategy. You can have buy, you can have partner, or you can have build. So there's clear alternatives to acquisition. And so One of the basic tenets of any M&A deal memo is you have to model out if we didn't buy but we built or we partnered, what are those 3 things and what is the impact, financial impact, quantitative impact of those 3 things? And so M&A professionals are very, very good at this modeling. And I think the other kinds of decisions are a little bit more squishy, but no less important to figure out as much as possible through data. What the impact of the decision is. What happened, what we saw with this SPA, before we get to D, let's talk about D is decide, which is, and I'll go back to what happened at Square once we started rolling this out. Once the alternatives are evaluated by people and pros and cons anchored to the setting, it's time to decide. And essentially you've got to essentially have, you know, a discussion, but ultimately you've got to have people I like taking input from people privately. So essentially people, based on looking at all the data, you basically ask folks to tell you privately, each of them, the consulted folks, what it can be by email, by Slack, SMS, whatever the case may be, why, what alternative they choose amongst all the alternatives and why they choose it. And then after you get all that back, you ruminate on it and you essentially You basically decide, make the decision, thoughtfully consider their feedback, and then you've got to choose. That involves choosing one of these alternatives and then writing out in as much detail as possible why you chose it. And then finally explaining. And explanation is, I think, important because this is how you essentially explain to the broader or communicate to the broader group of stakeholders, even beyond the folks that are involved, why the decision was made. And what the decision is and what it's optimizing for. You want to run the decision and the process by the approver to make sure there's no veto. Typically, approvers don't really veto things unless vehemently disagree with the process or the way it was done. And the approver's goal is really to monitor decision process, not the result. And then you want to also make sure that folks who are involved in that decision are committed. We have this phrase, disagree but commit. You want to make sure even if people disagree, because you need them to execute, you need a group of people to execute on the decision, help you execute on the decision. And one of the failure modes is where people say, oh yeah, decision has been made, but then they undermine the decision through actions, even if they don't say it otherwise. So you want them to explicitly in a public setting say that I disagree, but commit. It's called a commitment meeting. And then you circulate, you basically send an email out with a with the Spade summary, and you ideally even record the decision in a spreadsheet or some other place so a person who's joining the team new can see all the decisions that were made and look at the Spade document behind it. What we started seeing at Square after about 2 or 3 years of doing this was the people were basically making a decision and using Spade to justify it, uh, and so retroactively going back and coming with the framework. So we basically said Actually, then we should not make a decision. We should just focus on SPA, which is a SPA, and then hold off on the decision. So there's no decision going to be made. You just have to spend a lot of time outlining the alternatives, outlining the setting, getting people together, getting their inputs, and then we make a decision separately. So this very quickly eliminated that decision. There was no decision going to be made. It was just doing the work around the alternatives and doing high-quality work there. And so we saw this in, I think it was first done, quite a company called Weebly. And so there was a ton of decisions going to be made around Weebly integration, and they use spa instead of spade, which I thought was really powerful. And the D was made a couple of months after the spa was written, which is great. It gave time for that to settle in, people to understand the alternatives, and not quickly come to a decision and back justify it based on some other So yeah, and I would guess obviously it seems like the SPA is one—

in my experience, those are things that most people don't even talk about or don't expose and don't make explicit when they're making a decision. So it does seem like that's where all the leverage, that's where all the meat is. What do you think was special about this framework? Because on the one hand, obviously it's a shared context that everyone has around how decisions are made. So then people feel like it's more transparent and that they can— they know what I guess path to follow. And then there's also the sharing the decision and just making that part of the culture and talking about that and making it open and transparent. Do both of those have equal weight? What do you think is, I guess, the most impactful part of a framework like this?

Biggest impact for me was people just didn't have a common framework to make decisions. There was no framework existed at most companies. Consulting firms have things they use, like people who work at like RACI, RACI, or RACI. There's a few frameworks, but in the technology industry, there was no shared language around making decisions. It was all made informally and not really articulate. There was no framework. So I think it literally was bringing light to where there was darkness. There was literally— that's, I think, the biggest thing. There was a vacuum, a void, and Spade filled it. I personally think any reasonable framework could have done a good job. I don't think Spade is anything special or unique. It just articulates a bunch of common sense things and puts a framework around it. But I personally feel almost— I think the biggest impact was there was nothing before and now there's something, and people wanted a framework, whatever it is. So I personally, I have no illusions. I don't think Spade is anything revolutionary. It's a common sense approach, but it just was something where there was nothing earlier. That's the biggest thing.

Yeah, I mean, I do think that setting an alternative seems incredibly powerful regardless of what decision you're making, even in your own personal life of like buying a home.

Exactly. Yeah, I've actually seen people use it in their personal lives now, but all these— yeah, so it's been gratifying to see that it's not just like you said, it's really used for decisions that are high stakes, that are irreversible, where we have multiple options with no easy decisions. It helps you, like you said, lay out the pros and cons of each approach and then make a decision quickly and If a decision can be validated by a quick experiment, then Spade is probably not a good fit because you just want to run an experiment to see. But in many cases, it may not be possible to run an experiment because they're almost— once you make it, they're not reversible as easily. So they're almost one-way door decisions. And that's where Spade really shines, or some framework like that.

That's really well said. So I have many other questions that I would love to ask you, but I want to be respectful of your time. So I'll ask you one final question. Which is, you know, you talk a lot about— and this is just kind of, you know, on Twitter and for anyone listening, I'll recap this at the end of this interview, but you should absolutely follow Gokul on Twitter. It's @gokulr. He's got some amazing stuff. But one of the things that you talk about quite often is, you know, speed, small teams, why small teams win, and just this concept of once teams get too large, you almost need to decompose that team and break it back down into a smaller team. And so I know these are three separate but related ideas. So I'm trying to tie them together, but can you just— one, I want to hear your thoughts on why speed is so important and how you've seen speed either help or hurt companies that you've invested in, companies you've worked at, and then just why small is so important from your experience. I think it'd be really helpful.

Yeah, I think speed— it's funny, speed is a product feature, you know, almost always if you make a service faster, you see that customer conversion increases, retention increases, everything increases. I've seen this all the way from Google, Facebook, Square, DoorDash, every company, literally, if you can make something faster, if you can make the app faster, the website faster, whatever the case is, it increases. The reality is the same thing applies to companies also, because I mostly worked at companies that were underdogs or small when I joined, and I've seen that cycle times matter a lot. Why? Because the faster you can execute, the more experiments you can run in a given period of time. And there's a lot of data that shows that. What matters is not what experiments you run. What matters is how many experiments you can run in a given period of time and learn from them. So if you can run in a— therefore, when a goal is completely unknown, or even it's unknown what to do, I always suggest setting an OKR or a goal such as run at least 6 experiments in a 12-week period where the goal is to learn from each experiment and get better. And I promise people that if you can run 6 good experiments where each builds on the learnings from the prior one, you'll actually get to a very good place by the end of the quarter, even if you don't know where you're setting out. And so speed means that you can actually run experiments faster and you can learn faster and you can move faster. Because competing against large companies, incumbents— I've always been an underdog at underdog companies— the only thing you have going for you is speed. That is your asset. If you lose that, you're done. If you're running experiments at the same pace as your much larger competitor, you're not learning faster, you're not getting, going, getting better faster. And I think this is why I think speed and size of team are tightly coupled together, because when you want to do something, you need to coordinate. The cost of coordination grows larger and larger, exponentially larger, with more nodes you add, more people you add that you need to coordinate. And there's also free riding, which is a human tendency that inadvertently happens. And I Saw this first in— I was like undergrad in computer science, and I remember in our— one of our bachelor— one of our course— I think it was compilers, one of the hardest classes. We had a team of 4, and then I think somehow like middle of the quarter, middle of the semester, a 5th person joined the group. And that 5th person, we were excited initially because we were like, this will help us go faster. But literally bring this person up to speed, and they also saw that we had actually made a lot of progress, so they were there, but they were not really there. They didn't show up for any of our joint brainstorming stuff and so on. So literally, and we were waiting for them, the whole thing went slower by a 5th person joining than just the 4 of us. So we really regretted having this 5th person join us. And so I feel when a team is performing well, and I think there is a— there's a— no, I don't know. I don't know what the— I know there is a number called Dunbar's number, Dunbar's, which is 150 people. But this is like a Maybe we should call it the Skrivner number or Gokul Rajaram number of 6 people or 8 people. I think beyond that, I think teams stop moving fast because the cost of free riding and the cost of coordination becomes too high. The best functioning teams, the product teams I've been part of, are just small, tight-knit. Also, they share the same cultural values in terms of product development. They are all in simpatico with each other. Clearly defined roles and responsibilities. They feel comfortable challenging each other. And you can't challenge each other in a— the bigger the group goes, the harder it is to do that. In a small, tight-knit 6, 7, 8 person group. So I think 8 is the upper bound. I, I feel I randomly came up with it. 6, I think, is the ideal number because you're gonna have 2 backend engineers, 1 frontend engineer, 1 iOS engineer, 1 Android engineer if needed, and then a PM and a designer, something like that. 5 to 7 people. And an analyst, 8 people. There you go, once you get a quartet instead of a trika. So that's, that's an 8-person team that I think is a tight-knit, great, high-velocity team. And so what it means is, if your mission is too broad, where you rate— I think what happens is, as leaders, we automatically get, oh yeah, this team is doing well, let's give them a few more people. But by giving them more people, they're actually slowing them down. So what you do is, instead of the mission slowly expanding and scope creep happening, we should take a big mission and break it down into two smaller sub-missions, or mini-missions. Each of them is owned by a 6-person team or a 4-person team instead of having a big 10-person team owning something. And I think you'll just see— that's the other thing about high-performing teams. They have a very clear definition of success and a clear mission. The more squishier it gets, the harder it is for all of them to stay aligned on what success means.

Really well said. Well, that's the perfect note to end on. This has been amazing, Gokul. I have a feeling I'm going to listen to this many, many, many times. Many times after, uh, this episode comes out. So thank you so much for the time. Thank you for, for coming on. I really appreciate it.

Thank you, Daniel. It was awesome. Thanks for the conversation. Thank you for having me.