Definition
The two-pizza team is an organizational principle attributed to Jeff Bezos at Amazon. The rule is simple: no team should be so large that it cannot be fed by two pizzas. In practice, this means teams of six to eight people. The principle is not really about pizza. It is about keeping teams small enough to maintain high ownership, fast decision-making, and minimal coordination overhead.
At Amazon, two-pizza teams are structured as autonomous units that own a specific service or customer experience end-to-end. Each team has its own product manager, engineers, and any other roles needed to ship independently. The team makes its own technical and product decisions within the boundaries of its charter. This model directly influenced the microservices architecture at Amazon and later at companies like Spotify, Netflix, and Shopify. The idea is that organizational structure and software architecture should mirror each other.
The concept is closely tied to empowered teams, where teams are given problems to solve rather than features to build. A two-pizza team that is handed a list of features to implement is just a small execution squad. A two-pizza team that owns a customer metric and has the authority to decide how to move it is a true product trio plus supporting engineers. The distinction matters enormously for team motivation and output quality.
Why It Matters for Product Managers
For PMs, the two-pizza team model changes the nature of the job. Instead of coordinating across a large team and managing dependencies with other groups, the PM focuses on understanding the customer problem, setting direction, and removing obstacles for a tight-knit group. Decision-making is faster because the PM does not need to build consensus across 15 people. Accountability is clearer because the team's success or failure is directly attributable to a small group.
The model also forces PMs to think carefully about team boundaries. If a team needs to coordinate with five other teams to ship anything, the organizational design is wrong. Good two-pizza team boundaries align with customer journeys, service domains, or business metrics. PMs who design these boundaries well create the conditions for speed. PMs who get them wrong create a coordination nightmare that no amount of agile process can fix.
How to Apply It
If you are forming a new team, start with the customer outcome you want the team to own. Define the scope narrowly enough that six to eight people can make meaningful progress. Staff the team with all the skills needed to ship without external dependencies: product management, design, front-end engineering, back-end engineering, and ideally data analysis. Give the team authority over its own roadmap, architecture, and release schedule within the guardrails of company strategy.
If you are working on an existing large team, look for natural seam lines where you could split into two smaller teams. Common split patterns include splitting by customer segment, by product surface area, or by user journey stage. Each new team should have a clear north star metric that it owns. Use OKRs to align the smaller teams toward shared company goals while preserving their autonomy on how to achieve those goals. For more on building effective team structures, see the product operations handbook.