The best sprint review I ever attended had charts, confetti emojis, and forty-seven story points of completed work. The warehouse it was built for still printed pick lists by hand and re-keyed them into the order system every afternoon. Forty-seven points. Zero change. Everybody clapped.
That meeting is why I flinch at velocity charts. Somewhere between the burndown and the backlog, the software industry got very good at measuring effort and somewhat worse at measuring whether anything improved.
Outcome-based software delivery is the alternative: you agree on a business number before writing code, then measure the work by how much that number moves. Invoice cycle time. Picker error rate. Hours of manual re-keying per week. The software is a means; the number is the point.
The story point confession
Story points aren't evil. They're a planning tool that escaped its cage and started grading the class. Once a team's status depends on points completed, points get completed, and the question "did the business get better" quietly leaves the room.
I've watched it from both sides. The team isn't lazy or cynical; the metric is just louder than the mission. If the sprint goal is "finish the ticket," finishing the ticket is what you'll get, even when the ticket describes a feature the warehouse doesn't want.
What outcome-based software delivery actually means
The working agreement is simple to say and surprisingly hard to sign: pick one number the client cares about, measure its baseline, set a target and a date, and treat everything else as negotiable. Features, architecture, even the tech stack, all subordinate to moving that number.
Say you're embedded with a regional distributor. The outcome isn't "build a quoting tool." It's "cut quote turnaround from two days to under one hour." That phrasing changes every downstream decision, because half the features on someone's wish list suddenly have no visible path to the number.
A number you can argue about
Good outcomes are falsifiable. "Improve efficiency" cannot fail, which is exactly why it's useless. "Cut manual re-keying from twelve hours a week to two" can fail, which is why it works: it forces the argument about what's actually wrong to happen before the build, not after the invoice.
How it changes the work
Scope gets murdered early, and nobody mourns. When every feature must justify itself against the number, the backlog shrinks to a fighting weight. On one nine-day engagement, the original ask was a fourteen-feature portal. The outcome contract was "reduce order-entry errors by half." We shipped three features. Errors dropped by more than half, because the other eleven features were decoration.
Demos change too. Instead of walking through completed tickets, you put the metric on the wall and show its slope. Stakeholders stop asking "is it done yet" and start asking "is it working yet," which is a much better question. This is the working style behind the forward deployed engineer role: you're embedded close enough to the problem that the number is visible from your desk.
Saying no gets easier, which might be the whole trick. "Does this move quote turnaround?" is a question with an answer, and when the answer is no, the feature waits. Compare that to the traditional process, where prioritization is a knife fight between whoever shouts loudest, a dynamic I compared in how FDEs and product managers split the decision-making.
The weekly metric review deserves its own mention, because it's where the model either lives or dies. Fifteen minutes, same time every week, the number on the screen and the client owner in the room. No slides about effort. When the number moved, we talked about why so we could do more of it. When it didn't, we talked about what to stop doing. After four weeks of this ritual, the client started holding their own internal teams to the same standard, which is when you know the working style has actually transferred.
The uncomfortable parts
Sometimes the honest answer is that the outcome doesn't need software. I once spent a week on-site concluding that the client's real problem was a pricing approval chain with four signatures, and the highest-ROI deliverable was a one-page process change and a whiteboard. We billed for the week and built nothing. The client saved more than any tool would have.
There's also the miss. You will sometimes target a number and not move it. An outcome contract makes that visible, which is the point and also the pain. Pre-agreeing on kill criteria, the conditions under which everyone stops and reassesses, turns a failure into a decision instead of a slow bleed.
Billing is the other friction point worth naming. Procurement departments are calibrated for hours and deliverables, and "pay us when the number moves" makes some of them genuinely distressed. The workable middle ground is a fixed fee for the build with a documented outcome target attached, rather than pure pay-for-performance. You keep the honesty of the metric without asking anyone's finance team to invent a new contract vehicle on a Tuesday.
Setting up your own outcome contract
The checklist I use before any engagement:
- Baseline. Measure the current number, even crudely. "About two days" is fine; "we think it's slow" is not.
- Target. One number, one date. Resist the urge to have three.
- Owner. A named person on the client side who verifies the measurement and settles arguments about it.
- Kill criteria. The conditions under which we stop: budget consumed, number unmoved after N weeks, better solution discovered.
- Weekly check. The number on the wall, reviewed with the owner, every week, no exceptions.
None of this requires a fancy contract. I've done it in a two-paragraph email, and the discipline mattered more than the legal language. It also travels well beyond FDE work; any team doing hands-on delivery alongside a client can steal it wholesale.
Why this is the FDE default
Forward deployed engineers end up working this way almost by accident. When you sit next to the person whose Tuesday your software is supposed to fix, you can't hide behind story points; they will tell you, at lunch, whether Tuesday got better. The proximity forces the honesty. You can get the same effect without the embedding, but you have to build the forcing function yourself, and the outcome contract is the cheapest one I've found.