The Product Engineer
You're living in the dissolved handoff. You hold the product "why" and the systems "how" in the same head. The old division of labor between PM and engineer doesn't describe your job, and the role that's forming around this convergence is where the most durable work is moving.
A role that didn't exist when the handoff was clean
The old engineering game had clear lanes. PMs wrote specs. Engineers built them. The handoff was the boundary. Quality lived in how faithfully the engineer translated what the PM wanted.
That division dissolved. AI tools let PMs ship prototypes. AI agents handle the spec-to-code pipeline. The boundary between "what to build" and "how to build it" is no longer a clean line separating two jobs. It's a space, and you're already working in it.
Online searches for product engineers have grown 89% since 2021. Companies like PostHog, incident.io, and Ghost prioritize engineers who talk to users directly and are comfortable working autonomously. This isn't a temporary hiring trend. It's the organizational structure catching up to the reality that the best work happens when one person holds both halves.
You're ahead of the curve. The question isn't whether you're in the right role. It's whether you can keep both halves sharp enough that neither one goes shallow.
What both halves actually mean
The product half isn't just "talking to users." It's understanding why the PM made their last three decisions. The user research that changed a feature's scope. The business constraint that made a simpler approach impossible. The tradeoff the company accepted between speed and correctness. When you hold this context, you don't build what someone tells you to build. You build what the situation actually requires.
The systems half isn't just "writing good code." It's architecture that survives the growth the prototype has never seen. It's production intuition built from watching systems break in embarrassing ways. It's the second mind that catches what the solo builder can't see. When you hold this depth, the demo that "works" doesn't satisfy you. You ask the questions nobody assigned you to ask.
The combination is powerful because each half makes the other more valuable. Product context without systems depth produces features that work in the demo and break in production. Systems depth without product context produces technically sound solutions to the wrong problems. Holding both means you close the gap between "working prototype" and "surviving system" without the overhead of a handoff.
The specific risk at this altitude
The squeeze from below and the squeeze from the side don't threaten the product engineer directly. You've moved above both. But there's a risk that's unique to your position: spread.
Holding both halves means maintaining two different kinds of expertise. Product sense requires regular contact with users, with business context, with the "why" behind decisions. Systems depth requires regular contact with production systems, with failure modes, with architectural consequences that surface over time. Both demand ongoing investment. Neither stays sharp on autopilot.
The failure mode looks like this: you lean into the product half because it's higher-leverage and more visible. The systems depth quietly erodes. You stop reviewing code as carefully. Your architectural decisions rely on patterns from two years ago. You accept AI-generated code without finding the structural flaw first. Then a production incident reveals the gap, and you realize the systems half went shallow while you weren't looking.
The reverse happens too. You lean into the systems half because it's your comfort zone. The product sense narrows. You start building what feels technically right instead of what users actually need. The PM brings a prototype that's closer to correct than your solution because they talked to users last week and you didn't.
How to keep both halves sharp
Stress-test prototypes with real conditions. Take a working demo and throw a network partition, a partial failure, a retry storm at it. This exercise keeps the systems half active while the product half stays current through the context of what was being built and why.
Own one feature from user problem through production. Understand why the user needs it. Build it. Deploy it. Watch it survive real traffic. The full arc from user intent to production behavior is the product engineer role in practice. Do this regularly, not as a special project.
Follow your own decisions three steps downstream. Pick a recent architectural choice. What does it enable? What does it quietly prevent? What does it make expensive to change? The third step requires both product and systems thinking, which is exactly why it keeps both halves honest.
Reject AI-generated code before shipping it. Not always, but deliberately. Find the structural problem. The assumption the AI didn't question. The second-order consequence it can't model. This keeps the second-mind reflex alive. The moment you start accepting everything is the moment the systems half goes shallow.
Be willing to disagree with yourself. The biggest danger of holding both halves is that nobody pushes back on your full-stack decisions. You're the PM and the engineer. Who tells you you're wrong? Build a habit of adversarial self-review. For every decision, name the strongest argument against it. If you can't, you might be in a blind spot.
Where this role is going
The product engineer role isn't the end state. It's the current form of a larger shift. As AI handles more implementation and PMs handle more prototyping, the person who holds judgment across both domains becomes more valuable, not less. The question that will define the next phase of this role is: which half are you at risk of letting go shallow? Answer it now, before production answers it for you.