For twenty years, the two-pizza team was the default unit of product work. A product manager. A designer. Four to six engineers. Six to eight people, enough to feed with two large pizzas. This was Jeff Bezos’s famous rule of thumb for the maximum size of an effective team.

The model worked because it matched the constraints of the era. Building software was slow. You needed a PM to understand users and define the problem, a designer to shape the interface, and several engineers to write the code. The gap between “idea” and “working software” was wide, so most of the team sat on the building side. And a meaningful chunk of the week was spent not building, but coordinating: sprint planning, ticket grooming, design handoffs, code reviews, standups. The larger the team, the more process you needed to keep everyone aligned.

That model is over.

Everyone sees it. Nobody agrees on what’s next.

The conversation about smaller teams is everywhere right now, but it’s fragmented.

Henrik Kniberg, the agile coach who popularized the Spotify model, argues that AI is shrinking teams to two people plus AI. Sprints become pointless when you can ship a feature during a subway ride. Marty Cagan at SVPG, who has shaped how a generation of companies thinks about product teams, sees team sizes already dropping and predicts a new “product creator” archetype: a person who can own value and viability end-to-end, enabled by AI tools.

The tiny-company data points keep stacking up. MidJourney reached $200 million in annual revenue with eleven employees. Cursor hit $100 million with twenty. Our friends at Arctal, a data vendor, are building with five people what used to require a full analyst team. Sam Altman’s “one-person billion-dollar company” meme hangs over all of it.

But everyone is talking about fewer people. Almost nobody is talking about which people: what the new team actually looks like, who’s in the room, and what each person does.

What has actually changed

Two things have happened at once, and the combination matters more than either one alone.

On the engineering side, AI coding tools (Claude code, Cursor and Codex, primarily at this point in time) have compressed the work. A senior engineer with these tools can sustain the output that used to require three or four people. Not because the tools write perfect code, but because they absorb the routine work (the boilerplate, many tests, the standard implementations) and free the engineer to focus on architecture, edge cases, and the decisions that determine whether a system holds up or quietly falls apart. You don’t need four engineers anymore. You need one or two good ones.

On the product and design side, AI tools reshaped the job just as dramatically. PMs can now synthesize user research, generate prototypes, and test ideas at a pace that makes the old spec-writing workflow feel absurd. Designers can ship UI changes directly, test concepts on real product interfaces, and iterate without waiting in an engineering queue. The traditional separation (one person understands the problem, a different person designs the solution, a third person builds it) created overhead that was tolerable when building was slow. When building gets fast, that overhead becomes the bottleneck.

The result: the composition of the team changes. Not just the size. The shape.

The SWAT team

We think the new atomic unit of product is three people.

One: the product designer. This is the merged PM/PD role. They own the problem space: user research, customer conversations, understanding what needs to exist and why. And they own the solution shape: wireframes, prototypes, interface design. This is not a traditional PM who writes specs for someone else to design and build, and it’s not a traditional designer who waits for requirements. It’s one person who holds the full arc from “who has this problem” to “here’s what the solution looks like.” Their core output is alignment: making sure the small team has a shared, concrete understanding of what they’re building and for whom. Cagan might recognize this as his “product creator.”

Two: the senior engineer. This person owns the technical architecture and the hard judgment calls. They decide how to build it, what tradeoffs to make, where the system needs to be robust and where it can be simple. They work with AI coding tools as a force multiplier, not to avoid thinking, but to spend more time thinking and less time typing. They’re the person who knows what the AI doesn’t know it doesn’t know. When the AI generates plausible-looking code that will fail at scale, they catch it. When there’s a design decision that will create six months of technical debt, they see it. Their value isn’t in lines of code written. It’s in mistakes prevented and architectural decisions that still make sense in a year.

Three: the junior engineer. This person executes, tests, and, most importantly, learns. In the old model, junior engineers often got lost in large teams, picking up tickets without much context for why anything mattered. In a three-person team, there’s nowhere to hide and nowhere to get lost. The junior works directly alongside the senior, absorbing not just how to write code, but how to think about systems. When to push back on a requirement. When a shortcut is acceptable and when it isn’t. What “good enough” actually means. The AI tools amplify them too. They can be productive from day one in ways a junior five years ago couldn’t. But the real value of this seat is apprenticeship. This is how you grow the next generation of senior engineers.

Three people. Full autonomy. Shipping end-to-end.

Engineers, not coders

Here is the part that most of the “AI is shrinking teams” discourse skips over: it’s not just that you need fewer engineers. It’s that you need a different kind of engineer, and that kind is harder to find, not easier.

AI tools made coding dramatically easier. They did not make engineering easier. Coding is the act of translating a decision into working software. Engineering is the act of making the right decisions in the first place: which systems to build, how they should interact, where they’ll break under load, what the failure modes are, how they’ll evolve over time. Coding is a skill you can learn in months. Engineering is judgment you develop over years. Years of seeing systems succeed and fail, of living with the consequences of architectural choices, of learning what looks right on a whiteboard but falls apart in production.

AI tools amplify both kinds of person. But they amplify the engineer far more than the coder, because the engineer’s bottleneck was never typing speed. It was always the thinking. Give a great engineer AI tools and they become extraordinary. They can execute at the speed of their judgment instead of at the speed of their fingers. Give a mediocre coder AI tools and they produce mediocre code faster.

This means the senior engineer in the SWAT team model is not a commodity role. It’s the scarcest role. Finding people who have real systems judgment, who’ve seen enough to know what they haven’t seen, is the hardest part of building these teams. And this is a problem the industry hasn’t solved. That judgment has historically required a decade of experience, because the only way to learn it was to accumulate scars. Whether AI-assisted environments can compress that timeline, whether the junior in a tight three-person team can develop systems judgment faster than someone diffused across a large team, is an open question, and an important one.

This is why we think the three-person team is the right model, not the one-person or two-person team. You need the senior engineer’s judgment. But not every task deserves their full attention (fixing a recurring alert, building a routine automation, wiring up a standard integration.) That work is real and necessary, but it’s not the highest-leverage use of someone with fifteen years of systems intuition. The junior handles it, and in doing so, learns from proximity to the senior’s decision-making. The apprenticeship isn’t a side benefit. It’s how you make sure the pipeline of engineers with real judgment doesn’t dry up.

A better way to work

The three-person model isn’t just more efficient. It’s more interesting for everyone involved.

The product designer spends their time on customers and design decisions instead of grooming backlogs and translating between disciplines. The feedback loop between “I think users need this” and “here’s a working version” compresses from weeks to days or even hours. The senior engineer is the technical architect of an autonomous unit, making real decisions with real consequences, not managing a ticket queue. The junior engineer apprentices directly to one senior, seeing every decision in context, instead of piecing things together from scattered Jira comments and rotating code reviewers.

For all three: no sprint planning, no ticket grooming, no standups where seven people give a status update that could have been a Slack message. You’re just building.

What we don’t know yet

We should be honest about the things this model doesn’t answer.

Finding these people is hard. The senior engineer we’re describing is a rare profile: systems thinker, architecturally sophisticated, productive with AI tools. Most job postings are still written for coders, not engineers. Most interview processes still test for coding, not judgment. The hiring pipeline hasn’t caught up with the model.

Coordination across SWAT teams is an unsolved problem. When you have ten three-person teams instead of four eight-person teams, you have more autonomy but also more surface area for divergence. How do you maintain a coherent product when teams are this independent? The tooling hasn’t caught up either. Linear’s Karri Saarinen just declared that issue tracking is dead, arguing that tickets were designed for handoffs between humans and don’t fit a world where context and agency matter more than assignment and status. He’s right about the diagnosis. What replaces it is anyone’s guess (but I am curious to see Linear’s solution!).

Career ladders don’t fit. Most organizations still define career progression in terms of team size managed, scope of reports, title hierarchies that assume traditional pod structures. The three-person team doesn’t have a “lead” in the traditional sense. Everyone is senior in their domain. The career incentive structures need to be rebuilt for this shape.

We don’t know what this means for total headcount. Whether the same company ends up with the same number of people in more teams, or fewer people overall, is a question of whether demand for software expands to absorb the increased productivity. That’s a macro question we can’t answer here, and we’re skeptical of anyone who claims they can.

What we do know is this: the pizza pod was designed for a world where building was the bottleneck. That world is gone. The bottleneck now is judgment: the taste to know what to build, the design sense to make it usable, the engineering wisdom to make it hold up, and the customer understanding to make it matter.

Three people, if they’re the right three people, is enough.