Outputs enable Outcomes
Kent J. McDonald
Product Management Writer | Advisor | I help organizations build the right software | Specialize in IT, B2B product management, agile software development
It’s a common feature of transformations to describe the target for the transformation in terms of contrast. The agile manifesto is probably the most well-known example with its “this” over “that” format.
For product transformations, the phrase that fits that model is outcome over output.
It makes sense to focus on outcomes, because we want to encourage product teams to make decisions and measure success based on the problems they solve, not necessarily the featured they deliver.
But that doesn’t change the cold, hard fact that you need to deliver output in order to reach an outcome. You can’t ignore outputs, but you need to understand the role they play.
Decide what outcome you’re trying to reach. Determine the best way to accomplish that outcome and identify the output that will get you there. Measure success based on whether or not you accomplished the outcome.
You need to deliver outputs to get the outcomes you set out to accomplish. You also want to do that with as few outputs as possible so that you can minimize the number of things you have to maintain.
It’s not outcome over output. Its maximum outcome with minimum output.
And now it’s time for the elephant in the room. Tech enabled enterprises are used to dictating what outputs they expect from tech. Even after going through agile transformations and digital transformations, projects always started off as “implement a CRM” or “change these three steps in the claims process.”
Rarely were teams in tech enabled enterprises asked to solve problems. As these organizations go through product transformations, that’s slowly changing. But teams at these organizations often have difficulty figuring out how to start with outcomes to decide what to do.
This week’s InsideProduct describes some ways you can use outcomes to decide which outputs to deliver.
Other Newsletters to Read
Product Collective
Join 50,000+ newsletter subscribers learning the latest methods, tools, and frameworks used to build, launch and scale world-class software products. Subscribers also get exclusive promos for INDUSTRY: The Product Conference and full access to the Product Collective Member Hub, including over 120 hours of On Demand video content.
Department of Product
Department of Product Briefing - the latest product launches, news and analysis designed to help you build winning products. Join 18,000+ product people from Spotify, Netflix, Amazon, Apple and Microsoft and get your free weekly product briefing.
Use outcomes to help you decide what investments to make
If your organization still organizes work by projects, it makes investment decisions when it starts, and hopefully finishes, a project intended to accomplish a particular result. The investment is in terms of money, people’s time, and other resources.
So even though your organization is still making discrete decisions about whether to pursue an investment with a defined timeframe, budget, and scope, there is still value in approaching those decisions through an outcome lens.
You want to frame the decision about what problem you’re trying to solve and whether that problem is worth solving.
The trick is getting all the people involved with that decision to agree on the problem and that it’s worth solving within certain constraints (for how much and by when) rather than making an explicit decision about how you satisfy that need.
I realize that’s easier said than done.
Structure your investment decision around outcomes
Most organizations that make investment decisions with a project paradigm decide whether to do a specific project, meaning they are deciding whether to implement a specific solution. You’ll know when your organization is falling into this trap you discuss investments similar to these:
On the surface, these all appear to be excellent investments, and it should be easy to tell when each is done. Right?
Maybe not.
Sure, you could claim that the rewrite is done when the new product is up and running. But does that mean you have to recreate all the functionality on the existing system, even if something isn’t relevant after 20 years?
You know you’re done moving customers over to a new ordering system when they are on the new ordering system. (Yes, that is tautological) But do you know for sure that moving the customers to the new ordering system is going to accomplish what you set out to do? Do you know what you set out to do?
Let me rephrase that. Do you know why you wanted to move customers over to a new ordering system?
You know you’re done introducing a new express pickup service when people can use it. But again, how do you know that service was a success?
To know when those investments were successful, you need to know what need each investment as trying to solve. You need to know why it’s worth making an investment.
You need to understand the outcome.
The best way I’ve found to drive investment decisions with an outcome focus is to have a discussion with the person or people who are proposing the investment, key stakeholders who are impacted by the investment, and the people who ultimately decide whether to make the investment.
I gather those people in a room and write 10 questions up on a whiteboard, leaving plenty of space between each question to write notes and answers.
The questions I like to use come from my variation of Marty Cagan’s opportunity assessment to guide the discussion around why to consider the investment.
Start with the first question and don’t move to the next question until you have agreement on what the need is, or if you identified more than one you know which of those need(s) is the most important.
That need will drive the answers to the remaining questions. So it’s important to settle on one.
I should note that you may run into a situation where you get about halfway through and the group’s understanding of the need changes. If you need to circle back and clarify, do that.
If you structure your discussion this way and get to question 10, you’ll no doubt get some push back that “we can’t decide whether it’s worth it without knowing how much it will cost.”
If you get that push back, reframe the question. Instead of trying to figure out how much it’s going to cost to fix–you can’t know that with any reasonable accuracy at the point when you should be having this discussion–ask how many people will invest.
It’s a subtle difference, but an important one. You’re providing a constraint that may actually lead to a more innovative solution.
Make outcome informed decisions
I’ve had experience with investment decisions very similar to the examples I mentioned above.
I led an organization through a discussion laid out as I described above to discuss introducing a service similar to the express pickup service. By talking through the ten questions, we uncovered that there wasn’t a clear understanding of the need the investment proposer was trying to address.
Once the group determined the need they were trying to satisfy, they determined the originally identified solution would not have addressed that need. The organization ended up avoiding a great deal of work and could focus efforts on other efforts that were addressing obvious needs.
This is the power of outcome informed decisions. Avoid doing unnecessary work before you even start.
How to use outcomes to decide how to deliver a solution
Usually, when you’re asked to deliver something, that ask is fairly specific. It’s usually as a solution to deliver.
Think back to the examples from above.
Recommended by LinkedIn
Each of these describes a solution. They describe output. What you want to know is why the person requesting the investments wants these outputs. You want to know what outcome they are looking for.
You want to know why you’re doing the rewrite.
You want to know why you’re trying to switch the ordering system for a specific customer.
You want to know why you’re introducing an express pickup service.
You want to know what problem you’re trying to solve for each.
You could use the opportunity assessment like I described above, but the results could be a little disappointing when you find out that you aren’t in a position to not do that particular initiative.
Explicitly asking “Is this problem worth solving” when you’ve already been told to solve it might be frowned upon.
So when I’m working on a product where the organization has already decided they are going to make an investment, I find it’s better to use an exercise that helps build shared understanding around the outcome. I like to use the problem statement exercise.
The problem statement exercise helps you build a view of the problem you’re trying to solve that you can use to guide decisions moving forward.
You have your decision filters.
You have defined scope in terms of an outcome, rather than a list of outputs.
You are now able to make outcome influenced decisions to ensure an effective investment. The nature of those decisions varies based on the type of investment you’re doing.
Let’s look at some variations based on the examples described above.
Rewrite only what you need to reach your outcome
System rewrites have gotten a bad rap (somewhat justified) because they often become an exercise in dressing up clunky processes, bad rules, and jumbled up data in a shiny new technology wrapper.
Your product team ishanded an unreasonable deadline, insufficient budget, and asked to rebuild a system. The expectation, whether stated, is that the new system will do everything that the old system did.
You describe scope in terms of all the functionality you have to rebuild in the new product.
Except you probably shouldn’t replace all the functionality that exists in the current system. Some of that functionality is no longer needed. You may take the opportunity that rebuilding the product provides that allows you to revise the process.
Don’t define scope based on a list of outputs you think you need to deliver. Define your scope based on the outcome you intend to deliver. A definition of scope based on outcome allows you to operate in time and cost constraints and still flex within the output you deliver as long as you satisfy the desired outcome.
I worked with a team that used discovery sessions to build an initial understanding of an investment to rebuild an existing internal product. The purpose of that activity was to understand the problem, the environment in which we’re working, and identify how the new solution could address the problem without recreating all the necessary functionality.
We used the results of those discovery sessions, continued discovery along the way, and a constant reflection back on our decision filters to make sure we produced only the outputs we need and to build those outputs in a sequence that helped us learn what other outputs we needed.
Does this solution bring the results you want?
When you want to add more products to an existing ordering system or introduce a new express pickup service, you may not be worried as much about the scope as you are about whether that’s the right solution to your problem.
The way you define scope is not as big a concern as understanding whether the identified solution actually solves the problem you’re setting out to solve, or if there is a simpler, less expensive way.
In this case, you want to be clear with your decision filters and then explore different ways to accomplish that outcome, which may be significantly different than changing the ordering system they use.
This is a good situation to use impact mapping or other techniques to make sure you’re solving the right problem. Look for ways to shorten the feedback cycle so you can try something, see how it works, and identify if it really is the solution you’re looking for. You may find that the solution you end up delivering is quite different than the originally identified solution.
Decide how to deliver an outcome
Just because someone told you to deliver a solution doesn’t mean that you still can’t figure out what outcome people are expecting and deliver that outcome in the most effective way possible. It may just be different than the folks who approved the investment originally thought.
What large product teams can learn from Dropbox
Sean Lynch shared some insights about the framework the product teams at Dropbox developed to keep a growing company on the same page through the product development process.
Sean explains that early at Dropbox, the CTO led the product team and was deeply involved with all aspects of product development - engineering, design and product management. This worked when the team was small but as the team grew, the CTO’s deep involvement became a hinderance.
Product Manager Anand Subramani proposed a three phase lifecycle for each project. Each phase had a review intended to answer a specific question.
Phase 0 — What is the problem we’re solving? Why is it worth solving?
Phase 1 — How are we going to solve that problem?
Phase 2 — What does our solution look like?
Sean found the value in this approach was three subtle but critical features that can help you guide your approach:
1. Clarify the right questions to ask and feedback to provide to a given project at a specific phase.
Having the phases in place made it obvious when a project was too early for a given type of feedback, but also gave leadership comfort that the project would return for that level of feedback when that phase was reached.
2. Separate getting agreement on the problem from getting agreement on the solution.
When you define and get agreement on the problem before proceeding, your team can move forward with much greater confidence that you’re working on the right thing.
3. So simple that it could be adopted by the entire company.
Concise and consistent communication is important to get a large team working together efficiently. The shared, and simple terminology helps everyone at a company understand where a project is in its lifecycle and know how much detail to expect.
Break outcomes down, not initiatives
If you adopt a framework similar to the one Dropbox used, when you’re in Phase 0, follow Ant Murphy’s advice when identifying the problem you’re trying to solve.
Ant suggests a good habit is to break down the problem first rather than the solution. That means take the broader metric and identify smaller metrics that can act as leading indicators that you’re impacting the broader metric.
Ant uses the example of increasing the percent of people who successfully complete an onboarding flow. Start by identifying the flow that customers follow to onboard, and then collect data on the percentage of people left after each step. Then, you can focus on improving the percentage of people who make it through a given step first. Once you’ve made progress on that measure, you can tackle another step.
When you break the problem down this way, you give your team a chance to focus on a smaller problem, which means you’ll address if faster, and you’ll reduce the number of backlog items you have to juggle.
I should note that this approach is appropriate when you’re trying to optimize an existing product. If you’re creating a brand new product, or rebuilding an existing product, it may make more sense to break down the solution.
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent J. McDonald Founder | KBP.Media