AI didn't replace our Product Trio. It turned us into an Atomic Team

A year ago, the death of the product manager became one of the loudest conversations in the industry. AI could research, analyze data, create interfaces and write working code, so the conclusion seemed obvious to some: the PM role would disappear and the Product Trio would collapse into a single AI-native builder.

I combined my own experience building AI products with dozens of interviews, articles and talks from product leaders. I saw three distinct scenarios for where product management was heading. I described them in an article about the changing role of product management.

• The first was the Product Builder/Maker. In this scenario, the traditional division between product manager, designer and engineer starts to disappear. One AI-native person can research a problem, design a solution and turn it into working software.
• The second was the Market-Focused PM, moving closer to product marketing, positioning and go-to-market.
• The third was a small team of AI-augmented Super ICs. The specializations remain, but every person becomes much more capable. The PM can prototype. The designer can run an analysis or build an experiment. The engineer participates in discovery and product decisions. Together, they can cover the full product loop without building a large organization around themselves.

At the time, these were hypotheses. I had experience building AI products, but I wanted to see that change hands-on. So I joined a small AI-native product company and spent a year testing two of those directions in practice. We started close to the Product Builder ideal. We ended up somewhere that I now call an Atomic Team.

The Product Builder promise

AI has fundamentally changed what one product person can do. For the first time in my career, I could take a small product idea, design an interface and build a working version without waiting for engineers, designers or researchers. Other people on the team worked in a similar way. Everyone used AI and everyone could move beyond the traditional boundaries of their role. They didn't need a whole team to build a feature.

On the surface, it looked like the Product Builder thesis had already won:

• end-to-end ownership,
• fewer dependencies and almost no waiting,
• an army of digital agents supporting each person,
• work that previously filled a two-week sprint sometimes completed in one day.

It was really exciting. At the beginning…

The problem was that the ability to build something end to end did not automatically make the whole product work end to end.

We became faster individually, but we didn't automatically build a better product

After a period of rapid growth, the product stopped moving forward. We were still shipping at impressive speed, but the growth had flattened and we started going in circles. As a product person who has experience with many output-driven (instead of outcome-driven) teams, I saw a set of smaller problems that kept repeating:

1. Everyone builds end to end, but each person moves in a different direction

Local autonomy increased faster than shared understanding. We were producing more, but sometimes we were simply turning different interpretations of the same problem into working software much faster.

2. Faster delivery left even less time for opportunity sizing and evaluation

When ideas move to production in days, people don't have time to do opportunity sizing and properly evaluate the features.

AI gradually took over more of that product discovery work. But without strong product metrics and a product mindset, it judged decisions through lagging indicators such as revenue. That made it easy to explain recent results and hard to understand which user behaviors were actually changing.

When I finally defined meaningful product metrics, we discovered that our key indicators had barely moved for the previous six months. We had been shipping quickly while going in circles.

3. AI democratized product analysis and decisions, but the problem is product judgment

Almost anyone could now generate an analysis and a convincing rationale for a feature or experiment. The result often looked polished, structured and persuasive, but… detached from important product context, trade-offs and nuances.

An experienced product person could often look at the same argument and quickly see that it did not make sense. The problem was not that AI was always wrong, but that the confident argument (one you can't judge without product knowledge) became cheaper…

4. When we could build almost anything, the Product Builder was tempted to test almost everything

Ideas that previously died because they were too expensive now survived long enough to become experiments - AI could prepare the research, draft a hypothesis, generate variants and help read the results. Cheap experimentation increased the need for prioritization, but initially we treated it as a substitute for prioritization.

5. Fast experiments created slow consequences

What took one person a few days to generate could create weeks of debugging, rewriting and negotiation later. AI reduced the initial cost of implementation, but it could also move that cost further down the process.

This matched what I had already seen in survey data on AI productivity in product teams: teams use AI heavily for coding and automating existing work, but far less for core product work such as discovery, customer research, strategy, opportunity sizing and evaluation.

Product Builder is a capability, not a team operating model

This became the main lesson for me:

A PM who can prototype, a designer who can build an experiment and an engineer freed from boilerplate all gain meaningful leverage. They can cross traditional boundaries without waiting for someone else to translate their thinking.

But they do not become interchangeable. A PM can miss a usability problem, a designer can miss the architectural cost and an engineer can solve a problem customers do not care about. AI doesn't remove our blind spots.

That is IMHO why the Product Trio still matters. I will even say that it is more important than ever. The specializations remain, but AI lets each person travel further into the neighboring disciplines.

The problem is linear handoffs and working in silos, and AI will not fix it. Most product work still involves discovery, design, development, release and measurement. The problem is not that these activities exist or that some happen before others. The problem starts when they become isolated phases owned by separate functions:

Discovery → handoff → Design → handoff → Development → Release → Measurement

AI can make every phase faster without changing this model. It can produce research, specifications, designs, code and reports, but it does not automatically create shared context or shared accountability.

What helped our team was a return to what had always worked in product: a small cross-functional team, shared ownership, decisions based on evidence and short feedback loops (at the strategic and operational level). We did not replace those product fundamentals with AI. We used AI to power both of our loops:

• Strategic Loop - every month, decide on the strategic bets we want to win and align around them.
• Product Operational Loop - every week, choose the problems for our strategic bets. And iteratively:
  • Explore the problem space
  • Frame the problem
  • Choose solutions
  • Experiment with the solutions
  • Evaluate quality and impact
  • Keep, change or kill it, and feed the learning into the next loop.

We did not eliminate every handoff. We tried to eliminate the handoff of ownership. The outcome and ownership of the product bet stayed with the small group of individual contributors needed for that bet, throughout the loop.

Sometimes this team is Product Manager + Product Engineer. Sometimes Growth Specialist + Product Engineer + Designer. Sometimes a Solo Product Builder.

I call it the Atomic Team

"Atomic" means the team is the smallest unit that can independently turn a problem into a measured outcome for a strategic bet. The product person still brings customer, business and strategic judgment. The designer brings understanding of behavior and usability. The engineer remains responsible for reliability, architecture and maintenance. But nobody hides inside their specialization. Each person brings:

• deep expertise in one area,
• useful capability in adjacent areas,
• shared context,
• explicit decision ownership,
• short loops from hypothesis to evidence.

That is the difference between three independent Product Builders and an Atomic Team. Its goal is not to generate ten times more ideas, screens, code and experiments. That only creates a faster feature factory. The goal is to use AI to better win the strategic bet - understand the user problem better, challenge assumptions earlier and shorten the time from hypothesis to reliable solutions.

This is why product discovery becomes more important when building gets cheaper. A team that can ship in a day can also move in the wrong direction every day.

What I would change in a product team tomorrow

If your trio is experimenting with AI, do not start by asking which role can absorb another. Ask:

• What full product loop are we improving?
• Where are we waiting for access, translation or context?
• Which decisions still require specialist judgment?
• Are we measuring output, or learning and outcomes?

The Product Builder is real, and product people should develop that capability. But a group of people who can each do everything is not automatically a team. The better destination is a small group of AI-augmented specialists with shared context, shared ownership and enough range to move through the loop together.