The Builder-PM Manifesto
The 52 Theses of the Builder-PM
In My Life in the Harness, the question was what happens to one person when scaling laws migrate out of the model.
My Life in the Harness
I don’t work in a chat window anymore. I work in the Business Engineer’s harness.
In How I Ended Up in the Harness the question was how that migration happened in the first place — the four-year arc from ChatGPT through o1 through MCP through the swarm era, in which scaling laws didn’t stop, they moved out of the model and into the harness around it. This book asks what comes next — when the migration reaches the team.
Why I Ended Up in the Harness
A few days ago, I explained how, over the last eighteen months, the way I work has completely changed.
The Harness pieces traced changes in the substrate at the scale of a single practitioner. The chat window dissolved into a harness. The keyboard stopped being the primary surface. The work shifted from operating a tool to framing a system that operated tools for me.
Seven structural principles fell out of that shift — agent swarms, self-improving loops, shared intelligence, gates over guardrails, memory as architecture, orchestration as substrate, the one-person-plus-harness-equals-team thesis. SaaS mutated into AGaaS in lockstep because the unit of value travels with the frontier. The thing being priced shifted from a tool a person operates to an outcome a system delivers.
The pieces left one question unanswered. If the harness is the new operating layer for one person — and if the outcome it produces is what gets sold now — what does it look like at the scale of a team?
This book is the answer.
Join Yearly Premium Membership To Get The Builder-PM
Or
The Builder-PM is what product management looks like once the migration has completed and reached the team. Conventional PM was built for an operating substrate that no longer exists — a chat-era world where specs got handed off, roadmaps got reviewed across quarters, and stakeholders got coordinated across functions that were expensive to bridge.
That substrate was the old scaling regime: capability inside the model, value inside the seat, work inside the spec. All three have moved.
The new substrate is the harness, applied at the unit of a team rather than the unit of one person. The five-to-ten-person founder cell is one person with a harness, scaled up by an order of magnitude and given a bet portfolio.
Same role compression. Same direct line to the source of authority. Same negative space — the deliberately absent functions that protect the unit’s geometry. Same collapse of the spec-to-prototype handoff into a single artifact. Same posture toward the curve: the bet lives in the gap between what just became possible and what has shipped.
What the Harness series argued at the scale of one person — that the edge has moved from operating to framing, and that authorship is the Accountability Floor that cannot be automated because it is not a capability — this book argues at the scale of an organization.
The Builder-PM does not operate the harness. The Builder-PM frames what the harness gets pointed at. The job is bet selection, prototype calibration, loop ownership — the authorship work that survives because nothing in the harness can do it for the team.
The Builder-PM Manifesto — fifty-two compressed statements organized in nine sections — sits alongside the book as the form that travels. The book persuades the reader who will invest ninety minutes. The manifesto reaches everyone the book’s readers want to send something to. Both belong to the same argument.
If you read the Harness pieces and found yourself asking what does this mean for the way I run a team, you are reading the right book next.
If you didn’t read them, you don’t need to. The argument stands on its own. But it stands more clearly if you saw the migration first.
The harness was the precondition. The cell is the application. The Builder-PM is the role inside it.
This manifesto is the compressed form of an argument I have been working on across the first half of 2026, in three editorial pieces and one consolidating book — The Builder-PM: How Product Management Is Being Rebuilt for the AI Era.
The work started by accident. In late 2024, while running many enterprise AI conversations, I kept hearing the same question phrased five different ways. Some version of: we are hiring product managers, we have always hired product managers, and the people we hire now seem to be working on a different job than the ones we hired three years ago — what is happening to the role?
The question came from CEOs, CPOs, VPs of Product, founders, and individual PMs trying to figure out their next move. The question was structural, but every answer offered for it at the time was tactical: better frameworks, new certifications, AI-PM bootcamps, prompt-engineering courses. None of the tactical answers addressed what was actually changing.
What was actually changing — once I started looking at the pattern — was the substrate. The operating environment underneath the role had shifted. Frontier model capability had begun doubling roughly every three months, while the integration of that capability into shipped products climbed in months rather than weeks.
The accumulating gap was the product overhang, and it rewarded a fundamentally different strategic posture than the one most product organizations were trained for.
Inside the companies pulling ahead — Anthropic, Cursor, Cognition, Replit, and a small number of others — a different unit shape had emerged: five-to-ten people, direct CEO reporting, broad decision rights, hybrid roles, communication overhead at roughly one-tenth of a comparably-staffed conventional product unit.
And inside that unit shape, a different role had emerged: framing strategic bets on capability ahead of public release, prototyping specifications directly with agentic tools, owning continuous validation loops in place of project cadence. Cat Wu named this role the Builder-PM in her March 2026 essay for Anthropic, and the name has stuck because it captures what the role actually does.
The three editorial pieces — the Anthropic Labs founder-cell analysis, the Product Overhang Doctrine, and the Anatomy of a Founder Cell — were my attempts to anatomize each layer of this shift in operating detail.
The book consolidated and extended them, adding two new chapters: one anatomizing the Builder-PM role itself, and one on the transition for individual PMs, PM leaders at incumbents, and founders hiring into AI-native cells.
The manifesto is what remained after I wrote the book and tried to compress the argument into a form that travels.
A manifesto, to do useful work, has to be different in genre from the book it sits next to. The book is a structural argument — patient, layered, cumulative. The manifesto is a declaration — short statements, each one quotable on its own, each one anchored by a brief mechanism.
The book persuades the reader who will invest ninety minutes. The manifesto reaches everyone the book’s readers want to send something to.
I wrote it for three readers in particular.
The first is the individual PM — typically with five to fifteen years in the conventional discipline — who can sense the substrate shifting underneath them but cannot yet name what is happening. The statements that follow are the names. If you find yourself nodding at the early ones and arguing with the later ones, the book is the longer working-out of each disagreement. If you find yourself nodding at all of them, you are probably further into the transition than you realize.
The second is the PM leader at an incumbent — VP of Product, CPO, Head of Product — who is responsible for an organization that is increasingly the wrong shape for the work that is now possible to do. The statements about the operating environment, the Envelope Problem, and the political precondition for the carved-cell pilot are written specifically for the conversation you are about to have with your CEO. They are designed to be quoted from.
The third is the founder or CEO — particularly at AI-native startups, but also at incumbents pursuing AI-native bets — who is making decisions about hiring, organizational design, and strategic frame at a moment when conventional product organization advice will produce predictable underperformance. The statements about hiring, screening signals, and patience in cell construction are written for you.
Each numbered statement is a claim. Each paragraph beneath it is the mechanism — short, but enough to anchor the claim in evidence and reasoning rather than slogan. Read straight through, the fifty-two statements walk the entire structural argument of the book in compressed form. Read selectively, any single statement stands on its own as a small argument with its own internal logic.
A note on what this manifesto is not. It is not a methodology. It is not a certification curriculum. It is not a framework to be adopted in twelve weeks. It is a statement of position on a discipline that is being rewritten in real time, and the rewriting is happening whether or not the manifesto exists. My contribution is to name the rewriting in terms that are precise enough to be acted on.
The fifty-two statements that follow are organized in nine sections — the role, the strategic frame, the operating environment, the activities, what stays human, the transition, the incumbents, the founders, and what does not change. The order matters. The argument is cumulative even in compressed form. The final two statements — we are the people doing the rewriting — name the position from which the manifesto is written, and the position the manifesto invites its readers into.
What follows is the position.
The Builder-PM Book
This book consolidates and extends three editorial pieces published on businessengineer.ai in early 2026 — the Anthropic Labs founder-cell analysis, The Product Overhang Doctrine, and The Anatomy of a Founder Cell. The trilogy is reframed here around the role at the center of the AI-era product organization:
SECTION I
On the role
1. The title is the same. The job is not.
Or
On the fracture inside a single job description.
The same company posts a Senior Product Manager role in late 2024 and another in mid-2025 with almost no overlap in the actual responsibilities. The first lists roadmap ownership, spec writing, stakeholder coordination, quarterly business reviews. The second lists framing strategic bets on capability six-to-twelve months ahead of public release, prototyping specs directly with agentic tools, operating inside a small autonomous unit. The title is the same because HR systems and career ladders haven’t caught up. The job is not the same, and pretending otherwise misreads what is happening to the discipline.
2. We run specs, we don’t write them.
Or
On the collapse of the spec-to-prototype handoff into a single artifact.
With agentic tooling, the spec and the prototype collapse into the same object. A description handed to Claude Code becomes a working branch in the same session. The conventional PM cycle — write the spec, hand it off, wait for the build, review the implementation — has been compressed into a single working session that the Builder-PM owns end-to-end. The Jira ticket has been replaced by the commit, and that is not a cosmetic change.
3. No roadmap. A bet portfolio.
Or
On what replaces the conventional forward queue when there is no stakeholder layer to make visible to.
A roadmap is a forward queue maintained for stakeholder visibility — it exists because people outside the team need to see what’s coming. Pre-PMF work inside a founder cell has no stakeholders to make visible to. The roadmap document, with its quarters and themes and milestones, is replaced by two to four active bet briefs that the cell is currently working. The bets are not a future queue. They are the live state of the unit’s work.
4. No stakeholder reviews. Pre-PMF work isn’t stakeholder business.
Or
On why the review function dissolves when the unit shape no longer requires it.
Stakeholder review exists to absorb the consequences of building the wrong thing at scale — a 50-person product org cannot afford to ship a quarter’s work and discover after the fact that it was misaligned. Inside a five-to-ten-person cell shipping for capability that has not yet arrived, the review costs more than it protects against. The cell’s accountability is to the CEO sponsor and to the bet portfolio itself, not to a stakeholder layer it was specifically designed to escape.
5. We don’t translate. The functions have compressed.
Or
On what happens when the cost of crossing between engineering, design, and PM collapses.
The conventional PM role’s largest value-add was integration across disciplines: translating between engineering capabilities, design considerations, business priorities, and research findings. That translation work was expensive because the boundaries between disciplines were expensive to cross. Agentic tools collapse most of those costs. The integration is now done inside the work itself, by people who can move fluidly across disciplines because the tools make that movement cheap. The translator function has nothing to translate.
6. The role is its own discipline.
Or
On disambiguating Builder-PM from technical PM, founder-PM, and AI engineer with product duties.
The technical PM was a conventional PM with engineering literacy, operating inside conventional org structure on technical products. The founder-PM is a CEO operating in PM mode, drawing on their strategic authority to push product direction through. The AI engineer with product duties is execution-weighted and taste-light. The Builder-PM is none of these. It is a PM whose PM-ness is the primary qualification and whose technical fluency is built into the role as a non-negotiable supporting capability, supported by tooling that did not exist for the prior eras.
7. The substrate changed. Not the bar.
On why a more senior conventional PM is not a Builder-PM.
A more senior conventional PM does not become a Builder-PM by adding years. The role exists because the operating substrate — the org shape, the strategic frame, the tooling — has all shifted at once. Layering seniority onto the old substrate produces a senior conventional PM, not a Builder-PM. The transition is across, not up.
SECTION II
On the strategic frame
8. The gap is where we work.
On the product overhang as the only place an organization can structurally pull ahead.
Frontier model capability roughly doubled every three months across 2024–2026 by the METR long-horizon agentic benchmark — from ~21 minutes of human-equivalent task duration on Sonnet 3.5 to ~12 hours on Opus 4.6. Integration into deployed products takes months per release cycle. The accumulating gap between these two curves is the product overhang, and it is the only place an organization can structurally pull ahead. Everyone is competing in the integration band; almost no one is shipping for the overhang.
9. Bet on demonstrated capability, not wished or shipped.
On why the bet has to live in the gap between research demonstration and production deployment.
The bet has to live in the gap. Capability that doesn’t exist yet, even in research demonstrations, is speculative fiction — building for it is a bet on the lab’s roadmap, not on the curve. Capability that has already shipped into products is closed competitive ground — the overhang for that bet has been closed. Only the gap rewards an asymmetric bet, and the gap is narrow enough that the bet has to be specific about which capability, on which axis, at what horizon.
10. Build for the next model, not the current one.
On why optimizing tightly for today’s model produces obsolete work.
Anything built tightly against today’s model — its context limits, its tool-use quirks, its specific reasoning failures — is technical debt that gets settled on the next release. Building for the trajectory rather than the snapshot is the only durable posture. The product that ships into next quarter’s capability landscape, designed against today’s snapshot, has already aged out of relevance before it reaches users.
11. No named axis, no bet.
On axis selection as the Builder-PM’s first activity.
Capability does not climb monolithically. It climbs differently across reasoning depth, tool use, context length, multimodality, and agentic horizon. “AI is getting better” is not a bet — it is a weather report. “Long context will reach production reliability by Q3” is a bet, because it specifies which axis, what reliability threshold, and what horizon. The Builder-PM’s first activity is axis selection, and a brief that does not name its axis is a brief that has not done its first activity.
12. Scaffolding is decaying inventory.
On why the default posture on every model release is deletion, not preservation.
Every prompt-engineering trick that papers over a current model’s limitations, every retrieval system built to compensate for a context limit, every fine-tuned eval against a specific model’s quirks — all of it loses value the moment the underlying model improves. The default posture is deletion, not preservation. Hardening scaffolding into permanent infrastructure is the moment the unit stops treating the overhang as moving and starts treating its current integration position as a defensible product. The curve then moves past it.
13. Capability before cost.
On why the inference math closes itself and shelving correctly-framed bets is the most expensive form of risk aversion.
Shelving a correctly-framed bet because the inference math doesn’t pencil against today’s pricing is the most expensive form of risk aversion. Inference cost has fallen by roughly an order of magnitude per year across the frontier, and there is no structural reason to expect that to stop. The bet is on whether the capability will exist at production reliability; the cost curve closes the cost gap on its own. Optimizing for current pricing means missing the window every time.
14. Last quarter’s capability is the wrong question.
On the inverted strategic question that separates doctrinal from conventional product organizations.
The conventional question optimizes for what shipped — it asks how to integrate the most recent capability release into the existing product. The doctrinal question optimizes for what arrives — it asks what will be possible when the next release lands, and ships toward that horizon. Asking the second question is the strategic posture. Asking the first is the conventional one, and it produces conventional results.
15. The discomfort is the point.
On why the doctrine is a selector, not a prescription.
It requires placing bets without current product traction, absorbing months of pre-PMF work, deleting scaffolding the unit has already built, and hiring for axis-selection taste rather than for execution capacity. Most organizations cannot do these things. The doctrine selects for the small subset that can, and the small subset is increasingly the set of organizations pulling structurally ahead. The doctrine is not popular because it is hard. The hardness is what makes it valuable.
SECTION III
On the operating environment
