The more team members a startup has, the harder it is to geometrically share what is going on with everyone and get them emotionally bought into the decisions being made. **This cost should not be underestimated.** Ideally, founding teams for a product should never grow beyond 6 until there is true Product-Market-Fit (PMF). PMF is the milestone of created a product that customers are finding so much value in that they are willing to both buy it (after the test phase) and recommend it. Metrics that show that PMF has been achieved include revenue, renewal rates and Net Promoter Score (NPS). > The first goal of a company should be to find true Product-Market-Fit, not vanity metrics that fool people inside and outside. For a B2B company, note that enterprises have budgets for testing new technology and will buy products to do just that. **This is not PMF.** For these types of customers **only long term contracts** are an indication that they actually value the product or service. Initially, at a Deep Tech company the foray is to do cutting-edge R&D to build IP, mature unique capabilities and evaluate potential opportunities prior to true PMF. > For a B2B company, it's hard to imagine PMF at **anything less than $1 million in annual recurring revenue ### Why should a company not grow beyond a small team of 6 before PMF? 1. **Morale** 1. Until PMF is achieved, the company must have appropriate morale to adapt to negative customer feedback and pivot the company 2. No matter what is said to someone, when a company is more that 10 people, one expects more stability. When after six months of a product launch and it's customers don't instantly rave about it, the team will become demoralized. Irrespective of how many times you say you are a startup and this is to be expected and they should be ready about it. They will hear the words, but not internalize it. 3. By contrast, in a 6 or fewer person team, the environment feels like a team in a battle. Chaos is expected. So when it is actually encountered, the team meets it with glee. People who join small teams crave the challenge of new things and they want things to be hard. 2. Communication & Organization: 1. When there are few people in the room, one knows what everyone is working on without formally having to report to one another. This is valuable, as you can stay in sync without any formal management system, which sinks up significant time and headspace even when done efficiently. 2. When the team becomes large, information sharing via osmosis disappears and trust is harder to gain. This creates the need for a formal management system, taking up almost a day of work for everyone involved. 3. **Speed** 1. Features in code can be created about 10x faster in "prototype" vs "industrial" code. 1. Prototype code is only meant to create a prototype. It's not meant to handle many users, not be easily understood by those who didn't write it. 2. Industrial code is meant to be easily debugged as well as handle many users. 2. When the team is just a few programmers, there is no choice but to write prototype code, as you don't have enough coder hours to do anything else. 3. The reality is that the first product should always be viewed as a prototype. This is what we use to gather customer feedback only. And that feedback will definitely vastly alter what the product is, usually to a point of it becoming a completely different product. So all the effort that will be put into making the initial code beautiful (i.e. industrial) will likely be wasted. If you are small, there is no temptation to write beautiful, unnecessary code. 4. If you are a Deep Tech startup, usually you will raise significant capital early given a large potential market. This allows one to hire many people. Investors will pressure you to do so in order to **win the race to market share.** Resist this pressure, it is misplaced. 5. Startups don't really fail since they grew too late. They usually fail because they grew too early (i.e. before PMF)