Defining outcomes as a product team

Product teams should be focussed on delivering outcomes. 

In this post we will discuss how a product team can define outcomes and then ensure epics/features (outputs) are tied to outcomes.

Hours taken is not an indicator of value

As digital project delivery has developed from waterfall methodology, through the many flavours of agile to the current state of lean, so has how we measure the throughput, quality, and overall ‘fit-for-purpose’ of the digital products made.

In traditional manufacturing processes, the final product was a tightly constrained and predictable output. This means that a simple method of measuring (admittedly a single dimension) output was the number of hours invested into production. 

With digital engineering, it is quite likely for the number of hours invested in a single aspect of a product to vary wildly due to the number of constraints, dependencies, and influences from elements that are sometimes out of the control of the project team.

So without time as a measure, we need to view project outputs using different measurements.

Outputs are meaningless without context

Given free reign, most digital engineers will build what they like to. It’s part of human nature to operate within an environment where we feel safe, confident, and comfortable. Our ‘productivity’ will be as high as possible when we’re reproducing known solutions or re-purposing a product that’s proven, tested, and reliable.

This looks great then, the digital engineers are beavering away producing lots of output, at pace, with few issues and it all works (doesn’t break). However, this output is directionless. We will, at the very least, be creating a product that will be cumbersome, onerous, or even unusable by the end-user.

Moving from outputs to outcomes

So far, I’ve postulated that time is taken and the amount of ‘stuff’ produced has far less impact on the success of a project than assumed. This doesn’t mean that they shouldn’t be measured during a project, however, they need to be defined against a far more important measurement: the value of the outcome.

“Output is the amount of something produced, whereas an Outcome is the way a thing turns out.”

A change in terminology enables us to shift the entire focus and direction of a project team from an outdated 18th-century manufacturing metaphor to a principle that is aligned with how digital engineering is best approached.

Consider the review of a single component of a project that has just been completed. It is the output of a collaboration of designers, engineers, testers, etc. Thinking of the component as an output, we can determine that it has taken an amount of time to produce, it is of predictable quality, and that it will integrate into the intended environment with minimal issues.

Now let’s consider the same piece of work as an outcome. By producing this component of the product, it’s now possible for an action to be achieved by the end user, an amount of effort to be reduced, or an issue we identified to be fixed.

Why is this distinction valuable? In an engineering environment where anything, within reason, can be built, the stakeholders will have an aspirational view of what can be achieved. Put simply, teams will always be challenged to build more than they can within the time and/or budget available. Using outcomes to determine value allows the team to determine what should be built, in a way that outputs (time and volume of production) cannot.

Outcomes are synonymous with value

As mentioned before, the outcome is the way a thing turns out. So the team needs to know how a thing should turn out before they build it. I’m not asking for the team to predict the nuances of engineering detail that they will use to produce an outcome.  As an alternative, I’d ask them to be aware of how the component they will build will be used and how it will affect the end-user experience.

Before anyone accuses me of only being able to consider ‘end-users’, anything we build that interfaces with another service (be it human or digital) can be referred to as a user.

The value of an outcome is usually measured (ranked) against the value to the business (the client’s institution) and the value to the user. This moves us to some preparation that the entire project team must undertake to ensure the value of the outcomes and from the project as a whole.

Proper planning prevents piss poor performance

This is the core of user first/ outcome driven/ value-driven/ lean engineering methodology, or what you like to call it. Planning in this context is not the cumbersome collation of stale information into impenetrable documentation. Instead, we agree as a team to collaborate on a few exercises that will enable us to build the right thing quickly.

North star/Business vision/Business goals

Various schools of thought and workshop exercises use different terminology, but the key element for any project is an agreed direction of travel. This can be described as a value statement, a series of objectives, an elevator pitch, or a hypothesis statement. The format is less important than the overriding fact that the entire team knows where they are going and why. 

With a North star in place (my current favorite term), we now have a tool that enables us to measure the value of anything the team proposes to do with their time on the project.

This has to be done at the beginning of any engagement. It’s a challenging outcome to craft, especially, when a team consists of strangers, trust is low and many will be exposed to new working practices. I’d like to be able to demonstrate a prescriptive workshop sequence that magically delivers this outcome. The reality is that we need them to be brutally frank and honest about their goals, and to share this openly with strangers.

A pragmatic north star is a single measurement that we can use to rank all team effort. You’ll note I’m no longer expressing measurement in the abstract, I’m using it to rank project elements against one another.

A reasonable North Star could be “the number of digital interactions per user.”

What’s cool here is that we’re not dealing with the minutiae of user sign-ups, dwell time, journey, failure rate, etc. Instead, we’ll measure their interactions. Devil’s advocate could suggest that a frustrated user could endlessly ‘interact’ with the service without achieving anything of value, so I’m not suggesting the live service only has a single measurement.

The user goals 

The end-user, whether human or other digital services, is the reason the product is being built. It may sit within a legal or regulatory requirement, but these are vehicles for encapsulating a user’s need. The craft of discovering and documenting user goals is beyond the scope of this post, but the outcomes from this exercise are the principal way we determine what we should build.

We like to describe user goals as ‘user stories’. These are beautifully crafted works of art that Business Analysts spend decades perfecting on misty mountaintops as Haikus that conform to the meter of: negotiable, valuable, estimable, small and testable.

At the coalface of a 20-week project working under COVID-19 restrictions, we’re more pragmatic. A user story fits on a rectangular post-it note when written with a blunt sharpie, preferably in legible handwriting. 

The value they have is that they describe a manageable chunk of value to the user. With enough of these written, we can prioritise them against the north star using the team’s knowledge, any domain experts we can persuade to attend.

The end of the beginning

We’ve not written a line of code yet, so many unknowns remain to be discovered. We’ve spent as little time as possible doing this, so we can optimistically reckon on having missed 20% (Pareto principle) of the user needs. We’re also aware that pivots are likely to occur, such as a global pandemic, which will affect the project. 

However, we have a strong direction of travel and a backlog of user stories that are prioritised. 

Given the cyclical nature of agile development principles, we’re able to return to our original assumptions regularly and evolve it to meet emerging needs. One legitimate criticism of agile development is that it can lose direction, as all goals are short term. However, with a North star in place and an understanding of how to use it, the direction is strongly defined.

Final thoughts

I’ve skipped over lots of details. There are dozens of workshop methods, diagrams, and structures that make a methodology like this work, so please believe that there are no ‘leaps of faith’ required. 

In summary, a project is an expression of a need. They’re normally couched in the language of the organization that identified the need. It can take a great deal of unpacking and discovery of the ‘world’ where the project resides, however by helping the project team to collaboratively discover, identify, collate and rank what they should do, enables them to perform effectively and happily.

About the Author