Gokul Rajaram argues that speed is itself a product feature: faster products increase conversion and retention, and faster companies can run more experiments and learn quicker—an essential advantage for underdogs competing with incumbents. He recommends setting an OKR to "run at least six experiments in a 12‑week period" to accelerate learning, and he ties team size to speed: small, tightly-knit teams (ideal ~6 people, upper bound ~8) with clear roles move faster because coordination and free-riding costs rise as teams grow. He cites experience across companies (Google, Facebook, Square, DoorDash) and references Dunbar's number (150) as a contrast to his proposed small-team scale.
Questions this video answers
Run at least six experiments in a 12‑week period.
Six people (ideal).
Eight people (upper bound).
Dunbar's number — 150 people.
Google, Facebook, Square, DoorDash.
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. I've seen this all the way from Google, Facebook, Square, doordash, every company, literally. If you can make something faster, we 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, and I've seen that cycle times matter a lot. Why? Because the faster you can execute, the more experiments you can run in a given period of time. And there's a lot of data that shows that what matters is not what experiments you run, what matters is how many experiments you can run in a given period of time and learn from them. So if you can run in a. Therefore, when a goal is completely unknown, or even it's unknown, what to do, I always suggest setting an OKR or a goal, such as run at least 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 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, which is 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 don't know what 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 discriminant 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, 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 6, 7, 8 person group. So I think 8 is the upper bound. I feel I randomly came up with it. 6 I think is the ideal number because you're going to 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 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. You should take a big mission and break it down into two smaller submissions. It's not like 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.
