How They Built DoorDash and Square: Gokul Rajaram on Speed, Small Teams, Product Management, and the S.P.A.D.E. Decision Framework

Hello and welcome to another episode of our Investor Spotlight series where we dig into the ideas, frameworks and strategies of the world's best investors. I'm Daniel Scrivener and on the show today I'm joined by the one and only Gokul Rajaram, who's a prolific angel Investor and over 300 companies and counting, and an executive at Doordash, which he joined after Doordash acquired Caviar from Square in 2019. If there's one thing Gokul is known for, it's being an incredible angel investor. He's part of a new wave of solo capitalists like Elad Gil and Locky Groom that play an outsized role in funding and helping many of the world's best startups. As Gokul says in this interview, his goal is for every founder he backs to say that he's the most helpful investor on the cap table. And if there is another thing that Gokul is known for, it's his expertise around product management and decision making, including the Spade framework he created at Square for making transparent decisions at the highest levels. The spade is now used by many of the world's best startups for large, important and strategic decisions that need to be made transparently so the whole company understands why the decision was made. This is one of my all time favorite episodes. In it, we go deep on a lot, including what great product vision and leadership looks like in action, the difference between product managers and product analysts, the merits of editing versus managing a product, how the best product teams design and implement experiments cheaply, and how his Spade framework came out of a failed meeting with Sergey Brin, Larry Page and Eric Schmidt at Google. We even talked through a bunch of his controversial advice from how to test your hypotheses with no code tools and no engineers, to why small teams win and why speed is the ultimate advantage for startups. If you're a product manager or analyst you work on or lead product or you work closely with a product team, this is the episode for you. It's packed with incredible ideas, frameworks and advice from one of the best. You can find the notes and transcript for this episode@outlieracademy.com 102 and you can follow Gokul on Twitter, which I highly recommend at Gokulr. That's G O K U L R with that. Here's my conversation with the one and.

Only Gokul Rajaram Gokul, 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 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, paint a little bit of a picture for people of kind of your journey and your experiences so far.

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 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 six or 700 people. So I was employee number seven 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.combust era where most of the once promising Internet companies had essentially stopped hiring over debt. 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 five years and decided to start a company, which I did with my brother who was my co founder for over two 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 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, which sounded really interesting. So joined Square for a few years, was there actually for six 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 born by Doordash which is how I joined DoorDash two years ago and have been at DoorDash for slightly more than two years and I'm 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, you know, the classic Silicon Valley trike of operating and investing and doing some board work and hopefully 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 better investors. So hopefully nice virtuous cycle there.

I love that point because I always like to think that's the case anyways. But 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 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 that the type of investing I like most is investing in great people and investing in founders. I have a very founder centric view of investing. I think there are investors who believe that markets trump founders. But I 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 and I end up hopefully most likely investing in them.

I want to ask one question, just kind of going back to your background. 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. At the company I worked at Juno, we didn't have a product role. So as a software engineer I was able to. 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 so I got to. I think the biggest learning 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 have seen multiple paths to becoming a product person. Engineering is one path, design is another path. For example, Adam Mossetti, the CEO of Instagram used to be a designer. Marketing is another part. Fiji Simo used to be a product marketer. She's a 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 product analyst before that. So I feel there's at least four 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.

I think you're absolutely right. I think the reason is because the 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 were 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, et cetera, those are products that everybody could use, universal technology products. And so at that point, 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 spend more time and dive into product a little bit more because one, 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 with the vision. I think a great product vision has three or four 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, you got to end a vision look a few years down the road. So ideally five 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 looking down the road a few years out, it's basically, I think those are the three or four 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 a company because they were 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. You know, I think some, the best product leaders actually have 10 or 20% of the time where their 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.

Hearing you walk through that, I mean, it's one, you know, 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.

You know, 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, 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 builders, and they realize that. So I think, in fact, PMs who think of themselves or product leaders who think of themselves 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 are servant leaders and facilitators more than CEOs?

Yeah, it seems almost like the role of, like a quarterback on a football team. And, you know, just. Yeah, 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 want to talk for a second about product managers versus product analysts. And, you know, this was inspired in part by, you know, you talked about, 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 a 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 a 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 got to figure out what customer behavior changes because ultimately all the business outcomes, whether it's 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 is only using the product once a month. Now their behavior changed. They're using it five times a month. They were not paying. They went to paying. So if you think about it, almost everything we think of is actually a change in customer behavior. So 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 features which are really hypothesis around what things can 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 three 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 two times a month. We want those people to use us five 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 five different ways? Because ultimately you got to prioritize, you've got to sequence. And so which could be the most impactfully 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 on 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?

Ready to launch a career and future you can be proud of. Welcome to Merrell where an industry leading advisor training program will help you get licensed. And with lead gen support from bank of America's vast customer base, you'll get the referrals you need to establish your own practice. It's time to see your career charge forward with Merrill. Apply now at careers.bankofamerica.com Copyright 2024 bank of America Corporation.

And the third is quantifying. And this is a constant thing, quantifying underlying business relationships. There is something called an output metric. An output metric as well. You know something you know, for example revenue is an output metric or even retention is an output metric. But what are input metrics? Input metrics are 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? What is the actual increase in retention? Is it worth putting the energy, effort, money in to reduce delivery times in order to improve retention? So you need to know the relationship. Similarly, 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 what is the relationship between price and demand, for example, or retention? So these are all the relationships 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 tradeoffs 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 three things. And then I think they also help us set goals. So help product team set goals around, hey, you know, we have say a thousand people who are using us frequent daily. If you want to grow it to 10,000 people, is that realistic or not? What do we know from, from the past, what we've done? So what is a realistic goal? Is it 5,000, 10,000, 100,000, etc. So they are an indispensable. Again, I think in the past I've, I've been in situations where analysts have been used more for dashboarding, where they use post factor 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, I think the dashboarding work should either be just moved to self serve where people can get 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 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 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 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 and then what the correlation between inputs and outputs is. Because if you focus on the wrong inputs, you may end up doing a lot of work or 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 a hundred inputs, but which inputs truly matter? Which inputs truly. Because we also. 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's many different things you could do on each of them, but if you don't know the right input to control, 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, you know, generally just brutal to answer.

Even personal life. Right. We have. We could have we 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 the hard question that maybe you don't want to confront. But the reality is 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 was. 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 at 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 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 some 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 you do X customer bi will change in way. Why? The problem is that most product teams don't articulate that very clearly. So 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. And so 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, we all how do you validate a hypothesis? You run an experiment. And so basically in order to validate whether this hypothesis is actually going to move customer behavior in the way we think it's going to be, it's going to do. So we have to think of a feature launch as basically an experiment. And 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 like email customers and just manually do stuff. They call it concierge testing or smoke screen 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 thing daily, 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 change in before you can infer that yes, it is going to, at the whole population level, change that behavior. So you create success metrics, 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 could lower the price on a product, and of course, you know, the price is zero, demand will go up, but you have a certain gross margin, you know, 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 A service daily goes up by 20%, assume it only goes up by 10%. It's very important to then dig deeper and understand why it didn't, 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 better. Once we understand by like, why were fewer people, is it because they didn't see the message? Is it because they didn't act on it? Where did it, where did the, 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 1, 1 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 we never remove. 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, which 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 hit the success metrics.

Yeah, I love, 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 things, including some that you probably don't expect. And just the focus on learning there. I wanted to ask, kind of one, I don't know, maybe going from there and going slightly higher. 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, you know, does that, is there an approach where it's like 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 where how experimentation fits in to just the bigger picture.

I believe that you talk to good product development teams, do two things. They 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 how their life is, especially as it relates to the product. How did they last use the product? Not even use the product. How did they last perform a certain action which the product is designed to fulfill. Helps us uncover customer pain experiments. So I think how do you uncover what are the biggest pain points or 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 solve 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, you know, 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, you know, whatever, or there was something else that happened with secular trend, the Fed east 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 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 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 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. When I first joined, I was struck by this word editor. And 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 young product managers gravitate towards it. Unfortunately, it's become a. It is. It is part of the lexicon, so it's hard to get out. But it seems to imply that the PM manages the product. And 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. And 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. And the best product leaders also focus on. I mean Jack is an epitome of that. Right. I think if you look at every product is 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 you know, cashiers to use them square, you can download it from the app store and use it instantly. A point of sale. And so 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. So it's I think an exhortation to think of oneself as going for a minimalistic approach. 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. Spend an inordinate amount of time on prioritization and just making sure that you're focusing on highest level leverage thing. And basically it really is, you're trying to create a forcing function to make sure that it's basically a check and balance just to make sure that you're investing those resources in the right way, which I think generally a lot of companies don't do. Well, I want to talk briefly about decision making in spade because you have this framework that you came up with that has 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 wanted to.

Start with the origin story of Spade.

And you know, 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 a crazy story 16 years ago, I was working in product at Google and 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, three of us simultaneously raised our hands at the same time. And so when he looked around and he saw three of us raising our hands owning the decision, he said, well, three 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. And 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 sum of 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. And because they all have different other things and all of them takes owner, 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 got to have someone 100% on it. Otherwise it's 0%. Anything you want to get done, you got to put someone hundred percent on it. And then at square a few years later.

Gift the remarkable with Marc Jacobs fragrances this holiday season. From the iconic Daisy and Perfect to the all new Daisy Wild Marc Jacobs perfume Gift sets include everything she needs to to feel special from her favorite fragrance plus the matching travel spray. Holiday gifts don't get much more perfect than this. So if you're looking for a gift inspiration these holidays, gift the remarkable with Marc Jacobs.

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 a 13 or 14. The top thing that people were dissatisfied with was the decision making that the transparent. They didn't feel that decision making was transparent and they didn't understand why decisions were made. So at one of the town squares, which is the all handed 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's going to come back in two weeks or three weeks with a solution.

Had you talked with him about that before? He said that I hadn't.

And so he suddenly said that. And so literally we had three weeks to figure out what to do. So I basically got, you know, some people together and all of us brainstormed and our own experiences with high quality decisions. We looked at literature, we looked at what, what had worked for us. And then we talked to a bunch of people across the company and came up with this framework which, 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 the P, but then we said acronyms mean a lot. So we just moved the setting up front and we called it spade. Spade, which is easier to remember than psad.

Yeah, yeah. And it's a very thorough framework. So for anyone listening, you know, check the show notes. I'm going to make sure to link to Goku. You have many amazing interviews. We'll link to. You have many amazing pieces that you have a 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, 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 want to launch internationally, the decision is how to launch internationally. That's imprecise 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 in, 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 you need to make the decision by as well as. Probably the most important part of the essay 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, 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 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. And 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 horsepower behind executing a decision. And it's really three pieces. One, the folks who are consulted and give input towards a decision. The next is people who approve the decision and most importantly, the person who's responsible for ultimately making the call. So you have responsible approver and consultant. And I think the big question that comes up is who should be responsible. You come 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.

Exactly. You own the decision. And the third one is, we talked about SP 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. So it's essentially a different way. You could argue that when we were 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're 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, 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 three 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, 556, 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. 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 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 and A is where companies do this the best, because every acquisition decision has alternatives. You Want to accomplish certain acquisitions done to accomplish a 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 and A deal memo is you have to model out. If we didn't buy, but we built or we partnered, what are those three things and what is the impact, financial impact, quantitative impact of those three things? And so M and 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's 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 a discussion, but ultimately you 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 consultant folks, what it can be by email, by Slack, sms, whatever the case may be, 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 the feedback, and then you 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 who 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 veto things unless vehemently disagree with the process or the way it was done. And approved goals is really the monitored 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 kind of 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 spot 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 knew can see all the decisions that were made and look at the spade document behind it. What we started seeing at Square after about two or three years of doing this was the people were basically making a decision and using spade to justify it. And so retroactively going back and coming at 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 used 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.

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, the decision and just making that part of the culture and, and you know, talking about that and making it open and transparent. Do both of those have equal weight? What, what do you think is, you know, 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 rac. 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, 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, 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 seem incredibly powerful regardless of what decision you're making. Even in your own personal life of like buying a home.

Exactly. 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 the 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 ties. 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, at the end of this interview, but you should absolutely follow Gokul on Twitter. It's Gokulr G O K U L R. 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, 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 six 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 six 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 place 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 four and then I think somehow like middle of the quarter, middle of the semester, a fifth person joined the group. And that fifth 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 fifth person joining than just the four of us. So we really regretted having this fifth person join us. And so I feel when a team is performing well and I think there is a, there's a. I don't know, I, I don't know what the. I know there is a number called Dunbar's number. Dunbar, which is 150 people. But this is like a. Maybe we should call it a scrivener number or Rajaram number of like six people or eight 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. And the best functioning teams, the product teams I've been part of are just small, tight knit. Also having. They share the same cultural values in terms of product development. They are all in sympathico with each other, clearly defined roles and responsibilities. They feel comfortable challenging each other. And you can't challenge each other. The bigger the group goes, the harder it is to do that in a small, tight knit, six, seven, eight person group. So I think eight is the upper bound. I feel I randomly came up with it. Six, I think is the ideal number because you can have two backend engineers, one front end engineer, one iOS engineer, one Android engineer if needed, and then a PM and a designer, something like that, five to seven people and an analyst, eight people. There you go. Once you get a quartet instead of a Trica. So that's, that's an eight 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 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 keep 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 six person team or a four person team instead of having a big ten 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 after this episode comes out. So thank you so much for the time. Thank you for coming on. I really appreciate it.

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

Thank you so much for listening. You can find the show notes and transcript for this episode@outlieracademy.com 102 that's 1 02. @outlieracademy.com you can find more incredible interviews with investors like Joey Krug of Pan Capital, Renick Paley of Stratos, James Currier of nfx, Simon Mikhailovich at Bullion Reserve, and Dan Roller of Moran Capital Management. You can now also find all of our interviews on YouTube@YouTube.com outlieracademy on our channel you'll find all of our full length interviews as well as our favorite short clips from every episode including this one. So make sure to subscribe to get notified whenever we share new videos each week week and if you haven't already, follow us on Twitter, Instagram and LinkedIn at Outlier Academy, thank you so much for listening. We'll see you right here next week on Outlier Academy.