Contact
Building features is easy, making a real impact is hard. At Hike One, we like to apply the habits of Continuous Discovery to build products that really make a difference. Let's take a look at how to set meaningful product outcomes, so that your product team can start connecting leadership’s goals to what your users need.
Many product people struggle to define product success. Is a product successful when it makes users happy? When it brings in a lot of money for the business? When it is delivered on time and within budget? When all the features that were on the roadmap are in the release?
At Hike One, we deem a product successful when it solves user problems in a way that works for the business. It’s not about features. It’s about impact, in the long run. It’s successful if we manage to bring more and more value, every release, again and again, to the user and to the business. We don't care so much about time-to-market, we care about time-to-value.
A product team’s job is to always create value for the user and in turn create value for the business. We like to apply the habits of Continuous Discovery to cultivate this product mindset, and build products that really make a difference.
Continuous Discovery is defined as weekly touch points with customers by the team that’s building the product, where they conduct small research activities in pursuit of a desired product outcome.
The paths we may take to reach our desired outcomes are charted in an Opportunity Solution Tree. It connects what a product team is doing to the company's goals. Since outcomes are the root of the tree, defining them is the first step—and often the hardest, even for seasoned teams.
To deliver value, we need to focus on outcomes, not output. An output is what we build (features, mobile app, integrations, etc), whereas an outcome is the impact of what we build.
When you focus on output, you're just looking for confirmation: we're building output X because we think it will result in outcome Y.
The real value of thinking in outcomes is that your starting point is a problem to solve: we're going for outcome Y, how might we get there? Your answer might be ‘build output X’ but your answer might also be ‘don’t build anything at all, and remove previously built output Z’.
If you're in a so-called feature factory, where you’re told to deliver specific features because they’re on the roadmap or because your boss wants them, shift the conversation to outcomes. It will help you make a compelling business case for solving real user problems with solutions actually worth building.
There are two types of outcomes at the root of an Opportunity Solution Tree, which we will unpack in order to translate high-level business goals into actionable product outcomes.
A business outcome measures if the business is moving forward, whereas a product outcome measures if the product is moving the business forward.
A business outcome is defined by leadership. It's typically a financial metric or something that measures progress against a strategic initiative, such as to increase profit or decrease churn. They are lagging indicators, which means they happen after something else. A business outcome usually consists of several components that we can’t all influence as a product team.
A product outcome is a user behaviour that occurs within our product and that we can measure, such as accounts created or time spent to complete a task. They are leading indicators, which mean that they are driving the lagging (business) ones. A product outcome should be within the influence of the product team. The business and the product team define product outcomes together.
You can integrate outcomes into your way of working—even if you've never tried Continuous Discovery before or if you're stuck in a feature factory. Get started by organising a workshop with key stakeholders and product team, and go through these four steps together.
Ask business stakeholders to explain your company’s desired business outcome and any relevant context (market, recent developments, strategy, etc.) to the product team.
If your company wants more profit, the simplest way to break that into components is revenue minus costs. The formula you come up with doesn’t have to be a perfect representation of reality, it just has to clarify any relevant components the product team might be able to have a meaningful impact on.
The format we advise for writing down product outcomes is:
− [increase / decrease] %
− of [user type]
− that [shows behaviour]
You can play around and make it more specific—figure out what is helpful for your team. For example, add frequency (how often per time period) or efficiency (how fast):
− [increase / decrease] %
− of [user type]
− that [shows behaviour]
− per [time period]
− and achieves success under [amount of time]
Make sure you walk out of your workshop with three possible impactful product outcomes. Afterwards, you can estimate which user behaviour will have the biggest impact on the desired business outcome, either with real data or with hypothetical scenarios.
Only after defining the desired business outcome and the most impactful product outcome, explore the problem space by uncovering opportunities. Then, explore the solution space and find out what you might build to create value for customers, in a way that also creates value for the business.
If you're struggling to define outcomes, or with any of the other Continuous Discovery habits, apply to join our Beyond Design community. We regularly host webinars and events for you to learn from experts in the field and share experiences with peers. Or give us a call for a custom approach.
Feel free to contact me!
