The One-Pizza Product Team
How big should my product team be? We all know the answer to this question: if you can’t feed your product team with two pizzas, it’s too large. Appetites vary, but I believe it was meant to mean “about 5”. In this post, I argue that when you are innovating new products, you might be ordering too much food.
The “ideal” size of a product team depends on where the product is in its maturity lifecycle. In the innovation stage of product, you should have the smallest team possible.
Innovation At SuperAwesome
SuperAwesome exists to make the internet safer for kids. To do this, we are defining an entirely new category: kidtech. There is no map for what “kidtech” is or what it does. Given that no-one knows exactly what kidtech products are supposed to do, or even what the scope of our category is, we have to experiment a lot. Discovering which opportunities could mature into scalable business models for us is critical, as is rapidly eliminating dead-ends.
For the record, kidtech is technology designed to enable kid-safe digital products by ensuring privacy and responsibility by design. If you want to know more about the principles that underpin kid-safe online products, check out the Kidtech Standard, and please consider endorsing it.
When innovating solutions to new problems, we need a team that is optimised for rapid iteration, high communication bandwidth and low inertia. We also want to remove as much “survival instinct” as we can, so that a product idea that isn’t working can be killed and the team work on something higher impact. Smaller teams are better on all these axes.
The team must be given a clear and measurable mission. They must be empowered to make day-to-day decisions about the best way to deliver against this mission. The first action of the new innovation team must be to establish it’s core KPI. (It might later prove to be the wrong KPI, but we ship, learn, and iterate.) At some point, its possible they are not making “enough” progress against the KPI, or that the product is “good enough” right now.
Case Study: Kidsafe Social Video
In 2018, we launched a new product, called Kidsafe Social Video. The initial idea for this product emerged from conversations with our customers. The product value proposition was first validated with a “concierge” prototype without writing a line of code. The early product got swift adoption, product/market fit was strongly validated, and of course our initial prototype couldn’t scale with customer demand.
We were able to validate the value risk and product/market fit for our B2B solution with zero engineers. This isn’t possible in every situation, but it’s a dream when you can pull it off. We then needed to figure out the right technology needed to deliver on this product’s value proposition and strategic potential.
We formed a team of two engineers and a product manager to discover and rapidly iterate and innovative the right technical platform to support and accelerate the product’s growth. Our core KPI was initially set around accelerating our nascent operational function. Later, our KPI changed to focus on accelerating the speed at which we could expand the breadth of our offering.
Innovation Requires Focus
In the initial innovation stage of a product, I believe a good team size is two engineers and a product manager. Why do I think a team this small is a good idea? This is a very fragile size for a team. What if someone goes on holiday, has a baby or gets sick?
In a team this small, communication is extremely high-bandwidth. With only three people, the number of communication lines is minimised. Staying on the same page as each other is easy, reducing the number of miscommunications and bogus assumptions.
Faster communication means decision-making is faster, although not necessarily better. During the innovation phase, I would strongly argue that the speed of failure and learning is more important than the proportion of “correct” decisions.
Appetite for risk is high, because the business impact of failure is low. The cost of the team is still small, so everyone can feel a little more aggressive without loss aversion bias kicking in too hard.
The team can’t multitask as they just don’t have the capacity. A team this size will struggle to work on more than one thing at a time. The inability to multi-task forces very strict prioritisation. As each item of work is prioritised, the team must ask: is this the piece of work that most directly helps answer our core question, as measured by our KPI?
For the same reason, the team can’t over-optimise their solutions. The team is simply not going to have the resources to do anything but under-engineer their solution. It will be wonky. It won’t be scalable. For the innovation and early discovery phase of a new product, these are valuable characteristics. Optimise too early and you are just taking longer to fail.
What if your product hypothesis is just too big to be tackled by such a small team? As Jason Fried says:
We don’t throw more people at problems, we chisel problems down until they can be tackled by three people, at most.
Case Study: Kidsafe Filter
The Kidsafe Filter is the part of SuperAwesome’s AwesomeAds platform that solves the problem of ensuring that any advert, even one that is designed to execute arbitrary client-side code, is completely unable to transmit or receive any personal data from kids. The first version of the product emerged from the crucible of our AwesomeAds product team. (AwesomeAds is a scaled product with a large-ish product team). Within the larger team, an innovation team formed of two engineers. The product management and product design was shared with the host team, but the backlog was somewhat separated.
It wasn’t clear initially if this would be the right strategy. We considered whether this work should just be a series of epics for the larger team, but the product needed sustained focus on an innovative new technology solution. They adopted a different rhythm to the larger team and were somewhat shielded from the day-to-day operational noise.
The core KPI for the team shifted over time, essentially following the classic journey of first make it work, then make it scale, then make it cheap.
The smaller team were able to focus and communicate internally extremely efficiently, testing and discarding technical approaches rapidly on their way to something valuable. After the innovation period, the team rejoined their host team to integrate and scale their nascent product as part of the wider AwesomeAds platform.
Survival Instinct
Let’s say you disagree with me. Two engineers is unacceptably fragile. It’s too slow. It’s too much at risk of disruption, disagreement or burn-out. Even in the early stages of a product’s innovation lifecycle we should be putting at least four or five engineers on a problem or we aren’t really trying. I don’t buy it. In my experience: the larger the team, the stronger the survival instinct, and the harder it is to fail fast.
Getting teams to recognise that their usefulness is over is tough. Social groups (and so product teams) naturally and unconsciously defend their own existence.
If you have a brand new product idea and staff the team with five engineers from the start, I think you pretty much always get the answer that the product is worth pursuing, at least initially. The product rapidly builds an ant-hill around it. Unless your team is extremely disciplined about consulting their core KPI daily, a larger team will take more cycles than a smaller team to realise it has failed or succeeded.
In this larger team, team members will naturally divide up work and begin to specialise. Individuals will be less able to see the whole. Unable to perceive its whole as clearly, the team will be slower to recognise and acknowledge the end of its usefulness.
Note: For the avoidance of doubt: “teams” here has absolutely nothing to do with “employees”. When a configuration of employees in a product team ceases to be valuable, the employees move onto the next exciting and high-value challenge. It is the team that disappears, not the employees.
Wider Context
Ensuring teams can assess the value of their current work, within the wider context of the business, is really important. At SuperAwesome, our product teams have direct access to the P&Ls for their product and others, as well as data about our customers adoption and spend across our product. This visibility allows us to provide autonomy with accountability, and with accountability comes the responsibility to make informed decisions to persevere, pivot or disband as makes sense from quarter to quarter and product by product.
We need to create product environments where everyone is aware of the holistic prioritisation landscape, is actively skeptical about whether what they are currently working on is the highest impact thing they could be doing, and has access to the data to answer that question.
Ordering Another Pizza
Small product teams are awesome, but they aren’t right for every product and certainly not for every stage of a product’s lifecycle.
If the product begins to succeed, a team with two engineers is not sustainable for long. As the product discovery and technology innovation begins to head towards product/market fit and stable value generation, it’s time to order another pizza. I can’t tell you when that needs to be, but people will start to look hungry.
If deep tech innovation turns out to be the right solution to a problem, a team constrained by policy may never find that part of the discovery space, and pursue only those solutions that are feasible for them. This is going to depend a lot on your domain.
As with literally everything in product development, there is no one correct answer to anything. The point remains that keeping teams leaner than you are naturally comfortable with (without endangering the health and happiness of your team members) is a Good Thing.
If you want rapid and fearless innovation, I believe you should seek to have the smallest team you can. You also save money on pizza.
If you want to share a pizza or two with us while making the internet safer for kids: we are hiring!
