From mere outputs to real impact

It is one of the key questions for a leader – how to ensure that what we do has the impact we really want. That we are investing the capacity of people and teams in the company’s biggest priorities. The frequency of this question has increased after the OKR goal-setting method became well known. This particular method focuses a lot on the measurability of goals and distinguishes between the two types of measurement that Lucie mentions above. Let us clarify the difference between them.

Output vs Outcome 

Output is a metric that shows how well we can deliver previously planned activities.

Outcome is a metric that measures whether we have met our original goal/intent, and whether we have achieved the desired benefit.

In most of the examples, it is immediately clear why Outcome is the more important one. Moreover, focusing only on measuring the Outputs of individuals leads to the good old “I’ve got my work done” claim. Hence the theme, and why we need to focus more on Outcomes – because we are interested in fulfilling the intent, not just working on the activities.

How to easily distinguish Output and Outcome from each other? There is a simple guiding question “So what?”. Whenever in doubt, try asking yourself this question. “I’m going to make 100 client appointments next week!” So what? What good will that do? “… and I will close at least 50 grand worth of business.” That is a more specific result.

But let’s not be fooled, both ways of measuring are important. In fact, the results often take some time to show up, after we’ve done the work. And it is the “done work” that is well measured by Outputs. To sell something as the aforementioned salesperson, it probably won’t happen without a lot of client meetings. No appointments – no sale. Therefore, it makes sense to measure both Outputs (am I doing enough to get the Outcome?) and Outcomes (the result itself). The combination of both will give us insight into what we are doing and whether it is leading to the goal.

How about larger companies where the team is far from the Outcome?

1. Teams still need to look at the overall Outcome – what does the company want to achieve and how does our team contribute?
2. It must be clear why our activities are the most important activities to reach the Outcome – there must be a clear link between these
3. It must be clear who else we are working with and how this leads to Outcome
4. And we have to update and keep reminding all this very often

Only then it starts to make sense for e.g. a mobile app to measure the number of installs and app ratings because we know how it relates to the rest of the business and how it should affect the overall impact. We just need to be careful not to take it for granted and forget about the actual Outcome – hence point 4.

Why doesn’t everyone just focus on the Outcome?

This seemingly simple question does not have a simple answer and that is why it troubles leaders. The answer is not straightforward; we need to look at several possible causes:

We don’t know our proper goal (and that’s why it’s hard to keep the right direction)

Almost everyone can come up with some seemingly beneficial activities. You probably have a desk full of those even now. But if they didn’t come about by looking for how to fulfill a higher purpose, you may possibly be on the Output path. In order to get these activities focused properly, we must first know what our intended higher goal – the Outcome – is. So put all your activities in a drawer, forget about them for a while, and ask yourself:

What do I really want to change? What do I want to achieve in my area now?

The answer may not be obvious at first. It helps to review the following list of Planning in Context sub-questions that are related to this key question:

When you go through these questions, there are often immediately several areas you want to change. Typical examples are:

• We want to increase sales, our vision is to become the market leader
• We need to recruit people, we are preparing for expansion and we don’t have the hands to do it
• We want to stabilize our finances, we are in the red 
• We want to improve our product sales margin, the market has changed and we are not profitable anymore

Each of these examples is easy to understand at first glance and gives a clear goal and metrics for how we know it’s succeeding.

We have the right goal, but we forget about it (we’re drowning in operations)

The second reason may be that we “forget” the goal. This happens most often because we choose the right goal and create the right activities for it and start working on them… and then they get worked on, they get refined, follow-up activities are generated… but we don’t go back to the original goal and evaluate whether we’ve achieved it. It’s more common than you might think. People often focus on the closest level of activities and forget why they are actually doing those activities in the first place. 

Therefore, both the goal and the key metrics need to be visualized and regularly revisited.

1. The easiest way to do this is to revisit them at a regular meeting to see what the current metrics show, how our goal is doing, and if the activities toward the goal are going as we intended.
2. It also helps to keep key metrics in sight at all times – if you have a place where the team meets (office, hallway, Miro board, JIRA dashboard) – keep your goal and its metrics there. Seeing it regularly won’t let you forget it.
3. You can also add the goal and its metrics to your activity templates, so it will always immediately “hit” you in the eye when you want to start a new activity and remind you why you are doing the activity now in the first place.
   Here’s a template used by the Tealmakers on OKRs that you can use for inspiration: https://www.tealmakers.cz/blog/okr-jak-psat-spravne-key-results (CZ)

These techniques will help you remember your goal at all times. When I want to climb Everest, I don’t just look under my feet either – at altitude camps, we work out how to go further, the altimeter and map show me how far I am and the goal is always in front of my eyes.

We move and measure towards the right goal, but our activities do nothing about it

Another reason is that the activities we have planned to do towards the goal are not producing the expected results. We tend to push the activities further anyway, or procrastinate… and that gradually reduces our focus on the goal. This happens most often because:

• We’re planning too big activities
  This is where the Agile approach or requirements splitting methods help

• We are doing the wrong activities
  Probably the most common cause, see the next chapter below.

• We don’t have enough skills/tools/money for the particular activities
  We have overestimated ourselves and do not have the capacity for the activity. Let’s look for alternatives.

• We’re too impatient
  Few great goals are accomplished immediately, for even “Rome was not built in a day”. Sometimes just a little patience and continuation of activities helps.

We’re not doing the right activities

Wrong activities are probably the biggest killer of Outcomes. A typical inefficient cycle looks like this:

1. We have an app, and our proper goal is to increase the number of paying users
2. That’s why we’re coming up with great new features to add to the app.
3. From these, we make a Roadmap that is perfectly presented to the management
4. We will subsequently spend year(s) implementing these functionalities
5. We’re looking at the number of paying users and the growth is nowhere to be seen. So we go back to point 2.

We have seen this cycle in countless companies and teams. We just have a certain way of working (we develop new functionalities) and somehow we believe that the next functionality will be the right one. What else would we do anyway? After all, we pay for a team of developers, so they should develop something. However, this is not the right line of thinking. To make a real change, you need the following:

1. Continually look for what may be the real problem / real added value
2. Learn to experiment in a disciplined way and discard invalid hypotheses

Both are well described in the book Lean Startup by Eric Ries and have been widely known and discussed topics for some time. In many companies, point 1 is even already succeeding and the search for the right problems/values is actively underway. That’s why User Experience / Customer Journey Mapping and the like are in such high demand today, focusing on exactly what users really need and want.

The problem is more often in the second part – learning how to formulate hypotheses correctly and even more so to verify and discard them rapidly. This is quite an advanced skill and not many teams/companies are actually able to do this. This is because you “fall in love” with your solution/idea and you don’t like to be told that it’s not the right one. Even more so when it’s already written in some Roadmap and someone will ask why we’re not doing it and what specific different activity are we going to do instead.

Therefore, let’s extend the Planning in Context mentioned above with additional steps:

And let’s go through this list repeatedly. Feel free to do it once every 14 days, that way we minimize working on the wrong activities by identifying them and throwing them away. The simplicity is to maximize the amount of work not done – by not doing work that is not directed toward the desired Outcome. (Agile Manifesto, Principle #10)

Wrong activities – what prevents us from stopping them?

• Not knowing any alternatives – the Hypothesis + Verification approach is not known everywhere. What I don’t know, I can’t do well enough. Moreover, when I have a hammer in my hand, everything looks like a nail. And when I’m a feature developer, I most often think of developing another feature. To do anything else is to step out of my comfort zone. Often connected to the next point:
• The culture of habit – “it doesn’t work like this around here”! We haven’t tried it, but it’s a change with an uncertain outcome, no one is an expert in this field, so we’d rather not even try.
• Strong management culture – “We do have specific solutions, we do have a Product Manager to figure out what to do, so you do your thing”. Often you talk to a person who knows exactly what they want and thinks it’s the only right solution. And questioning his enlightenment is not desirable in such a culture. Even more so when you don’t immediately come up with a different/better specific idea to do right now. A culture of fear, closed roles, and concrete solutions is thus closing itself off to alternatives.
• The culture of pressure to utilize resources – “If we have these developers, they must be developing” – is a real objection and concern, but again leads to suboptimization. Yes, this program feature may not be in demand by customers, but it may possibly be someday, and better to have it than not, right? Not really – it will consume time, cost to maintain, and make the product more complex. A better solution may be to give programmers time to experiment and research, involve them in co-inventing the solution (they know the technical part), or just reduce the pressure to deliver (and perhaps gain technical quality).

So what exactly can I change from tomorrow in my team?

BEWARE: It’s much harder than it looks. None of the activities below will happen “on their own”. You will spend more time planning WHAT to do, and less time actually doing it. But it’s all worth it, the change from “doing activities” to “getting results” is great.

• Plan in Context
  Plan in context, according to the following list of questions. Of course, based on incoming changes and needs – if nothing has changed since the last planning, there is no need to deeply discuss who our customer is again. But do have an answer to all those questions. Post them somewhere (on your wall, or virtually on Miro/Mural), and come back to them once in a while to validate they are still valid.
  The questions from point 6 onwards are valid in any planning meeting, without exception. They lead you to measurable Outcomes.

• “So what?” technique
  When you plan an activity, look for a measurement against which you will evaluate that activity. And ask yourself “So what?” question. If the answer doesn’t seem “good” enough, chances are you’re only planning to measure Outputs.

• Ruthlessly kill failed hypotheses and unhelpful activities
  This is where the rubber meets the road. If we plan well, form hypotheses, test them, and… they don’t work out quite the way we wanted – DON’T proceed further. Yes, even though you’ve poured dozens of hours into it. Yes, even though you have nothing else planned. Yes, even though the team will grumble that they’re half done.  Just stop it.
  Rather put time into analyzing what went wrong, creating new hypotheses, and planning further than finishing something that brings no value.
  It’s a difficult and unpopular step, but that’s what you’re a leader for.

• Plan and organize your work in an Agile way
  As RainFellows, we have been promoting Agile approaches for years. Precisely because it relies on small steps and allows for quick changes of direction. A small step – verify – discard or continue – next small step. Such an approach allows you to get very good at Outcome orientation by allowing you to spot any deviation with minimal delay.
  Using a Retrospective technique you will clarify with the team how to change your process to be more Outcome-oriented. At the Planning meeting you will go through the “Planning in context” list with the team and the Short Sprints technique will verify that you are still moving in the right direction.
  If you don’t know how to do this, we’d be happy to teach you here https://www.agileacademy.cz/agile-clear-and-practical/.

• Try out Walt Disney’s creative technique
  It may be that you know what the right Outcome is, but you have no idea how to approach it. There are multiple methods for generating new ideas, our favorite is Walt Disney’s Creative Technique (CZ). The article is from the Covid era when companies also used this method to figure out how to adapt to the new reality.

• Get inspiration from the outside
  If you are still lacking inspiration, go to a meetup (there is a lot of talk about goal setting and Agility here: https://czechagile.cz/pravidelne-akce/), read an inspiring book (The Goal, or Start with why ), visit an interdisciplinary meeting (e.g. ProductTank Brno) and of course go to workshops with RainFellows (https://www.agileacademy.cz/kurzy-agile-academy/).