The “WHY” behind building products
As product people, we always need to and are expected to understand our users deeply to solve their problems and make their lives better.
But, have you ever wondered - “Why do we do that?”
Most probably not, because obviously we do it as it’s our job, and if the users won’t get what they want, they won’t use it. We need to build products that people love to execute the product roadmap well and to achieve product goals, right?
But, products don’t exist without companies. Product roadmaps don’t exist without business roadmaps and goals.
Any product effort should be aimed at generating a business benefit and every successful product effort is driven by a business need. Successful products have been never isolated from the business.
Now, you might be thinking that if business goals are so important, why even bother to execute the product roadmap, we should directly try to optimize for the business goals.
Imagine if a team really tries to do that. It means that they will most likely lack information on customers and users personas, market needs, value proposition, and competitive products.
This will lead them to building products full of feature that might make them revenue, but in the long term, it will just become a “feature soup” without providing any real value to the user.
That’s why we need product roadmaps that optimize for product outcomes that push the business outcomes.
More about Business Goals
Businesses exist to create a financial outcome for their investors. Business outcomes give executives and investors language to track their progress.
Examples of business outcomes include:
- Grow revenue
- Grow profit
- Grow margin
- Grow market share
Imagine how we are talking about only the outcome - revenue should be increased. That’s our business goal.
What are Product Outcomes then?
Product outcomes are basically things that are in control of the product team and are representation of user’s behavior and interaction with the product. Product outcomes are leading indicators - they measure a specific change in behavior. And leading indicators eventually drive lagging indicators.
Wanna know how?
Okay, let me make it very simple for you. I will even oversimplify.
Revenue is a function of number of users and the average revenue per user. This equation can be broken down further:
Now, in this equation, if we increase the “Conversion rate to paid user” value, it will automatically increase the value of Revenue.
“Conversion rate to paid user” is a product outcome because its value depends on the product and how users interact with it.
The product team can work on the product, change the user behavior and change the product outcome by increasing it. Which will eventually lead them to increase the revenue, hence achieving the business goal.
Product teams responsible for business outcomes need to do the work to translate a business outcome (a lagging indicator) into a product outcome (a leading indicator) that is within their span of control.
Mapping Business Goals to Product Outcomes
Anticipated human behavior is the critical link between the product teams and business outcomes.
Recognizing that the business outcome won’t happen without the product outcomes, which are basically the anticipated change in human behavior is a powerful way to align executives and the unmet needs of the humans (customers, prospects) they want to behave differently.
If the business wants retention to increase, it will only happen when we will be able to change some of the user behavior. And which behavior to change and how much, that comes from product outcomes.
Using a simple metric tree, you can break a business outcome into product outcomes by mapping it to changes in user behavior. For example, subscription revenue can be decomposed into active subscribers × average revenue per subscriber. Active subscribers can then be influenced through activation, retention, resurrection, and conversion.
Build a product outcome tree
Start with one business result, such as increasing monthly recurring revenue. Decompose it into measurable drivers, then identify which driver your product team can realistically influence. Finally, name the user behavior that would move that driver and add a guardrail metric to prevent harm.
A good product outcome is measurable, time-bound, and solution-agnostic. “Increase successful first-week projects from 32% to 40% without increasing support contacts” is stronger than “launch a new onboarding flow” because the team can explore several ways to achieve it.