Outcome Engineering: The Discipline of Building What Actually Matters

There's a pattern I've seen in every organisation I've worked with or consulted for. The engineering team ships features on time. The product roadmap gets executed. The sprint velocity is healthy. And yet, the business isn't moving. Users aren't engaging the way anyone expected. The metrics that actually matter — retention, activation, revenue — are stubbornly flat.

This is what I call the feature trap. You measure progress by what ships, not by what changes.

Outcome engineering is the discipline of breaking out of that trap.

What Is Outcome Engineering?

An outcome is a change in behaviour. A feature is a thing you built. These are not the same thing, and conflating them is the root cause of most product failures.

Feature thinking: We need to build a notification system.
Outcome thinking: We need users to come back within 48 hours of signing up. What's the highest-leverage way to achieve that?

The notification system might be the right answer. It might not. Outcome thinking asks the question first, then finds the solution. Feature thinking assumes the solution and skips the question.

The Outcome Stack

When I start on a new problem, I work through three levels:

1. The Business Outcome

What does the company need to be true? This is usually a metric: retention, conversion, revenue per user, time to value. It should be measurable and have a clear owner.

2. The User Outcome

What does the user need to be able to do, feel, or accomplish? This is where empathy lives. The business outcome can't be achieved without a real user outcome underneath it.

3. The Product Outcome

What specific product change will create the user outcome? This is where engineering begins — not before.

Business outcome: Increase 30-day retention by 15%
    ↓
User outcome: Users feel successful in their first session
    ↓
Product outcome: Reduce time-to-first-value from 12 minutes to under 5
    ↓
Feature: Guided onboarding flow with inline contextual help

The feature is the last thing you decide, not the first. This sequence feels obvious when written out. It's violated constantly in practice.¹

Measuring What You Change

Outcome engineering requires instrumentation. You cannot know if you achieved an outcome without measuring it before and after.

Before writing any code for a new feature, I define:

Success metric: The specific number that should move, with a target and a timeframe.
Counter metric: The thing that shouldn't get worse. (Fixing retention at the cost of satisfaction is not a win.)
Leading indicator: A signal you can see within days that predicts the lagging metric you'll see in weeks.

This forces precision. "Users will love this" is not a success metric. "30-day retention for new users increases from 34% to 40% within 8 weeks" is.

The Build-Measure-Learn Trap

Lean methodology gave us build-measure-learn. It's correct in principle and catastrophically misapplied in practice.

The trap is treating every iteration as equally valuable. Some things you should build and measure. Some things you should learn without building. A five-minute user interview might invalidate an assumption that would have taken three weeks to build a test for.

I use a decision matrix before any significant piece of work:

The bottom-right quadrant kills roadmaps. A low-confidence, high-cost bet is a gamble dressed up as a feature.

Design Engineering's Unique Advantage

Here's where I think design engineers have an edge that neither pure designers nor pure engineers have: we can prototype high-fidelity experiences fast enough to test outcomes before full implementation.

A designer's prototype can't be measured in production. A backend engineer's implementation takes too long to be disposable. A design engineer can ship a real, instrumented version of an idea in a timeframe that still allows for course correction.²

I've shipped features that were intentionally incomplete — functional enough to measure, rough enough to throw away if the outcome didn't materialise. Most of them got thrown away. That's not failure. That's the whole point.

Questions I Ask Every Sprint

• What outcome are we trying to create this sprint?
• How will we know if we succeeded?
• What's the fastest way to find out if this is the right solution?
• What's the riskiest assumption we're making?

These aren't philosophical questions. They're practical tools that surface misalignments before they become expensive mistakes.

Outcome engineering is a practice, not a framework. Frameworks provide structure; practice builds judgment. The judgment to know when a feature is really a question, when a roadmap is really a hypothesis, and when shipping means learning rather than finishing — that's what separates the teams that move fast from the ones that just look like they do.