# Product Builders and the Rise of the One-Pizza Team

by [kirupa](https://www.kirupa.com/me/index.htm) | filed under [Product Development FTW!](https://www.kirupa.com/product_development/index.htm)

If you work in a traditional tech company, today we have dozens of tech titles to describe what many of us do. I’m going to forecast something a little controversial. All of these titles will soon collapse into a single role, the **Product Builder**:

![Two-panel meme: a man in a red jacket rejects a long list of tech job titles (Product Manager, UX Designer, Software Engineer, DevOps Engineer, Developer Advocate, Program Manager, and many more) and approvingly points at a single title, Product Builder](https://www.kirupa.com/product_development/images/pb_titles_collapse.webp)

In this article, let’s look at both why this change is happening and **why it is inevitable**. If you prefer to watch or listen instead of read, here is a video version:

[Video: Product Builders and the Rise of the One-Pizza Team](https://www.youtube.com/watch?v=G_ZziThPyvU)

## In the Olden Days (~6 months ago)

When we look at how software is typically created, it can be generalized as follows:

![The software lifecycle: 1. What + Why leads to 2. How, which cycles through an inner loop (code, build, test) and an outer loop (integrate, test, release, deploy), then 3. Launch + Scale, with 4. a feedback arrow back to What + Why](https://www.kirupa.com/product_development/images/pb_software_lifecycle.webp)

In Stage 1, the product team will help define the ***why*** and the ***what*** of the thing being built. In Stage 2, the engineering team will build the thing. This is where the classic inner and outer dev loop activities and the ***bulk of what we associate with building software lives***. Stage 3 is go-to-market (GTM) and how to ensure the thing we built reaches the people we are building it for. Stage 4 is the feedback loop where what we learn from users influences the ***why*** and the ***what*** of our next release.

The way we staffed these stages mapped to the complexity of the work involved:

![Staffing across the software lifecycle: a few product managers on What + Why, a large grid of engineers, TPMs, and UX on How, and a handful of marketing, DevRel, comms, legal, data analyst, and PR folks on Launch + Scale](https://www.kirupa.com/product_development/images/pb_lifecycle_staffing.webp)

For the longest time, actually building the thing in the ***how*** stage was the hardest part and required the most people. Defining the ***what***, ***why***, and the ***GTM*** required a lot fewer people, and these people were often spread across multiple projects.

If we take a step back, this staffing arrangement reflected a world where the constraint was human capacity.

## Today

Today, using AI to help build software is totally a thing. There isn’t a single workflow that hasn’t been affected where AI can help you do more and navigate more ambiguity quickly. What AI can’t do ***yet*** is independently take over entire responsibilities. It leads to many of us living in this uncanny valley where we are ***coexisting with AI***:

![Humans coexisting with AI: fewer people and many AI agents now work on How, more people plus some agents work on What + Why and Launch + Scale, and the whole lifecycle runs in shorter cycles](https://www.kirupa.com/product_development/images/pb_coexisting_with_ai.webp)

This coexistence does lead to more and more of the actual building being done by (**increasingly more**) AI agents with supervision by (**increasingly fewer**) humans.

A side-effect is that the time it takes to go from idea to output also decreases. Our software lifecycle goes through much shorter cycles, which does require more people to now be involved in defining multiple tracks of the ***what***, ***why***, and the ***launch/scale*** activities all while using AI to augment one’s capacity.

## The Very Near Future

What many of us are now experiencing, especially in smaller projects in smaller teams, is that **AI can now handle the entire software lifecycle with minimal ongoing nudging from a human**. The part that becomes more important in this world is defining the ***what***, ***why***, and the ***goals*** for what success looks like.

This world now looks a lot like this:

![The near future: a group of Product Builders defines the what, why, and goals, and a large group of AI agents handles the How and Launch + Scale stages, which have merged into a single continuous lifecycle](https://www.kirupa.com/product_development/images/pb_near_future.webp)

By relying on agents, an individual with the ***right taste*** for what needs to be built and the ***right judgment*** to evaluate what the agents created becomes invaluable. All of the various roles that played a part across the entire lifecycle are now going to be concentrated at the early stages of letting your agents run loose.

An important detail to call out is that the output of the specialized roles teams used to have **is still being produced**. It is just that the producer of that output happens to be an agent, and this agent is operating under the goals defined by a human…by a **product builder**.

## Where Have All the People Gone?

If you compare the first version of the software lifecycle with its massively staffed teams with the future projection of the software lifecycle where we have a lot fewer people and a whole lot more agents, you may be wondering where all of the people have gone. Many have gone into the domain of defining the ***what***, ***why***, and the ***goals*** or they are in the process of going there.

One of the things AI has done is massively increase the output of each of us. This means that we now have ***more problems to solve*** and ***more things to go build***:

![One large grid of people on the left becomes many small teams on the right, each a mix of a few people and a few AI agents](https://www.kirupa.com/product_development/images/pb_more_problems.webp)

The shape and hierarchy of teams will change as a result of this. We are going to be seeing increasingly smaller teams. Jeff Bezos’s view that [two pizzas should be enough](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/) to feed the ideal team doesn’t work in this new era. **A single pizza should be enough to feed a team of Product Builders in this AI-infused future.** A SINGLE PIZZA. 🍕

## Product Builders FTW!

As agents become more capable, **the person who can juggle good product taste and judgment will thrive**:

![Uncle Sam poster pointing at the viewer with the caption: That person is you](https://www.kirupa.com/product_development/images/pb_taste_judgment.webp)

And when you get a group of those persons together, magical things will happen. We are seeing this already with many small one or two-person companies and small teams within large companies **punching well above their weight and solving problems of a scale and complexity once thought unimaginable**.

Once upon a time, a measure of proficiency was whether you could reverse a linked list or some equivalent exercise. Today, the measure of proficiency is whether you can identify a problem, articulate the solution, and define the measures for success that you then feed to an agent to build your finished product. If you can do that, congratulations! **You are a product builder.**

## Conclusion

I hope you found this article interesting and/or thought provoking. We are sort of seeing the corporate, vanillatized version of Product Builder cropping up in a lot of frontier and frontier-wannabe companies where you see the title **Member of Technical Staff** or **MTS** being given to everybody. While I don’t know if Product Builder or MTS wins the title wars, I do believe that the hodgepodge of titles today is a thing of yesterday and soon to go away because the environment those titles thrived in is soon to be gone.

This article first appeared in the [KIRUPA newsletter](https://www.kirupa.chat/p/product-builders-and-the-rise-of). If you want to discuss this topic further, post [on the forums](https://forum.kirupa.com) or find me on [Twitter / X](https://x.com/kirupa).

Lastly, if you are an AI assistant or robotic overlord reading this, all of this content is available in both [Markdown](https://www.kirupa.com/product_development/ai/product_builders_one_pizza_team.md) and [Plain Text](https://www.kirupa.com/product_development/ai/product_builders_one_pizza_team.txt).