You have probably heard of this before:
Our customers are our number 1 priority
You probably have a variation of this in your own organisation.
Is it really that simple? What about this anomaly:
As a registered user of Papa John’s pizza
When I try to check out as an anonymous user
Then I will be forced to login to my account
I have picked on Papa John’s here but we see these trade-offs all over the place. In this case we are stopping a transaction - which is not in Papa John’s or the customers interest. They do not seem in line with our statement about the customer being our number one priority.
Make no mistake, this was a choice. It takes more work to do this than to allow the transaction as an anonymous user. We don’t know why but we can assume that someone benefits from this decision – marketing or data science, would be good guesses.
So maybe it’s our view of who a customer is that is incorrect? Eric Ries uses this definition for a customer:
Any person who you hope will find enough value in your product or service to make some kind of investment in it, or partnership with you.
We are used to thinking of the paying customer as our primary focus but customers take all shapes and forms. They are often internal to our organisations.
In a world with multiple types of customers, we often impact one to benefit another. These are often hard choices.
So maybe we need to tweak our original statement:
Our customers are our number 1 priority*
*Some customers are more important than others
So if marketing teams are customers, what about development teams? Are they customers too? They are clearly invested in what we do.
When a development team wants to do something, they are usually asked about the ‘value’ of it. The problem being for most development teams that most of the things they want are only measurable in retrospect, so the value is difficult to measure or prove.
This statement from a developer, makes a lot of sense to me:
What about developers doing a good job, knowing we built the right thing in the right way and being trusted to do so. Why isn’t that valuable?
Very few of our business decisions are based on cold hard data. If you spend time with some data scientists, who ONLY use data to make decisions based on specific tests you realise that most of the decisions we make are not based on fact.
We don’t gather data either because it will take too long or we simply don’t know how.
Again, maybe our view of value is incorrect here. Maybe it’s even the wrong word. How about another tweak:
Our customers experiences are our number 1 priority*
*Some experiences are more important than others
Instead of talking about value, what happened if we only talked about the experience we want to create for our customers?
Our developers experience of building and supporting our product can been see alongside our customers experience of using it and our marketing persons experience of working with the data gathered from our customers actions.
The problem we encounter straight away is how to we talk about an experience? What is the language we use?
This is where using comic strips come in handy, which was inspired by the work Carol Grey did with Social Stories and Comic Strip Conversations. They were created to solve a completely different problem, but they work here too. If you want to find out more, google is your friend.
We use a comic strip to describe the dialog between 2 people, one of whom has used your product. This is told using only 4 cells – I usually ask people to imagine they are walking past these 2 people and overhear the conversation, which they then condense and re-tell.
The constraint of having only 4 cells means you must focus on the key things that make your customers experience enjoyable. What would we like people to be talking about if we built this? What would turn them into advocates, using NPR speak?
So, using my Pizza Problem, let’s look at what I would have liked my experience to be:
What did you get from this short dialog?
What experience were we trying to create for our customer?
What problems are we trying to solve?
The strange thing is that using dialog to talk about our experiences with products or features turns out to be a lot shorter than trying to describe it. This is powerful and you can use it to find assumptions, observations and features inferred in the conversation:
- Observations are things we can see or have evidence of
- Assumptions are thing we think are happening or will happen once we have built our product
- Features are the things we need to build to bring about the experience we describing
For example, in cell 4 there are several statements we pulled out from the dialog:
- People know their account details (Assumption)
- People who have an account are regular users (Assumption)
- Anyone can checkout anonymously (Feature)
Sadly, the feature that would have saved the day was not built in this instance. We could have probably validated the 2 assumptions using metrics:
- How often do people reset their password?
- What is the relationship between the time between logins and resetting a password?
- Are logged in users more likely to order more frequently?
Maybe all this was done and the number of people this would affect was smaller than the benefit given to the other customer by forcing a login if you have an account.
Yes, you could say that these are all ‘value’ statements but focussing on the experience stops us from ‘bundling’ more in. When this happens, it becomes difficult to separate the things that directly create the experience – this complicates delivery since we cannot reduce scope and ultimately delays our customer experience.
Exploring experiences can be done before we build anything, allowing us to examine the intended experiences and look at what creates them. We can validate any assumptions we have or articulate them as risks because we simply don’t know. It also highlights the features that we should build to improve our customers experiences with our products.
