Lots of Data

AI workloads, data platforms, and infrastructure notes, written from the engineering edge between benchmarks and production.

RSS feed
/

BEYOND THE JOB TITLE – What Happens to Product Management When Roles Melt Into Archetypes

Boris Cherny’s five archetypes reframe product management beyond job titles—how to hire, organize PM teams, and self-diagnose your default mode in the AI era.

I

Itzik — VP Mission Alignment, VAST Data

·

·

13 min read

BEYOND THE JOB TITLE

What Happens to Product Management When Roles Melt Into Archetypes

On Boris Cherny’s five-archetype framework, and what it means for how PM gets defined, hired, and organized

Table of contents

Boris Cherny, who leads the Claude Code team at Anthropic, recently shared an observation that’s worth sitting with if you work in product. Looking at his own team, he didn’t see the usual lineup of job functions — engineer, PM, designer, data scientist. He saw five recurring archetypes of work, and crucially, those archetypes don’t line up with anyone’s title. Some designers behave like one archetype, some like another; the same spread shows up among engineers, PMs, and data scientists. People often span two or three archetypes at once. None of it is determined by what’s printed on the org chart next to their name.

The five archetypes, in his framing: the Prototyper, who generates a high volume of new ideas knowing most won’t ship; the Builder, who turns a validated prototype into something production-grade; the Sweeper, who simplifies, cleans up, and unships what no longer earns its keep; the Grower, who iterates on something already built to push it toward stronger product-market fit; and the Maintainer, who keeps a mature system secure, reliable, and efficient as it scales. A healthy team, in his view, needs a deliberate mix of these depending on where the product itself sits — not a fixed roster of job titles.

That’s a sharper claim than it first sounds. It’s not just “people wear multiple hats” — every team has always known that informally. It’s that the job title itself may be becoming the wrong unit of analysis for how to staff, organize, and evaluate product work, with the archetype underneath it doing the real explanatory work. This piece takes that idea seriously and asks what it means specifically for product management: a function whose entire premise has traditionally been a single bundle of responsibilities under one title.

The Five Archetypes, Translated to Product Work

Cherny’s framework comes out of watching an engineering-heavy team, so it’s worth translating each archetype explicitly into what it looks like when the person doing it is wearing a “product manager” badge — because the underlying mode of work turns out to translate cleanly, even though the deliverables look different.

•The Prototyper PM. Comfortable being wrong most of the time. Runs many small, cheap bets — rough one-pagers, throwaway prototypes, quick customer conversations — to find a direction worth committing to, rather than writing one polished plan and defending it.
•The Builder PM. Takes a direction that’s already been validated and turns it into a real, shipped v1. The defining skill is writing the rigorous, unambiguous spec that a team can actually execute against — not generating new ideas, but committing fully to one and seeing it through.
•The Sweeper PM. Walks through a live product looking for what should be removed, not added. Kills features nobody uses, simplifies a bloated flow, tightens a backlog that’s accumulated cruft — the unglamorous work of making a product less complicated, which most roadmaps systematically under-reward.
•The Grower PM. Takes something that already exists and runs the iteration loop — pricing experiments, onboarding tweaks, activation funnels — to push it toward stronger product-market fit. This is the closest archetype to the traditional “data-driven PM” stereotype, but it’s one mode among five, not the whole job.
•The Maintainer PM. Owns a mature product’s quiet, compounding obligations: reliability commitments, security posture, the slow accumulation of technical and product debt that nobody notices until it breaks. Unglamorous, frequently undervalued, and essential once a product has real customers depending on it.

People rarely sit in exactly one archetype — most PMs are a blend of two or three, with one dominant.

Archetype, By the Numbers

Putting the engineering framing and the product translation side by side makes the mapping concrete:

.

Archetype

In engineering (Cherny’s framing)

As a PM mode of work

Best product stage

Prototyper

Churns out new ideas; most don’t ship

Runs many small bets and throwaway specs to find direction before committing

Pre-PMF

Builder

Turns a prototype into production-grade work

Writes the rigorous spec and drives a validated idea to a real, shipped v1

Pre-PMF → growth

Sweeper

Cleans up UI and code, unships, optimizes

Audits a live product, kills unused features, simplifies flows and the backlog itself

All stages

Grower

Iterates on a built product toward PMF

Runs the experiment loop — pricing, onboarding, activation — once there’s something real to iterate on

Growth

Maintainer

Owns a mature system’s security, reliability, scale

Owns a mature product’s roadmap of reliability, trust, and quiet, unglamorous fixes

Mature / strong PMF

.

Why ‘Product Manager’ Was Always a Bundle

None of this is entirely new. Anyone who has worked across a few product teams has noticed that two people with the identical title, “product manager,” can do almost unrecognizably different jobs — one spends their week running experiments on a mature funnel, another spends it writing the first spec for something that doesn’t exist yet. The bundle was always somewhat arbitrary, held together more by hiring convention than by any deep logic that these particular responsibilities belong under one job title.

What’s changing is the cost of staying bundled. A separate but related shift is happening in how the underlying work gets executed: Andrej Karpathy, describing what he calls “agentic engineering,” has documented engineering teams moving from writing every line of code by hand to directing fleets of AI agents that execute against a precise specification, with a human reviewing the output. That shift doesn’t replace any of Cherny’s five archetypes — a Builder still needs to decide what to build, a Sweeper still needs to decide what to cut — but it does compress how long each archetype takes to execute, which makes it more obvious, not less, when someone’s actual day-to-day work doesn’t match their job title. A Builder PM who can direct AI agents through most of a build cycle has time left over that a rigid “product manager” job description doesn’t have a clear answer for. The natural place for that time to go is into a second archetype — which is exactly the multi-archetype blending Cherny describes.

Archetype Mix Across Product Stages

Cherny’s framework includes a specific, falsifiable claim about staffing: a pre-PMF product needs people strong in Prototyper, Builder, and Sweeper; a growing product that’s found product-market fit needs Builder, Sweeper, Grower, and some Maintainer; a product with strong, established PMF needs Sweeper, Maintainer, and Grower, with some Builder. Applied to product management specifically, this reframes a staffing question that’s usually asked badly. Teams tend to ask “how many PMs do we need,” as if a PM is a fungible unit. The better question is which archetypes the product’s current stage actually demands, and whether the PMs already in the room have that mix — regardless of their seniority or title.

A team that’s pre-PMF and staffed entirely with Maintainer-leaning PMs will tend to over-invest in reliability and process for a product that doesn’t have proven demand yet. A mature, scaled product staffed entirely with Prototyper-leaning PMs will tend to generate a constant stream of new ideas while the core experience slowly degrades from neglect. Neither team is short on PMs. Both are short on the right archetype mix — a mismatch that a simple headcount number will never surface.

The right archetype mix shifts with product stage — a fixed PM headcount number can’t capture that on its own.

What This Means for How You Hire and Build PM Teams

If archetype, not title, is the real unit of staffing, a few practical changes follow directly:

•Interview for archetype, not just seniority. A candidate’s strongest stories — do they light up describing a scrappy early bet, a clean v1 launch, a feature they killed, an experiment that moved a metric, or a reliability fire they prevented — are a more honest signal of archetype than years of experience.
•Staff against the gap, not the headcount target. Before opening a new PM role, ask which archetype the team is actually missing for its current stage, rather than defaulting to “we need another PM” as a generic ask.
•Let people move between archetypes deliberately. A Builder who’s been on the same mature product for two years may be doing reluctant Maintainer work without anyone naming it — worth surfacing explicitly rather than letting it happen by attrition of energy.
•Evaluate performance against archetype expectations. A Sweeper who shipped fewer net-new features than a Builder isn’t underperforming — they’re doing a different, equally necessary job, and a single evaluation rubric for “product manager” will systematically undervalue that work if it isn’t named.

A Self-Diagnostic: Which Archetype Do You Default To?

A few honest questions tend to surface someone’s dominant archetype faster than a formal framework does:

•When handed a blank page, do you reach for a dozen rough ideas, or one direction you want to commit to fully?
•When you look at a roadmap, are you more drawn to the next big bet, or to the feature three lines down that nobody’s gotten around to cutting?
•Does a flat or declining metric feel like an interesting puzzle to you, or a problem you’d rather hand to someone else?
•When something in production breaks at 2am, is your instinct dread, or a strange kind of satisfaction at finally having a clear, solvable problem?

Most people will recognize a clear top answer and a close second — which matches Cherny’s observation that people typically span two, sometimes three, archetypes rather than living entirely in one. The point of the exercise isn’t to put yourself in a box; it’s to be able to name, out loud, what kind of work you’re actually doing well versus what kind of work your title says you should be doing.

The Verifiability Lens, Archetype by Archetype

AI tools help unevenly across the five archetypes, and it’s worth being specific about where. Karpathy’s distinction between what can be precisely specified and what can be verified maps cleanly here: AI is most useful where there’s a clear signal to check output against, and least useful in ambiguous, open-ended territory.

•Builder and Maintainer work is comparatively verifiable — a spec either gets executed correctly or it doesn’t, a reliability target either gets met or it doesn’t — which makes these two archetypes the biggest near-term beneficiaries of AI-assisted execution.
•Prototyper and Grower work is much less verifiable — whether an idea is worth pursuing, or whether an experiment result reflects something real versus noise, both require judgment AI can support but not substitute for.
•Sweeper work sits in between — AI can flag candidates for removal (unused features, dead code paths, redundant flows) very effectively, but the decision to actually cut something customers might quietly depend on stays a human judgment call.

This matters for staffing too: a team leaning on AI heavily without adjusting its archetype mix risks over-investing in Builder and Maintainer capacity, precisely because those are the archetypes whose output is easiest to feel productive about, while under-investing in the Prototyper and Grower judgment that AI can’t substitute for.

A Worked Example: One Feature, Five Archetypes

Take the same feature request — usage-based alerting for a B2B product, notifying admins as they approach a plan limit — and watch how it looks different depending on which archetype owns it.

•Prototyper: ships three rough versions to a handful of design-partner accounts in a week — a banner, an email, a dashboard widget — expecting two of the three to be wrong, purely to learn which surface customers actually notice.
•Builder: takes the surface that won and writes the precise spec — exact thresholds, per-account scope, re-fire rules, explicit edge cases — tight enough that an AI-assisted engineering team can execute it without guessing.
•Sweeper: six months later, notices the original banner version nobody uses anymore is still running in parallel with the email version that won, quietly confusing a subset of accounts, and removes it.
•Grower: tests whether alerting at 70% versus 85% of the limit changes upgrade conversion, and iterates the threshold based on the result rather than the original guess.
•Maintainer: two years in, notices the alerting service has become a single point of failure for billing-adjacent logic nobody originally designed it to carry, and quietly re-architects it before it causes an incident.

None of these five people are doing a lesser version of “product manager.” They’re doing five different, complete jobs that happen to share a title — and a team that only has Builders on staff will ship the feature well once and then slowly accumulate the exact problems the other four archetypes exist to catch.

Failure Modes to Watch For

•Archetype mismatch. Assigning a strongly Maintainer-leaning PM to a pre-PMF, zero-to-one problem (or the reverse) produces visible frustration on both sides long before anyone names the actual cause.
•Title-based evaluation. Judging a Sweeper or Maintainer by the same “what did you ship” rubric used for a Builder systematically undervalues exactly the work that keeps a mature product from rotting.
•Automation complacency. The more often an AI-assisted draft turns out fine, the more tempting it becomes to skim the review instead of doing it properly — a risk that hits Builder and Maintainer work hardest, since those are the archetypes leaning most heavily on AI execution.
•Accountability diffusion. When a spec, a piece of research, and a prioritization call all passed through an AI assistant, it becomes easy for no single person to feel fully responsible for the outcome — a clearly named archetype owner per decision is the simplest fix.

Without a named archetype and a named owner, accountability tends to fray quietly at the edges.

What Changes in How Teams Are Structured

If archetype is the real unit of work, org charts built around job titles are measuring the wrong thing. A few structural questions worth asking directly:

•Does a pod need one PM, or does it need a Builder and a part-time Sweeper, regardless of how many people that turns out to be?
•Should performance calibration happen within an archetype — comparing Growers to Growers — rather than within a job title that spans wildly different work?
•Does career progression need an explicit archetype-rotation path, so a PM who’s spent three years as a Builder gets deliberate exposure to Sweeper or Maintainer work before it’s assumed they can do it?
•Where does review capacity for AI-assisted output live — is it a skill expected of every archetype equally, or does it concentrate in Builder and Maintainer roles where AI execution is heaviest?

Org structures built around job titles measure something different from the archetype mix actually doing the work.

A Short Glossary

•Archetype. Cherny’s term for a mode of work — Prototyper, Builder, Sweeper, Grower, Maintainer — that cuts across job titles rather than being defined by them.
•Agentic engineering. Karpathy’s term for the disciplined practice of directing AI agents against a precise spec, with a human reviewing every output before it ships.
•Verifiability. The idea that AI is most reliable where output can be checked against a clear signal, and least reliable in ambiguous, judgment-heavy territory.
•Archetype mismatch. Staffing a person whose dominant archetype doesn’t fit the product’s current stage — a Maintainer on a pre-PMF product, or a Prototyper on a mature one.

Further Reading

This piece draws on Boris Cherny’s public commentary on the Claude Code team’s archetype mix, and on Andrej Karpathy’s public talks and writing on the shift from vibe coding to agentic engineering, including his April 2026 talk at Sequoia Capital’s AI Ascent event. Both are offered here as a lens for product management specifically; neither is a direct claim about what either person has said about the PM function, which is an extrapolation made in this piece.

Closing

The PM who clings to the idea that their title fully describes their job will find the ground shifting under them in ways that are hard to name. The PM who can say plainly which archetype they’re operating in today, which one the product actually needs next, and which one they’re deliberately building toward will find that same shift easy to navigate — because they were never relying on the title to do the explaining in the first place.

Note: Boris Cherny leads the Claude Code team at Anthropic; the archetype framework referenced here is drawn from his public commentary. Andrej Karpathy is the founder of Eureka Labs (formerly OpenAI and Tesla); the agentic engineering material is drawn from his public talks and writing in early-to-mid 2026.

From Applications to AI Agents · The Great Unlocking: GTC Paris and Agentic AI · What Does VAST Data Actually Do?

More like this

Discover more from Lots of Data

Subscribe now to keep reading and get access to the full archive.

Continue reading