The New PM-Engineering Contract

Somewhere in tech right now, a PM is walking into sprint planning with a working prototype. Not a mockup. Not a Figma flow. A functional application backed by real data, built over a weekend using Claude Code.

The room goes quiet. Not because the prototype is bad. Because nobody knows what to do with it.

Engineering didn't build it. Engineering didn't spec it. Engineering didn't review it. And now it's sitting on the table, shaping the conversation about what the team builds next. The prototype is good. The silence is the problem.

The Old Contract

Every product team operates on an implicit agreement. It's rarely documented, but everyone knows it.

The PM defines the what and answers the why. The PM brings the market insight, shapes the strategy, and owns the prioritization. Engineering defines the how and builds it. Engineering brings the technical judgment, the architecture, the reliability, the craft.

This contract worked for decades because the build cycle was the bottleneck, and only engineers could address it. PMs could have the best insight in the world, but without engineering capacity, nothing shipped. That constraint kept the lanes clean. PMs needed engineers. Engineers needed PMs. The dependency was mutual and the roles were complementary.

Nobody signed this contract. Nobody needed to. It was enforced by the physics of how software got made.

What Broke

AI didn't rewrite the contract. It made one side of it optional.

A PM with Claude Code can now demonstrate the "what" in a form that looks remarkably like the "how." A working application. Real UI. Functional logic. It compresses the distance between "here's what I think we should build" and "here's the thing, running, that I think we should build."

This is not a tool upgrade. It is a power shift. And power shifts without explicit renegotiation create confusion, resentment, and organizational debt that compounds fast.

The PM prototype isn't an attempt to do engineering's job. It is a higher-fidelity way of communicating the what and the why. But when that distinction isn't explicit, when nobody renegotiates the contract, you get three predictable failure modes.

Three Antipatterns Will Emerge

The Cleanup Crew. Engineering gets handed a PM's prototype and is asked to "make it production-ready." The architecture decisions were already made. The UX patterns are already set. The technology choices are already locked in by someone who wasn't thinking about scale, security, or maintainability. Engineers become cleanup staff. The best ones leave. The rest disengage. This is the fastest way to destroy an engineering culture.

The Shadow Stack. PMs build and deploy things that engineering doesn't know about. Internal tools, customer-facing demos, sales enablement apps. They work fine until they don't. Nobody is monitoring them. Nobody owns the dependencies. When something breaks at 2 AM, engineering discovers code they've never seen. And it gets worse: a PM prototyping with a cloud-hosted AI agent may be sending proprietary data, customer information, or competitive strategy through systems that were never reviewed by security or compliance. A PM with Claude Code is, from an InfoSec perspective, a Shadow IT incident waiting to happen. This isn't just a maintenance problem. It's a trust problem and, increasingly, a regulatory one.

The Veto Reflex. Engineering, sensing the power shift, pushes back by rejecting all PM-built artifacts on principle. "That's not how we do things." "We can't inherit code we didn't write." "This isn't production quality." Every objection is technically valid. None of them address the actual question: how should we work together now? The Veto Reflex restores the old contract by force. It's stable but regressive.

The New Contract (In Explicit Terms)

The contract needs renegotiation, not abandonment. The PM still owns the why and the what. Engineering still owns the how at scale. What changed is the medium of communication between them.

Here's what the renegotiated terms look like in practice.

PM prototypes are disposable evidence, not draft production code. The prototype's job is to make the hypothesis tangible. To compress the conversation from "imagine if..." to "look at this." It is designed to be thrown away after the decision is made. If engineering inherits a PM prototype into production, something went wrong upstream.

The handoff point is a decision, not a file. In the Bet Register framework from earlier in this series, every bet has a resolution: kill it, iterate, or graduate to engineering. Graduation is the handoff. When a bet graduates, engineering starts from their own architecture, informed by the prototype but not constrained by it. The PM's job is to transfer the insight, not the code.

Engineering's role elevates, it doesn't shrink. In the old contract, a significant portion of engineering time went to building things that were essentially exploratory: features that might work, integrations that might matter, UX experiments that might resonate. That speculative build work now happens in the PM prototype layer. Engineering gets to focus on the work that actually requires engineering judgment: architecture, reliability, performance, security, system integrity. The parts AI-generated code fundamentally cannot reason about.

The boundary is explicit and revisited regularly. This is not a one-time negotiation. As PM prototyping capability grows, the boundary shifts. What counts as "disposable evidence" today might include more sophisticated artifacts tomorrow. The teams that handle this well will be the ones who talk about the contract openly, not the ones who pretend it hasn't changed.

Prototyping has guardrails, not just guidelines. The new contract must include terms that security and compliance can live with. That means defined sandboxes for PM prototyping: approved tools, local vs. cloud execution policies, clear rules on what data can and cannot flow through AI agents. I'm already seeing forward-thinking organizations stand up secured sandbox environments specifically for this purpose. It's the right instinct. If you want PMs to prototype, give them a sanctioned space to do it. The alternative is pretending it isn't happening while sensitive data leaks through personal API keys.

What Engineers Gain, and What Some Will Lose

I want to be direct about this because I've seen the conversation go sideways when it's framed as a PM empowerment story at engineering's expense.

The engineers I work with who have embraced this model are doing the best work of their careers. They spend less time on throwaway experiments and more time on system design. They're thinking about scaling patterns, not CRUD endpoints. They're reviewing PM prototypes the way a senior architect reviews a design brief: looking for the intent, flagging the assumptions, then building something right.

But let's not pretend this is universally good news. Many world-class engineers became world-class precisely because they love building. The craft of writing code, the satisfaction of a clean implementation, the flow state of making something work. Telling those engineers their new role is "system thinker and prototype reviewer" doesn't feel like an upgrade. It feels like being promoted to a job they never wanted.

This is a real tension, and it points to something bigger than a team-level renegotiation. We are not just rewriting the PM-Engineering contract. We are redefining what "Software Engineer" means. Some engineers will thrive as architects who set the boundaries and harden what the AI and PMs produce. Others will feel like they've been demoted to AI reviewers, auditing code they didn't write and don't feel ownership over.

The honest answer is that this shift will cause talent bifurcation. The engineers who find purpose in system-level thinking will see this as a liberation. The engineers who find purpose in the act of building will need a new answer to the question: where does my craft live now? Organizations that ignore this split, that pitch the new model as a universal upgrade, will lose people they can't afford to lose.

The Question Worth Asking Your Team

Most product teams have not had this conversation. They're living in the ambiguity between the old contract and the new one, running into antipatterns and treating them as individual incidents rather than a systemic shift.

So: what does the handoff look like on your team? Who decides when a prototype stops being an experiment and starts being a product? Is that decision explicit, or does it happen by drift?

If you haven't defined the boundary, someone is already crossing it. And the longer you wait to have the conversation, the harder the renegotiation becomes.

This article is part of my series, Product Management in the Agentic Era. You can find all previous installments on my profile.