Key Takeaways

  • Jeff Bezos designed the two-pizza team (8 to 10 people) for an era before modern AI tools collapsed execution time.
  • Dan Shipper argues that teams larger than two people create coordination drag, conflicting visions, and slow discovery loops on AI frontiers.
  • Fast product discovery requires splitting messy value search from production-grade code architecture.
  • Product teams discover viable features faster by running competing experiments where separate builders tackle the exact same problem in parallel.
  • Shipper structures this discovery process through The Two-Slice Team Formula.

The Two-Slice Team Formula

Jeff Bezos popularized the idea that an internal team should be small enough to feed with two pizzas: roughly eight to 10 people. Shipper argues that modern AI tools make that size obsolete for early product discovery. “For a long time, the standard for team size was the two pizza team,” Shipper explains. “In the AI age, I call it a two slice team. You can get so far so fast with one or two people that anything more, there's a lot of coordination overhead and there's differing visions and it just doesn't work.”

To move fast without accumulating permanent technical debt, Shipper structures two-slice teams around three core components:

  • The Pirate: A high-velocity experimenter who acts as a 'slop cannon' obsessed with finding raw value and exploring new model capabilities without worrying about code quality or architecture. As Shipper describes, this person focuses purely on unearthing whether a new model capability actually solves a human problem.
  • The Architect: A systems builder who inspects messy prototype code, identifies underlying value, and refactors it into a beautiful, extensible, and scalable foundation. The architect ensures that working prototypes do not collapse under real user traffic.
  • Parallel Competition: Deploy multiple two-slice teams or individual builders to solve the same problem from competing approaches in parallel to rapidly map unknown capability frontiers. Shipper notes: “You should be building many experiments in parallel even if those experiments are trying to do the same thing.”

When This Works (and When It Doesn't)

This framework works best when exploring early, ill-defined frontiers of new AI model capabilities where fast iteration and disposable prototypes outperform heavy planning. When you do not know what the model can reliably do, planning a traditional six-week sprint is a waste of engineering hours. You need cheap, disposable software to test user appetite.

It fails when applied to core, mature infrastructure where uptime, data security, and deterministic reliability matter more than novel discovery. You do not want a pirate rewriting your Stripe billing logic or authentication flows with disposable scripts. If the problem space is well-defined and requires high reliability, standard engineering practices and structured code reviews must replace rapid parallel experimentation.

What to Do With This

Take the most speculative AI feature currently on your product roadmap. Instead of assigning a standard five-person sprint team to write specifications, split the work between two people tomorrow morning.

Appoint one engineer as the pirate and give them 48 hours to build three disposable, quick prototypes attacking the user problem from different angles. Have them ignore unit tests, formatting rules, and code modularity. Once real users test the prototypes and locate a working interaction, hand the winning prototype to your architect. Give the architect three days to tear down the prototype code, extract the core prompting and data flow, and rebuild it into a clean, tested service inside your main codebase.