The Business Engineer in the Era of AI
Book length article: "The Builder-PM Manifesto". 📚 🎓If you build with AI, you might want to look at this.
Good Morning,
AI Supremacy Newsletter is also committed to getting a variety of some of the top voices around AI, technology and business. I’ve admired the work of Gennaro Cuofano for a while now and I’m glad to host a special inside look at the future of Product Management in the era of Generative AI.
The Business Engineer
Explore the insights and frameworks developed from a decade of research.
Gennaro Cuofano is the creator of Business Engineer and founder of FourWeekMBA. A technology executive by day and business engineer by night, he works at the intersection of technology, business strategy, and innovation.
The Business Engineer is a publication that does what I would call “radical non-linear analysis”, a system that results from the author researching companies and blogging since 2015. As you might know I also appreciate deep thinking bloggers who create incredible infographics, frameworks and new ways of thinking of business transformation. This visual component really adds another layer of understanding. So his work is going on 11 years at this. He’s arrived at a deep understanding of his topics and who he is providing value for.
Gennaro Cuofano looks at business analysis like an engineer, and he’s also the creator of AgentOS. It’s hard to summarize his unique synthesis of tech & business, but one way to think of it is that he “forces digital operators to think like financial analysts, and corporate executives to think like systems engineers”, thus making him a critical and pragmatic guide for navigating the architecture of the AI economy.
The Opportunity of AI (how will you be involved?)
Thus he has a lot of frameworks, tutorials and ideas on how the role of Product Management is evolving in the era of AI and AI agents. Product management is essentially being rebuilt in the AI era, and as a side note I’ve noticed many Product management publications I used to read on substack now read more like AI publications (this isn’t by accident). Roles in technology companies are being fundamentally redesigned and it’s leading to a convergence in the future of business. New kinds of builders and entrepreneurs are arriving taking advantage of this unique window.
With the evolution of Claude Code, Cursor and tools like Loveable and Codex, the AI builder doesn’t need to be a technical engineer in 2026. How we think of engineering and product iteration in the era of AI is going to vastly expand economic opportunity in the decade ahead. Read that over again slowly, and think about how you want to participate?
As a reader of dozens of AI and business publications myself, I’m also just a fan of how Gennaro thinks.
Let me introduce you to some of his standout work recently:
Business Engineering Book, Workshop + CustomGPT [Available To Yearly Premium Members]
The Subsidized AGI Economy (June, 2026)
How SpaceX Is Rewriting the Map of AI (May, 2026)
I believe his audience are potentially for example professionals like product managers, business executives, startup founders, business model strategists, growth hackers, investors in technology who like frameworks, and enterprise digital transformation leaders on the chief of innovation analysis spectrum. Browse his articles in full here. He’s also recently launched a second Newsletter called the AI Supercycle.
“Gennaro forces digital operators to think like financial analysts, and corporate executives to think like systems engineers. Now he distills the emerging new role of Builder-PM that’s AI-native.”
The Builder-PM Manifesto
THE BUILDER-PM MANIFESTO
What we believe about the role now — and why
A companion to The Builder-PM: How Product Management Is Being Rebuilt for the AI Era
Eds: This manifesto is approx. 6,000 words or 33 pages.
Premise
How this manifesto came to exist
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, from CPOs, from VPs of Product, from founders, from individual PMs trying to figure out their next move. The question was structural, but every answer being 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 was left after I had written 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.
SECTION I
On the role
1. The title is the same. The job is not.
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.
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.
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.
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.
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.
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
16. The cell is not a fad. It’s a recurring pattern.
On the structural signature that appears across Skunk Works, AWS, Stripe API, Instagram, and Anthropic Labs.
The same structural signature — small, dense, direct-reporting, hybrid roles, broad decision rights — appears across Skunk Works at Lockheed (1940s), the original AWS team at Amazon (2003), Stripe’s API team (2010), the Instagram team inside Meta (2012–2016), and Anthropic Labs (2024 onward). Different domains, different eras, same shape. The pattern is older than the AI exponential and recurs wherever 0-to-1 building has happened at speed. AI accelerates the shift toward it; it doesn’t invent it.
17. Five to ten people. Structural, not preferential.
On why the headcount window is grounded in combinatorics, not aesthetics.
Below five, the cell cannot cover the skill surface required to ship a full product end-to-end — even with role compression, there are minimum competencies that two people cannot span. Above ten, communication overhead overwhelms the output gain from adding people, because the number of pairwise edges in a team of N grows as N(N−1)/2. The window is structural, not preferential. Anthropic Labs started at five and has remained inside the 5–10 window through multiple product launches. The principle holds across the historical cases.
18. Direct to CEO. Structural insulation, not status.
On why the reporting line is the only thing that prevents scaled-org metrics from killing pre-PMF work.
A unit operating under the Overhang Doctrine ships pre-PMF for months. Its KPIs are not adoption, not revenue contribution, not feature cadence. If it sits inside the scaled product org’s review cycle, those KPIs will be applied to it, it will fail them, and it will be cut before the bet validates. The direct line is what prevents the scaled org’s metrics from killing the unit. It is structural insulation, not status.
19. Decide unilaterally. Escalate only on bindings.
On the unusually permissive decision rights envelope and what it excludes.
Stakeholder-driven prioritization is the binding constraint conventional PMs operate inside — every major decision routes through reviews, frameworks, and alignment meetings. The cell operates without that constraint. The decision happens in the next conversation between the cell lead and the relevant builder, not in the next cycle. Escalation is reserved for headcount changes, public commitments, and strategic direction that contradicts the company’s published thesis — and only those.
20. The negative space is the feature.
On why the cell is defined by what it deliberately leaves out as much as by what it contains.
The cell is defined as much by what it deliberately leaves out as by what it contains. A senior PM tower would re-create the layered hierarchy the cell exists to escape. A QA handoff would slow the quality signal past the point where it can inform the next bet. A project manager would add a communication edge without adding a unit of output. Each absent function removes a communication edge, a handoff, or a metric. The aggregate effect: the cell operates at roughly one-tenth the coordination overhead of a comparably-staffed conventional unit.
21. Communication grows N². Output doesn’t.
On the mathematical reason the headcount window is hard.
This is the mathematical reason the headcount window is hard. It is not a cultural preference, not a stylistic choice, not an aesthetic about small teams. It is combinatorics. Adding people past the threshold produces additional communication cost faster than additional output. Brooks formulated this for software projects in 1975, and the principle generalizes to any unit whose binding constraint is coordination.
22. Decision velocity is combinatorial, not cultural.
On why a 50-person product org cannot match the cell’s velocity regardless of how good its culture is.
The cell can decide things in the next conversation because the next conversation can include everyone who needs to be in it. A 50-person product org cannot decide that way, regardless of how good its culture is — the meeting that includes everyone relevant is too large to be a conversation, the calendar coordination is too expensive, the stakes per decision are too high. The differential is geometric, and cultural interventions that try to close it without changing the geometry produce theater, not velocity.
23. Products graduate. Cells don’t scale.
On the mechanism that handles success without destroying the operating geometry.
Claude Code graduated from Anthropic Labs into its own org with dedicated engineering, design, marketing, and customer success. The cell did not grow to twenty people to absorb the graduated product — it stayed at five-to-ten and reformed around the next bet. Scaling the cell past its threshold destroys the operating geometry that made it work. Graduation, not scaling, is the mechanism that handles success.
24. The cell retains the right to disband.
On why the cell is an operating arrangement, not an organizational permanence.
When the bets have validated or invalidated, the cell may dissolve, redistribute its people across other parts of the company, and reform with different composition for the next opportunity. This is the opposite of the conventional pattern, in which teams calcify around their initial mandate and resist disbanding even when the original rationale has expired. The cell is built around a bet portfolio, not around a permanent identity. When the portfolio changes shape, the cell may too.
SECTION IV
On the activities
25. Three activities. Everything else is residual.
On Cat Wu’s reduction of the role to frame bets, prototype directly, own the loop — and why it holds.
Cat Wu’s reduction of the role to these three activities is correct and durable. Every other activity associated with the conventional PM job is either absorbed by tooling (spec writing, prototype management, status reporting), deleted as unnecessary inside the cell shape (stakeholder management, roadmap maintenance, cross-functional review), or downstream of the three core activities. The Builder-PM’s job description is three sentences long, and the discipline of staying inside those three sentences is much of what separates the role from its conventional predecessor.
26. Spec-to-prototype same day.
On the operational discipline that separates cell velocity from conventional cadence.
The spec-to-prototype same-day discipline is the most operational expression of the role. It is what separates the cell’s velocity from a scaled product org’s velocity. Specs that sit in document form for days or weeks are the early warning sign that the strategic frame has been replaced by the conventional one — the rest of the cell structure may still be in place, but the operating cadence has reverted, and the cadence is what produces the output.
27. The artifact is the working branch.
On the elimination of intermediate artifacts that exist only to be handed off.
The output of the work is the work. Intermediate artifacts that exist only to be handed to other functions are the residue of an org shape we have left behind. The Builder-PM does not produce documents that describe work to be done later; they produce work. The branch in the cell’s repo is the artifact, and the iteration on the branch is the iteration on the spec, because the two have collapsed into the same object.
28. Evals or intuition. Pick one.
On the evals harness as the role’s primary feedback instrument, not an optional deliverable.
The evals harness — structured evaluation of model behavior on the cell’s specific bet — is the Builder-PM’s primary feedback instrument. A Builder-PM without evals is making strategic claims about capability without the empirical instrument to test them. A Builder-PM with strong evals can detect, within the validation cycle, whether the bet is becoming more validated, more decayed, or invalidated. The evals are not optional, and they are not a deliverable for someone else — they are the role’s feedback loop.
29. The loop replaces the roadmap.
On the internally-generated structure that replaces externally-imposed rhythm.
The conventional PM’s continuity comes from the roadmap document and the stakeholder review cycle — externally imposed structure that gives the role rhythm. The Builder-PM has neither. The loop — re-audit on release, evals re-run, user reality check, bet portfolio review — is the internally generated structure that replaces them. The Builder-PM owns the loop in the way the conventional PM owned the roadmap, and the loop is what gives the role its rhythm.
30. Every model release triggers a full re-audit.
On the non-negotiable practice that keeps the cell tracking the curve rather than defending its scaffolding.
What just became possible. What is now cheaper. What is now reliable. What we shipped last cycle that is now obsolete. The re-audit is typically a one-day activity producing a written assessment that updates the bet portfolio, and it is non-negotiable — a cell that does not re-audit on release is a cell that has stopped tracking the curve and started defending its current scaffolding. The defense always loses.
SECTION V
On what stays human (for now)
31. Two activities absorb. One doesn’t.
On the trajectory of the role as tooling climbs the capability curve.
Two of the three activities are absorbing into the agentic stack on a fast curve — the implementation work is increasingly the agent’s; the loop instrumentation is increasingly automated. The third activity is not absorbing. As the curve climbs, the role concentrates around the activity that doesn’t automate, and the share of the role that is bet selection grows. This is the trajectory: a more taste-loaded, more bet-loaded role across the next several years, not a less skilled one.
32. Taste is the binding constraint. Frameworks are background.
On why conventional PM frameworks are not the wrong instrument — they are answering the wrong question.
The conventional PM frameworks — jobs-to-be-done, the four risks, growth loops, North Star metrics, RICE — were designed for an operating context where the question was how to build well. The question now is what to bet on against capability that does not yet exist. The first question is framework-tractable. The second is not. Frameworks remain useful as background knowledge; they are not the binding constraint on the role’s performance.
33. Bet selection is closer to investing than to PM.
On the venture-investor pattern recognition the role increasingly requires.
The relevant pattern recognition is closer to what venture investors do than to what conventional PMs do: recognizing the shape of a category-defining opportunity against a background of many opportunities that are technically real but strategically vapid. The Builder-PM is asked to make this judgment continuously, at speed, with imperfect information about the curve’s trajectory. Frameworks help structure the inputs to the judgment; they do not make the judgment.
34. Taste comes from shipping 0-to-1.
On why the pattern library cannot be acquired through conventional PM experience.
The Builder-PMs who are succeeding in 2026 are typically people who have crossed the 0-to-1 line at least once — built something pre-PMF, taken it through the moment where it either found product-market fit or did not. The crossing is what builds the pattern library: an internalized sense for what shipped products feel like at the moment they cross from interesting to important. No amount of conventional PM experience substitutes for it, because the conventional substrate never required that pattern.
35. This bet, not that one.
On the irreducible sentence the role is selected for.
That sentence — this bet, not that one; this axis, not the other; this horizon, not the alternative; these criteria, not the conventional ones — is the irreducible content of the role. Everything else is supported by tooling: the spec gets implemented by an agent, the evals get run by a harness, the loop gets instrumented by an orchestrator. The choice itself is the work that does not get supported, and it is therefore the work the role is selected for.
SECTION VI
On the transition
36. The role isn’t evolving. It’s forking.
On the most important distinction in the manifesto.
This is the most important distinction in the manifesto. Evolution implies the role is changing shape but staying continuous — that a conventional PM with effort can become a Builder-PM by acquiring new skills. Forking implies two distinct trajectories diverging from a common origin. The conventional fork is contracting as agentic tools absorb its activities. The Builder-PM fork is expanding as the doctrine and the cell pattern spread. These are two different jobs that share a name, moving in opposite directions, and the choice between them is structural.
37. Staying is a slow bet against the direction.
On why stability under current conditions requires moving.
The discipline is rebuilding. The substrate has changed. The frontier is climbing on a three-month doubling time. Hoping the role will evolve around you while you stay in place is the same bet as hoping a curve will plateau when its doubling time is three months — it might happen, but the base rate is poor and the cost of being wrong is the next decade of your career. Stability under these conditions requires moving, not staying.
38. Operating fluency. Daily. Real problems.
On the concrete, checkable bar that gates the transition.
The bar is not “I have used Claude Code in tutorials.” The bar is “I can take a spec from idea to working prototype in a single working session, reliably, without supervision.” That bar takes four to eight weeks of concentrated practice on real problems, not tutorial work. The transition to the Builder-PM role cannot happen without crossing this bar, and the bar is concrete enough to be checked in an hour by anyone hiring for the role.
39. One shipped prototype makes it concrete.
On the artifact that converts intention into evidence.
Before that moment, the transition is a stated intention — something the person says they are doing. After that moment, there is an artifact — something the person has done. The artifact is what hiring will look at; the intention is not. The artifact does not need to ship to external users; it needs to demonstrate that the three core activities have been run in a working cycle, with evidence about whether the bet held.
40. Artifacts shape careers now, not roles.
On what hiring will actually evaluate for the next several years.
For the next several years, the question in every Builder-PM hiring conversation will be: what have you shipped using this stack, against this kind of bet? The conventional CV signals — title progression, company prestige, framework fluency — do not answer that question. They were the signals that mattered inside the prior substrate. The new substrate is artifact-based, and the people building under it now will define the hiring patterns of the next half-decade.
SECTION VII
On the incumbents
41. You cannot hire your way into a cell.
On the most uncomfortable structural claim in the book.
This is the most uncomfortable structural claim in the book, and it is the one most incumbents resist. Hire ten AI-native Builder-PMs into a scaled product organization, and within a quarter they will have been absorbed into the existing PM hierarchy, assigned to existing roadmap slots, scored on existing KPIs, and constrained by existing decision rights envelopes. The conventional org has metabolic processes that convert any newly-hired role into a shape consistent with the surrounding structure. Within six months, the new Builder-PMs are doing the conventional PM job, because that is what the org pays them to do.
42. The envelope makes the cell. Not the people.
On the Envelope Problem as the dominant failure mode for incumbents.
The headcount window, the reporting line, the decision rights, the negative space, the freedom from quarterly KPIs — these are what produce the unit’s velocity. Without them, the same people produce conventional velocity. This is why the Envelope Problem is the dominant failure mode for incumbents attempting the cell pattern: they hire the people, skip the envelope, and produce a conventional unit with better titles.
43. CEO sponsorship is non-negotiable.
On the political precondition that cannot be worked around.
A carved cell without escalating sponsorship cannot survive stakeholder pressure, KPI scrutiny, or budget reallocation. The political move is non-negotiable. A VP of Product attempting to construct a cell inside the product organization, without going to the CEO or President for explicit sponsorship, will produce a structurally consistent unit that gets killed inside two quarters. The technical work is wasted if the political work isn’t done first.
44. First pilots fail. Plan for that.
On the management of political capital across the carved-cell pilot cycle.
The pilot may invalidate for honest reasons — wrong bet, wrong composition, wrong horizon. Or it may fail politically despite being correctly framed. Either way, the result is informative, and the right move is typically to dissolve the cell cleanly, redistribute the people, and not retry within six to twelve months. Multiple consecutive failed pilots burn the political capital required to try the model at all, and burned political capital is much harder to rebuild than a failed pilot.
45. Organizational debt compounds silently.
On why the gap between conventional orgs and cell-pattern insurgents shows up too late to close.
The accumulation is invisible quarter to quarter. The conventional org continues to ship, hit its planning cycles, deliver against its roadmap. Nothing visible breaks. But the rate at which the org can integrate new capability falls relative to insurgents who built around the cell pattern, and the gap compounds across cycles. By the time the gap shows up in the financials — competitive losses, talent attrition, missed category transitions — it cannot be closed back. The cycle for closing it is longer than the cycle in which it opened.
SECTION VIII
On the founders
46. Hire for taste. Tech fluency second. Frameworks not at all.
On the screening signal hierarchy that produces the right cell composition.
Taste under pre-PMF uncertainty is the binding constraint and is developed primarily through the experience of shipping 0-to-1. Technical fluency is non-negotiable but checkable in an hour: show me your working environment, walk me through a recent prototype, tell me about your evals practice. Framework fluency is the negative signal — candidates who lead with JTBD, the four risks, growth loops, and OKR fluency are typically operating inside the conventional substrate and have not yet made the transition.
47. Patience beats speed in cell construction.
On why staffing fast on weak hires costs more than waiting for the right composition.
Cells that staff faster on weaker hires produce structurally consistent units that underperform their potential and require subsequent rebuilds. The right move is to spend six to nine months hiring the right cell composition rather than six weeks staffing with the available one. The cost of waiting is real and visible. The cost of staffing weak is invisible until the third cycle, when it shows up as work that should have shipped and didn’t.
48. Hire the role you cannot absorb.
On what survives when a technically-fluent founder can do most of the conventional PM job themselves.
The conventional PM role is increasingly absorbable by a technically-fluent founder using Claude Code or Cursor. The Builder-PM is not — because bet selection at scale, across multiple cycles, against a moving frontier, exceeds what one person can hold alone alongside running the company. That is the role the cell needs and the role the founder cannot replicate themselves. Founders who try to do everything end up doing the conventional PM job at half attention; founders who hire Builder-PMs delegate the activity they cannot scale.
SECTION IX
On what does not change
49. Tools change. The discipline doesn’t.
On what to expect when the specific tool stack named here ages out.
Claude Code will yield to a successor. Cursor’s competitive position will shift. The agentic orchestrators of 2027 will look meaningfully different from those of 2026. The specific tool stack named throughout this manifesto will age out within two years. But the discipline beneath the tools — frame bets that are calibrated against the curve, prototype directly with whatever has the lowest spec-to-code cost, run loops continuously rather than projects discretely, cultivate taste as the binding constraint — will not move.
50. Four claims hold up everything else.
On the load-bearing structure beneath the entire argument.
The capability curve will keep moving faster than the integration curve. The overhang will continue to exist as a strategic feature, not a transient gap. The cell will continue to be the unit shape that can execute against it. The role inside the cell will continue to be compressed, taste-driven, and execution-fluent. Those four statements are the durable load-bearing claims of the entire argument. Everything else in this manifesto — every specific bet structure, every named role, every operating practice, every transition path — descends from them. If the four hold, the rest holds. If any of the four fail, the rest needs reconstruction.
51. The discipline isn’t dying. It’s being rewritten.
On the misreading that mistakes the forking for an ending.
Conventional product management is contracting. The Builder-PM discipline is expanding. The total work being done under the name “product management” is at least as large as it was five years ago — possibly larger. The discipline as a whole is in motion, not in decline. The decline narrative misreads the forking for an ending.
52. We are the people doing the rewriting.
On the position the manifesto is written from and invites its readers into.
That is the position. The rest is execution. The book is a structural account of the rewriting. The manifesto is a declaration of intent. The work is what makes both real.
The Builder-PM Manifesto
Gennaro Cuofano
The Business Engineer
businessengineer.ai
2026
 | A guest post by
|