“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.” – Gokul Rajaram
Gokul Rajaram (@gokulr) is an angel investor and Product and Business Helper at DoorDash. He started his career as a Technical Lead at Juno, and has since led product development at Google, Facebook, and Square. He is an investor and advisor in many companies, and is an active member of several Boards, including Coinbase, Pinterest, and The Trade Desk.
Topics discussed with Gokul Rajaram
- 00:02:26 – Gokul’s background in product management
- 00:06:58 – Applying a computer science background to product management
- 00:10:26 – What great product vision looks like
- 00:16:32 – The product analyst role
- 00:23:11 – Focusing on controllable inputs
- 00:26:07 – Experiment design
- 00:34:54 – Editing vs. managing a product
- 00:42:50 – SPADE decision making
- 00:55:18 – Speed in product creation
Gokul Rajaram Resources
- Connect with Gokul Rajaram: Twitter |LinkedIn
- Juno
- Square
- DoorDash
- Coinbase
- The Trade Desk
- Adam Mosseri
- Fidji Simo
- Instacart
- eBay
- Jeff Iacono
- Jeff Bezos
- Jack Dorsey
- Cash App
- SPADE
- Gokul’s S.P.A.D.E. Toolkit
- Eric Schmidt
- RACI matrix
Books Mentioned in This Episode
- Amp It Up: Leading for Hypergrowth by Raising Expectations, Increasing Urgency, and Elevating Intensity by Frank Slootman
Learn More About This Topic
This is a great starter guide to the product management role in software development.
What It Takes to Become a Great Product Manager
This article from Harvard Business Review outlines the traits needed to excel at the product management role.
10 Powerful TED Talks To Make You a Better Product Manager
Check out these great talks from leaders like Simon Sinek and Guy Kawasaki that are recommended for product managers.
Are You Ready to Serve on a Board?
Gokul and Daniel discuss being a great board member; HBR outlines the first steps to take in that direction.
The Complete Guide to Board Member Responsibilities & Roles
This extensive guide explains the responsibilities of a board member and what to expect from the role.
Transcript
Daniel Scrivner (00:00:06):
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 Scribner, and on the show today, I'm joined by the one and only Gokul Rajaram, who's a prolific angel investor in over 300 companies counting, and an executive at DoorDash, which he joined after DoorDash acquired Caviar from Square in 2019.
Daniel Scrivner (00:00:27):
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 Lachy Groom, that play 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. 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.
Daniel Scrivner (00:01:07):
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 a 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.
Daniel Scrivner (00:01:43):
If you're a product manager or analyst, you work on or lead product, or you work closely with the product team, this is the episode for you. It's packed with incredible ideas, frameworks and advice from one of the best.
Daniel Scrivner (00:01:55):
You can find the notes and transcript for this episode at outlieracademy.com/102, and you can follow Gokul on Twitter, which I highly recommend, @GokulR. That's G-O-K-U-L-R.
Daniel Scrivner (00:02:07):
With that, here's my conversation with the one and only Gokul Rajaram.
Daniel Scrivner (00:02:13):
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.
Gokul Rajaram (00:02:24):
Thank you, Daniel. Great to be here.
Daniel Scrivner (00:02:26):
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 experience so far.
Gokul Rajaram (00:02:45):
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 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 is an early ISP, as a software engineer. 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.
Gokul Rajaram (00:03:17):
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 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 heading over debt. And so Google was a great environment. Worked with a lot of great people there, and was lucky enough to work on some good products, and stayed there for five years.
Gokul Rajaram (00:03:55):
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. 10% team, most of us joined Facebook, and stayed at Facebook for a few years.
Gokul Rajaram (00:04:18):
And then got a call from Square. It sounded really interesting, so I 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 bought 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.
Gokul Rajaram (00:04:45):
And in addition to DoorDash, I sit on a few boards. I sit on the boards of coin-based interest 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 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 has become a better investor. So hopefully [inaudible 00:05:22] cycle there.
Daniel Scrivner (00:05:23):
I love that point because I always like to think that's the case. But I love when people can think of those things as 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 describe you as basically a solo capitalist? So you're just investing your own money 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 any notes around strategy, number of investments.
Gokul Rajaram (00:05:53):
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 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.
Gokul Rajaram (00:06:36):
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 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.
Daniel Scrivner (00:06:58):
I want to ask one question just 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?
Gokul Rajaram (00:07:20):
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 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 quartet in one person.
Gokul Rajaram (00:07:45):
And so 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 one of the things that product managers work on, and that's why I decided to move into product.
Gokul Rajaram (00:08:12):
I think what is interesting is, 15 years ago if you'd asked me, I would've 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. Fidji 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 [Icono 00:08:54], who led for product for Caviar, was essentially a product analyst before that.
Gokul Rajaram (00:08:58):
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 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.
Daniel Scrivner (00:09:24):
What do you attribute that change to? You talked about early on this point of view that you had to have an engineering background. 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 take?
Gokul Rajaram (00:09:44):
I think you're absolutely right. I think the reason is because the earlier software product was somewhat esoteric. They were operating systems, and they were quite esoteric to build. So the Microsoft back in the eighties and nineties, which some of the first product managers were working on Sun Microsystems, they were extremely technical environments and the products were also used by techies 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 insights and skills to designing these products because they're universal.
Daniel Scrivner (00:10:26):
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 I think that you have a lot of just fascinating, full of wisdom thoughts around product. I wanted to just start with, at a super high level, what does a gr what does great product vision in leadership look like? And I think what I'm looking for there is your experience not only at Square, Caviar, DoorDash, 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 iterate and operate.
Gokul Rajaram (00:11:06):
It is a great question around what a great product vision looks like.
Gokul Rajaram (00:11:09):
Let's start with a 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 and how, what way?
Gokul Rajaram (00:11:51):
Third thing is you need to show differentiation. Something in your vision should explain why your product is different. Why does it serve the customer differently than everyone else? So what aspect are you going to be different in? The remarkability part of it. And then you've got to end the vision. Look a few years down the road. So, ideally, five years, I would say. You want people to say blank about your product.
Gokul Rajaram (00:12:14):
So 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. I think those are the three or four things that we need to have in a product vision.
Daniel Scrivner (00:12:33):
Yeah.
Gokul Rajaram (00:12:33):
In terms of product leadership, I think if you think about product leaders, the best product leaders, first, they care about impact. 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 X, Y, Z 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?
Gokul Rajaram (00:13:05):
Second, they recruit amazing teams. They don't just leave recruiting to the recruiting team, but they step in 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 the product function is surrounded by great colleagues, and product leaders recognize that.
Gokul Rajaram (00:13:35):
Third, they're a culture setter. They understand the kind of culture the founders want to set at a company because they work closely with the founders, and they influence that as a champion of that culture.
Gokul Rajaram (00:13:46):
Fourthly, 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.
Gokul Rajaram (00:14:16):
They can be a model IC. They need to demonstrate how. I think some of the best [inaudible 00:14:24] actually have 10 or 20% of the time with 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.
Gokul Rajaram (00:14:35):
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.
Daniel Scrivner (00:14:51):
Hearing you walk through that, 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 a particular function. Is that how you think about it? Because it's this mix of vision, execution, discipline ...
Gokul Rajaram (00:15:10):
Again, 15 years ago, if you had asked me, I would've said the product person or the PM or the product leader is the CEO of the product, but I 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 engineer leader, design leader, all of these people don't necessarily report to you as a product leader.
Gokul Rajaram (00:15:33):
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 them-
Gokul Rajaram (00:16:03):
And they realize that. So I think, in fact, PMs who think of themselves as prodigies, 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.
Daniel Scrivner (00:16:19):
Yeah. It seems almost like the role of a quarterback on a football team and 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.
Daniel Scrivner (00:16:32):
Okay. I want to talk for a second about product managers versus product analysts. And this was inspired in part by, you talked about, and we'll talk about it in a second, this idea of a product team quartet and having 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, 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?
Gokul Rajaram (00:17:04):
Yeah. It's a great question. And to be honest, until someone works with a product analyst, 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 outcome.
Gokul Rajaram (00:17:27):
So what do product managers do? We 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. Your 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 is revenue, profit, whatever it is, are a result of customers changing behavior. Customers were not a customer, this person is not a customer, they became a customer. They were a customer that was only using the product once a month. Now the behavior change, they're using it five times a month. They were not paying, they went to paying. So if you think about it, almost everything they think of is actually a change in customer behavior.
Gokul Rajaram (00:18:15):
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 solution are. What are the best ways tactically to basically change this customer behavior? That's at a high level. 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 which features, which are really hypotheses around what things can customer behavior?
Gokul Rajaram (00:18:45):
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 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... 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 trying 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've got to prioritize, you've got to sequence. And so which could be the most impactful [inaudible 00:19:37]? That's one. So it's almost a compass that tries to directionally estimate which direction to go in.
Gokul Rajaram (00:19:43):
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 a hypothesis and 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?
Gokul Rajaram (00:20:04):
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 is something... For example, revenues are 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 are 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 of retention. But what is that improvement?
Gokul Rajaram (00:20:43):
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 into reduce delivery times in order to improve retention? So you need to know that relationships. And really if you lower price, almost suddenly people will order more. But what's the relationship? How much do you lower price? Do 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 relations between input metrics that we control and output metrics that are changes in customer behavior that we observe.
Gokul Rajaram (00:21:19):
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 three things.
Gokul Rajaram (00:21:35):
And then I think they also help us set goals, help product teams set goals around, hey, we have say 1,000 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 the past of what we've done? So what is a realistic goal? Is it 5,000, 10,000, 100,000, et cetera? So they're indispensable. Again, I think in the past, I've been in situations where analysts have been used more for dashboarding, where they use post factor reporting. They create great BI dashboards, local tables, whatever it is, whatever the tool of choice is. And that's, I think, they get disgruntled ultimately because that's not what is the best use of their talents, I think.
Daniel Scrivner (00:22:17):
It's very low leverage. It sounds like what you're doing is putting together a dashboard.
Gokul Rajaram (00:22:21):
Exactly. They don't feel that they're actually influencing product decisions. And so I think you'll find instant productivity change. Therefore, I think the dashboarding work should either be just move to self-serve where people can create their own dashboards, roll them out, the tools like [inaudible 00:22:35] and so on. Or there should dedicated BI team whose job is to just build these dashboards easily. But using product analysts to create dashboards, I think, is maybe a 10% part of their job at most.
Daniel Scrivner (00:22:46):
Yeah. Yeah. Well, I love that point because I think the metapoint I've observed there that's felt very profound to me is... Yeah. If you're focused on productivity, you need to give people sizeable, meaty roles and response to abilities 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.
Gokul Rajaram (00:23:10):
Exactly.
Daniel Scrivner (00:23:11):
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 a follow on was 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 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?
Gokul Rajaram (00:23:47):
That's exactly right. This is where the analysts come in. The great analysts really constantly try to figure out which inputs to focus on and then what the correlation to 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 outputs. So that's probably one of the most high-leverage things that an analyst or data team could do; figure out which inputs matter. There could be a 100 inputs, but which inputs truly matter?
Gokul Rajaram (00:24:24):
Because also time is an 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 biggest... Look, you and I, any smart person given a product can brainstorm a hundred 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. 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 focus on, you could end up doing something that doesn't needle.
Daniel Scrivner (00:25:11):
Yeah. 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.
Gokul Rajaram (00:25:23):
Even personal life. We are all a fan of checklists around doing stuff, but if you think about it, if I ask someone, " What is one thing you need to complete today," people struggle to answer and they also just shy away from it because it's sometimes a hard question that maybe you don't want to confront. But the reality is they say, "Eat the frog first."
Daniel Scrivner (00:25:41):
Yes.
Gokul Rajaram (00:25:41):
Which means you've got to just do the hardest thing first, if possible, in the day.
Daniel Scrivner (00:25:46):
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 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 what an amazing question that is.
Gokul Rajaram (00:26:05):
That's a great question. I love that question.
Daniel Scrivner (00:26:07):
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 some notes around that.
Gokul Rajaram (00:26:28):
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 behavior will change in way Y."
Gokul Rajaram (00:26:50):
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, how do you validate hypothesis? You run an experiment.
Gokul Rajaram (00:27:21):
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 email customers and just manually do stuff. They call it concierge testing or smoke screen testing or visitor [inaudible 00:28:02] testing, where it's just a person behind. Might look like a product, but it's just a person.
Daniel Scrivner (00:28:06):
With a bunch of no code tools.
Gokul Rajaram (00:28:08):
Exactly. No code tools. Exactly. People, essentially. And so I think what you want to do is you want to take a population. First of all, you need a clear hypothesis. You want to say, for example, that we believe that the number of customers using our service daily 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.
Gokul Rajaram (00:28:36):
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 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?
Gokul Rajaram (00:29:16):
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 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.
Gokul Rajaram (00:29:46):
So you then run the experiment and then you report back. And then you also list your assumptions. And the key here is that even if 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%. As 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 develop be better.
Gokul Rajaram (00:30:25):
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 the success.
Gokul Rajaram (00:30:54):
But you cannot give up an experiment, just like if a scientist gave up on an experiment after one run, we would not see anything happen. So as a product team, if you truly believe that this is a high leverage thing... Because you're not going to do an experiment for low leverage things. Hopefully all you 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 until 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, until you conclude success on the experiment or hit the success metrics.
Daniel Scrivner (00:31:43):
Yeah. 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 one, I don't know, maybe going from...
Daniel Scrivner (00:32:03):
... 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 would be interesting for a second to talk about why thinking in terms of experiments is so valuable. Because I think that's something that, 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 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 an embracive 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 in to just the bigger picture.
Gokul Rajaram (00:32:58):
I believe that good product developer 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 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. 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.
Gokul Rajaram (00:33:46):
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, a secular trend, the Fed eased interest rates or something that changed.
Gokul Rajaram (00:34:27):
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.
Daniel Scrivner (00:34:54):
Yeah. No, that's really well said. So run experiments, both, I think to better understand ground truths in reality. And just make sure you're not kind of seeing things in a distorted way. And also run experiments, because you may know what nail 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 course graining versus fine graining experiment. Okay. I want to talk for a second about editing versus managing, because obviously we both spent time at Square.
Daniel Scrivner (00:35:25):
Just for a quick bit of background, and then please correct me, add to this, Gokul, but at Square, it largely 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. I think shaping's 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.
Gokul Rajaram (00:35:55):
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 data 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 unfortunately it's become, it is part of the lexicon, so it's hard to get out. But it seems to implied that the PM manages the product, and it somehow even it seems to apply 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.
Gokul Rajaram (00:36:51):
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. 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 sale used to have training sessions for baristas or cashiers to use them.
Gokul Rajaram (00:37:35):
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, and it's like using essentially any simple consumer app, that shows you the part 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 at 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.
Daniel Scrivner (00:38:24):
Yeah. So to distill down, focus, yeah. Spend an inordinate amount of time on prioritization and just making sure that you're focusing on highest leverage thing. And basically, it really is you're trying to create a worse 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 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.
Gokul Rajaram (00:39:21):
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." He was very good at ending meetings quickly. "I'm ending this meeting now. Go back, and then don't come back until you figure out who owns this decision."
Gokul Rajaram (00:40:11):
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 case 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 there's basically, there's a group of them and none of them takes ownership.
Gokul Rajaram (00:40:58):
So at the end, they end up leaving him behind because they all have different other things. And each of them take ownership, 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, it's the language 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 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. They didn't feel the decision making was transparent and they didn't understand why decisions were made.
Gokul Rajaram (00:41:51):
So at one of the town squares, which is the all handed Squares, you remember them, 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."
Daniel Scrivner (00:42:06):
Had you talked with him about that before he said that?
Gokul Rajaram (00:42:08):
No, 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 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. Where 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, which is easier to remember than PSADE.
Daniel Scrivner (00:42:50):
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. 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.
Gokul Rajaram (00:43:22):
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 really what the decision is. For example, when we say, well, we want to launch internationally. The decision is how to launch internationally. That's a 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 launch it in. So there's more decisions, more dimensions to any decision that with the S you can articulate.
Gokul Rajaram (00:44:20):
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 S is the why. Till we understand why, which is the objective, why are we making 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 a market share. So of course, if you're arguing over two completely different things, the price you come up with, the decision was actually how to price a certain product would be completely different.
Gokul Rajaram (00:45:16):
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 had [inaudible 00:45:25] ... implemented SPADE and it really forced us in that case to get them to implement SPADE, but that it was only 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 harsh part 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 just responsible for ultimately making the call. So you have responsible, approval and consultant. And I think the big question that comes up is who should be responsible?
Gokul Rajaram (00:46:07):
You go out with [inaudible 00:46:07] ... think about it, 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 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 duration to implement, which you had no role in making, that's one of the least empowering things.
Daniel Scrivner (00:46:34):
Yeah. You need skin in the game and that alignment of incentive. If you're going to deal with the consequences, then yeah, you should get to own it. Absolutely.
Gokul Rajaram (00:46:41):
Exactly. You own the decision. And 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 participant, your next step is to outline the alternatives. And 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 obviously, you can't have impractical alternatives. They should be realistic. They should be diverse.
Gokul Rajaram (00:47:20):
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, 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%, then charging $5 plus 2%? Those are three completely different ways of thinking about it. Is a fixed price better, a percentage better, or some blend better? And then once you figure out that, then you can actually micro, whether it's 5, 5.56, et cetera. And so you want have a diverse set of alternatives. And then finally, the D is the decision phase. Once you have these alternatives-
Gokul Rajaram (00:48:03):
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. 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, every alternative has pros and cons and what you care about the most.
Gokul Rajaram (00:48:35):
I think M&A is where companies do this the best because every acquisition decision has alternatives. Acquisition is done to accommodate a certain business strategy. You can have buy, you can have partner or you can have build, so there's clear alternatives to acquisition. 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, are we partnered? What are those three things and what is the impact, financial impact, quantitative impact of those three things? M&A professionals are very, very good at this modeling. 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.
Gokul Rajaram (00:49:20):
What happened, what we saw with this SPA, before we get too deep, let's talk about these decide, which is and I'll go back to what happened at Square Once 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. Essentially, you've got to have 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 and the consultant folks. It can be by email, by Slack, SMS, whatever the case may be. Why what alternatives they choose amongst all the alternatives and why they choose it.
Gokul Rajaram (00:50:05):
Then after you get all that back, you ruminate on it and you basically decide. Make the decision. Thoughtfully consider their feedback and then involve choosing one of these alternatives and then writing out, in as much detail as possible why you chose it. Then finally explaining. Explanation is 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 approval to make sure there's no veto. Typically [inaudible 00:50:45] don't really veto things unless we vehemently disagree with the process or the way it was done and [inaudible 00:50:52] goals is really the wanted decision process, not the result.
Gokul Rajaram (00:50:56):
Then you want to also make sure that folks who are involved in that decision are committed. We have this phase, 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 this to help you execute on the decision and one of the failure modes is when people say, oh yeah, decision has been made, but then they undermine the decision through actions, even if they don't say it otherwise. You want them to explicitly, in a public setting, say that I disagree, but commit. It's called the commitment meeting. Then you circulate. You basically send an email out with the SPADE summary and you, ideally 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.
Gokul Rajaram (00:51:42):
What we started seeing at Square after about a 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. 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 the decision, so there's no decision going to be made. You just have to spend a lot of time outlining the alternatives, outlying the setting, getting people together, getting their inputs and then we make a decision separately. This very quickly eliminated that decision. The decision was already going to be made, it was just doing the work around the alternatives and doing high quality work there.
Gokul Rajaram (00:52:20):
I think it was first done with a company called [Vibli 00:52:25] and so there was a ton of decisions going to be made around Vibli integration and they use SPA instead of SPADE, which I thought was very powerful. 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 understand the alternatives and not quickly come to a decision and back justify it based on some other stuff.
Daniel Scrivner (00:52:46):
Yeah. 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. It does seem like that's where all the leverage, that's where all the meat is. What do you think is special about this framework? 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 know what path to follow. Then there's also 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 the most impactful part of a framework like this?
Gokul Rajaram (00:53:28):
Biggest impact for me was people just didn't have a common framework to make decisions. There was no framework existing at most companies. Consulting firms have things they used like, people who worked at like RACI or AC. There's a few frameworks, but in the technology industry there was no shared language around making decision. It was all made informally and not really articulated. There was no framework. I think it literally was bringing light to where there was darkness. 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. I think the biggest impact was there was nothing before and now there's something and people wanted a framework, whatever it is. 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.
Daniel Scrivner (00:54:32):
Yeah. 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.
Gokul Rajaram (00:54:40):
Exactly. I've actually seen people use it in their personal lives now. 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 you have multiple options with no easy decisions. It helps you, like you said, layout the pros and cons of each approach and then make a decision quickly. If a decision can be validated by a quick experiment, then SPADE is probably not a good fit because you just wanted run an experiment to see, but in many cases it may not be possible to run an experiment because once you make it, they're not reversible as easily. They're almost one way door decisions and that's where SPADE really shines or something like that.
Daniel Scrivner (00:55:18):
That's really well said. I have many other questions that I would love to ask you, but want to be respectful of your time, so I'll ask you one final question, which is, you talk a lot about and this is just kind of 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, G-O-K-U-L-R. He's got some amazing stuff, but one of the things that you talk about quite often is 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. I know these are three separate but related ideas, so I'm trying to tie them together, but 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.
Gokul Rajaram (00:56:14):
Yeah. It's funny. Speed is a product feature. Almost always, if you make a service faster, you see that customer conversion increases, retention increase, everything increases. I've seen this all the way from Google, Facebook, Square DoorDash, every company, literally, if you can make something faster, 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, are 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.
Gokul Rajaram (00:57:06):
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. 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. 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're going for you speed. That is your asset. If you lose that, you're done.
Gokul Rajaram (00:57:43):
If you're running experiments at the same pace as your much larger competitor, you're not learning faster. You're not getting better faster. This is why I think speed and size of team are tightly coupled to 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. There's also free writing, which is a human tendency that inevitably happens. I saw this first in, it was undergrad computer science and I remember in one of our bachelor, one of our courses, I think it was compilers, one of the hardest classes. We had a team of four and then I think somehow 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 bringing 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. 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.
Gokul Rajaram (00:58:55):
I feel when a team is performing well, I know there is a number called Dunbar's Number, which is 150 people, but this is like a way we should call it a [inaudible 00:59:07] number or a [inaudible 00:59:08] number of like six people or eight people. Beyond that I think teams stop moving fast because the cost of free writing 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. They share the same cultural values in terms of product development. They are all [inaudible 00:59:32] with each other, clearly defined roles and responsibilities. They feel comfortable challenging each other and the bigger the group goes, the harder is do that. In a small, tight knit, six, eight person group. I think eight is the upper bound. I feel I randomly came up with it. Six I think is the ideal number because you're going to have two backend engineers, one frontend 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 tri. That's an eight person team that I think is a tight knit, great high velocity team.
Gokul Rajaram (01:00:07):
What it means is, if your mission is too broad... I think what happens is as leaders we automatically get, 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. What you should do is, instead of their mission slowly expanding and scope keep happening, you should take a big mission and break it down into two smaller sub missions, like mini missions. Each of them is owned by a six person team or a four person team, instead of having a big 10 person team owning something. 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 see and land on what success means.
Daniel Scrivner (01:00:49):
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 after this episode comes out. Thank you so much for the time. Thank you for coming on. I really appreciate it.
Gokul Rajaram (01:01:02):
Thank you Daniel. It was awesome. Thanks for the conversation. Thank you for having me.
Daniel Scrivner (01:01:07):
Thank you so much for listening. You can find the show notes and transcript for this episode at outlieracademy.com/102. That's 102. At outlieracademy.com, you can find more incredible interviews with investors like Joey Krug of Pantera Capital, Rennick Palley of Stratos, James Currier of NFX, Simon Mikhailovich of Bullion Reserve and Dan Roller of Maran Capital Management. You can now also find all of our interviews on YouTube at 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. Make sure to subscribe to get notified whenever we share new videos each week. If you haven't already, follow us on Twitter, Instagram and LinkedIn at Outlier Academy.
Daniel Scrivner (01:01:53):
Thank you so much for listening. We'll see you right here in next week on Outlier Academy.
On Outlier Academy, Daniel Scrivner explores the tactics, routines, and habits of world-class performers working at the edge—in business, investing, entertainment, and more. In each episode, he decodes what they've mastered and what they've learned along the way. Start learning from the world’s best today.
Explore all episodes of Outlier Academy, be the first to hear about new episodes, and subscribe on your favorite podcast platform.
Daniel Scrivner and Mighty Publishing LLC own the copyright in and to all content in and transcripts of the Outlier Academy podcast, with all rights reserved, including Daniel’s right of publicity.
