Learn Product Engineering

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.

Every ticket arrives with the solution already chosen. Decompress it into the problem, the people, the evidence, the change and the smallest test before you estimate a single line.

"Users" is not a person. Name a role doing a task at a moment, and the job they are hiring the feature to do — then build for the job, not the request.

Output is what shipped; outcome is what changed because it shipped. Being measured on the second changes what you build, how small you build it, and what you do after launch.

The sprint is the cheapest part. Support, performance, complexity and eventually removal arrive after launch, keep arriving, and are paid by people who were not in the planning meeting.

A product engineer almost never refuses. They propose the smaller, cheaper way to find out who is right — and make it easy for the person asking to say yes to that instead.

Every real decision rejects something. Say what you gave up, who pays for it, and why that price is worth it — before someone else discovers it for you.

A short record written after the call — what was decided, what was rejected and why, and what would reopen it — so the reasoning survives the people who made it.

The page that gets a decision made by people who will read one page: the decision you need at the top, the options and their costs next, and everything else below the fold or gone.

Bring two or three real options, each with what it costs, and say which you recommend. Never bring only the recommendation — and never bring options without one.

Say you do not know, say what you will do to find out and by when, and give the best current guess with its confidence — so the room keeps trusting you instead of trusting whoever guessed loudest.

Decide fast on what can be undone, and slowly, in writing, with the right people, on what cannot. Most of the skill is noticing which is which — and turning the second kind into the first.

The quarter-size version that answers the same question as the full feature — found by naming the question first, and proposed by you before scope gets cut for you.

When the work does not fit, cut the parts that would not change the answer to the question the feature is asking — not the parts that are hardest to build.

Order the work so something useful reaches people in the first slice, and let the second slice — not a guess — justify the foundation.

A flag is how a launch becomes small and reversible: who sees it, how many, and how to stop it — owned like a product decision, and removed once the decision is made.

Merged is a midpoint. A feature is done when real people have used it and you know what happened — including when what happened was nothing.

A steady rhythm of small releases beats a heroic quarter: the team gets a pace it can hold, and stakeholders get a calendar they can plan around instead of a date they have to chase.

One number, close to the job the user came to do, that goes up when the product genuinely improves and is hard to push up any other way — written down precisely enough that two people compute the same value.

Decide how you will know before you build, and ship the events a cycle ahead of the feature — because "measure it later" has no baseline, and a number with no before is a number with no meaning.

Sample size decided in advance, a duration that covers the weekly cycle, a stop rule nobody changes after peeking, novelty accounted for — and "+3%" reported with its range and its conditions, not as a fact about the future.

The numbers that must not get worse while you move the one that should — chosen before the change, with thresholds agreed in advance, so that "we won" cannot mean "we won by breaking something nobody was watching".

A dashboard shows what someone thought to measure when they built it. The support tickets, session recordings, error logs and sales notes show what nobody thought to measure — which is usually where the next problem is.

The chart tells you what happened; five conversations tell you why. How to find the people, ask about the last time instead of the hypothetical, keep your solution out of the room, and turn what you hear into something the team can act on.

The PM owns the why and the priority; you bring the cost curve, the smaller version and the question behind the ticket — and when there is no PM, you say out loud which of their jobs you are now doing.

Tell the designer which part is expensive and why, in their terms, and offer the version that keeps the intent — before the mockup is signed off, not in week two of the build.

The first line is the decision you need or the thing that changed for them; everything after it is optional reading for whoever wants the detail.

Disagree once, in writing, before the decision; then build it as if it were yours, and agree in advance what would show which of you was right.

A demo exists to get a decision, not applause: show the path a real customer takes, ask the one question you need answered, and leave out everything that does not bear on it.

Feedback that lands is specific, about the work rather than the person, and says what effect it had — and you ask for it the same way: about one piece of work, with one concrete question.

An incident is something that happened to customers, not to a server. Who was affected, what did they lose, what do we tell them and what do we owe them — the fix is one line of that response.

The support queue is the cheapest user research you have: real people, describing real problems, unprompted, every day. Build the loop from ticket to change and back to the person who wrote it.

Debt has a cost you can name in the features it slows down and the incidents it causes. Argue for paying it in those terms — against the roadmap — not by asking for a refactor sprint.

Removing something is a feature with its own users, launch and success measure: announce it, measure who still depends on it, remove it, and say what you learned about why it did not work.

If you shipped it, you own the page. That means alerts on what customers feel, a runbook that makes the page short, and treating every page as a signal about the product, not only about the system.

A postmortem is worth what it changes. One change that would have prevented this incident, owned by a named person, with a date — instead of ten action items that quietly expire.