Product Engineering: It Was Always One Job

Walk into almost any software company and you'll find the same wall. On one side, people who decide what to build. On the other, people who build it. Between them: tickets, specs, refinement meetings, estimation rituals, and a translation layer so thick we invented entire job families just to maintain it.

I've spent twenty-five years on both sides of that wall, and here's the thing nobody wants to say plainly: the wall was never a principle. It was a workaround. We split the job because building software was so expensive and so specialized that the person who understood the customer couldn't afford to also be the person who understood the code. The split was rational. It was also always a compromise, and everyone who's ever watched a great idea die in a handoff knows it.

AI just removed the reason for the compromise. Building got cheap. And when building gets cheap, the most expensive thing left in your delivery pipeline is the seam itself, the lossy, slow, accountability-diffusing handoff between the person who knows why and the person who knows how.

The discipline that emerges when you remove the seam needs a name, and it has one: product engineering. Not product management with a code editor. Not engineering with extra meetings. One person, or one small team, that owns the loop from customer problem to shipped outcome, with nothing handed off in between.

Why we split the job in the first place

It's worth being honest about the history, because the split made sense when we made it.

In a world where a feature cost a quarter of engineering time, a wrong bet was catastrophic. So you put a careful, customer-facing person in front of the engineers to pre-filter the work. In a world where engineering skill took a decade to build and was scarce on the market, you protected engineers from anything that wasn't engineering: no customer calls, no pricing conversations, no support tickets. Keep them building, because building was the bottleneck.

Every artifact of modern product development is downstream of that economics. The spec exists because the builder wasn't in the room when the problem was understood. The estimate exists because the decider couldn't judge the cost themselves. The backlog exists because demand for building always exceeded the supply of builders. The sprint demo exists because the people who asked for the thing had to wait weeks to see it.

Now run the numbers in 2026. A competent engineer with AI leverage ships in days what used to take a quarter. The cost of a wrong bet has collapsed alongside the cost of a right one, which means the elaborate pre-filtering apparatus is protecting an asset that's no longer scarce. Meanwhile the seam, the handoff, hasn't gotten one minute faster. Specs still take days to write and still lose the nuance. Refinement meetings still burn whole teams' afternoons. The question still travels from engineer to PM to customer and back over a week, when the build itself would have taken two.

What a product engineer actually is

Let me define the role precisely, because the title is already being diluted into "full-stack engineer who attends roadmap meetings."

A product engineer owns a customer problem end to end. They talk to the people who feel the problem, directly, not through a research summary. They decide what's worth building and how much it's worth, because they can judge both the value and the cost in the same head. They build it, with AI doing most of the typing. They ship it, watch the metrics, sit in on the support tickets, and decide whether it actually worked. Done doesn't mean merged. Done means the problem stopped happening.

Notice what's absent from that loop: a handoff. There's no moment where context gets serialized into a document, transmitted across a wall, and deserialized with loss on the other side. The person who heard the customer sigh is the person who ships the fix. That's the entire advantage, and it's enormous.

Notice also what the role is not. It's not a PM who learned to prompt. Product engineers carry real engineering judgment, they're accountable for the system staying coherent, secure, and operable, and AI doesn't grant that judgment, it amplifies it. And it's not an engineer who got handed a backlog column. Product engineers carry real product judgment: they say no, they kill their own features, they understand that owning a feature costs far more than building it. The role is demanding precisely because it refuses to let you hide in either half of the old split.

The skills are different from either parent

Product engineering isn't the union of two job descriptions. It selects for things neither parent role hired for:

• Problem fluency over solution fluency. The scarce skill isn't writing code or writing specs, it's holding a customer problem in your head at the right altitude and noticing when the thing you're building has quietly stopped solving it.
• Appetite judgment. Deciding how much an outcome is worth before deciding how to build it, and scoping the build to fit the worth rather than gold-plating to fit the ego.
• Taste under speed. When you can ship anything in days, the discipline isn't shipping, it's choosing. A product engineer's portfolio is judged by coherence, not throughput.
• Comfort with the whole consequence. No one to blame the requirements on, no one to blame the implementation on. You decided, you built, you own what happened next.

If that list sounds like what we used to expect from founders, that's not an accident. Product engineering is founder-mode made into an organizational discipline. Every early-stage founder already works this way, talks to a customer in the morning, ships the fix in the afternoon, and most companies spend their entire scaling journey engineering that loop out of the org, one specialized role at a time. The AI-era opportunity is to scale without severing the loop.

What it does to the org chart

I won't pretend this is a painless reshuffle. It isn't. Two roles feel it directly.

PMs bifurcate. The ones whose value was the translation layer itself, gathering requirements, grooming backlogs, running ceremonies, are translating between two sides that no longer need an interpreter. The ones whose value is editorial judgment move up: fewer of them, covering more surface, acting as the keepers of product coherence across many fast-moving product engineers. I've written about that inversion before; the short version is that the PM becomes the editor, and the product engineers become the writers.

Engineers face the more uncomfortable question, because the comfortable version of the engineering job, take a well-specified ticket, implement it well, hand it back, is exactly the part AI absorbed first. The engineers who thrive are the ones who move toward the customer, not away. That transition is real work. Most engineers were actively trained out of product judgment, told for years that the requirements were someone else's job. You don't undo that with a memo. You undo it by handing people small, real outcomes, an appetite, and the safety to miss.

Which is why this is an operating-model change, not a re-titling exercise. Teams get smaller, two or three product engineers instead of eight specialists in a relay. Cycles get shorter. The unit of work stops being the feature and becomes the outcome. And the management layer stops assigning tasks and starts shaping problems and betting on them.

How to start without blowing anything up

If you run a product or engineering org and this resonates, don't announce a reorg. Run an experiment.

Pick one real customer problem, small enough to be safe, real enough to matter. Pick one engineer with latent product instincts, you already know who they are, they're the one who keeps asking why in refinement. Give them the problem, not a spec. Give them direct access to the customers who feel it. Give them an appetite, say, two weeks, and explicitly take estimation, tickets, and the ceremony layer off their plate for the duration. Then judge the result by one question: did the problem stop happening?

Run that three or four times and you'll learn more about whether product engineering works in your organization than any framework comparison will tell you. You'll also learn who your product engineers actually are, and it will not perfectly match your current seniority chart. Expect that, and treat it as information rather than a problem.

The companies that get this right won't be the ones with the best AI tooling. Tooling is available to everyone. They'll be the ones that noticed the wall was a workaround, took it down deliberately, and rebuilt their teams around the loop instead of the seam. That rebuild, the roles, the bets, the culture that makes owning an outcome safe, is the core of an AI-native transformation, and it's the work I do.

If you're somewhere in the middle of taking the wall down, or deciding whether to, I'd genuinely like to compare notes. Let's talk →