There’s hardly a more popular word in product management than “outcomes.” Alongside this, I’m pretty sure the phrase “to focus on outcomes over outputs” is in the top five of product management commandments.
But what do outcomes and outputs really mean? More importantly, are outputs truly as irrelevant as often painted?
Unfortunately, it’s not so simple. In this article, you’ll learn the difference between the two, the importance of focusing on outcomes, and why this can be flawed advice.
The difference between outcomes and outputs is often confusing for more junior product people. The most established definition is that outcomes are end goals you try to achieve (often referred to as “product impact”), whereas outputs are the means to achieve these outcomes.
Let’s use some examples to make the concept more tangible.
Some examples of outcomes, that is, goals you might want to achieve, could include:
All of those outcomes are a representation of an actual value for users or businesses, which is the most critical indicator when talking about an outcome.
Outputs are trickier. Some product folks would consider any sub-metric that leads to the outcome as an output. Others tend to split outcomes for different types and instead treat outputs as delivery metrics.
While I represent the second camp, and that’s how I’ll differentiate outputs and outcomes in this article, it’s worth remembering that it’s still a subjective topic. The most important thing is to ensure that both you and the person you talk to use the same vocabulary.
Returning to the topic of outputs, I’d define an output in software development as any measure of work your team delivers. These include:
In other words, any measure of your team’s delivery performance is an output (such as a feature delivered), whereas the business and user impact the output creates is an outcome (such as extra revenue generated by that feature).
Any product manager will agree that focusing on outcomes is the key in agile product development. After all, what’s the point of delivering new features, improving the velocity and pace of work if the work you deliver doesn’t yield any positive results?
It’s better to deliver 10 story-points-worth features in two weeks that double user engagement than deliver 20 story-points-worth features in a day that achieve nothing.
However, outcomes are not equal, and you can make different types of impact. These differences are what make working with outcomes confusing to many. To simplify things, I recommend differentiating between business and user outcomes.
Business outcomes are primarily about, you guessed it, the business impact that you strive to achieve. At the end of the day, it’s also what you’re hired for.
Examples of business outcomes include:
Let’s say you want to increase the sales of a food delivery app — that’s a typical example of a business outcome:
User outcomes are the changes in user behavior that help you drive business outcomes.
If your business outcome is to increase the sales of a food delivery app, user outcomes are the changes you’ll want to see in your users’ behavior and activity that will help you achieve that outcome:
One way could be to generate additional triggers for people to use the app, measured as the average number of weekly app visits. Another option would be to maximize the chances of sales by making users explore more restaurants, whether by offering more options or making the exploration more fun.
These are both examples of user outcomes you might want to focus on to drive the business outcome:
To wrap up, you deliver new features and initiatives to drive user outcomes, which in the long run lead to business outcomes everyone hopes for.
Although outcomes are what truly matters in product management, don’t fall into the trap of ignoring outputs altogether.
Yes, you’re hired to chase outcomes, but you won’t have any outcomes without catering for outputs first. It doesn’t matter how fantastic and valuable your idea is if you can’t ship it to the market.
Let’s take a look at a few examples of why outputs matter.
Although more (features, story points) isn’t necessarily better, with most initiatives often failing, the more you ship, the higher the odds that you’ll strike gold or learn something new.
The truth is, most innovations don’t come from careful planning and discovery, but rather from learning on the go and some dumb luck.
More delivered features lead to more user-facing tests, leading to more learnings, and ultimately, a better product.
Although the volume of delivery is essential, the speed also matters.
The faster you can go from picking up the work to its delivery (cycle time), the faster you can validate your assumptions, the faster you learn, and the faster you can pivot the direction you take.
Speed of execution is often the key factor that allows smaller companies to compete with giant competitors, so don’t neglect that area.
Innovation rate answers the question of what proportion of the time the team spends on delivering new value compared to other initiatives:
It doesn’t matter if the team delivers a high volume of work in an extraordinary time if most of what they do is running around circles with maintenance tasks.
Optimizing the innovation rate helps you optimize the type of work the team works on, and the more time and energy is put into new value (high innovation rate), the higher the odds this team will make a meaningful contribution to chased outcomes.
To wrap up, you should optimize the outputs you deliver, hoping that these outputs will help you with user outcomes that ultimately contribute to the business outcomes you were hired to deliver.
Although outcomes are what ultimately you’re judged for, outputs are still an essential part of the equation. Without outputs, there are no outcomes at the end of the day. You need both.
It’s all about carefully balancing between focusing on outcomes and outputs. Focus too much on outcomes, and you’ll fail to execute all your ambitions. Focus too much on outputs, and you’ll master the speedy delivery of solutions no one needs.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Quality function deployment (QFD) helps you validate whether you’re on the right path to satisfying your customers.
Learn how to use Fibonacci story points for Agile estimation, avoid pitfalls, and explore alternatives like T-shirt sizing and #NoEstimates.
Randolph D’Souza talks about how he works to align different teams together, such as product, OEM engineering, and sales.
Understanding the root causes of project bloat is essential for aiming to improve productivity and streamline workflows.
Learn more →
