Outcomes Over Output

An outcome is “a change in human behaviour that drives business results.” Outcomes have nothing to do with making ‘stuff’ – though they’re something created by making the right stuff.

Outcomes are the changes in the customer, user, employee behaviour that lead to good things for your company, your organisation, or whoever is the focus of your work.

Features are outputs, solutions have outcomes.

Organizations need to embrace the goal of building as little as possible to solve the problem at hand. Intuitively, this makes sense. You’d obviously rather invest $1M solving a problem than $5M.

Once we realize the goal of building as little as possible, we can orient our planning process around building less.

Engineering managers and product managers pride themselves on delivery. Did the thing get built on time, on budget, on spec? That’s how we judge our own performance and also how our managers typically judge us.

Instead, we should be measuring ourselves against user and customer behaviour changes. Email open rates, user interactions, account creations, and the like.

Instead of building plans around outputs or features, it often makes more sense to plan around themes of work, problems to solve, or outcomes to deliver.

A leader has to coordinate with internal teams(like support) for input and shift the conversations about features to conversations about problems and the possible solutions.

In place of big bang product releases, a leader has to focus on creating specific, smaller customer behaviours that drive business results. You can create new behaviours or focus on existing customer behaviours (e.g. opening emails or sharing images). This could in turn help increase the lifetime value of those users, which is a measurable business result.

The customer-centric company's highest priority is to satisfy the customer through early and continuous delivery of value.

For example: Enabling users to create a music playlist, so that they can find their favourite music easily. 

An MVP is NOT version 1.0 of your product. It is the smallest thing you can create to learn if your hypothesis is correct. Agile products begin with a series of hypotheses and experiments, designed to achieve a specific and measurable outcome.

How do teams determine the right outcomes to concentrate on?

Firstly, they ask: “What are the customer behaviours that drive business results?” and set an “impact level target”.

Secondly, once the impact level target has been defined, they can then ask “what are the things that customers do that they predict they’ll visit our site?”

The focus is on observable and measurable outcomes.

The Magic Questions that we can all apply when figuring out the right, measurable outcomes to concentrate on: 

• What are the user and customer behaviours that drive business results? This is the outcome that we’re trying to create.
• How can we get people to do more of these behaviours? These are the features, policy changes, promotions, etc. that we’ll do to create the right outcomes.
• How do we know that we’re right? This uncovers the dynamics of the system, as well as the tests and metrics we’ll use to measure our progress.