Outcome vs Output


What are the KPIs we should measure for a team to be considered successful? We usually fall in the trap of measuring how fast a team delivers features, often called team velocity, but at the end of the day, does it really matter when a team releases functionality that nobody uses? This is an example of what differentiates an output versus an outcome.

For a company to be successful, what matters is the measurable outcome of an effort, and for a team to get there, it is important for this to have been defined from the beginning. One way to achieve this is to set the expectations of Minimum Viable Products (MVP) and in the agile world, functionality is built upon MVPs in order to test the waters and iterate, either by shifting direction, adding functionality or abandoning a plan.

Minimum Viable Products

When the Product Squad is shaping up Missions, it is important to set some expectations in terms of Return-Of-Investment (ROI). When defining MVPs, they should be clear what is the expected outcome, which usually falls into one of the three categories below.

The Successful MVP

When is team is working on successful MVPs, they put their efforts by defining an expected ROI, such as revenue or customer retention. They communicate with customers, understand their needs, they probe the market and they put the effort required to make this a successful journey.

The Experimental MVP

Sometimes it is important to test the waters and learn. These are experiments, usually short in effort in order to gather early feedback, understand the userbase or check if an idea could have the potential to take off.

The Bad MVP

This is the worst case scenario, where a deadline is put in place, and the team delivers an output. It is the place where bugs, technical debt and low quality are borned.


This is a list of examples that differentiates an outcome vs an output.


  • A goal was met
  • A hypothesis was validated
  • An investment was returned
  • Customer retention was improved
  • A feature is used by X customers


  • Developers built a feature
  • Team velocity increased
  • Release cycle time increased
  • Kanban flow reduced waste
  • X number of defects were addressed