Product Engineering

TL;DR

We are product engineers before we are coders. Our job is to move user outcomes — not to ship tickets. Work is shaped before it is scheduled, scheduled against a fixed appetite rather than an estimate, and measured by the change it makes in user behaviour rather than the volume of code it produces.

Why this matters

The dominant failure mode of engineering teams in 2026 is not technical debt — it is building the wrong thing well. Feature factories optimise cycle time and output velocity and end up with a product surface that grows faster than the value it delivers. Product engineering is the discipline of resisting that. It says the unit of work is a user outcome, the unit of planning is an appetite, and the test of a PR is whether a real user can feel it.

Our principles

1. Outcomes over outputs

An "output" is a feature shipped, a ticket closed, a migration completed. An "outcome" is a change in what a user can do, how quickly they can do it, or how reliably the system supports them. We plan around outcomes and let outputs be whatever shape is required to deliver them. A sprint ending with three closed tickets and no user-visible outcome is a sprint of failed work.

2. Shape work before scheduling it

No work enters a sprint without having been shaped: the problem stated in user terms, the rough solution sketched, the boundaries drawn to exclude rabbit holes. Shaped work is expensive upfront and cheap downstream. Unshaped work is the single biggest source of mid-sprint drift, scope creep, and late-breaking discovery that the whole approach was wrong.

3. Appetite, not estimate

We set an appetite — "this is worth about two weeks of one engineer's attention" — and then design a solution that fits inside it. If it cannot fit, we either reduce scope or reject the work. This inverts the usual flow: instead of estimating the cost of a fixed solution, we fix the cost and negotiate the solution. It forces the team to ask "what is the cheapest version of this that delivers the outcome?" and it kills the tendency of work to expand to the time available.

4. Kill your darlings

If a feature is not moving an outcome, we remove it. Deletion is the most under-used tool in a product engineer's kit. Every line of code, every page of docs, every dashboard tile, every CLI flag that does not pay for its maintenance cost should be cut. A smaller, sharper product is cheaper to operate and easier for the next engineer to understand.

5. Instrument everything you ship

A feature that is not measured does not exist from a product engineering point of view. We decide the signal before we ship — event, dashboard, success criterion — and we check the signal after release. If we cannot measure it, we negotiate the feature until we can.

How we apply this

• Run Tests — we test the outcome, not the implementation.
• Progressive Delivery — canaries and flags are the mechanism by which we measure outcomes safely.
• Observability — the signal layer that makes outcome-based engineering possible.
• Decisions — the record of shaping decisions that cost us real time.

Anti-patterns we reject

• Velocity-as-KPI. Story points per sprint measure nothing about user outcomes. Optimising for it corrupts the team.
• Estimate-driven planning. Estimates anchor on how long the team thinks work will take, not on how much the work is worth. We use appetites instead.
• "Build it and they will come." Launching a feature without a measurement plan is a signal that no one owns the outcome.
• Technical-debt-for-its-own-sake projects. Refactors without a user-visible payoff are a smell; wrap them inside an outcome that demands them.

Further reading

• Shape Up, Ryan Singer — the canonical treatment of shaped work and fixed appetites.
• Inspired, Marty Cagan — the product-engineering triad and its implications for how teams are built.
• Escaping the Build Trap, Melissa Perri — why feature-factory metrics corrupt outcomes.