Output vs Outcome

Output is a metric that shows how well we are able to fulfill the activities we have planned.

Outturn is a metric that measures whether what we originally wanted has happened, whether our activities fulfill our purpose.

‍

For most, it is immediately clear why the outcome is more important. As a salesperson, I can go through hundreds of meetings, but if I don't sell in the end, my activities do not have the desired benefit for the company. In addition, the orientation to the measurement of the outputs of individuals leads to the old familiar “I have mine ready”. This is where the theme flows and therefore wants to focus more on Results — because she is interested in the fulfillment of the intention, not just the work done.

How to distinguish between Output and Result? There is a simple auxiliary question here “Well and?”. Whenever in doubt, try asking yourself this question. “I'm going to do 100 client appointments next week!” Well and? What good will it do us? “... and I will close deals on them for at least 50 thousand. This is already much more specific.

But let's not be fooled, both methods of measurement are important. The results often only become apparent after some time, after we have worked on it. And it is that work that is well measured by the Outputs. In order to sell something like the aforementioned seller, it is probably not possible to do without a lot of meetings with clients. I'm not making appointments -- there will be no sales. Therefore, it makes sense to measure both Outputs (am I doing enough to arrive at Results?) , so Results (the result itself). Combining both will give us an overview of what we are doing and whether it leads to a goal.

‍

What about larger companies, where from Team to Result is far away?

1. Teams must always look at the overall result — what does the company want to achieve and what is the benefit of our team?
2. It must be clear why these are the most important activities to the Result — there must be a clear link between team activities, team metrics, and Outcome
3. It must be clear who we are working with and how it leads to the result
4. And we have to update and remind all this very often

Then (e.g. for a mobile app) it starts to make sense to measure the number of installs and app ratings, because we know how it ties in with the rest of the business and how it should affect the overall impact. It is only necessary to be careful that this does not become a matter of course and the real Result is not forgotten — hence point 4.

‍

Why doesn't everyone just focus on the outcome?

This seemingly simple question has no completely trivial answer and that is why it bothers leaders. The answer is not clear, it is necessary to look at several possible causes:

‍

We do not know our correct goal (and therefore find it difficult to navigate in its direction)

Almost everyone can come up with some seemingly beneficial activities. You probably have a table full of them now. But if they did not arise from finding a way to fulfill a higher goal, this is precisely the path of the Ascent. In order for these activities to be properly focused, we must first know what our intended higher goal is — the Outcome. Therefore, store all your activities in a drawer for a while, 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 on the first try. It helps to go through the following list of individual steps related to this key issue and plan in context:

Planning in Context

1. Who are we as a team/company?
2. Who is our customer? Who do we work for?
3. What is our product/service for him?
4. What value does he get from us, what does he pay us for?
5. What is our strategy/way to deliver that value to it?
6. How do we measure that we are doing this job well?
7. What bothers us most, or where do we see room to grow?
8. So... what do we really want to change?

When you go through these questions, you will often see a few areas that you want to change and why. Typical examples tend to be:

• We want to increase sales, our vision is to become the number one in the market
• We want to recruit people, we are preparing for expansion and we have no hands on it
• We want to stabilize finances, we are in the red
• We want to improve the margin of our product sales, the market has changed and we are not profitable

Each of these examples is understandable at a glance and gives a clear goal as well as a metric for how we recognize that it is succeeding.

‍

We have the right target, but we forget about it (we are swallowed up by the operative)

The second reason may be that we “forget” the goal. What happens most often is that we choose the right goal and create the right activities for it and start working on them... and then they are worked on, they are completed, follow-up activities are generated... but we do not return to the original goal and evaluate whether we have already achieved it. It's more common than you'd say. As the popular saying goes, “a shirt is closer than a coat,” people often focus on the nearest level of activity and forget why they are actually doing these activities.

Our brain has the property to jump after any activity that “keeps us busy.” As Christian Hoffmann once said, 90% of managers are great fire fighters. To have a vision, a goal, to constantly return to it, requires strategic talent (to see beyond the horizon of days and draw motivation, energy from it), it does not have many people. But reactivity in the form of “extinguishing fires” is a competence we all have by nature.
‍Roman Šmiřák, RainFellows

Therefore, both the target and the key metrics are needed visualize and also to them Regularly return attention.

1. The easiest way is to return to them at Regular meetingswhere we will see what the current metrics are, how our goal is doing and whether the activities towards the goal are going as we intended.
2. Further helps possess key metric perpetually in plain sight — if you have a place where the team meets (office, hallway, Miro board, JIRA dashboard) — it is important to have our goal and its metrics in sight.
3. You can make a target and its metrics add to templates to write down activities, so it always “hits” you right over the eyes when you want to start a new activity and it reminds you why we're actually doing activities now. Be inspired, for example, by the template they use Tealmakers to OKR.

These techniques will help you not to forget the goal even for a while. When I want to climb Everest, I also don't just look under my feet — in altitude camps we solve how to go further, the altimeter and the map show me how far I am and the goal is always in front of my eyes.

‍

We go and measure towards the right goal, but our activities do nothing to it

Another reason is that the activities that we have planned to do towards the goal do not bring results. So we have a tendency to push the activity further, possibly procrastinate, or develop with other activities... and this gradually reduces our focus on the goal. This happens most often because:

• We are planning a very large activity
  This is where the Agile approach helps, or the method of dividing requirements

• We do the wrong activities
  Probably the most common cause, see the chapter below.

• We do not have enough skills/tools/money for these activities
  We have overvalued ourselves and are not up for the activity in question. Let's look for alternatives.
• We are too impatient
  Few great goals are fulfilled immediately, for even “Rome was not built in a day.” Sometimes just a little patience and getting on with activities helps.

‍

We are not doing the right activities

Improper activities are probably the biggest result killer. Typical Inefficient Cycle for example:

1. We have an app, and our right goal is to increase the number of paying users
2. That's why we're going to come up with great new features to add to the app
3. This is the best way to make a Roadmap, which presents itself well to the management
4. We will then spend a year (s) implementing these functionalities
5. We're looking at the number of users... and rocketing growth nowhere. So we repeat from point 2.

We have seen this cycle in countless companies and teams. We just have some established way of working (developing new functionalities) and we kind of believe that the next one will already be the right one. What else would we do, after all, we pay a team of developers, so they will develop. However, this is not the right line of reasoning. It reminds you of that popular game for which you need games and a wall — surely you know the rules yourself. To make a real change, you need the following:

• Constantly looking for what may be the real problem/real added value

• Learning to experiment and discard hypotheses in a disciplined manner

Both are famously described in the book Lean Startup or Erik Riese and have been a widely known and discussed topic for some time now. In many companies, point 1 is already successful and the search for the right problems/value is actively underway. This is why experiences in the field of User Experience/Customer Journey Mapping and the like are so in demand today, which focus on exactly what users really need and want.

The problem is more often in the second part — learning to formulate hypotheses correctly, and even more so, to verify and discard them in a flash. This is already a reputation of higher girls and few teams/companies can actually do this. A person “falls in love” with his solution/idea and does not like to be convinced that it is not the right one. All the more so if it's already written in some Roadmap and someone will ask why we're not actually doing it and what else are we going to do.

Therefore, let us extend the aforementioned Planning in the context above with further steps:

Planning in Context

1. Who are we as a team/company?
2. Who is our customer? Who do we work for?
3. What is our product/service for him?
4. What value does he get from us, what does he pay us for?
5. What is our strategy/way to deliver that value to it?
6. How do we measure that we are doing this job well?
7. What bothers us most, or where do we see room to grow?
8. So... what do we really want to change? What is our current hypothesis?
9. What data do we have for this?
10. How much time/money do we want to throw into this for verification?
    And on what basis do we throw that hypothesis away?

And let's go through this list repeatedly. Once every 14 days, we minimize the work on the wrong activities by identifying and discarding them. Simplicity is to maximize the amount of work not done by not doing work that does not measure up to the desired result. (Agile Manifesto, Principle #10)

‍

Incorrect activities — what prevents us from stopping them?

• Ignorance of alternatives -- not everywhere the Hypotheses + Verification approach is known. What I don't know, I can't do well enough. Plus, when I have a hammer in my hand, everything looks like a nail. And when I'm a feature developer, that's how I most often think of developing a new feature. To do anything else is to step out of the comfort zone. Often linked to the next point:
• Culture of habit — It doesn't work like that and it can't work! We haven't tried it, but it's a change with uncertain outcome, no one is an expert on it, so we'd rather not even try it.
• Manager/Product Manager Culture ---- “We have concrete solution proposals, we have a producer/manager to figure out what to do, you do it yourself”. Often you have a person in front of you who knows exactly what he wants and thinks that this is the only right solution. Moreover, questioning his enlightenment in such a culture is not desirable. All the more so if you don't come up with a different/better concrete idea that should be done right now. The culture of fear, closed roles and concrete solutions hereby closes itself to alternatives.
• Culture of pressure to use resources ----”If we have these developers, they have to develop.” — is a real objection and concern, but again leads to sub-optimization. Yes, the feature may not be in demand, but someday it may be and better to have than not to have, right? Not really -- it will consume time, it will cost to maintain, and the product will be more complex. A better solution is to give those developers time to experiment and search, involve them in co-inventing solutions (they know the technical part), or just reduce the pressure on supply (and thus need to get technical quality).

‍

What's up with that? What exactly can I change with us from tomorrow?

ATTENTION: It's more strenuous than it looks. And it takes patience. None of the activities below will happen “by themselves”. You spend more time planning what to do, and less time doing it yourself. But it costs everything, the change from “doing activities” to “getting results” is great.

• Plan in Context
  Plan in context, following this list of questions. Of course, according to changes and needs — if nothing fundamental has changed since the last time, there is no need to discuss deeply again who our customer is. On the other hand, questions from point 6 onwards are valid at any planning meeting, almost without compromise. Questions 6 and 9 lead you to measurable results.
  But to all those questions, have an answer. Post them somewhere (on the wall, or virtually on Miro/Mural) and come back to this once in a while to validate if it still applies. At least once a year, if not more often.

Planning in Context

1. Who are we as a team/company?
2. Who is our customer? Who do we work for?
3. What is our product/service for him?
4. What value does he get from us, what does he pay us for?
5. What is our strategy/way to deliver that value to it?
6. How do we measure that we are doing this job well?
7. What bothers us most, or where do we see room to grow?
8. So... what do we really want to change? What is our current hypothesis?
9. What data do we have for this?
10. How much time/money do we want to throw into this for verification?
    And on what basis do we throw that hypothesis away?

• Technique “Well and?”
  When you are planning an activity, look at the measurement to evaluate the activity. And ask yourself the question “Well and?”. If the answer doesn't seem “good” enough to you, chances are you plan to measure only Outputs.
• Ruthlessly kill unproven hypotheses and unhelpful activities
  This is where the bread is really broken. If we plan well, we start to form hypotheses, try to verify them, and... they don't work out exactly the way we wanted - DON'T GO ON. Yes, that's despite the fact that you've been pouring in for dozens of hours. Yes, even though you have nothing else planned. Yes, even if the team will say that they are already half done. Better put the time of analyzing what was wrong, where we were wrong, into creating new hypotheses and planning more than finishing something that has no value.
  It's a tough and unpopular move, but that's what you're a leader from.
• Plan and organize your work agilely
  As RainFellows, we have been promoting Agile Approaches a lot for years. Precisely because they build on small steps and allow quick changes of direction. Small step -- verify -- discard or continue -- next small step. This approach allows you to be very well versed in the result by being able to spot any deviation with minimal delay.
  On such Retrospectively clarify with your team how to change your process to aim more towards the Result, to Planning together with the team you will go through the Planning list in context and in short Sprintech Make sure you're still going in the right direction.
  Who does not know how to do it, we will be happy to teach it here https://www.agileacademy.cz/agile-jasne-a-prakticky/.
• Try Walt Disney's Creative Technique
  It may be that you know what the right result is, but you can no longer think of how to approach it correctly. There are more methods to generate new ideas, our favorite is Walt Disney's Creative Technique. The article is from the Covid era, when companies were also figuring out how to adapt to the new reality using this method.
  

• Get inspired from the outside
  And if you still lack inspiration, go to a meetup (Goal setting and Agility are talked about everywhere here: https://czechagile.cz/pravidelne-akce/), read an inspiring book (about setting goals about OKRs I'm reading this great book — so far only in English Moving the Needle with Lean OKRs or Radical Focus), visit interdisciplinary meetings (e.g. ProductTank Brno) and, of course, go to workshops with RainFellows (https://www.agileacademy.cz/kurzy-agile-academy/).

‍

‍