Doug Seven

The existing definition describes the wrong direction.

If you Google “what is a product engineer” right now, the AI overview gives you this:

A technical professional who bridges the gap between engineering, product management, and user experience to design, develop, and refine products throughout their lifecycle.

That definition is accurate. It describes an engineer who learned to think about products, someone who can sit in a roadmap conversation and a code review on the same afternoon. Good role. Worth having on your team.

But it’s describing the wrong direction.

Something different is happening now, and the term hasn’t caught up yet. PMs who have never written a line of production code are building functional, testable software prototypes. Not because they learned to code. Because the skill they already had, describing what they want clearly, setting constraints, defining what done looks like, transfers directly to directing AI systems that can build it.

The existing definition describes an engineer moving toward product. The new definition runs the other way: a PM who can now build.

Not a job title. A capability.

Thanks for reading! Subscribe for free to
receive new posts and support my work.

The Line Is Moving

For most of PM history, the line between “defining what to build” and “building it” was the line between PM and engineering. You owned the what. They owned the how. Discovery lived in documents: PRDs, wireframes, user stories. Then you handed it over and waited.

That line is moving.

Not disappearing. Engineering isn’t going anywhere, and anyone who tells you a PM-built prototype is production-ready is setting you up for a painful conversation with your security team. But the gap between “I have a hypothesis” and “I have something testable” used to require an engineering sprint. Now it can require an afternoon.

That changes a lot.

What It Looks Like in Practice

Product Engineer capability exists on a spectrum.

At one end: a PM uses a design tool to produce a high-fidelity interactive mockup. Not a static wireframe. Something a user can click through, realistic enough to put in front of customers and get real behavioral signal. No design background required. No engineering time consumed.

In the middle: the PM uses an AI coding agent to build a functional prototype. A form that accepts real input. A dashboard that reads from an actual API. A flow with real branching logic. It behaves like software because it is software. Users don’t have to imagine how it would work. They can use it.

At the higher end: a more technically fluent PM builds a multi-surface working application, scoped tightly and not production-quality, but functional enough to run a real experiment. Behavioral data. Validated evidence before a single engineering sprint gets committed.

The ceiling keeps rising. What’s at the high end today will be the middle in two years.

It’s Not About Code

Here’s the thing that surprises people when they first hear this: none of it requires coding skill. It requires briefing skill.

A PM who can write a clear brief, context, user, constraints, definition of done, can direct an AI coding agent. That’s it. The same competency that makes a PM effective with engineers makes them effective with AI systems. The artifact changed. The underlying skill didn’t.

This is why “Product Engineer” is the right frame. It’s not a new hire profile. It’s a capability that develops in existing PMs, the ones who already know how to think in specifics, who already push back on vague requirements, who already know what “done” means before work starts. They’re not learning to code. They’re applying what they already know to a tool that can do more with a good brief than anyone’s had access to before.

What This Isn’t

A PM-built prototype is not production code. It is evidence for a decision. It answers “does this work the way we think it does?” before engineering time gets committed. Treating it as a starting point for production development is a mistake, technically and organizationally. You’ll inherit tech debt on something never meant to scale, and you’ll create a dynamic with your engineering team that takes a while to repair.

Product Engineer capability doesn’t replace engineering. It replaces the gap between hypothesis and testable artifact. Engineers are still responsible for scalability, security, reliability, and the hundred other dimensions of production software that prototypes are not designed to address.

What changes is what the PM brings to the engineering conversation. Not a document. Evidence.

A PM who shows up with a working prototype and three sessions of user feedback is making a fundamentally different case than a PM who shows up with a PRD. The prototype answers “should we build this?” The engineering team builds it properly. That has always been the division of labor. The Product Engineer capability just closes the gap between the question and the answer: faster, with better signal, and without burning engineering cycles on ideas that haven’t been tested yet.

How to Start

The PMs who get the most out of this aren’t the ones who learn to code. They’re the ones who already know how to think clearly enough to brief a system that can.

Start with a design tool. Get used to describing exactly what a screen needs to do, for whom, and how you’ll know if it worked. That practice, thinking in specifics rather than vague intent, is the same muscle that makes an AI coding agent useful. One sharpens the other.

Then scope a coding prototype. One surface. One user action. A form. A dashboard. Something small enough that the brief is achievable and specific enough that the output is testable. Expand from there.

The label matters less than the capability. Call it Product Engineer, call it PM-built prototyping, call it whatever lands in your organization. What matters is that the line between “I have an idea” and “I have evidence” just got a lot shorter.

PMs who close that gap faster will make better decisions, run better engineering conversations, and build better products.

The ones who don’t will keep writing PRDs about ideas no one has tested yet.