Goals & OKRs
You shipped the feature everyone agreed on. A month later, someone asks the only question that matters: did it work? Too many teams answer with a shrug - "people seem to like it." Metrics turn that shrug into an answer: this many people used it, this many came back, this number moved. Without them, a team can stay busy for years and never know if it's winning.
Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.
Listen to the full Goals & OKRs course on DesignPath
But numbers are easy to get wrong. Pick the flattering ones and you'll feel great while the product quietly fails. This topic is about choosing numbers that tell the truth - starting with the goals you set before you measure anything.
Outcomes vs Outputs
A team ships fourteen features in a quarter and celebrates a productive run. Nobody asks whether any of the fourteen changed what users actually do. This is the most common trap in product work: mistaking motion for progress. The features are outputs. Whether they moved anything is the outcome - and only one of the two is worth measuring.
The Difference
Output:what you produce - a feature, a release, a redesign. It's inside your control and easy to count.
Outcome:the change in human behavior or business result that the output was supposed to cause - more people finishing signup, fewer support tickets, higher retention.
Shipping a checkout redesign is an output. Cart completions going up is the outcome. You can hit the first and completely miss the second, which is exactly why "we shipped it" is not the same as "it worked."
Why Teams Drift to Outputs
Outputs are seductive because they're easy and safe. You can promise a feature and deliver it; you can't promise that users will behave differently. So teams quietly measure what they can guarantee - features shipped, story points, velocity - and call it progress.
The cost is a product that's always busy and never sure it's improving. A roadmap full of shipped outputs can sit on top of a flat or falling business, and nobody notices until it's late.
Pro tip: Watch for "we launched X" as a success story with no number after it. A launch is a beginning, not a result. The honest version is "we launched X, and it moved Y by Z."
Aim at the Outcome
The fix is to state the outcome first, then treat the feature as a bet on reaching it. Instead of "build a referral program," the goal is "grow signups from existing users," and the referral program is one attempt at it. If it doesn't move the number, you try another attempt - you're not married to the feature.
This is the same shift that outcome-based roadmaps make (from the last topic), now applied to how you measure: judge the work by whether the outcome moved, not by whether the thing shipped. Get this right and everything downstream - your OKRs, your north-star metric - lines up behind results instead of activity.
Where AI Helps
Prompt: "Here's a feature we're planning: [describe]. What outcome is it really trying to cause, and what metric would tell us whether it worked? Separate the output from the outcome clearly."
AI names the outcome behind an output; you decide if it's the right one.It's good at translating "build X" into "the change X is meant to cause" and suggesting a metric, but whether that outcome is what your strategy actually needs is your judgment to make.
