In order to optimize for Better Value Sooner Safer Happier in the context of product development, there needs to be a shift from fixed, big, up-front designed solutions to outcome hypotheses with experimentation. There is a pivot from output to outcomes, from following a fixed plan to maximizing value.
Key considerations:
1: Emergence
Product development is emergent; the work is unique and unknowable. Organizations are complex adaptive systems; they are not predictable. We can’t accurately predict what people want, how to build it, the obstacles we’ll come across on the way, or how external market forces will change over time. We cannot travel in time and see the full path ahead
That said, empowered teams need a clear ‘North Star’, a clear mission. It provides alignment and direction. For this type of knowledge work, that mission should not be articulated as a fixed solution or output by a date with predetermined tasks.
A ‘Business Outcome’ is an articulation of business value in the form of a hypothesis, a bet, as no one knows for sure what’s going to happen. Insights can be gathered; however, the only way to know is by doing. The system of work should be optimized for fast feedback, safe-to-fail experiments, and psychological safety in order to test the business outcome hypothesis early and often. Importantly, value should be from the perspective of both the consumer and the producer.
2: Nested Outcomes
A quarterly time period is neither too close nor too far. It is just beyond our knowledge threshold and yet not too far away. Each quarterly business outcome consists of monthly ‘experiments’ to test the outcome hypothesis.
These are in turn broken down into ‘user stories’ (the smallest item of potential value), which are daily and optionally turned into hourly ‘tasks’. Ideally, there are frequent (daily or weekly) releases of value into the hands of customers. It should not be a case of the first deployment being at the end of the quarter. This provides the fast feedback loop that enables learning, insight, and the ability to pivot. It provides fast feedback on multi-year strategic intent, enabling increased business agility.
Traversing up the outcome hierarchy, the quarterly business outcomes are grouped into a handful of annual outcomes. These are also articulated as outcome hypotheses. This is starting to get into strategy alignment. Annual outcomes group into multi-year outcomes, which are business-unit level strategic items. For larger firms, these are contained within a handful of strategic objectives, a top-level, strategic intent that spans the organization. It is important to note that Outcomes should not be cascaded top down. There should be alignment, not a cascade. That is, teams and teams of teams, determine their own Outcome hypotheses, in line with the Outcome it is nested within. It is bottom up and top down, iterating, refining, informing, with a regular cadence of reflection and acting on learning
This structure of nested outcome hypotheses is incredibly powerful. With tooling to make the structure transparent across the organisation, someone can be working on a two-hour task and click up the outcome hierarchy to see how their task aligns to one of a few strategic outcomes. Those closest to the work are best placed to innovate about how to achieve the desired strategic intent. There is strategic alignment.
Rather than eat the elephant in one go, aim for carpaccio. Aim to get the thinnest vertical slice of real value in the hands of real customers. This de-risks delivery and maximizes learning, providing fast feedback on strategic intent.
3: A Business Outcome
Articulating unique product development work as outcome hypotheses creates a clear expectation that it is a hypothesis and may be invalid, and that there are unknown-unknowns that will only be uncovered when the work takes place. It also creates a clear expectation that experimentation is required, with people empowered to use their own brains to discover how to best achieve or even if the outcome hypothesis is worth continuing trying to achieve.
You can write an outcome hypothesis like this:
Due to <this insight>
We believe that <this bet>
Will result in <this outcome>
We will know that we’re on the right track when :
Measure 1: quantified and measurable leading or lagging indicator
Measure 2:
Measure 3:
Example
To aid the writing of business outcomes a canvas could be used, such as the example below:
Importantly, to reiterate, this is a hypothesis, and the value is articulated with the leading and lagging measures that are relevant to customer behavior, citizens, and/or the climate so that it’s not at any cost to society or the planet. The business outcome measures are not the completion of testing or the implementation of an IT system, which is a means to an end. They are the definition of business value.
Over time, as mastery increases, consider writing business outcomes as moonshots, as stretch goals. Traditional objective setting tends to lead to mediocrity, to under promising in order to over achieve the goal. Instead, achieving 60% to 70% of a business outcome is doing well. Achieving 100% regularly is not thinking big enough. To quote Google’s “Ten Things That We Know to Be True”: “We set ourselves goals that we know we can’t reach yet, because we know that by stretching to meet them we can get further than we expected
Swapping fixed milestones on fixed solutions for outcome hypotheses changes the question. Instead of constantly asking, “Is it done yet?” we ask, “What value have we observed, what have we learned, and what steps shall we take next to get closer to the desired outcomes?”
Learning resources:
If you found this article useful you might be interested in additional Sooner Safer Happier learning resources on this topic
Organising for Outcomes Simulation Event
by Jon Smart, 11/10/22