• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

On outputs and outcomes

3 May 2018 by Robert Falkowitz

I have frequently discussed in passing the difference between the outputs and outcomes of work. Given the importance of the distinction between the two for your service models, it is worthwhile examining the issue in more detail.1 What do I mean by outputs and outcomes? Why is it important to distinguish be­tween them?

Some definitions of outputs and outcomes

outputs and outcomes
Fig. 1: A provider creates some output using its system. It becomes input to the customer's system, used to achieve an outcome.
Output is the goods or services delivered by a provider to a cus­tomer. It is the result of doing some form of work. It is output from the perspective of the pro­vider, but input from the per­spec­tive of the customer. Outcome is the effect obtained by a customer in using those goods or services. Outcome is also an out­put, when viewed from the perspective of the customer’s production system. How­ever, we are particularly interested here in how the output from the provider influences the outcome at the customer. This is why I distinguish between the two and do not simply treat them both as outputs. For example, a provider delivers an electronic messaging service. The output of that service is the delivery of messages to their recipients. The outcome of that service is the effect on the customer for having received or sent a message. A customer uses the service to invite a colleague to lunch. The output is the delivered invitation. The outcome might be an enjoyable hour together among colleagues. Another customer uses the service to submit a proposal to a prospective client. The outcome, assuming that proposal is accepted, might be the future prosperity of the customer. I will use the term product in the following discussion. A product is one or more goods and/or services bundled into an offering made by a provider within a marketspace.

Responsibilities for outputs and outcomes

Fundamentally, the provider is re­sponsible for producing the output, whereas the customer is responsible for the realization of the outcome. In the example of the messaging service, the provider is responsible for the delivery of the message, although it might also depend on various suppliers and sub-contractors. The customer, be it the sender of the message or the recipient, is responsible for the contents of the message and the ultimate effect that it might have, respectively.

Perhaps you have read the details of a software license. Often, the li­cense contains a clause with lan­gu­age similar to:

The copyright holders and/or other parties provide the program “as is” without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of mer­chant­a­bility and fitness for a particular purpose.

Whatever does this mean? Who­ever would buy something that is not fit for their purpose? From the perspective of the software’s out­put, the license is saying that the output depends largely on how the user uses the software. The software’s copyright holder cannot warrant that the user will use the software in any particular way, not to mention using it in some intended way. From the perspective of the outcome, it is saying once again that the purpose for which the user is using the software is not under the control of the copyright holder. The reference to “implied war­ranties of merchantability” is specious, insofar as the right to expect merchantability (that the product is indeed fit for a particular purpose) is generally protected by commercial law.

hammer used to sink nail
Fig. 2: The provider of hammers expects the outcome to be sunk nails
A manufacturer of hammers might have intended that the hammer be used to sink nails. However, a user might suc­cess­fully use one to crack open walnuts, just as another user might try to use it to remove screws. obtaining very mixed results. If a customer returns a hammer to a vendor because it is not fit to drive nails, the merchant should take the complaint seriously and might decide to sell a different brand of hammer.
hammer used to crack walnuts
Fig. 3: Some customers might use a hammer to crack walnuts
If the customer says that the hammer is OK for cracking fil­berts, but hopeless for Maca­damia nuts, the vendor will respond that the hammer was not intended for that purpose. And if the customer rants about tearing off screw heads without removing the bodies, the vendor might think he or she is in the midst of a blonde joke.
hammer used to pull screw
Fig. 4: Although other customers might try to use a hammer to pull screws, the manufacturer hardly has this in mind
The astute reader may have noticed that I spoke of what are “fundamentally” the res­pon­si­bilities for output and outcome. This is because the customer might influence the output, just as the provider might influence the outcome.

How the customer might influence the output

There are various ways in which a customer might influence the output of work, even if the provider is ultimately responsible for that creation of that output.

  • By specifying options
  • By participating in the cre­a­tion of the output
  • By participating in the spe­ci­fi­cation of the product

A provider might define a product with various options, such as customer chooses an existing optionthe speed of execution, attributes such as color or texture, various possible add-ons, etc. For example, a mes­­sage might be sent with high priority or using a tunneling protocol. In addition, the provider might accept to perform bespoke work that is not a pre-defined option. Thus, the customer can influence the output, as well as the risk that the output meet the customer’s expectations.

In certain cases, the work performed to create the output is a collaboration between the provider and the customer. customer requests a custom optionThis approach has become increasingly common in recent years. Thus, we see many cases where the provider manu­­fac­­tures parts, such as furniture parts, but the customer assembles them. In support ser­­vices, customers are increasingly being provided with means to diagnose and resolve issues by themselves.

Influencing the output is not limited to acts during the per­for­­mance of work. It may also occur during the planning of the products to be offered. While some providers find the funds needed to develop and customer requests a new serviceprovide new products on a speculative basis, other pro­viders have the luck to find customers willing to pay for the development of the product. Such customers have a strong influence in specifying the product. Once an initial offering is available, most providers are strongly influenced by specific customer requests that shape the evolving functionality and performance of the product. There are, of course, many other factors shaping the evolution of a product, such as competition, regulatory changes and the ima­gi­nation of the provider.

How the provider might influence the outcome

If an outcome is derived, in part, from the output, then it is clear that providers influence outcomes. But this is rather like saying that manufacturers of hammers and nails influence the architecture of houses. I am thinking instead of some more direct ways in which the provider might influence the outcome:

  • By enabling customer actions that might otherwise be un­fea­sible
  • By building the possibility of agile use into products
  • By temporarily and agilely al­­tering product speci­fi­cations

When a provider truly innovates (i.e., makes something new, rather than simply acting differently) and when customers find that in­nov­ation to be useful, there is a period during which new customer out­comes are possible, outcomes that simply could not happen without the innovation. Mobile telephony is perhaps the most pervasive example of such an in­­nov­­a­tion. It has led us to sacrifice serendipity for agility and pre­dictability.

Certain goods or services can be used in only very limited ways. Sometimes, we would have wanted to use a product to achieve a certain outcome, but it is not very practical to do so or simply is not possible. The entire software in­dustry is built around this issue. All software is the result of a compromise between sim­­pli­c­ity and reliability, on the one hand, and flexibility on the other hand. Does your software application allow you to create new structured fields in your records, or do you have to record information in an unreliable, unstructured way? Are your tools good for only one task or do you choose them for the Swiss army knife capabilities? By keeping in mind the unpredictable ways in which a customer might wish to use a product in the future, a provider might create products that can be used agilely. In other words, the products might be usable to foster outcomes that might not be possible with products that are only good for known and predictable uses.

Have you ever asked a provider to help you achieve a certain result, only to be told “Sorry, we don’t offer that service”? Some airlines, for example, forget that their cus­tomers need transportation. In­stead, they only offer airplane flights. A subtle difference, per­haps, but one that makes all the difference when a flight is greatly delayed or canceled. A customer needs to get from point A to point B to make a business presentation or to attend a wedding. Some airlines will tell you “tough nuggies” if their operations fail to help you achieve your outcomes. Others, however, will make an extra effort to get you where you want to go, when you want to be there.

Designing products with outcomes in mind

The innovation of the user story framework, as opposed to the use case framework, has facilitated the creation of products that support the achievement of customer out­comes. A user story might take various forms, such as:

  • As a {role} I can {capability}, so that{receive benefit} ; or
  • As {who} {when} {where}, I {want} because {why}
fireman persona explaining needs
Fig. 8: A firefighter persona explaining the needed output and the beneficial outcome

The role, the “who” or the persona of the story is the customer. The benefit or the “why” articulates the desired outcome. The capability of the “can” in the story alludes to, but does not specify, the output. The purpose of the user story is to easily capture the framework that allows the product designer to generate the product that de­li­vers—or is—the output that helps t­he customer achieve the outcome.

We could rewrite the user story framework in a very generic way:

A customer uses {output} to help achieve {outcome}.

But this formulation lacks the detail that helps ask the questions needed to derive the product.

It is interesting to note that the degree to which the provider keeps the possible outcomes in mind falls within a broad spectrum. At one end of the spectrum, the provider completely ignores the potential outcomes. This somewhat omphaloskeptic approach is likely to result in products that no one wants to use. At the other extreme, the provider is able to confirm in advance that at least one customer will indeed use the output to achieve an outcome.

But this is an extreme and is loaded with surprises. Thus, the agile soft­ware movement assumes that you rarely know in advance how a customer will use your newly developed output and whether the customer will be happy to use that output. In consequence, the iter­ative approach to product de­ve­lopment allows the provider to feel its way forward with relatively low risk and with pragmatic confirmation of delivering useful output. Or, the customer might actively reject an output or pas­sively neglect to use it. Both cases allow the provider to recover from the mistake and try a dif­ferent solution.

In sum, it behooves the provider to keep in mind the outcomes that the targeted customers may wish to achieve. But there is no guarantee that the customers will indeed use the outputs in the expected way. As we described above, the ultimate responsibility for the outcome lies with the customer, not with the provider. Indeed, the world is full of products that have succeeded in spite of the initial intentions of the product developer. The mar­ket­place sometimes finds entirely new and unexpected uses for products.

The correlation of outputs and outcomes

There are generally multiple ways in which a customer might achieve a given outcome. The exception to this rule would be the case, described above, where an innovation enables an outcome that would otherwise be impossible to achieve.

This means that a given output is probably not a necessary precursor to a given outcome. There are likely other ways of achieving the same outcome. There are two logical fallacies to avoid, however tempting they might be:

  • post hoc ergo propter hoc: the simple fact a certain output was delivered and a certain outcome was achieved does not imply that that output was the cause of that outcome

 

The supplier resolved the incident ∧ the customer won the contract
does not imply
The supplier resolved the incident ⇒ the customer won the contract

  • Affirming the consequent: even though a given output might lead to a given outcome, the presence of that outcome does not imply the presence of that output

Although
The supplier resolved the incident ⇒ the customer won the contract
The customer won the contract

does not imply
The supplier resolved the incident

This is why I regularly describe an output as helping to achieve an outcome. A given output is part of the customer’s production system leading to outcomes. It is rare that a single output can be understood as the sole cause of an outcome. In other words, the output is output by the provider’s delivery system, but is input to the customer’s system. In most cases, it is but one input among many. In the example we used above, where an electronic message is used to fix a lunch date, the outcome was the pleasurable meal with a colleague. Surely the pleasure came from an entirely different source than the in­vi­tation. It d­epends largely on the ambiance of the meal, the quality of the food, perhaps the price, the type of conversation, and so forth. So the invitation is but one input among many leading to the outcome.

ℙ(output ⋂ outcome)

Thus, unless we are able to identify all the elements of causality in an obvious or a complicated system, it is more appropriate to speak of the probability that there is a cor­relation between an output and an outcome. Indeed, it is often the case that the customer’s production system is complex, or even chaotic. From the perspective of making business decisions, a relatively high correlation coefficient is a typical justification in such systems (unless the organization falls back on the seat-of-the-pants, emotional de­ci­sions that characterize so much decision making).

But what happens when the provider’s output coincides com­­pletely with the cus­tomer’s desired outcome? There are several possibilities. In the short term, the customer is really outsourcing the work to the provider. Rather than using the provider’s output to achieve a given outcome, the customer has asked that the provider deliver the whole kit and caboodle. However, in the longer term, the customer will generally redefine the outputs and outcomes to a higher level of value. The customer’s new purpose or out­­come is then based on a further reuse of the outsourced result.

For example, many organizations used to perform accounting functions in-house. They might have used the output of accounting software and adding machines to book their debits and credits. Some, however, have outsourced that function to a third party. The higher level purpose is to allocate their limited assets to other uses that presumably help the or­­gan­­i­za­­tion better achieve its goals.

If, however, outsourcing never results in this economic trans­ference, if the customer adds no value to the work being done by the provider, then that customer is merely a parasite.

Outputs that don't contribute to outcomes

Another phenomenon is the failure of an output to contribute to the realization of an outcome. There several scenarios that lead to this situation:

  • The obvious case where using the output from a given provider was a pure and simple mistake
  • The much less obvious case where a provider’s output is used because it is commonly done and the customer does not really understand how to use that output
  • The typical case where an output has lost its usefulness but the customer does not yet realize it

The first case is not necessarily the result of stupidity or bad ma­­nage­ment. In fact, it is a common occurrence in our current atmosphere of agile ma­nagement. Try simple new things. If they work, great! If not, no great loss—try something else instead!

The second case is an all too common occurrence that manifests a “keeping up with the Jones’” mentality, a case of getting shiny new toys so that you can play with the big boys.2 We acquire expensive and feature-rich software packages with little idea of how their use will add any value to our organization. We select auto­­mo­­biles in terms of the prestige they confer or the self-image we hope to project, with little thought to the economic return on investment, both to ourselves to and to society. We acquire expensive tools thinking that they will be less risky, having little idea how to measure or to palliate that risk.

The third case is happens all the time. We acquire I once visited a data center conducted by the server platform team leader. I asked what a certain randomly chosen computer was used for. He said, “I have no idea.” I suggested that we disconnect it to find out. He replied, “I dare not do that.”a product for a particular purpose. As time goes by, that product becomes deeply embedded in our organizational structure and work processes. But at the same time, we lose track of the original reasons for getting the product and no longer know if the product has maintained any usefulness, if it still contributes to some desired outcome.3

Metrics for outputs and outcomes

How might we measure output and outcomes? Perhaps the first ques­tion to ask, in answering that question, is who might be responsible for making those measurements? This key question brings us back to my initial points concerning the responsibilities for output and for outcomes. Let’s start with outcomes.

Measuring outcomes

Remember that the provider is not principally responsible for out­­comes. Furthermore, the out­­comes from a given output can vary tremendously from customer to customer. They can vary in terms of frequency, quantity and value. They can vary in terms of performance and in terms of the degree to which constraints are relaxed. So it is virtually impossible to find a common ground among all customers for numerical data. What is more, to the extent that customers are parts of entities independent of the provider organization, most measurement data could simply not be obtained.

example of an output to outcome non sequiturAt best, we could make the as­­sump­­tion that there is some ordinal correlation between the provider’s output and the cus­tomer’s outcomes. But even this assumption has its limits. I am not likely to vary my use of electricity according to my satisfaction with the quality of the delivery by the local utility. If anything, I am more likely to be constrained by my own resources than by the degree to which electricity helps me achieve outcomes. This same principle is likely to be true for many utilities and situations with monopolistic providers.

In sum, a provider’s attempts to measure outcomes are of limited interest. In the best case, the provider might detect trends in the outcomes, represented as ordinal data. But that data can hardly be used for management purposes. For example, suppose we ask our customers to rate their outcomes based on our outputs on a scale of 1 to 10. And suppose we find that the mean assessment passes from 7 to 8. We might even assume that we are doing something right (or maybe that change has nothing to do with our outputs). But we would be very hard pressed to say what we were doing right (or wrong).

For these reasons, I would leave the measurement of outcomes to those responsible for them, namely, the customers. But a customer’s out­­come is, in reality, just another example of an output. So let’s turn to the measurement of outputs.

Measuring outputs

Recall that outputs are the result of some work using a production system, be it a service system (to deliver services) or a manu­­fac­turing system (to create goods), or both. We are in the realm of several centuries’ worth of analysis on how to measure economic activity, so it would be misplaced to delve into an analysis here.

Suffice it mention that there are internal metrics, such as costs, lead times, defect rates, etc. There are external metrics, such as revenues, sales volumes or customer sa­tis­faction ratings. But remember that a customer’s satisfaction de­­pends on many factors, only some of which depend directly on the output they use. If we return to the example of the organization that uses electronic messaging to submit business proposals, it is not hard to imagine that the success of those proposals might influence the assessment of the inputs used to create those proposals. Re­­mem­­ber the adage, “It’s a poor carpenter who blames his tools”. And yet, the organization de­­li­v­ering the messages can have only very limited influence on the success of the submissions (unless they manage to corrupt the message or fail to deliver in a reasonable amount of time).

In sum...

There is a complex relationship between outputs and outcomes. Depending on your perspective as provider or as customer, they can be very different or very similar. They have separate responsibilities, but can readily influence each other. The provider should produce outputs and the customer should select outputs based on their probable influence on the desired outcomes. A solid understanding of outputs and outcomes underpins your entire service model.

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International LicenseThe article On outputs and outcomes by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Notes:

1 I had completed 95% of this article when I discovered an article with a similar name that has also just been published. While the point of departure of the two articles is very similar, I think I cover other territory.

2 This phenomenon has been analyzed at length by René Girard. His foundational book, Violence and the Sacred, lays out the basic principles.

3 The classic exposition of this phenomenon may be found in Primo Levi’s The Periodic Table.
Summary
On Outputs and Outcomes
Article Name
On Outputs and Outcomes
Description
What is the different between an output and an outcome? Who is responsible? How do they relate to each other? How are they measured?
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Service Model Tagged With: outcome, output, service model

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

impact lead time incident flow manifesto for software development Incident Management service request agile change control ITIL kanban board cause waste change management risk Cost of Delay incident management tools value tools leadership lean automation knowledge work value stream adaptive case management kanban context switching process metrics histogram urgency manifesto statistical control chart ITSM bias rigidity lean management service management tools problem kanban training knowledge management
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}