Product Engineering Roadmap
Start at Think in outcomes. 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. Progress is stored locally in your browser.
Where to start
Product engineering
6 stages · 0/36 lessonsDeciding what is worth building, explaining the decision, shipping the smallest version that teaches you something, knowing whether it worked, and owning it in production.
- 10/6
Think in outcomes
Start hereWhat the role is, 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. This stage is the difference between taking tickets and owning results.
Before moving on: Take any ticket on the board and say, in one sentence each, what problem it solves, for whom, how you know the problem is real, what changes if it is solved, and what the smallest thing that would tell you is.
- 20/6
Decide, and explain it
Naming the trade-off you rejected, writing decisions down where others can find them, presenting options instead of answers, admitting what you do not know yet, and telling the decisions you can undo from the ones you cannot. A decision you cannot explain was not made — it happened.
Before moving on: Write a one-page decision record for a real choice on your team — the options, the one you picked, the one you rejected and why, and what would change your mind — that a colleague can read in five minutes and disagree with precisely.
Needs first:Think in outcomes - 30/6
Ship the smallest thing
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.
Before moving on: Propose a first version of a feature that is a quarter of the requested scope, say what question it answers, and plan its rollout behind a flag so it can be turned off in a minute.
Needs first:Decide, and explain it - 40/6
Measure what matters
One metric that moves when the product improves, instrumentation before code, honest experiment reading, guardrails against winning the wrong way, what a dashboard cannot tell you, and where five conversations beat a thousand events.
Before moving on: Name the metric and the guardrail for a feature before it is built, instrument both first, and read the result after launch honestly — including when the number did not move.
Needs first:Ship the smallest thing - 50/6
Work with people
Product managers, designers and stakeholders as partners rather than sources of tickets; writing for people who stop reading after the first line; disagreeing and still committing; demos that end with a decision; feedback that lands in both directions.
Before moving on: Turn a solution someone handed you into a problem statement together, write a status update whose first line is the decision, and run a demo that ends with a decision instead of applause.
Needs first:Decide, and explain it - 60/6
Own it in production
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.
Before moving on: Write a postmortem whose one action item someone actually does, and argue for removing a feature nobody uses — with the numbers and the announcement.