What a Product Engineer Actually Is
An engineer who owns whether the thing they built changed anything — from the question behind the ticket to the number after the launch — and can explain every decision in between.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
If the tickets stopped arriving tomorrow, what would a product engineer still know how to do?
The team lead says: "We want engineers who think like owners, not ticket-takers." Nobody says what that means on a Tuesday afternoon.
A product engineer is a full-stack engineer who also attends product meetings. Do the tickets well, ask good questions in refinement, and care about the users.
Caring about users is a feeling; owning an outcome is a behaviour. The engineer who "cares" still ships the feature exactly as specified, watches nobody use it, and calls the quarter a success because the tickets closed.
- Caring about users is a feeling; owning an outcome is a behaviour. The engineer who "cares" still ships the feature exactly as specified, watches nobody use it, and calls the quarter a success because the tickets closed.
- Attending the product meeting does not change who decides. If the engineer cannot say what problem the feature solves and for whom, they are a well-informed ticket-taker.
- Full-stack describes what someone can build. It says nothing about whether they can tell the difference between a feature that should exist and one that should not — which is the entire job.
- "Think like an owner" without a definition becomes "work more hours and agree in meetings". That is not ownership; it is compliance with extra steps.
What is really going on
- A ticket is a compressed decision. Someone saw a problem, imagined a solution, and wrote down the solution. The problem is usually lost in the compression, and the solution was chosen with less information than you will have while building it.
- A product engineer decompresses the ticket: what problem, for whom, how do we know it is real, what would change if it were solved, and what is the smallest thing that would tell us. Those five questions are the job; the code is what happens after them.
- Ownership is being on the hook for the outcome, not the output. The output is "the export button shipped". The outcome is "finance stopped asking support for CSVs". An owner knows which one they are measured on and behaves accordingly.
- The unit of work is a decision you can explain: what you chose, what you rejected, why, and what would make you change your mind. Everything else in this domain — one-pagers, metrics, flags, postmortems — exists to make those decisions cheaper to make and easier to explain.
- It is a role you take, not a title you are given. On most teams the space is there; the reason it stays empty is that taking it means being wrong in public sometimes.
A ticket is a compressed decision
Every ticket was once a conversation. Someone noticed something — a support pattern, a lost deal, a competitor's screenshot — imagined a way to address it, and wrote the way down. By the time it reaches a sprint board, the conversation is gone and the way remains: "Add CSV export to the orders page."
The engineer who takes that ticket literally builds an export. The product engineer asks what the conversation was. Finance asks support for CSVs every Monday; support runs a query by hand; the numbers are late and occasionally wrong. Now there are several ways to solve it, the export button is one of them, and it is possible to say which is cheapest to try first.
The five questions
The job compresses to five questions asked before the first line of code. They are not a process and they do not need a template; on a good day they take ten minutes in the refinement call. On a bad day they reveal that nobody in the room can answer the second one, which is the most valuable thing that can happen to a ticket.
- What problem? In one sentence, without naming a feature. "Finance gets Monday numbers late and sometimes wrong."
- For whom? A person or a role, not "users". Finance, weekly, one analyst who currently pings support.
- How do we know it is real? The support tickets, the Slack thread, the analyst's own words — not a hunch that someone somewhere would like it.
- What changes if we solve it? Two hours of an analyst's Monday, two support interruptions, a number nobody has to re-check.
- What is the smallest thing that would tell us? A saved query the analyst can run herself. Then, if that is not enough, the button.
Refinement. The PM presents "Add CSV export to the orders page" as a two-point ticket. You have thirty seconds before the estimate.
"Should we also support Excel? And do we need date filters? Two points seems low, maybe five."
"Who is asking for this and what do they do with the file? — Finance, every Monday, for the revenue report. — Do they need it from the page, or do they need the numbers? Because a saved query they can run is a morning's work and would tell us if the button is the right shape."
Output, outcome, and who is on the hook
The difference between a product engineer and a very good engineer is which of two sentences they are measured on. "The export shipped on Thursday" is output. "Finance stopped asking support for CSVs" is an outcome. Both are true or false; only the second says anything about whether the work mattered.
Being on the hook for the outcome changes behaviour in specific ways. You instrument before you build, because you will need the number. You ship the smaller version, because being wrong small is cheaper than being wrong large. You read the support queue after launch, because that is where the outcome shows up first. And you say, in writing, when it did not work — which is the part that makes the role trustworthy rather than merely opinionated (Outcome vs Output).
Shipped CSV export for orders. 3 points, on time, no bugs reported.
Export shipped Thursday. Support tickets tagged "export" went from 4/week to 0 over three weeks. Finance still re-checks totals by hand — the numbers disagree with their ledger by refund timing, which is the next problem.
The second version tells the team whether to invest more, and has already found the next problem. The first tells them the sprint went fine.
It is a role you take
On most teams nobody is stopping the engineer from asking the five questions, proposing the smaller version, or reporting the number afterwards. The space is empty because taking it costs something: you are wrong in public sometimes, your smaller version is occasionally too small, and the PM may not thank you for the questions the first time.
The way in is not a declaration. It is doing the behaviour on one ticket, visibly, and letting the result argue for the next one. The export that turned into a saved query and saved a sprint is worth more than any conversation about "thinking like an owner" (Saying No Well).
How to do it
Most important first.
- Before starting any ticket, write one sentence: "This exists so that [who] can [do what], which we will see as [signal]." If you cannot fill it in, that is the first thing to find out (Problem Before Solution).
- Ask for the smallest version that would answer the question the feature is really asking, and propose it yourself rather than waiting for scope to be cut for you (The First Version That Teaches You Something).
- Write down every non-obvious decision in a place someone else can find in six months, with the option you rejected (Decision Records).
- Decide how you will know it worked before you build it, and instrument that first (Instrumentation First).
- Stay attached after launch: read the support tickets, watch the number, and be the person who proposes removing it if it did not work (The Support Loop).
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with the problem, not the solution: "Finance spends two hours every Monday asking support for order CSVs" makes everyone in the room want the export button. "We should build an export" makes them ask why.
- Say what you are not doing and why: "We are shipping CSV only, no scheduling, because we do not yet know whether the Monday report is the real need or just the visible one."
- Name the signal you will watch: "If support tickets tagged *export* drop to zero within a month, this worked. If they do not, we will have learned the actual problem was somewhere else."
- Offer the reversal: "If it turns out finance needs it scheduled, that is a two-day addition; if they need it in their BI tool, this was the wrong shape and we will say so."
- "We hired you to build, not to question the roadmap." Fair — and building the wrong thing well is the most expensive way to build. The questions take twenty minutes and save weeks; here is the last one that did.
- "Just ship the ticket, we can measure later." Later never has the baseline. If we do not record what "before" looked like, we will never know whether this worked, and the next argument will be opinions again.
What can go wrong
- Ownership theatre: strong opinions in the planning meeting, then building exactly what was specified when the opinions met resistance.
- Owning everything: treating every ticket as a strategy question and grinding refinement to a halt. Most tickets are fine. The skill is knowing which ones are not.
- Confusing "I would have built it differently" with "it should not be built". Engineering preference is not product judgement.
- Measuring the wrong thing because it was easy to measure, then optimising it. Clicks on the button are not finance getting their numbers.
- "Product engineer means I decide what we build." No — it means you help decide, and you can explain the decision either way. The PM, the founder or the customer may still hold the call.
- "This is a PM skill, not an engineering skill." The engineer is the one who knows what a change actually costs and what the system can tell you afterwards. That knowledge is exactly what the decision needs.
- "If I own outcomes I should refuse tickets I disagree with." Refusing is rarely the move; proposing a smaller, cheaper way to find out who is right almost always is (Disagree and Commit).
Knowing whether it worked
- You can state, for the last three things you shipped, what problem each solved and whether it did. If you cannot, you are shipping output.
- People bring you problems before they have chosen a solution, because you have shown you will help choose rather than just build.
- The number you said would move after launch — you looked at it, and you told the team what you saw, including when it did not move.
- Support tickets in your area go down over a quarter, not up, and you can name which change did it.
- On a three-person team the product engineer *is* the product function. At a company with a product organisation, the same behaviour is what makes a product manager treat you as a partner instead of a resource.
- At 10x team size, the decisions you cannot explain in writing get made without you. Decision records and one-pagers stop being nice-to-have and become the only way your judgement travels.
- At 10x users, every "small" feature has a support cost, a performance cost and a deprecation cost. The bar for "should this exist" rises, and the engineer who can argue *against* a feature becomes more valuable than the one who can build it fast.
- It is slower to start. Five questions before the first line of code is a real cost on a genuinely simple ticket, and you will sometimes ask them of a ticket that did not need them.
- It exposes you. An engineer who only builds what was specified is never wrong; an engineer who argues for a smaller first version owns the outcome when it turns out too small.
- It costs relationships if done badly. Decompressing every ticket in front of the person who wrote it, without care, reads as "your idea is bad" rather than "help me understand".
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALTrue wherever someone writes software for people who did not write it. The five questions apply to an internal tool and to a consumer app alike.
- TEAM-SPECIFICWith a strong PM the role is a partnership and the engineer leads on cost, feasibility and signals; without one, the engineer often has to do the PM's discovery work too, and should say so rather than absorb it silently.
- STAGE-SPECIFICPre-product-market-fit, "what problem is this" is asked of everything because the product itself is the experiment. In a mature product most tickets are genuinely operational, and asking the five questions of a copy change is noise.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.