The Product Manager Gets Bisected
Why AI Speed Demands Two Roles, Not One
Three product launches in the last 60 days tell the same story.
Runtime (YC P26), launched in May, gives every engineer on a team their own sandboxed coding agent. Twill.ai, from April, lets you delegate entire features to cloud agents and get back pull requests. Ferrix AI, from last week, is an “agentic product management platform” designed to automate the PM’s workflow itself.
These startups aren’t niche toys. They generate value and have legitimate propositions and business models. In fact, Runtime scored 103 points on Hacker News. Twill.ai hit 77.
Note that these scores show “real developer interest,” though imperfect. Hacker News skews toward certain demographics, it’s easy to game with social media linking.
The pattern is clear: coding agents are no longer reserved for solo developers. They’re being deployed to entire teams.
Unfortunately, the cold truth most product leaders haven’t confronted yet is that our engineers just got 2-5x faster — and us, the product managers, are now the bottleneck.
Andrew Ng said it best at Y Combinator Startup School last year:
“While engineers are becoming much faster, I don’t see product management work — designing what to build — becoming faster at the same speed as engineers. I’m seeing the ratio shift.”
One of his teams proposed a ratio of 1 PM to 0.5 engineers. Not 1:4. 1:0.5. Half an engineer per product manager. Let that sink in.
The Old Model Is Breaking
For the last two decades, the product development assembly line worked like this:
PM writes a PRD
Engineers estimate it
Backlog gets prioritised
Engineers sprint for two weeks
PM reviews and course-corrects
That cadence was built for a world where coding was the slowest part of the cycle. That world is over.
In 2026, engineers equipped with Claude Code, Cursor, and purpose-built coding agents can ship working features in hours, not days. Tools like Modulus coordinate multiple agents across repositories with shared context. Capacitor shares memory between Claude Code and Cursor sessions. The question “how long will this take to build” no longer has the same answer it did six months ago.
But the PM workflow hasn’t accelerated. Research, stakeholder alignment, spec writing, prioritisation — these still move at the speed of meetings, document reviews, and human decision-making.
The result is a growing tension: Engineers are idle, waiting for specs, making teams frustrated. Organisations are now pushing back by embedding a product-minded engineer directly into customer/product teams rather than waiting for PM to finish discovery.
This person:
Works alongside customers in real-time
Understands the problem context (not just a spec)
Can design and code simultaneously
This signals that traditional PM gatekeeping is breaking down.
The Bisect: Fast App, Slow Platform
Drew Breunig wrote one of the clearest analyses of this shift last year, in August 2025. His thesis: product management won’t disappear, but it will bisect into two distinct roles.
The Application Product Manager works embedded with engineers and customers. They code — at least enough to prototype. They write tight specs that agents can execute on directly. Their cycle time is measured in hours, not weeks. This is product management blended with consulting and customer success. It’s the person who can sit with a client at 9am and have a working demo by 3pm.
The Foundation Product Manager owns the platform. They design APIs, data structures, and core business logic. They handle compliance, security, QA standards, and productising the innovations the App PMs throw over the wall. Their cycle time is slower by design — because platform stability demands it.
“Instead of going away, the function of product management will get bisected into two domains... This set up attempts to preserve the speed of AI-assisted development, the need for traditional product management functions, and any need to teach customers how to use your product.”
— Drew Breunig, “Bottleneck or Bisect”
I’ve seen versions of this split play out before. At organisations like Moonfare and Tier, the tension between platform stability and customer-facing speed was the central organisational challenge. What’s different now is that AI has compressed the speed differential from a factor of 2x to a factor of 5x or more. The split isn’t a nice-to-have — it’s becoming structural necessity.
What This Means for Your Backlog
The bisect has direct implications for how you manage your backlog.
For Application PMs, the backlog becomes conversational. You’re not writing detailed user stories with acceptance criteria into Jira. You’re writing a tight spec document — or even a prompt — and the agent executes. The feedback loop is minutes, not two weeks. Your backlog is less a queue of tasks and more a stream of experiments.
For Foundation PMs, the backlog becomes the contract between speed and stability. Every item is a question: is this platform improvement, or is this something an App PM can prototype and we’ll productise later? The foundation backlog filters and formalises. It’s the gate that prevents the fast-moving App teams from creating architectural debt.
However, there are some tactics you can still apply:
Start tagging backlog items by velocity tier. Label things “app” (fast, experimental, customer-facing) or “platform” (slow, stable, infrastructure). Sort differently depending on the tier.
Accept that App PM specs must be agent-executable. If an engineer can hand your spec to Claude Code and get a working PR back, you’ve written it at the right level of detail. If they’re asking clarifying questions, you haven’t.
Create an explicit “agent hygiene” backlog column. The Daemons team — who pivoted from building agents to cleaning up after them — know this well. AI-generated code introduces unique debt: hallucinated imports, redundant implementations, tests that pass but test nothing. Someone needs to own that triage. In the bisected model, it’s Foundation PM territory.
What about the Product Leader?
A Product Leader doesn’t define their day by story points, Jira tickets, or sprint ceremonies. If that’s your identity, you’re a Product Owner — and as you quoted Marty Cagan, POs are “sitting ducks” for AI.
It’s about three things:
Strategic conviction — Seeing around corners. Knowing what to say no to. Your piece on big bets and the commitment equation makes this clear: leaders build conviction through discovery loops, not by filling a roadmap with requests.
Enabling conditions, not controlling outputs — The AI at the Core post nails this: “Replace fear with curiosity”, “build learning loops not moonshots”, “lead by example.” You don’t manage people; you create an environment where they can do their best work. Your maturity model may frame this as moving from “ad hoc” to “integrated” — and the leader’s job is to accelerate that progression.
Critical thinking over process execution — Your strongest posts make the same point differently each time: process gets automated, but why we build something, whether it matters, who it serves — that’s the leader’s domain.
Focus on these three levers, and you’ll be miles ahead of the average, traditional, product leader.
The Hardest Question
The hardest question isn’t whether the split will happen. The launches from Runtime, Twill, and Ferrix suggest it’s already happening — the market is building tools for both sides.
The hardest question is: which side of the bisect are you on?
If you’re a PM who codes, or is willing to learn, the Application path is wide open. You’ll be embedded, fast, and deeply connected to customer outcomes. You’ll write tighter specs than ever — because agents will execute on them.
If you’re a PM who thrives on depth, platform design, and long-term architecture, the Foundation path offers more influence than ever. You’ll decide what gets productised, what gets standardised, and how fast the whole organisation can safely move.
But if you’re trying to do both — to be the sole PM for a team whose engineers are suddenly 5x faster — you’re going to burn out. The pace gap is too wide for one person to bridge.
The PM role isn’t dying. It’s splitting. And the sooner you decide which half you want to be, the sooner you’ll stop being the bottleneck.
The Harsh Truth
Here’s the uncomfortable truth I’m sitting with: The old PM role is becoming harder to defend.
If you’re one PM managing 8 engineers, and those engineers can now ship working features in hours because of AI, and you’re still writing 10-page PRDs and waiting for two-week sprints, you’re not managing—you’re slowing things down.
That’s not a critique of you. That’s a critique of the model.
The model is breaking because the inputs changed. Engineering got 5x faster. PM didn’t. You can’t run a 2026 engine with a 2006 transmission.
So the question isn’t whether you should bisect. The question is: What are you going to do about it?
And I’d love to know what you think.