You have probably heard the famous phrase: “If I had asked people what they wanted, they would have said: faster horses”. This sentence has been put into Henry Ford’s mouth since the 2000s. It probably didn’t originate from him, but it fits perfectly with his Ford Model T, which triggered a revolution in transport and the manufacturing industry from 1908. This phrase is often used to emphasise that it is better to ask an expert.
I disagree with this for a number of reasons, see more on this later. In this article, I would like to use this example to illustrate the difference between output and outcome. These terms are often used in Lean-Agile courses. Output is the scope of services that, for example, an IT service provider provides according to the contract. Outcome is the proof of effectiveness that the customer must provide in the traditional service view based on the output: the value created.
If you ask people who have no experience with the agile culture after a training course what the difference is between output and outcome, they usually say that it is almost the same thing. Output is the basis, so to speak, and outcome is a kind of stardust on top of it. Yet the two terms are very different in essence.
Back to the year 1908: A traditional service provider asks the customer what he wants as a means of transport (output) and receives the answer “a fast, enduring horse”. The customer’s consultant tries to avoid grinning and then explains what is in his portfolio.
When a consultant for adaptive services asks what outcome the customer wants to achieve with the means of transport and the answer is: “I dream of a fast and enduring horse”. This horse vision is not perfect, but it is an alternative whose value can be determined. With the “fast and enduring horse”, value potentials can be identified. For example, the farmer can offer his products on more distant markets. With the value potential, alternatives can be put together and developed; whether the matter goes in the direction of the T-model is decided by further development.
This is precisely the difference when you traditionally ask for an output and do not encourage a discussion about the outcome. The reasons for this are manifold and can also be internal to the organisation if IT is only seen as a support function and people think they know enough about solutions from other sources. This means you have to live with fast horses.
I know ideas of “fast horses” well. It’s great when people dare to do this. If this turns into a discussion about values and proof of effectiveness, it brings to light a lot more suitable alternatives. This is where innovation can arise.