Outcomes vs Outputs

Has it ever happened to you that, even if you deliver features and mark activities as completed, there is no direct impact on the critical metrics of your business?

“Mistaking ‘making stuff’ for making progress, and mistaking shipping features for being done.” ― Joshua Seiden.

In my experience, the key is in the roadmaps. In them, the leaders usually deliver both the list of functionalities and the delivery deadlines. In this way, the team focuses only on execution—the success metric being its productivity—and loses sight of the result for the user and the business. Doing this makes it difficult for teams to understand the expected impact; it is not possible to propose a better solution; there is no room to experiment or make mistakes, and all of this complicates the relationship between the activities that are carried out and the results that are expected from the business.

Joshua Seiden, a successful strategy consultant, mentions that leaders and the people who do the work tend to define value at different levels of specificity. Thus, while leaders think about impacts, execution teams tend to think about resources, activities, and outcomes.

However, this situation can change if leaders improve communication in terms of outcomes, that is if they are more clear, direct, and specific with what must be done and what is expected. For example:

If the goal is to increase the sales of an online store, then we are talking about the impact. The execution team will know it can achieve this by increasing the average order price. That is the outcome. To achieve this, they consider implementing a section that says, 'Customers who bought this product also bought…'.

To do this, Seiden proposes a logic model based on the results:

The Project Logic Model by Josh Seiden

In the online store example, the logical model would look like this:

  • Impact: Increase the sales of the online store.
  • Result: Increase the average order value (AOV).
  • Output: Add a product section that says, 'Customers who bought this product also bought…'

This allows teams to better understand the expected result, measure whether the result was achieved, or iterate until it is achieved.

Now, for leaders in this situation who want to close the gap, Joshua Seiden proposes a series of questions to identify the results:

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

It is a great challenge for leaders to change from using measures of success based on productivity, to using measures of success based on outcomes. However, if you want to have a direct impact on key business metrics, it seems to me that we must insist that teams plan in terms of outcomes, and I consider it essential to ask ourselves, “Why are we doing this?” and “What are we trying to achieve?”