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. Most advice prescribes a transparent discussion at the seam without naming 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. 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. Both groups now operate a layer above the work that used to define them.

The lane between them mattered because crossing it was hard. It is getting cheap. Most of the historical PM-engineer friction came from asymmetric understanding, even when it presented as a fight over ownership.

If you manage engineers in 2026, the job is to compress the lanes where one person can now run the work end-to-end, while protecting 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 matters because it tells your engineers what range they are accountable for and 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 needing a PM on every small call. Watch for engineers reading the shift as a license to override PMs on strategy or customer calls. The Builder archetype expands range; it does not erase 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, one QA" is a habit from when crossing the lane was expensive.

A recent hackathon at work ran exactly this way. Three-person teams, deliberately picked so none had the usual one PM, one designer, one engineer per stack shape. Nobody asked who was supposed to do what. Everyone wrote survey questions and shipped a prototype. Engineers did customer outreach; PMs argued about which form field needed validation; the designer wrote backend stubs. The output was rough, but the texture of what each role had been doing for years was visible to the others for the first time.

That is what closes the empathy gap. PMs internalized the texture of building well: 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. Reading specs and sitting in standups had not done it. Conversations that used to take a week settled in a meeting afterward.

Two traps: forcing this shape onto a team with hard specialization needs, or shrinking the team without shrinking the scope. The latter overloads people and calls it Builder mode.

Replace the handoff

The artifact between roles is changing. 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, and engineering starts from a live prototype rather than from pixels. For smaller calls, a handwritten sketch or a screenshot is enough.

The rule is not "skip design." Polish where it compounds (the design system, the brand surfaces). Skip it where it slows the loop. The artifact's job is to transfer intent fast, not to be production-grade before code starts.

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

Protect the specialists

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

Two examples from my own teams. A 0-1 product we are building today has heavy ongoing user research; a senior PM is extracting strong insights from data and building personas. The PM-driven loop is faster than a Builder team could run it, because the work calls for deep customer insight rather than breadth. Separately, the offline-first decision in MyBillBook required 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. It needed concentrated specialist judgment.

Name out loud which work is Builder-shaped and which is specialist-shaped, and staff accordingly. When Builder enthusiasm swallows problems 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

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

The EM's job is part designer of training reps, part curator of safe failure zones. Put guardrails on the irreversible moves: do not let a Builder ship a one-way pricing change unsupervised, do not let a PM commit a customer to an architecture they have not 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.

Penalizing the first few errors kills the team's energy to learn and locks the old role boundaries back in place. Early mistakes are how the team learns the new shape of the work.

The playbook here is for the transition. Some of the engineer-PM compression will hold and become the default; some will reverse as we learn where breadth was the wrong call.