Outcomes Over Outputs: Set Yourself Up for Success

In the world of project management, outputs — what you produce in relation to what you planned to produce and the metrics for measuring how efficiently you did so — have long ruled the definition of success. You intended to design and build a functioning widget in three months at the cost of no more than $1 million, and you successfully did so. You now have a functioning widget in hand.

But what if your customer doesn’t want or need a widget? Or, what if the widget you built is the wrong size, shape, or color? What if the price you’ll need to charge for the widget is twice what your customer is willing to pay?

Was that really a successful project?

These questions highlight why many organizations have shifted their focus from outputs to outcomes in recent years. Here’s why your organization should consider doing the same and how you can start down that path.

Products Versus Projects

While this article isn’t focusing on the Project-to-Product conversation, the two topics share a lot of context in common. If you’re not at all familiar with P2P, you can get an excellent primer in our white paper, Project to Product: Build the Right Thing the Right Way, and the free webinar-on-demand, Project to Product Thinking: Unlocking Product Agility.

Outcomes Versus Outputs

There are fundamental differences between pursuing outputs and outcomes.

Outputs

As noted above, outputs are measurable things you’ve planned to produce and metrics around how you produce them. Typical outputs in traditional project management include physical items manufactured, software features developed, or qualified leads captured. And, standard metrics include schedule/timeline, budget, and efficiency or throughput.

So, when a big project is planned, the project manager will usually be tasked with producing XYZ within X number of months at a budget of no more than X number of dollars. Then, when XYZ is built, there’s a celebration. Months-worth of work is finished, and the team can check it off the project list. The celebration is even bigger if the project is done within the set schedule and under the budget. If it didn’t, the reasons might have been unforeseen complications or challenges beyond the company’s control, or it may have been a problem with the initial plan.

That’s where traditional project management tends to fall short: it requires thorough, in-depth planning at the start based on information available at the time and projections about an uncertain future. Then, once the project parameters have been set, “success” is all about completing the project as planned. Changes to the project parameters are avoided at all costs. And, as a result, the main goal of everyone involved in the project has to be completing the project.

Or, in other words, producing the desired output.

Outcomes

Unlike an output, an outcome is not an easily quantifiable thing that marks the end of a project. Instead, an outcome is a desired state created by the work being done by those involved. In some cases, the difference is subtle.

For example, a project output set before a group of software developers may be “create a two-click login sequence for returning customers to access their accounts.” The plan for producing that output would likely include a rough idea of what those two steps would look like and how they would interact with or replace the code behind the current login procedure.

On the other hand, an outcome under the same circumstances might be, “refine the login process so existing customers can log in to their accounts as quickly and seamlessly as possible.” Why is this preferable? Because without the upfront plan specifying the output so strictly, that team of talented developers can concentrate on what the customers want in their login experience. Maybe customers can log in in half the time with just one click. Or, maybe three clicks is satisfactory because it establishes a more comfortable level of security that the customer truly values.

Additionally, working with an outcome in mind is far more conducive to agility. Although they may define an outcome to the extent that those developers were focused on a particular feature set, the underlying state they’re pursuing is and always will be customer satisfaction. So, suppose the feedback indicates that customers are happy with the current login experience but would love to see another feature developed or refined as soon as possible. In that case, the teams can pivot without feeling like the work they’d started on was a complete failure. They can also produce, release, and begin gathering feedback on incremental steps toward the desired outcome rather than putting months of effort into an output that may very well turn out to be something customers aren’t excited about.

So, if you’re currently running an Agile development organization, but you’re establishing outputs in a project management framework, you’re not as agile as you could be.

How to Define and Measure Success via Outcomes

There is one more vital factor to consider when discussing outcomes versus outputs. As noted above, outputs are much easier to quantify than outcomes. Knowing how many widgets you’ve made, how quickly, and at what cost is far easier than determining how your customer feels about your widgets.

But, there are ways to measure success when working with outcomes rather than outputs.

Some examples of metrics that can measure success are increases in product usage and other indicators that customers are recommending or highly rating a product, feature, or service (such as the popular Net Promoter Score). Keeping that constant feedback loop open and operating is key to collecting the data necessary to put together numbers and trends that measure success.

Outcome-based roadmaps define success fundamentally differently from output-based roadmaps. Success is based on the value added for the customer. It becomes about problems being identified and solved so that customers feel heard and are satisfied with what’s being produced.

Of course, none of this means planning goes out the window. Many of the same project management and planning skills required to produce outputs are still applied to carry out the practical aspects of shepherding the work along, scheduling, allocating resources, and budgeting when pursuing outcomes. That’s why so many talented project managers can effectively move into product management with minimal learning curve required.

To learn more about planning with a product mindset and outcomes in mind, tune in for our free upcoming webinar, From Project to Product: Don’t You Dare Mess with Planning.

What’s Next?

If you’re pursuing enterprise agility and trying to establish a product mindset, moving from outputs to outcomes is a crucial component of success in that endeavor. Dive into the resources linked in this article, and if our Product Agility experts can help you in any way, we’re just an email or phone call away.