Patrick Collison argues that the main mistake startups make before product–market fit is insufficient speed of iteration and responsiveness to user feedback. He draws an analogy to John Boyd’s OODA loop and modern fighter design to emphasize optimizing for rapid responsiveness, and advises cautious hiring—typically keeping teams small (empirically between ~2 and 10) to remain nimble.
Chapters
The main thing that I think companies screw up at that pre product market fit stage is sort of speed of iteration. If you have some kind of meaningful, albeit perhaps small initial set of users and you're rapidly iterating in response to their feedback and observed behavior and so on, then I think that's a really good spot to be in. And I think again, at that juncture, pre product market fish, you should be sort of doing everything you can to tighten that sort of feedback cycle. There's a fighter pilot who kind of revolutionized airborne combat in the US in the second half of the 20th century, sort of Korean War onwards, called Boyd, and he had this concept of the OODA loop. Previously, people thought you wanted just like the fastest aircraft or sort of the most sophisticated weaponry and so on, where he was all about sort of. No, you actually want aircraft pilots and training that are really oriented around sort of the fastest sort of responsiveness and iteration to the kind of particulars of the situation in a way that kind of subsequently went on to really inform sort of modern aircraft design. And so I think you want to be like one of these sort of these modern fighters where you're sort of really optimized to respond as quickly as possible to sort of rapidly evolving situations again in this kind of pre product market fit stage. And so then from a hiring standpoint, I think it should really be about, okay, well, what's going to get you there faster? And I mean, I think at an early stage it's most likely just people who will help you kind of build a product, but of course not too many because at some point like you might be able to do more, but you might actually be less responsive because you have a bigger team to manage or something. Right. And so as an empirical matter, it seems that somewhere between kind of 2 and 10, depending on exactly what you're building, is kind of the optimally responsive size. I think in principle the calculation you're sort of trying to run is okay. Each successive person takes time to hire and so slows us down in that regard, takes time to onboard slows us down in that regard. Kind of takes time to just kind of meld with the sort of culture and learn the stack and all that stuff. That also takes cost and time then involves subsequent ongoing cost of just like coordination and alignment and sort of the organization is now distributed across more neurons. And so there's that kind of persistent tax. And that's not just necessarily a linear cost, but it can be sort of quadratic or something kind of given the multi way communication problem. So you have all these costs to an additional person. And so the question is, okay, but this person can also help us get more shit done, right? They can write more code or talk to more users or whatever. And so it's kind of is that fixed benefit to sort of that additional person worth all these other costs? Again with, I think, the ultimate ar abiter being will we be more responsive to what we're learning about our users, given the presence of this additional person? And I think whether or not you will be depends on the complexity of the product and the complexity of the market and all that stuff. But I think that's in principle, the calculation you might be running.
