Understanding our customers Minimum Expected Product

In “Designing a service no-one wants to use” I discussed combining Scott Jenson’s Value vs. Pain model with the experience realms of Pine and Gilmore. The aim of this approach was to identify opportunities for adding experiential value within a service.

I am referring to those occasions in a journey that result in positive, memorable, moments for the customer. Those delightful moments that could range from a quirky fun micro-interaction, a customer fear reassuringly allayed or the discovery of an entirely new set of functionality in the service.

The role of expectation in memorable moments
Discussion around these types of moments is not new. However, what is interesting is the consistency with which practitioners have discussed the role of customer expectation in determining their likelihood to occur. Whilst flicking through an old note book from 2011 I found the following doodle to myself:

What is a peak experience for a customer?
When my expectations are surpassed and my goals are achieved

Jon Fisher, November 2011

Despite writing this alone in the pub (it was £5 for a pie and pint to be fair), it appears I am not alone in my thinking. Pine and Gilmore discuss one measure of customer satisfaction in The Experience Economy as follows:

Customer satisfaction = What customer expects to get minus what customer perceives they get.

Dave Power III of J.D. Power & Associates

Giles Colborne in his presentation Designing for Delight  talks about delightful moments occurring following periods of anxiety. It is during these moments of anxiety when a customers expectations of a successful resolution to an issue are at their lowest.

There are many other sources that discuss the role of customer expectation in perception of a service but at its simplest I like the analogy of going to the cinema.

At some point we have all left a cinema and said something like “it wasn’t as good as I thought it would be“. If we are honest with ourselves how does our enjoyment of a movie change having read numerous positive or negative reviews vs. not having read any at all prior to watching the film? What expectations have we set ourselves?

Pain Points and low expectations
The service design community has consistently advocated identifying customer pain points and eliminating them as part of best practice.

A graph showing customer journey along the x axis and satisfaction along the y axis. The lowest point on the graph is highlighted.

Existing service pain points are obviously the place of low expectations

There are numerous definitions of pain points but Ratcliffe and McNeil ( a great book on Agile Experience Design) give a nice concise summary of types of pain point in a customer journey:

  • Manual workarounds;
  • Sources of customer frustration;
  • Anywhere that involves the use of legacy technology;
  • Points of high customer attrition;
  • Sources of customer complaints.

Eliminating pain points are the quick wins of design because these are the areas with the lowest existing customer expectations. More than likely, customers have already experienced these pain points (unless its a brand new service) and therefore have their low expectations firmly set.

In contrast, when things work well people don’t want change because they struggle to visualise how it could possibly be improved (plus if we are honest they are probably scared that the design team will screw it up). Acknowledgement of this fact may be part of the origins of Henry Ford’s thinking when he said:

“If I had asked people what they wanted, they would have said faster horses.”

Henry Ford

Deriving requirements – the Minimum Expected Product?
Hopefully by now you can see the powerful role that customer expectations play in both the the perception and subsequent design of a product or service.

Sophie Dennis discussed the combination of the Peak End Rule and the Kanban model for deriving a Minimum Viable Experience at her excellent talk Getting UX Stuff Done at UX Bristol last year. In my opinion, the strength of her technique was recognising that customer expectations have to be surpassed at some point (i.e. the peak in the peak end rule) whilst recognising that, in the context of a minimum viable product (MVP), we cannot do everything and must prioritise.

The Kano model showing three lines on a graph defining basic requirements, performance pay offs and excitement generators

The Kano Model from Sophie Dennis “Getting UX Stuff Done”

To further elaborate upon her approach, my point would be that we should be determining customer expectations around functionality much sooner in the development of our MVPs.

Whilst an upfront piece of user research is often conducted by project teams to identify user needs, we are missing a trick if we do not define the expectations around these potential requirements.

For example, on a recent project me and my team had developed a prototype and were excitedly sat watching users engage in our lab. We had developed a solution for a particularly complex filtering problem that was going down a storm with users but there was one small problem. It was trickier to build and implement than an alternative design solution the team was also thinking about.

The question was would customers miss the more complex functionality if it wasn’t there? Were they expecting it as a minimum or was our observed positive reactions from customers a direct result of their expectations being delightfully surpassed? Could we choose the alternative design option to ease our build and implementation whilst maintaining an acceptable level of customer satisfaction?

Without going into further detail on the project, I hope you can see the powerful role that expectation is playing in this context.

Customer expectation is a two way street
My key point is that expectation works both ways for project teams:

  1. Understanding expectations enables us to spot opportunities for adding experiential value by surpassing existing perceptions, thus delighting our customers.
  2. But also understanding expectation enables our project teams to understand, prioritise and justifiably de-scope functionality accordingly so that we can strategically invest our time and effort in the right places whilst maintaining acceptable customer satisfaction levels.

Both of these benefits can only be obtained early in a project lifecycle (most likely when we are conducting our initial research) and only by asking the right questions. Its all well and good defining our minimum viable product as a project team but perhaps a better way of looking at it would be to define the Minimum Expected Product from our customer base.

Viewed from this perspective we would then be in a position to both optimise our design efforts and delight our customers. Truly a happy place to be!

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.