Engineers as product thinkers

The dominant frame for working across the PM-engineer line has PMs owning what and why, engineers owning how, and the EM at the seam between them. The advice built on that frame prescribes a transparent discussion at the seam, and it goes quiet on when an engineer is right to push past it. The common counter-piece runs a pilot-and-copilot analogy: while execution is in flight, the engineer asks questions but does not take the controls.

That frame is breaking, because AI is absorbing the middle layer on both sides: the code an engineer used to spend most of the day inside, and the spec-writing a PM used to spend most of the day inside. Engineers direct agents more than they write code, PMs use the same generation stack to validate a flow without an engineer in the loop, and both groups now operate a layer above the work that used to define them.

The lane between them mattered because crossing it was expensive: a PM could not check a technical hunch without borrowing an engineer, an engineer could not test a product hunch without borrowing a PM, so both stayed put and negotiated through the seam. Most of the historical friction presented as a fight over ownership, but underneath it was asymmetric understanding, each side guessing at work it had never done. Crossing is getting cheap now.

If you manage engineers in 2026, the job is to compress the lanes where one person can now run the work end to end, and to protect the lanes where specialist judgment still pays. The transition itself is the team's training program.

Name the shift

The first move is to stop talking as if the lanes still hold. Companies like Linear and Stripe popularized the "product engineer" a few years ago: an engineer who takes a problem from idea to shipped, talking to users directly without a PM in the middle. The next iteration is showing up across 2026 commentary under the label "Builder" (Razorpay is hiring for it explicitly), a role that does research, monetization, MVP, and shipping end to end.

Naming this matters because it tells your engineers what range they are accountable for, and it tells your PMs they no longer own the upstream alone. Engineers need enough product judgment to push back when the PM is wrong and to ship the right thing without a PM on every small call. Watch for the failure on the other side too: engineers reading the shift as a license to override the PM on strategy or customer calls. The archetype expands an engineer's range without erasing anyone's specialization.

Reshape the team

Default to small teams, two or three people, deliberately not balanced. The instinct to assemble one PM, one designer, one backend, one frontend, and one QA is a habit from the years when crossing the lane was expensive.

We ran a hackathon at work recently in exactly this shape: three-person teams, picked so that none of them had the usual one-of-each composition. Nobody asked who was supposed to do what. Everyone wrote survey questions and everyone shipped a prototype; engineers did customer outreach, PMs argued about which form field needed validation, and the designer wrote backend stubs. The output was rough, but for the first time the texture of what each role had been doing for years was visible to the others.

That closed more of the empathy gap than years of reading specs and sitting in standups had. PMs internalized what building well involves: the way a form needs validation and styling, the way a "small change" surfaces three architectural questions. Engineers internalized the go-to-market journey, the surveys, the persona work, the monetization thinking. Conversations that used to take a week settled in a meeting afterward.

There are two ways to get this wrong: forcing the shape onto a team with hard specialization needs, and shrinking the team without shrinking the scope. The second is the sneakier one, because the org chart looks leaner to everyone above it while the people left on the team absorb the difference, and the overload gets filed under Builder mode.

Replace the handoff

The artifact between the roles is changing too. A polished design file is no longer the only trigger for engineering to start, and a long PRD is no longer the only acceptable input. The current prototyping stack lets a PM or designer attach a working website to the brief, so engineering starts from a live prototype rather than from pixels. For smaller calls a handwritten sketch or a screenshot does the job.

None of this means skip design. Polish where it compounds (the design system, the brand surfaces) and skip it where it slows the loop; the artifact exists to transfer intent fast, and it does not need to be production-grade before anyone writes code.

The reverse failure is just as available: treating a working prototype as production-ready and skipping the engineering rigor, or applying the loose-artifact rule to surfaces where consistency matters.

Protect the specialists

Not every problem is Builder-shaped. Builder mode is good at the cycle where you build a v1, learn, and iterate fast, and bad at the one where you make one expensive call and live with it for years.

I have both shapes on my own teams right now. A 0-1 product we are building has heavy ongoing user research, and a senior PM is extracting strong insights from the data and building personas; that PM-driven loop runs faster than a Builder team could, because the work calls for depth of customer insight rather than breadth. The offline-first decision in MyBillBook sat at the other end: several architectural calls (caching layers on client and backend, syncing across multiple devices) with long feedback loops and no chance of a clean v1-and-iterate cycle. That one needed concentrated specialist judgment, and it would have made a terrible hackathon project.

Name out loud which work is Builder-shaped and which is specialist-shaped, and staff accordingly. When Builder enthusiasm swallows a problem that needed a deep PM or a deep architect, you ship a confident-looking v1 that has to be rebuilt six months later.

Train the transition

The "stay in your lane" stance has to be taken on directly here. The pilot-and-copilot piece is right that you should not grab the wheel mid-flight on an irreversible customer call, and wrong that the prescription is for engineers to stay back. The lanes are dissolving whether you train people through the transition or not, so refusing to train them buys you a worse team three quarters from now rather than a safer one.

The EM's job in this stretch is to design the practice and to fence off the places where failing is cheap. Put guardrails on the irreversible moves: do not let a Builder ship a one-way pricing change unsupervised, and do not let a PM commit a customer to an architecture nobody has validated. On everything else, teach the muscle. When an engineer makes a product call that turns out wrong, ask whether they had the context to make a better one. Whether they should have stayed in the engineering lane is the wrong question.

Penalize those first few errors and everyone learns that crossing the lane is personally expensive, so they stop crossing, the energy to learn drains out, and the old role boundaries lock back into place. The early mistakes are where the team is learning what the new shape of the work looks like.

The playbook here is for the transition. Some of the engineer-PM compression will hold and become the default, and some will reverse as we learn where breadth was the wrong call. I would not bet today on which pieces land in which pile.