Product Engineering
How do I become an engineer who ships outcomes and can explain why? Not how to build the feature — how to decide what is worth building, explain that decision to people who did not make it, ship the smallest version that teaches you something, know whether it worked, and own it once real people depend on it.
How do I become a product engineer — someone who owns whether the thing they built changed anything?
Every lesson here starts from something someone actually said — in a meeting, in a ticket, in a support thread — shows the response that comes to mind first, and then shows how that response goes wrong on a real team. The obvious response is obvious for a reason; it is also where features nobody uses come from.
The order is the argument. A decision you cannot explain was not made — it happened. A feature you cannot measure was not shipped — it was merged. Skip a step and you get work that is locally reasonable and globally pointless.
This is the judgement domain
Every other domain teaches how to build something. This one teaches how to decide whether to, and how to explain the answer.
Problem Solving teaches how to make progress on a problem once you have one. This domain is about which problem, for whom, and whether it is worth it.
Decompressing tickets, naming trade-offs, writing the one-pager, cutting the first version, picking the metric, running the demo, owning the incident — and explaining every one of those decisions to someone who did not make it.
Practice and reference
The parts of this domain that are not reading.
Situations someone could plausibly hand you — a ticket to decompress, a scope to cut, an experiment that lies, an incident with a product cost. Each one carries the trap: the move that looks right.
What each question is really testing, what a strong answer sounds like, and the red flags that separate a remembered phrase from working judgement.
Six stages in one order — think, decide, ship, measure, people, own — each naming what it needs first and what you should be able to do before moving on.
Learning modules
Six modules, from what the role actually is to the postmortem that changes something.
What a product engineer is and is not, why the problem comes before the solution, who the users are and what they are trying to get done, and why a shipped feature is a cost until it changes something.
Naming the trade-off you rejected, writing a decision record and a one-pager, presenting options instead of answers, saying "I don't know yet" without losing the room, and telling reversible decisions from the ones that are not.
Cutting a first version that teaches you something, sequencing work so value lands early, feature flags as product tools rather than deploy tools, a definition of done that includes "someone used it", and a shipping cadence the team can sustain.
Picking one metric that moves when the product improves, instrumenting before building, reading an experiment honestly, guardrails against winning the wrong way, what a dashboard cannot tell you, and where qualitative signals beat numbers.
Product managers, designers, stakeholders and the engineers next to you: how to write for people who will not read past the first line, disagree and still commit, run a demo that changes a decision, and give feedback that lands.
What changes once real people depend on it: incidents as product events, the support loop as a source of truth, technical debt as a product decision with a cost, deprecating what nobody uses, on-call for people who ship features, and postmortems that change something.
Reference
For when you already know roughly what you are looking for.