The New Product Team

In a previous essay I argued that AI commoditizes execution and that value rotates to judgment, provenance, and willingness to guarantee. Here I'm trying to think through what that shift means inside a product team. If bounded execution gets cheap, the work has to shift, and I think the team's shape probably does too.

The work, before the tools

Strip the titles off and look at what a product team actually does. Some of it is heavy on judgment; the rest is bounded enough that AI is already competent at it: first-draft PRDs, code scaffolding, mockup variants, SQL, dashboards, experiment design, copy variants. The agent handles those well enough that an expert can verify in less time than producing from scratch.

The translation tax between roles collapses. The PM gets the code, the engineer the data, the designer the spec. What remains is what the agent can't do alone:

• Judge whether the output is good enough to put in front of customers.
• Pick the hypothesis worth testing.
• Encode the business into a form the agent can reason about.
• Build the proprietary models, signals, and data the product runs on.

None line up neatly with existing role titles. The pattern I keep landing on: they cluster into four archetypes.

1. Builders

Builders ship the product. Engineering and design start to merge under agent assistance: an engineer can prototype interactions and iterate on visuals; a designer can ship production code and reason about architecture. Each builder has a center of gravity, but the overlap is wide enough for one person to plausibly own the full loop.

The defining skill used to be production speed; every serious engineer I've talked to has felt that shift. What's scarce now is the ability to tell good from plausible. We're in the golden age of slop: confident output that reads and compiles, mostly fine, every so often quietly wrong. The builder becomes the last line of defense between the agent and the customer. Probably fewer of these people than a traditional team staffs across PM, design, and engineering combined, but better, paid like the liability is real. It is.

2. Product Strategy

This is the trickiest role to think about, and probably the most politically loaded. The old loop ran sequentially across PM, analyst, strategist, and engineer; results came back a month later, context lost across four heads. The new loop, on the teams I've watched, runs much closer to continuous. The agent watches data feeds, tickets, session traces, and experiment results. The strategist arrives to a triaged surface of anomalies and hypotheses, picks what to chase, pulls cuts, prompts the agent to prototype, hands it to a builder, and can watch it ship the same day. The roadmap looks more like a rolling portfolio of bets sized by confidence than a quarterly Gantt chart. The bottleneck stops being execution time. What remains is question quality.

The role pulls together the analytical core of four old jobs:

• PM: hypothesis formation, customer interviews, judgment on which tradeoffs matter.
• BizOps: decomposing vague business questions, sensing unit economics and growth.
• Data science: statistical intuition, experiment design, causal reasoning.
• Product analytics: taste for what to measure, the instinct for why a number moves.

What used to be split across four people has to live in one head.

That has consequences for who fills the seat. The agent is a technical instrument, and the strategist needs to read its output well enough to catch when an answer sounds plausible but the data underneath is wrong. I've watched non-technical operators accept agent output uncritically because they couldn't grade it. The agent also gives confident, plausibly-numbered answers to bad questions all day, and a junior strategist won't reliably know which to throw out. Pattern matching, the taste to ignore the urgent in favor of the important, and calibrated confidence come from having seen enough stories play out. One strategist now drives a loop that used to take four people; the leverage on a great one is enormous, and on a mediocre one enormous in the other direction. I think the bar on quality has to go up.

3. Context Engineers

This is the role that used to be plumbing and, I think, now sets the ceiling on everything else. The job: build the substrate the agent reasons inside. Semantic layers, metric trees, retrieval and eval infrastructure, data contracts. The old audience was humans reading dashboards; the new is the agent, and its quality is bounded by the fidelity of the world-model it works from. Every shortcut in how state gets modeled is a tax the agent pays later. More in the data essay.

4. Data Science

Data science seems to bifurcate. Measurement keeps the team honest: causal inference where there's no clean experiment, switchback tests, diagnosing results too good to be true or too inconvenient. Routine A/B testing flattens into self-serve tooling. The other side is the proprietary modeling: ranking, recommendations, pricing, personalization, fraud. Foundation models commoditize fast; what doesn't is the model trained on what happens inside your product. Data science owns the substrate those models train on, which I think makes the role half the moat. More in the data essay.

None of these archetypes is strictly new. What's changed, as I see it, is the weight on each, the tightness of the loop between them, and the fact that the agent in the middle isn't owned by anyone. Everyone feeds it. Everyone consumes from it. All at once.

An illustrative team

A traditional pod is roughly one PM, one designer, ten engineers, one data scientist, plus fractional slices of data engineer, BizOps, and content. Ten to fifteen heads. The version I'm sketching is more like four builders and four product strategists per pod, with context engineers and data science shared across pods. Around ten dedicated heads plus a thin shared slice. Roughly twenty percent fewer people, same product surface, faster.

Numbers are illustrative; the shape is the point. Fewer builders, more product strategists, context engineering promoted, sharper data science. Talent caliber, on this pattern, goes up. Every seat needs someone who stretches across boundaries: the designer who codes, the engineer who ships with design judgment intact, the strategist who combines framing, data chops, and prototype velocity. The new shape rewards composite profiles the old one pigeonholed.

What it adds up to

A team built this way is smaller, faster, and more opinionated than the one it replaces. The translation tax collapses. Verification and measurement get more expensive: volume is higher, and without measurement the whole thing is an illusion. The four-archetype shape is what I keep landing on from first principles and what I'm watching form at AI-forward companies. How fast it spreads beyond them, and whether the names stick, I'm less sure about. The underlying logic I'm more confident about: teams that get this shape right are likely to make teams still staffing the old shape look slow in a way that's obvious within a quarter.