Skip to main content

Inputs, Outputs, Outcomes

A Practical Framework for Managing Performance​

The Big Picture

This tool helps diagnose what kinds of things are impeding outcomes and where to focus efforts. Can be used on individual performance challenges, business performance, or even to debug technology challenges.

You can use this "Inputs Outputs Outcomes" model to identify where performance disconnect happens and work on solving it. This framework helps you move from measuring activity to measuring impact, and gives you a systematic way to diagnose where things break down between effort and results.

Quick Guide (30 seconds)
  1. Diagnose where work breaks down using three categories: Inputs (activities), Outputs (completed tasks), Outcomes (business impact).
  2. Ask diagnostic questions to find where conversion fails - inputs→outputs or outputs→outcomes - then focus your improvement efforts there.
  3. Work on fixing conversion between steps.

The Challenge​

Performance discussions typically focus on inputs (activities and time spent), outputs (completed tasks), and outcomes (business impact).

A lot of teams get stuck debating what to measure to figure out what needs fixing. Sometimes measures are meaningful, some are there because they're easy to get, many are deeply flawed, and some have a lot of conditions and context around them that need to be understood for correct use... which is rarely brought along with the measure. Mostly teams end up searching for a magic "solves everything" single metric.

This means that too often, conversations get caught up in measuring the wrong things. Teams fall back on tracking hours worked or tickets closed while losing sight of whether any of it creates real value. These approaches optimize for either inputs or outputs, but neither drives outcomes. They just make people busy and check off a lot of checkboxes.

We expect that grinding through long hours and relentless effort directly generates success, but this assumption breaks down in practice. Success is the result of completed work, not completed work itself or even time put in.

The Framework​

In simplest terms, "Inputs" are just raw human effort, you can work all day and never complete a task, but you still provide a substantial amount of inputs. Outputs are an indication of work that is done. An output is often that moment when you checked an item off your todo list. Outcomes are only ways that you were able to make a concrete impact on business driven metrics, something connected to the reason that you and your entire team got budget approval to exist in the first place.

In this model, inputs flow into outputs which flow into outcomes.

Inputs​

These are the activities taken and where time goes. Code reviews in-progress, meetings, waiting for CI, designing, calling customers, and more.

Outputs​

These are tasks that get completed. Tickets moved to done. Code reviews completed. Features launched. Customers onboarded.

Outcomes​

These are the consequences of what happens after work is completed. This is why the work mattered. What's the real benefit behind it (not the hypothetical, but the actual measured benefit)? This can be ROI, team happiness, CO2 reductions, or discovering new facts as the result of an experiment.

Start by Diagnosing Where Things Break Down​

Use these questions to get an assessment of where the challenges pile up, and figure out where things are not converting. If we see issues converting inputs to outputs, we should focus on the type of inputs. If we have issues getting outputs to outcomes, we should focus there instead. If we have no inputs we have to figure out where efforts are going.

For Inputs​

  • "What's keeping you busy?"
  • "Where is your time actually going?"
  • "What activities fill your calendar?"

Outputs (What completed bits of work can we put a checkmark on?)​

  • "What can we put a checkmark on?"
  • "What deliverables are ready to ship?"
  • "How do we know this task is truly done?"

For Outcomes​

  • "What's different about our business now?"
  • "Which metrics are you moving?"
  • "What would happen if this work was never completed?"

Common Performance Patterns​

Little/No Input, Little/No Output​

Symptoms: There is either an issue with transparency or effort. Possible causes: This may be due to a skill/knowledge gap, low motivation, or a lack of psychological safety. It might also be caused by lots of competing work that was not discussed. Action: Investigate transparency and effort. Address root causes directly.

Lots of Input, Little Output​

Symptoms: This can have many hard-to-anticipate root causes. Possible causes: They may be blocked on a task, asked to re-work it frequently, trying to make it perfect, afraid of feedback, or working on too many things at once by starting more than they complete. Action: Focus on completion strategies and removing obstacles.

Lots of Output, Little/No Outcomes​

Symptoms: Depending on the company this might feel really comfortable. However, not knowing the outcomes is a good way to spend a lot of money without thinking. Possible causes: In the long-term, this kind of performance will result in attrition due to boredom at best, and multiple failed products at worst. Furthermore, this lets you enter a false sense of security by "completing lots of work", but was any of it useful? Action: Bring the person closer to the business to understand what the bigger picture looks like in detail and how they contribute.

Lots of Output, Lots of Outcomes​

Symptoms: It might seem like this is perfect and there's nothing to do now. Action: This person is very likely a magnet for respect and can help bring up the rest of the company. Put them in a position where they can help improve the broader team.

How to Use This Framework​

On Your Own​

Use this tool as a diagnostic to figure out your own productivity

One-on-ones​

Use this framework with people you manage to coach them towards more efficient practices and keep them focused.

When you discuss productivity with someone you can diagnose their situation by starting a discussion about their outcomes. Ask them about what numbers they are impacting, what the results of their work will be, and if they have or have not already made an impact. This lets you identify if they understand the work's purpose and also if they are delivering.

Afterwards, and especially if you detect they have problems with delivering outcomes you can direct the conversation towards their outputs. Unfortunately engineers are commonly busy releasing software but unaware of how it is connected, this leads to a lot of change or work in areas that are not in the target-area. They may be over-producing quality in areas that do not need it, they might be cutting corners in places they should not, they might simply be stuck or slow in converting their input effort into output task completion.

If you have a lack of outcomes you should still check how their Inputs are doing. Are they not able to contribute to a topic due to being spread too thin? Are they lacking motivation? Did they not understand the importance of working on it, or are they uncomfortable with doing the work?

Team Retro​

Dig into what's eating your team's time and discover were the pain points are when converting efforts to outcomes.

Scope Considerations​

Sometimes Inputs can be confused for Outputs due to how people think about systems.

If completion of work ("output") is "input" to a bigger project this can confuse people who change scope from personal performance to project planning work. Reframe the conversation to make it clear that if you are actively working: it's input. If you completed something: it's output.

It is possible to have a lot of input time on something like "Code Reviews" as well as completing a lot of (or only a few) "code reviews".

Framework Template​

Use this structure for regular check-ins:

Inputs (What's keeping you busy?)​

  • Activity 1
  • Activity 2
  • Activity 3

Outputs (What can we put a checkmark on?)​

  • Completed task 1
  • Completed task 2
  • Completed task 3

Outcomes (What's different about our business now?)​

  • Business impact 1
  • Business impact 2
  • Business impact 3

Results​

In practice I've found I can use this to improve performance of Individual Contributors on my teams, improve the collective performance of a team, and get projects back on track.

I found I can also use the details I gained from these simple "Input, Output, Outcomes" conversations to help me communicate to the rest of the company about where a project is, what problems they have, and how they can track progress and effort at different stages. If you can't ship outcomes you need to be able to explain the outputs and explain how they will contribute, and show that outputs are happening. If you have no outputs you need to be able to show the inputs and explain what outputs those will create.

In my experience, once you and your teams consistently deliver good outcomes, most people outside of your team will stop asking about your outputs or inputs, but if you fail to keep up healthy outcomes they will start to ask about it (and sometimes it can happen when there is management change, and someone new with no context wants to understand your baseline performance numbers gets involved, or your outcomes are called into question in a political setting).

Details Matter​

In general I tell myself that inputs produce outputs which produce outcomes, and if something at an earlier stage is broken everything downstream will not see results. I do think this is not the full reality however, as some level of interplay exists. You may have someone with poor inputs because they do not understand the outcomes, or you may have someone with great quality of outcomes but the volume of outcomes is low due to low ability to complete work. In general the rule works, and if you have an awareness that they are not fully isolated like stages in a vehicle assembly line, you will be able to use this tool effectively.

The thing that makes this concept work is that it forces your conversations to add detail about how work gets done, instead of inspecting a person for different skills or characteristics. This gives you a way to find the right places to get involved with minimal guesswork, and makes clear what you need to do to help. In fact, you can form a plan together and explain the problems and get mutual agreement on where the focus for improvement is needed.

Avoiding Success Theater​

The Success Theater measures of team performance are too easy to get tricked into. Tracking the hours someone is typing is a measure of raw input but it tells you nothing particularly useful beyond how much they typed. If they are not typing, does it mean they are not participating in other forms of input (meetings, thinking, reading)? Does a high task completion mean a team is successful, or just that the team uses a task tracking system in a specific way? Does it mean that the outputs are actually useful, and are they actual outputs or just numbers reported in a ticket system?

Success Theater is attractive because it is so easy to access the data, but this data is relatively meaningless and distances you from the details about how you can manage and improve the performance of your team. Often, the data given to you by an elaborate query can be extracted with a simple conversation focused on "Inputs, Outputs, Outcomes" and a meaningful diagnosis with the details of what to do can be found faster than untrustworthy data.

Improving performance is about work getting results a bit faster each time, so focus your conversations into the details of these three stages and you will be able to diagnose, anticipate, and communicate performance issues with minimal effort and no overly complicated frameworks. It can be as simple as "Inputs, Outputs, Outcomes". Don't be afraid of the details, structure them.