Ship for the outcome, not the output
Common product principle, in my words
Features, commits and releases are output. What changes for the user is the outcome, and it is the only part anyone pays for.
Output is easy to see and easy to count: a feature shipped, a sprint closed, a release tagged. It feels like progress, so teams optimise for it.
An outcome is what changes because of that work. Users find what they search for. Orders stop failing. A process that took a day takes an hour. Outcomes are harder to measure and slower to show up, which is exactly why they get skipped.
The difference decides what you build. If the goal is output, a bigger roadmap is better. If the goal is an outcome, the best release might be the one that removes a feature, or the one that never needs to happen because a setting fixed the problem.
Try this
For your next piece of work, write one sentence that starts with “When this ships, users will be able to…” and one number that should move. If you cannot finish the sentence, you are planning output.