the handoff was the job

why everything in software is bending toward product engineering, and what that says about the work we've been doing all along

the technology companies have a new name for what their people actually do all day.

engineers who stopped writing most of their own code. product managers who stopped writing documents and started shipping. designers who noticed their sign-off had quietly become a bottleneck nobody asked for. all of them in the same loop, iterating, until something falls out that works.

they call it product engineering.

it isn't a role. it's what's left after ai dissolves the handoffs between the old ones.

the rename

vercel calls the mindset "code last": the product working comes first, the code is downstream of that. lee robinson, who ran product there before leaving for cursor last year, argues the point plainly, that in an ai-first era product engineering matters more, not less. linear is known for building almost its entire product this way, with small teams that talk to customers directly and own the roadmap, and little of the traditional pm layer in between. posthog practices a version of it and writes about it openly. atlassian documents it in its own playbooks. same move, different vocabulary.

the pattern underneath all of them is subtraction. you remove the seams between disciplines and the thing gets faster. so the interesting question isn't what a product engineer is. it's why the seams were there in the first place.

the handoff was the job

here's the uncomfortable part.

the artifacts we built careers on, the prd, the grooming ceremony, story points, the design sign-off, the beautifully formatted spec, were never the work. they were coordination overhead. handoff infrastructure for a world where moving an idea from one head to another was expensive and slow.

marty cagan, in inspired, told us to build teams of "missionaries, not mercenaries." teresa torres gave us the product trio and continuous discovery. both were right, for a world where product, design, and engineering were genuinely separate crafts that had to be stitched together. the trio was a bridge over a seam. good bridge. real seam.

ai collapses the cost of the crossing. when one person, or one person plus a model, can hold the problem, the design, and the implementation in a single continuous motion, the bridge becomes a toll booth. you're paying to cross a gap that isn't there anymore.

so the flow reverses. you don't write the ticket and then build. you build. you feed the problem to two frontier models arguing with each other, you iterate until it's real, and then the ticket writes itself, backwards, as a record of what got done. the artifact stops being an instruction and becomes a receipt.

the context is the deliverable

andrej karpathy said it in 2023 and it aged into a law: "the hottest new programming language is english." his software 3.0 framing is now just the water we swim in. you program the model in natural language, prompts are programs, and the distance from idea to running code is measured in minutes.

which means the scarce skill isn't coding.

the last world cup, chatgpt was weeks old and couldn't write a function. the one that just wrapped, the same tooling built an entire sdk over a weekend with the tournament on in the background. by 2030 the thing worth being good at isn't writing the code. the model does that, out of the conversation. it's describing a business problem and its solution precisely enough to build from. the solution falls out of the interaction. the problem is the part you own.

so the deliverable was never the powerpoint. it's the context. and the best container for context is a repo, not a word document: the conversation, the data, the decisions, versioned and shippable, handed to whoever builds next as a link they paste and go. everything portable. nothing formatted to be admired.

say, do

one caveat to the "talk to customers" gospel, because it's the exact spot where teams fool themselves.

asking a customer what they want is close to worthless. rob fitzpatrick wrote a whole book, the mom test, on the fact that everyone lies to you, kindly: "opinions are useless," and anything about the future is wishful thinking. nielsen norman group has said it for thirty years in blunter terms: "pay attention to what users do, not what they say." self-reported claims are shaky, and people usually can't tell you what they actually want. the moment you describe your idea, you've contaminated the answer. this is confirmation bias with a smile. you go fishing for validation and a polite human hands it to you.

so the signal was never the opinion. it's the behavior. what they actually did, last time, with something at stake. usage data is just the highest-fidelity recording of that behavior, collected while nobody's performing for you. it's revealed preference instead of stated preference, and it's why piping real usage and real client calls into the loop beats another round of stakeholder interviews.

but don't swing so far you start worshipping the dashboard. usage data carries its own two knives.

goodhart's law: "when a measure becomes a target, it ceases to be a good measure." aim a team at a number and they'll move the number, not the thing it was standing in for. the soviet nail factory hit its target by the ton and shipped nails nobody could use.
survivorship bias: your analytics only contains the people still using the product. abraham wald worked this out armoring bombers in the war. the command wanted to reinforce where returning planes were riddled with holes; wald saw those were the survivable hits, and the planes shot through the engine simply never came back to be counted. the churned, the bounced, the never-signed-up are your missing planes. optimize only on who stayed and you build a sharper and sharper product for a shrinking room.

usage data also tells you what happened, never why, and there's no usage data for a thing you haven't built yet. so the move isn't analytics instead of talking. it's behavior instead of opinion, drawn from both: instrument everything, read what people actually did, and when you do talk to them, ask about their life, not your idea.

a graeber problem

this is where it stops being a tooling story.

david graeber, in bullshit jobs, defined the thing as work "so pointless that even the person doing the job secretly believes that it shouldn't exist." he wasn't talking about us (actually he was). but sit through enough ceremonies and the resemblance gets loud. a lot of what we do, the meetings that produce documents that produce meetings, generates nothing unless it produces something. we are the friction. we built entire careers being excellent at the friction.

and that's the trap. people are genuinely good at it. good at writing tickets. good at grooming a backlog. good at a clean prd. none of it matters the way it did, everyone can feel that it doesn't, and the response to the feeling is fear, and the response to fear is more process. more documents. a design function that mistakes its own step in the chain for independence, and defends the seam, because the seam is the job.

conway's law says your systems come out shaped like your org chart. product engineering is conway's law run backwards: collapse the org chart and the architecture simplifies with it. you stop needing seven people to ship what two can. fred brooks told us in the mythical man-month that adding people to a late project makes it later. the whole industry is finally in a position to act on that, and mostly it's flinching.

what to do tomorrow

the divide isn't ai versus people. it's people who use ai versus people who don't. a developer who won't is already irrelevant. a product person who won't understand this is next.

so the move is not better documents. it's teaching people to think differently:

reward whoever builds the prototype, not whoever writes the prettiest spec
put a terminal in front of your product managers and let them run research on the live site while they're on the call
treat every client conversation as a data source and pipe it somewhere a model can read, then let the corpus tell you what to build
stop asking permission. for this, the downside of asking forgiveness instead is roughly nothing

product engineering isn't a title to hire for. it's what happens when you stop paying the toll. the disciplines don't vanish. the craft of a real product thinker, a real engineer, matters more than ever. what vanishes is the space between them: the handoff, the ceremony, the friction we mistook for the work.

all of it only stands if you ship.

sources

vercel's "code last" philosophy, articulated by lee robinson (then vercel's product lead, now at cursor)
posthog and linear on customer-facing product-engineering teams that run with little traditional pm structure
marty cagan, inspired, 2nd ed. (2017), "missionaries, not mercenaries"
teresa torres, continuous discovery habits (2021), the product trio and continuous discovery
andrej karpathy, "the hottest new programming language is english" (tweet, 2023) and the software 3.0 keynote (yc ai startup school, june 2025)
rob fitzpatrick, the mom test (2013)
jakob nielsen and the nielsen norman group, "first rule of usability? don't listen to users"
goodhart's law (charles goodhart, 1975; marilyn strathern, 1997)
abraham wald on survivorship bias (statistical research group, wwii)
paul samuelson (1938) on revealed vs stated preference
david graeber, bullshit jobs: a theory (2018)
melvin conway, conway's law (1968)
fred brooks, the mythical man-month (1975)