On Building for Outcomes…
I joke with my trainees that 3Pillar knew outcomes over outputs were cool before they ever were. They have been part of our Product Mindset from its inception nearly 16 years ago. However, things have changed as the industry around us has evolved. Our understanding of outcomes has changed and matured.
In the early days, outcomes were always business-focused — revenue, adoption, retention etc. As a young product manager, I struggled with this because revenue was not always the main goal for the products I worked on. Moreover, some products were focused on more internal-facing factors like operational efficiency. It always felt like a bridge too far to be asked to “build for outcomes.”
It wasn’t until I read Josh Seiden’s book, Outcomes over Output, that I started to really understand the differences and power of outcomes. The more I dug, the more I saw key product influencers coming to the same conclusion. Teresa Torres talks about it in her Continuous Discovery Habits work; Jeff Gothelf calls it out in several articles. There are different outcomes, and they should align with one another. It totally started to make sense now.
Not one to leave well enough alone, I continued to ponder and try out a few concepts through our Product Mindset training and finally arrived at a place that feels right regarding the different types of outcomes.
In the Product Mindset, there are three types of outcomes when building a product — and they are reinforcing concepts!
Let’s break this down!
The business outcome is a metric that moves the business forward and focuses on what we want to achieve from a business point of view, generally defined by Company Leadership. It revolves around the “pirate metrics” of acquisition, activation, revenue, retention, and referral. The Product team has a non-direct Influence on it.
Customer/User outcomes are specific to users of the system and outline what is success to them. We have to talk to them to figure out what this might be, and knowing this helps drive what our product should do/achieve. This isn’t just the problem we’re solving but the resulting behavior change that happens by solving that problem that creates value.
The Product outcome is a result we want to achieve that solves the users’ problem while creating business value for our organization. Product Teams directly influence them as they are the ones to define and manage them after considering the user and the business.
Historically, in training, we focus on Business outcomes when actually our teams should concentrate on product outcomes. But what’s more, we should be concerned with all three! They are a self-perpetuating relationship — Business should inform product, and product can help achieve business, but without understanding the customer outcomes — none of this really matters.
Understanding Outcomes
Outcomes can be hard to understand if you’re new to the concept. Essentially they are behaviors we want to impact or change to achieve success and create value. They are supported and measured by OKR or other metrics.
So, what do good product outcomes look like? Let’s explore using the example of a birthday cake.
You head to the store and order a custom-made cake. Many would assume the cake is the outcome as the main objective of the task is to buy a cake, but that isn’t quite right. The cake is actually the output. It is a part of the puzzle that comes together to form the outcome: a delighted child on their birthday. Keep up the streak of great birthdays, and you’ll find the impact is a great childhood.
Now, back to technology examples — let’s look at a few possible product outcomes that tie back to a business outcome:
- Increased customer satisfaction (which ties to retention and referral goals)
- This one is incredibly broad and possibly too broad to be an effective outcome but can be used in the right situations.
- Faster time to customer reimbursement after an accident (for insurance companies, for example). Again, ties to retention/referral.
- Increased average cart size for a retail customer
Remember — the litmus test on this is being able to use this outcome statement to evaluate if a feature or set of features should be in or out of consideration. It helps combat the HIPPO (highest paid person opinion)
Outcomes and B2B
For b2c products, it’s often easy to identify outcomes because we’re talking directly to the consumer and can understand and then influence their behaviors. Satisfy them, and theoretically, our business outcomes are impacted. But in B2B organizations, you face the user vs. the buyer conundrum — whom do you satisfy? Unfortunately, the answer is likely both.
Let’s use operational efficiency as an example to dig into this problem.
The buyer wants to improve operational costs for his business and is evaluating your product. One way to do this is to make it easier/faster/cheaper for his people to do their job when they use your software. Theoretically, if you can increase efficiency, you increase throughput without increasing staff numbers, which will impact your business goals of improving operational efficiency.
The product outcome is focused on serving the user of the product but has to consider the goals of the buyer in his purchase decision, and you, as the product manager, have to consider your own business outcomes!
What other examples can you think of?
