Beyond Five Archetypes, What Must PMs Decide?

A product manager standing between prototype cards and a validation checklist, representing the PM's work of choosing and verifying in the AI era

Recently, Business Insider reported an observation from Boris Cherny, who leads Claude Code, and it has stayed with me.

As engineering, product, design, and data begin to blend together, he argued, what distinguishes people on future teams may no longer be their job titles. It may be five work archetypes: someone keeps throwing out prototypes; someone turns them into a product; someone cleans up the system; someone grows it; and someone keeps a mature system reliable.

He added that these archetypes are not tied to functions. Designers, engineers, and product managers can each fall into different ones. A healthy team also needs a different mix at each product stage. Early teams need more prototypers and builders. Mature products need more people who clean up and maintain.

The observation feels right. But I think it answers only half the question.

It explains how the work gets done. It does not explain how the choices get made.

This framework is not new

Organizing people around product stages is not a new idea.

In 1992, Robert Cringely divided people at technology companies into commandos, infantry, and police: some secure the beachhead, some turn it into a system that can scale, and some protect and expand it. Simon Wardley later used a different set of labels—pioneers, settlers, and town planners. Peter Thiel compressed the same shape into “zero to one” and “one to n.”

The pattern keeps returning because it is real. A person who enjoys chaos and can make something from nothing is rarely the same person who wants to keep a stable system healthy for ten years.

What is new in Boris’s version is not the discovery of that pattern. It is that he moves this axis to the foreground.

In the past, “Which stage are you good at?” was mostly a difference in temperament. The main identity was still “Are you an engineer, a designer, or a product manager?” AI is dissolving those functional boundaries. The stage at which someone is effective is becoming a more important label.

Understanding that matters more than memorizing five names.

The missing layer is decision-making

Put the five archetypes side by side and you notice that almost all of them work on a problem that has already been selected.

The prototyper generates ideas. The builder turns one into a product. The cleaner makes the system coherent. The growth person connects it to the market. The maintainer keeps it reliable.

One step is missing: which prototype is worth continuing?

A builder cannot rely forever on instinct to choose among a pile of demos. A growth team should not have to wait until launch to discover that the original direction was wrong. What is missing is not a sixth kind of person. It is a decision mechanism that narrows many possibilities into one clear choice.

This is also where the PM’s role in the AI era is most easily misunderstood.

Discussions of PM work often turn into a long list: strategy, user insight, prototype management, requirements, acceptance criteria, evaluation plans, staged rollout, growth reviews, complexity control, compliance, and trust.

All of these matter. Flattening them into one list makes the important part harder to see.

I would rather compress them into three kinds of output.

The first is an opportunity judgment: why is this worth doing, and why now?

The second is a decision record: why did we choose A from this set of prototypes instead of B?

The third is a verification rule: what counts as correct, and what conditions send the work back?

Requirements documents may become thinner. On some teams they may stop being the central artifact. These three outputs cannot disappear, because more of the people executing the work are no longer people. They are agents. An agent can read documents, code, and chat logs. It cannot read the hesitation, taste, and trade-offs that stayed in your head.

A judgment that was never written down and cannot be retrieved does not exist to a machine.

The PM’s output is no longer just telling other people what to build. It is helping the organization decide what deserves to be built, then making it possible for both people and machines to carry that judgment forward.

Two companies, two approaches

Anyone can describe a role in the abstract. The more interesting question is how teams at the front of this shift actually work.

In public accounts, Claude Code and Codex offer two somewhat different answers.

Claude Code looks more like “prototype first, then use internal adoption as the filter.” Boris Cherny originally built it as an internal tool before it spread through Anthropic. In the AP’s reporting, Cat Wu described how people using these tools stop watching every line of code and begin expressing higher-level goals instead. She also stressed that final responsibility remains with the human.

The point of this mechanism is not to write a long requirements document and wait for engineering capacity. It is closer to this: get something running, let the team use it, and treat genuine dependence as a strong release signal.

Codex looks more like “turn the repository into an agent’s working environment.”

A file such as AGENTS.md tells the agent what the project is, how to build and test it, which rules it must not break, and what completion means. Research has begun measuring the effect of repository-level instructions like these. One study found that AGENTS.md files can reduce runtime and token usage, but that does not mean more instructions are always better. Give an agent too many rules and it can get lost in them too.

The lesson is that judgment needs to enter the repository, but deciding how much to write and how to write it is itself a product capability.

The two paths look different. Claude Code leans toward real usage; Codex leans toward structured context. Their common ground is clear. Neither brings the old long process back. Neither hands all judgment to the machine. Human judgment still sets direction, taste, trade-offs, and quality boundaries. The execution environment is what changed.

Do not copy them too quickly

All of this rests on one assumption: execution has become cheaper.

That is true on some teams, especially where talent density is high, the builders are also the technical users, and internal dogfooding happens quickly. Prototype and build speed really has changed in those environments.

Move to an ordinary company—especially a B2B product whose customers are outside the building, whose use cases are messy, and whose delivery chain is long—and the assumption may not hold.

METR ran a striking randomized controlled trial with experienced open-source developers using AI tools. The developers took 19% longer to complete their tasks, even though they believed they had become 20% faster. Meanwhile, a Stanford-related study reported a clear employment decline among workers aged 22 to 25 in occupations highly exposed to AI, while more experienced workers were comparatively stable.

Taken together, this evidence does not support a simple conclusion such as “AI always makes execution cheaper” or “AI is useless.”

The more honest answer is that AI reshapes execution, but it rewards people who already know what good looks like and can verify results quickly.

Before copying another company’s organization, ask one question: has execution actually become cheaper here? If the answer is no, an untested assumption is a bad foundation for changing the organization, the process, and where people sit.

In the end

The five archetypes are a snapshot. So is any list of PM responsibilities.

They describe how people divide work on some AI-native teams right now. But “right now” is moving quickly. The useful things to hold on to are not a fixed job title or a longer responsibility list. They are two questions:

Where there is no answer yet, can I make a choice?

Where the result can be verified, can I turn judgment into rules the system can inherit?

Boris offered one answer through five archetypes. Claude Code and Codex each offer another. All are worth studying. None are worth copying wholesale.

You still have to return to your own context. Which judgments on your team must remain human? Which rules can be written down and handed to a machine? Which places look like process problems but are really places where nobody is willing to choose?

That is where the PM’s real position is hiding.

This framework is not new

The missing layer is decision-making

Two companies, two approaches

Do not copy them too quickly

In the end

References