Understanding the difference unlocks what “Software Value Delivery” really means
“I’m just going to brute-force this and ship everything by the first quarter.”
An experienced IT manager recently shared how he was getting pressured by leadership to deliver a set of features and technology implementations by a specific date through Agile teams. But no one could tell him what those features were supposed to accomplish. And the Agile teams about to be “brute-forced” knew even less. Not the best start for effective delivery.
Understanding Outputs, Outcomes, and Impact is the key to unlock what stakeholders really want and get Agile teams to step up and deliver work that matters.
Outputs
“Outputs” are the things teams make. Whatever they create, it’s an Output:
- Output: Redesign new login form
- Output: Build new microservice
- Output: Deliver training
- Output: Define use case
(Note that in the above list, “activities” are italicized.)
Everything in project-focused IT delivery stops at Outputs & Activities
IT managers have been traditionally rewarded for getting teams to deliver Output on time, on budget, keeping everyone busy the entire time. But just shipping more stakeholder “stuff” faster and keeping people busy won’t guarantee the business succeeds. Research by Microsoft uncovered that stakeholder-mandated solutions either failed to deliver any value or had a negative impact on their business anywhere from 60% to 90% of the time.
Managers need to shift from this pure focus on Outputs to the next level.
Outcomes
Outcomes are the actions customers take with the Outputs teams create.
In what ways will their behavior change, what will they be doing differently once they’re using what we’ve given them? Everything can be thought of in terms of increasing or decreasing an existing behavior we’re trying to change:
- Output: Redesign new login form >> Outcome: Increase successful customer logins
- Output: Build new microservice >> Outcome: Increase teams’ secure development speed
- Output: Deliver training >> Outcome: Increase manager’s support of Agile teams doing experimentation and iterating based on learnings
- Output: Define use case >> Outcome: Decrease risk by learning which application of our technology will be most helpful to our target persona
Impact
Impact usually boils down to either Revenue ($) or Sentiment (NPS).
As a result of interacting with our team’s work, and having customers taking actions in the ways we hope, will that result in either more money for our company, reduced costs, or our customers speaking positively about our company (alwaysthe most powerful & cost-effective marketing possible)?
- Output: Redesign new login form >> Outcome: Increase successful customer logins >> Impact: Reduce users leaving our service (“churn”)
- Output: Build new microservice >> Outcome: Increase teams’ secure development speed >> Impact: Decrease cost to build secure applications
- Output: Deliver training >> Outcome: Increase manager’s support of Agile teams doing experimentation and iterating based on learnings >> Impact: Decrease cost sunk into stakeholder-mandated “boondoggle” solutions
- Output: Define use case >> Outcome: Decrease risk by learning which application of our technology will be most helpful our target persona >> Impact: Increase revenue sooner
Ultimately, these are all just hypotheses
We can’t know what customers will do with our team’s work ahead of time.
This is why everything in everyone’s backlog is a hypothesis. The goal is to move away from mandating the Outputsthat teams deliver, and get business stakeholders to focus on what Outcomes the work is supposed to drive, and support teams to use the process of Discovery to uncover the best path to drive the right Outcomes and Impact through better Outputs.
What you can do as a manager
Managers can either enforce top-down delivery, or help in two different ways:
- Get stakeholders to refocus on what customer Outcomes they need to drive, with resulting business Impact they want the teams to contribute to
- Get teams to work backwards from Impact through Outcomes and have a hand in negotiating improved Outputsthrough running better Discovery
Remember that product management is the crucial competency to connect Outputs to Outcomes and Impact, and guide the crucial Discovery process — make sure you have experienced product people leading the teams.
Understanding the mental models underlying these terms means seeing how business value really gets delivered, and giving teams the opportunity to get out of “factory” delivery and challenge themselves to deliver better work.
Where to learn more
Watch this short video (~10 minute) by Jeff Patton for a walkthrough of Outcomes & Impact, and why we want to minimize stuff and maximize Impact
Next, watch this video (25 mins) from Josh Seiden on how product management connects Outcomes to Impact.
Finally, Josh Seiden’s excellent “Outcomes Over Outputs” is a great short read you can finish in a day that will help deepen these ideas.