Decoding "Outcome-Driven" Product Development

Leverage cascading customer > product > business outcomes to align teams and accelerate growth.

This article was originally published with Product Coalition here on August 16th, 2024

Outcome-driven management models and mantras are ubiquitous these days. You’ll find authors and coaches promoting the value of being outcome oriented in business, product management, marketing, education, and even life coaching circles.

A quick Google search yields articles by Harvard Business Review and Boston Consulting Group, books like “Outcomes Over Output” by Josh Sieden, and frameworks like OKR’s and Jobs-To-Be-Done.

In the product management arena, outcome-driven thinking is taught as a core principle of the discipline — see Marty Cagan’s latest book, “Transformed”, as a recent, high-profile example.

An outcome-driven focus is also prescribed by product leaders for specific product activities like discovery and roadmapping — see Teresa Torres’s Opportunity Solution Tree model and “Product Roadmaps: Relaunched” by Lombardo, McCarthy, Ryan, and Connors, as notable examples.

All of this teaching has inspired leaders across countless organizations to endeavor to elevate themselves to a stronger outcome focus.

And yet, countless organizations stumble in their journey to embrace outcome-driven product development. They remain stuck in a “more features and efficiency” output-oriented mentality.

Why is that? The reasons usually stem from a lack of understanding of the different types of outcomes, how they are interconnected, and how to align teams around them.

Why does this matter?

A misalignment of focus and ownership around outcomes can have sharply negative consequences on both the success potential and the culture of a product development organization. Sure, you might get lucky with an output-driven focus for a short period of time, but it’s hard to stay lucky.

On the flip side, the right alignment of ownership and focus around outcomes can dramatically accelerate value creation while fostering empowerment, efficiency, and a more acute sense of business impact across a product development team. This is a durable advantage.

Have you ever wondered or debated questions like:

“What’s the difference between a business outcome and a customer outcome?”

“What is a product outcome?”

“How do these outcomes relate to one another?”

“Who owns which outcomes?”

“How does our customer value proposition and business model fit in?”

“How do we get started with outcome-driven product development?”

If so, article is for you!

1. The Outcome Chain

There are three distinct types of outcomes for a product development organization: customer outcomes, product outcomes, and business outcomes.

These outcomes are joined by specific operating relationships. I refer to these outcomes and their relationships as the Outcome Chain:

There’s a lot to unpack here. Let’s start by reviewing each type of outcome in detail:

2. Customer Outcomes

Customer outcomes involve progress towards unmet needs, unfulfilled desires, problems, and/or jobs-to-be-done. They typically manifest as social, emotional, economic, or intellectual benefits. You might hear customers articulate their realized benefits as:

“I am more empowered to connect and communicate with people”

“I am more confident in myself”

“I made and/or saved money”

“I was able to buy the thing I wanted”

“I know more about my interests and passions”

“I was entertained”

Customer outcomes are owned by customers and experienced by users. These outcomes are the result of their own choices to deploy their limited time, attention, and money.

While customers and users are most often the same people in a B2C product context, they can be different people in a B2B or enterprise product context.

Finally, customer outcomes are ENABLERS of product outcomes via the value proposition of the product.

3. Product Outcomes

You might be wondering: how do products have outcomes? Product outcomes are indeed less intuitive than customer and business outcomes because we don’t typically think of products as being implicitly motivated to pursue their own growth and betterment.

It’s important to recognize that customers and businesses have an indirect relationship through the product being sold. Both customers and businesses make decisions to act relative to the product.

A customer makes a decision to purchase and adopt a product based on its perceived value proposition and the relative trade-offs they face with their time, attention, and money. Similarly, a business makes a decision to build and maintain a product based on its forecast of customer adoption and business success.

What’s more, a realized customer outcome does not directly translate to a business outcome. In fact, a product can be wildly valuable for customers but not generate business outcomes due to a poorly fit business model. The opposite can be true too: a product with a brilliant business model may not see any adoption at all.

So, between a business and its customers lies an intermediate set of outcomes: product outcomes. Product outcomes demonstrate how compelling your value proposition is while controlling for the business model “variable” in the equation.

To put a finer point on the definition, product OUTCOMES are captured as changes in user behavior with the product. They are typically measured by metrics such as adoption, utilization, or engagement. Those metrics may also include sentiment metrics.

Product outcomes are LEADING indicators of business outcomes. In the way that a product’s “North Star” reflects the user’s “aha” moment of value realization, product outcomes are the realm of North Star Metrics.

Finally, product outcomes are transformed into business outcomes via the business model of the product.

4. Business Outcomes

Business outcomes are experienced by the business. They are defined and owned by business owners or the C-suite.

Business outcomes are typically measured with metrics like revenue, profit, market share, and churn. They are achieved through contributions from all business functions: sales, marketing, finance, product development, customer services, and more.

Business outcomes are LAGGING indicators of business and product activity, meaning that they reflect activities that have already happened.

5. Outcome Focus & Ownership

Earlier we established that customers themselves evaluate and own their own outcomes. If a customer’s choice to use or buy a given product does not adequately produce their desired outcomes, that customer will take their time, attention, and money elsewhere.

We also noted that business owners and/or the C-suite owns business outcomes as they hold organizational control and financing over all of the contributing business functions.

That leaves us with product outcomes. An ideal alignment of product outcome ownership is one in which the roles closest to the development of the product, and the value it offers to customers, own product outcomes.

In terms of job functions, that is the cross-functional product development team: product management, engineering, design, and potentially other operationally integrated roles (business analysts, product ops, etc.).

However, a product development team can’t simply build adoption, utilization, engagement, and sentiment. They are beholden to customers realizing their outcomes through the value proposition of the product.

This brings us to the matter of focus, and perhaps the most important takeaway of this article: while a product development team ideally owns product outcomes, they must ensure that what they build (their day-to-day focus) produces customer outcomes to reinforce a compelling value proposition.

"Product development teams OWN product outcomes, and BUILD TOWARDS customer outcomes"

6. Cascading Outcomes

You surely noticed the arrows indicating the directionality between outcomes. I hope this made some immediate intuitive sense.

Simply put, you can’t have business outcomes without product outcomes, and you can’t have product outcomes without customer outcomes. However, with the the right channeling and flow (via the operating relationships described above), each outcome may cascade into the next.

While it’s entirely valid to consider your value proposition as part of your business model (the popular Business Model Canvas includes value proposition as an input), a value proposition can exist without a business model. A value proposition without a business model could be thought of as a gift or a favor.

Charity aside, the two important “flow” principles here are:

1. As each type of outcome builds on the realization of the prior outcome and cascades into the next, the natural focal starting point on the Outcome Chain is customer outcomes

2. It’s not sustainable to move backwards across the chain

What do I mean by moving “backwards” across the chain? Moving backwards means forsaking the impact on customer outcomes and your value proposition for a focus on product or business outcomes.

I will acknowledge that in some circumstances, it is possible (usually temporarily) to exploit things like product dependency, addiction, or high switching costs. However, even those situations are not without ethical implications, negative externalities, or other problematic consequences. Furthermore, it opens the door for competitors to offer a more compelling value proposition.

7. Getting Started: Outcome-Driven Discovery

All product development efforts should be motivated by an opportunity to make progress towards customer outcomes in ways that work for your business.

A product vision and mission should inform the scope of customer opportunities that are relevant to the product and business outcomes you’re trying to achieve. For example, a product leader might task a product development team with accomplishing the outcome: “increase adoption of the Whiz-bang Module”.

The manner in which “increase adoption of the Whiz-bang Module” impacts business outcomes via the business model of the product should be well understood by the product development team and business leaders alike. The Whiz-bang Module strategy should also be informed by insights on why it matters to customers.

Armed with this direction from their product leader, the cross-functional product development team may then begin discovery of opportunities on customer needs, desires, and problems that are relevant and applicable to the Whiz-bang Module.

The following diagram is a version of Teresa Torres’ Opportunity Solution Tree model. You’ll notice that customer value opportunities are organized against a product outcome on top. An expanded diagram might include multiple product outcomes, each with their own opportunity and solution trees below.

This model fits beautifully when the broad scope of customer needs and their relevance to your (existing or planned) products is reasonably established.

Taking a step back for a moment, the process of directing a team’s discovery efforts is also often described as “empowering teams with problems to solve”. Marty Cagan describes that there are two types of problems: customer problems and company problems. In the latter type, company problems refer to impediments to a company’s ability to deliver solutions effectively and efficiently.

Solution enablement is a critical branch of the broader continuous discovery practice. It often takes the form of technical research and proofs-of-concept. It can also include design research into things like human behavior and interaction patterns. In all cases, it should be motivated by opportunities to make progress towards customer outcomes.

However you frame and model discovery, the overarching objective is for product development teams to be able to perform rapid and relevant discovery of opportunities to serve customers in ways that also work for their business.

It may be the case that insights from discovery invalidate the product outcome and/or reveal an opportunity for a new type of product outcome (or anew product altogether!). This is the process working!

Lastly, I’ve alluded to the continuous nature of discovery several times, and I think it’s worthy of a call-out: as the landscape of customer needs, your own products, and competing solutions are constantly changing, discovery only remains relevant if it’s a continuous journey, and not a point-in-time activity. Dare I say it’s the only (almost) free lunch!

8. Getting Started: Outcome-Driven Roadmapping

In parallel to their continuous discovery activities, a product team may develop a strategy that encompasses the pursuit of multiple (hopefully synergistic) outcomes. For example, “increasing adoption of Whiz-bang Module”, in addition to “reducing setup time on the core Super Solution”, may have the combined effect of also reducing customer churn.

A multi-outcome product strategy can be represented as an outcome-driven roadmap that might look something like this:

Here’s a primer on outcome-driven roadmapping:

1. An outcome-driven roadmap should tell the story: “what customer-centric outcomes are we going to pursue to compel changes in user behavior relative to our product and/or improve our ability to deliver solutions effectively and efficiently?”

2. Phrase outcomes as [Action verb] [Value-added user benefit/result]; action verbs could be words like “accelerate”, “improve”, “streamline”, “reduce”, or “optimize”. Words like “implement” or “support” are ok as long as the outcome described is feature agnostic

3. Themes can be framed as key “focus” or “investment” areas, but be sure not to lose the context of customer needs

4. The accompanying product roadmap narrative should include the relative customer personas and highlight “why?” problem context

5. This is not a feature delivery plan!

9. Iterating Towards Success

Agile and Lean methodologies emphasize incrementality, experimentation, and responsiveness. These methodologies shine in complex, ever-evolving product development and market environments.

Thinking about agile and lean methodologies through the lens of the Outcome Chain illuminates two distinct milestones: Minimum Valuable Experience and Minimum Viable Product.

Product development organizations face a natural temptation to expedite shipping an iteration of product in an urgent (and sometimes desperate) desire to get the wheels of business turning. However, shipping code/product is an expensive way to test your value proposition, aka your product-market fit.

Before you jump to a Minimum Viable Product based on assumptions of customer desire and willingness to pay, focus on validating a Minimum Valuable Experience with your customers. There are many ways to test experiences without writing a single line of code.