Category Archives: Voice of The Customer

by - 25 Comments

Failure Demand – A Starting point for Outcome Driven Collaboration

Quite a while ago I was introduced to the theory of Failure Demand. Failure Demand has been defined by System Thinker John Seddon as “demand caused by a failure to do something or do something right for the customer“. It is probably a Customer Services department of a company that can relate to it the most e.g. through Customers with repeat calls, because their problem has not been solved, despite the promise made. I agree with Tripp Babbitt, that failure demand can cause between 25 % en 75 % of Customer services work. In itself this is not strange (it is what you have Customer services for), yet I also think that the majority of failure demand can be prevented. How? I will address this in a second post on this theme, next week.

In this post I would like to focus on the implications of changing the definition of Failure Demand and, by doing so, broadening the scope and application of the principle.

Failure Demand Redefined

Coming from a Customer services background and with extensive personal experience in analyzing root-causes for failure demand (use of terminology in hindsight by the way) I came to think that Failure Demand, as a concept, can have a much broader impact and applicability, if we change the definition to what it really is:

Failure Demand is the consequential act, or non-act, of a Customer when his desired outcomes are not met.

Why is it important to redefine Failure Demand

For me, the importance of redefining Failure Demand lies in the following: I believe it is important that there is some kind of general accepted vocabulary that can be used across industries and disciplines. If we are ever to establish good collaboration between company silo’s it is needed that we all understand what we are talking about. As you might already know I believe collaboration (and its superlative “co-creation”) is at the center of a Customer centric strategy. Such a strategy even requires collaboration to extend outside the company with Customers and partners.

The traditional definition of Failure Demand makes a good case of tackling the consequences of a failure to act or a failure in acting by a company on its own work. I believe  it is a powerful concept from that angle. Taken from the angle of putting in place a Customer centric strategy, like Social CRM, designing great Customer (Service) experiences and Innovation, the “traditional” definition falls short.

Implications of Failure Demand for Service (Experience) Design and Innovation

Service (Experience) Design and Innovation should focus around Customer’s needs and desired outcomes.  In essence this is what putting Customer needs at the center of your Business Strategy is about.

I believe it is important for both Service (Experience) Designers and product/service Innovators, as much as it is important for Business Process Engineers, to understand that their insights will be enhanced when starting their approach from an outcome perspective and that they can also learn a great deal from understanding Failure Demand in their own organizations and from their own products and services. Furthermore I believe all functions mentioned in this blog-post should collaborate closely to really address the issue. It stretches far beyond Customer Services and the back offices. Analysis of Failure Demand, even in the “traditional” definition, is probably a very good first step for such a collaborative venture to improve or innovate the Customer experience. At the same time, understanding where your products and/or services fail to do the job that Customers want to get done, will help you best understanding where you need to focus your improvement or innovation efforts.

Extending to the above and my proposed definition, Failure Demand can even be regarded as a failure in Customer demand from an economic perspective: lack of (repeat) sales and revenue. All as a consequence of not meeting desired outcomes. From this perspective failure demand enters the world of marketeers and strategic business development too. A perspective well worth a try if your short of demand in current economic times. And who isn’t?

To conclude

Failure Demand, as a concept, provides great insight in the inability of the Customer experience (design) to provide for a Customer’s desired outcome(s). Failure Demand cannot only explain the level of extra work to be done as a consequence of failures by the own organization, it can be a powerful concept that contributes to the field of Service (Experience) Design and Innovation. Failure Demand can well be the starting point for Outcome Driven Collaboration.

I will blog on my approach towards failure demand analysis next week, to further outline that perspective. In the meantime let me know what you think. How could you apply Failure Demand in your work?

Reblog this post [with Zemanta]Worth to read:
The Customer Centered Innovation Map
Strategyn: What is Outcome Driven Innovation
Service Design – practical access to an evolving field

by - 4 Comments

Don’t take your Customer’s word for it!

This week I had a conversation in which a friend said: “Bad results begin with bad assumptions”. We scrabbled around with the theme and got from “Assumptive Bias” to  “BIASsumptions” (which is not an actual word unfortunately). A fun to have conversation, but I believe underlying is a serious matter that brought me to write this post.

Let me start by saying that some form of guessing or interpreting facts is inevitable when you are embarking upon new roads, trying out stuff, experimenting or analyzing e.g. process failures and their consequences. ” Assumptions” are not the problem. It is how we treat assumptions and what we believe are good assumptions that worries me. My 3 main worries about assumptions are:

  1. Assumptions are often built upon “common knowledge or understanding” that are presented as facts
  2. When used for building business cases assumptions are hardly ever checked in hindsight
  3. Attempts to validate assumptions lead to “biased”  research aimed only to prove one’s assumption is correct

Assumptions based on Common Knowledge or Understanding, not supported by facts

I wrote about one of the most sticky assumptions, which is regarded knowledge in the Customer Services arena, before: Why keep chasing the wrong Goose? The assumption I’m talking about: One should pick-up the phone within (on average) 20 to 30 seconds to keep customers satisfied. As this might be true for a specific company, it is most likely not to be true for all companies. It actually doesn’t matter if it is true or not in general. What does matter is if it is true for you, or better, if you can change it to: what is customer waiting time tolerance for your company? For a good example on how one could prove what’s true for your company, take a look at this post by McKinsey. Research based on the facts & data of your company is the best you can get. You have it, why don’t you use it? As the example shows: a lot of waste can be prevented.

Assumptions are hardly ever checked in hindsight

Much attention gets paid to the assumptions in preparing a business case. It therefor has always surprised me how little time is taken to review afterwards, whether the business case came through or not. In both cases this is missed opportunity. First of all you can learn from the validation of your assumptions. It might be your assumption came through, but the result of your business case didn’t, or the other way around. There is always a great learning potential by checking in hindsight. Best case: you have proved your assumption for this business case. Now you know it is a better assumption for your next business case. But never forget: even if it came through 2 times or more, you need to check every time. Don’t miss-out on the opportunity to learn.

Biased research

The first two are about failing to check, my last one is about poor validation. The issue here is that most people tend to look only for the positive proof of the assumptions they made. We often disregard completely the proof against the assumptions. It is not only scientifically better to make a real effort to not prove your assumptions, it also makes your assumption (much) less of an assumption if it comes out as true (or highly correlated at best actually). True validation is about checking both sides of the coin.  It will provide you with great (personal) satisfaction if you do, even if your assumption proved false. At the same time you might have saved your company from adding more waste to the bottom line.

Bad results begin with hypotheses poorly validated

The best way to take the turn away from Assumptions in your business cases, plans or analysis, is to change from Assumptions to Hypotheses. As discussed above, assumptions are regarded truths without the facts supporting it, are poorly checked and often a result of bias. Hypotheses are not about that. Hypotheses are screaming to be challenged. Change your assumptions to hypotheses the next time you need one and dig in the facts.

And, if you get any of those facts from Customer Surveys, don’t take your Customer’s word for it: you have another Hypothesis in your hand..

What do you say?: will you start working with hypotheses and walk away from assumptions?