When I sent my newsletter last month, Modern Management: Want Valuable Outcomes? Create Overarching Goals, several readers asked me questions. Why did I differentiate between outputs, outcomes, and benefits? I decided that was worth a blog post.
Here’s how I define and use the terms.
Outputs
By themselves, a customer can’t use an output. We might use them as a team. But they are incomplete. Some examples:
- Tasks in a user story, such as “design database schema.”
- Or “write test plan.”
- Word counts for writers. (I track my word counts, but you don’t see everything I write.)
We might need these tasks, but no one outside the team can use them.
If you still use phases in your projects, anything you designate as “complete” is an output, not an outcome. Why? Because until you finish the testing, you don’t know that anything is complete. (See “Complete” and “Freeze” Aren’t for more details.)
It’s the same idea with tasks in a user story. You might well need to create a test plan or design a schema. But neither of those tasks offers the user a benefit.
These tasks don’t benefit the team either—unless the team collaborates to complete that work. Why? Because the value of those artifacts is partly in the discussion to create them, not just the artifacts themselves.
Outputs might help your team. But your customers use your outcomes.
Outcomes
We can learn from outcomes, either about the risks or how people use our work. We can’t learn from outputs because the outputs are incomplete by themselves.
Which people learn? Any of: end-users, or buyers/customers, or another team. I gave examples of a variety of product-based outcomes in Consider Product Options with Minimum Outcomes. For writers, this might be a finished blog post or article. Or a chapter in a book.
Notice I haven’t yet said anything about the benefits someone might get from an outcome. That’s because we can only create outcomes. We can’t guarantee benefits—because we can’t make people use our outcomes. We can only offer these outcomes.
Other People Derive Benefits from Outcomes
Benefits are what people might get from the outcome. We can’t make them get the benefit. We can only offer the outcome to derive the benefit.
Let me offer an example from my writing. I publish a wide variety of blog posts and books about agility in all forms. In Create Your Successful Agile Project, I offered ways to rethink any given team’s approach to agility. Why? Because my clients were flailing, not succeeding with their given framework.
I offered the outcome: a complete book.
The benefits for people who’ve read and acted on that writing? Substantial. All the people who haven’t read it? They didn’t take me up on my offer. I still created the outcome. They haven’t benefited (yet).
That’s why I hate the idea of ROI for any kind of product. We can’t make people take what we offer. That means we can’t predict the benefits people will gain. That’s why I separate the benefits from the outcomes.
Separate Benefits from Outcomes
Since we can’t make our clients (or anyone) choose to benefit from our work, we can only offer usable outcomes. And that means while we might track outputs inside our team, it’s not worth tracking anything other than outcomes outside of the team. That’s why I track cycle time to see how long it takes for us to release an outcome.
When I track my word counts (my output), I can see at a glance what I write and how much. Do I need to write more? I can see that output and change what I do. I don’t even need a real retrospective.
However, you can’t use my word counts unless I finish something and publish it. That’s the outcome.
And if you change your behavior based on what I write? That’s your benefit.
Here’s how this all works together. When we have an overarching goal, we all work towards that goal. While we might create outputs on the way to outcomes, we see that the outcomes help move us closer to that overarching goal. The shorter our feedback loops, the faster our users can realize the benefits.
When we separate the ideas of outputs, outcomes, and benefits, we might see when to release something faster. For me, that’s the best outcome of all.
(Thank you, dear readers, for your questions.)
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Clarify the Difference Between Outputs, Outcomes, and Benefits Opinions expressed by Java Code Geeks contributors are their own. |
