Output-Toward-Outcome Measurement
Don't forsake motion for progress — keep asking whether the metric you climb still serves the outcome.
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 4
- Confidence
- 87%
As teams debate lines-of-code, tokens consumed, and time-to-land-PR, Fiona Fung's discipline is to zoom out to the problem being solved and ask whether the output is really going toward the outcome. Usage-style metrics measure action, not impact, and any metric can quietly stop serving the goal as the landscape shifts. The rule: pick a metric you can hill-climb, but keep checking that it still reflects the outcome you actually want, and be willing to change it.
Origin
Fiona Fung, illustrated with her early Facebook Marketplace experience where a seller-count gate missed the real outcome; she frames it under 'don't forsake motion for progress.'
Core principles
- 01Measure whether output moves the outcome, not just that activity happened
- 02Token-maxing and lines-of-code are motion metrics, like the flawed proxies they replaced
- 03A good metric is one you can hill-climb, but it may stop serving the outcome as the landscape changes
- 04Pair metrics with a listening tour of senior engineers — dashboards miss shared learnings
How to run it
- 1
Name the outcome first
Zoom out and define the problem you're trying to solve and what good actually looks like before choosing a metric.
- 2
Pick a hill-climbable proxy — cautiously
Choose a metric you can improve against, while recognizing it is a proxy for the outcome, not the outcome itself.
Watch out Usage or activity metrics (tokens, lines of code) measure motion; confirm the output is going toward the outcome.
- 3
Re-audit whether the metric still serves
Periodically ask if the metric still reflects the outcome, since a fast-changing landscape can make a once-sensible metric misleading.
Pro tip When a metric misfires, update it rather than defending it — blindly following a stale metric is the failure mode.
- 4
Supplement with a listening tour
Talk to senior engineers about what's working and not; these conversations surface ideas and shared learning that metric dashboards can't.
In the wild
In early Marketplace, the team gated regional expansion heavily on number of sellers. After launching one region, seller count was low but people were finding the items they wanted — the actual goal — because a few power sellers carried supply. The metric didn't factor in power sellers.
→ They updated the expansion metric to reflect the real outcome instead of blindly following seller count, avoiding a wrong go/no-go call.
Common mistakes
Optimizing motion metrics
Measuring tokens consumed or lines of code tracks activity, not impact, so teams can look productive while the outcome doesn't move.
Blindly following a metric that used to make sense
Landscapes change fast; wearing blinders on a stale metric (like raw seller count) leads to wrong decisions the anecdotes would have caught.
Is it for you?
Best for
Product and engineering leaders under pressure to prove ROI of AI tooling and code velocity
Not ideal for
Stable domains with well-validated metrics where the outcome-to-proxy link is already trusted
From the transcript
“my advice here is one is output like is the output really going towards the outcome?”
“if you're measuring like, you know, like tool user usage, then you're you're measuring the action, but is it really making whatever the end outcome…”
“always keep in mind like is that metric really uh, still serving the outcome that you were aiming for.”
“in that region it wasn't uh, large number of sellers, but there were power sellers.”
From the episode
What happens after coding is solved?
Fiona Fung (Manager of the Claude Code and Cowork Teams)