Accelerating product discovery using experiences

I am a DIY fan. I like building things and over the last year I have had to try a load of new things since I was low on cash but had time to spare.

Recently, I have been doing some tiling and found working out where to start tiling a wall actually quite difficult. There are indeed 'apps for that' I had a look around and nothing really did what I wanted so I thought I would build something for fun.

Instead of pile straight into some code I stopped and took some of my own advice. I recently wrote a little about using experiences to help discover product features, so this seems like a good opportunity to show how this works.

So after about 7 minutes of 'work' I came up with this comic strip which is explains my experience of tiling a wall in my kitchen:

This small dialogue describes the experience I had. I call this a negative or problem story - it explains the problems I had and gives some context of why.

As product developers we can dig a little into this dialog and find extra detail in the conversation. In a problem story, this is all about what has happened so we can expect to find some observations and assumptions. The difference between the 2 is simple - one is observable, something we know is happening and the other is something we think might be happening.

For each cell of the comic strip we quickly extract some key words or maybe phrases (1 word definitely, may be 2):

Cell 1: pride, amateur, mistake, research
Cell 2: ignorance, questions, previous work
Cell 3: lesson, impact, planning, difficult
Cell 4: surprise, assumption, simplistic

Next I would create some statements for each cell which would describe our keywords in a little more detail. Some statements might cover several keywords and that's fine. I also categorise what I find as an assumption or observation:

Cell 1
"People like to take pride in their work" - Assumption
"Some jobs take a considerable amount of effort" - Observation
"People look up things if they don't know how to do them" - Assumption
"People want to learn from our previous mistakes" - Assumption

Cell 2
"Some people might not know what a good job looks like" - Assumption
"Given different jobs some people will still not be able spot the problems" - Assumption

Cell 3
"Starting correctly helps ensure the job goes well" - Assumption
"Specific problems can be avoided through forward planning" - Observation
"Knowing what to look for is not obvious to everyone" - Assumption
"Even when you know what to do, it might not be easy to do in practice" - Observation

Cell 4
"People might think they know what to do when they don't" - Assumption

I am doing this solo and I would recommend doing this in a group so there is a conversation around these experiences. By doing this by myself I am subject to my own biases but you should get an idea of how this works.

As someone building a product, a probably spending a while doing so, I am particularly interested in the assumptions I have listed. I can zero in on the one that bothers me most and tackle just that or I could list them out in order and tackle all of them. At this point it's all about visibility - given what we know now, is there anything we should test before we proceed?

As someone thinking about making something to solve a specific problem, a couple of these are troubling:

"People look up things if they don't know how to do them"
If people don't they will never know there is something that might help them! I would want to be pretty sure that people will research about how to tile rather than just doing it. If they won't seek out information they will never find something that could help them.

"People might think they know what to do when they don't"
Similar to above. Often called "unknowns, unknowns" these are things have complete ignorance about and would not think of getting outside knowledge about.

"People want to learn from our previous mistakes"
If people don't want to then any amount of information that might help them wont make any difference. They won't find out how to do it properly because they simply don't want to!

As product team just starting I would look at these as elements of risk. By proceeding without testing these assumptions, we risk our product not being fit for purpose. If we think the risk is small enough - or we feel confident about our market experience etc etc - we could proceed and convert these into risks.

The observations might help us target anything we build at our target audience a little better:

"Some jobs take a considerable amount of effort"
Helping people to not waste time or materials doing the wrong thing could help us sell our product.

"Specific problems can be avoided through forward planning"
Offering something that helps avoid common issues could also help us sell our product. "Canning" expertise and providing this knowledge in an easy to use format is something people find useful.

"Even when you know what to do, it might not be easy to do in practice"
There are some things that are just difficult. If we can solve that problem, we have something that people might want to use.

I have done this exercise with several groups of people and I am always surprised by the insight that is generated by this - we always find something interesting. It's also very fast - doing this including writing this blog has taken about 45 minutes.

You can scale this with larger groups by using a technique called "diverge and merge". Multiple, smaller groups do the same exercise and then you merge these together. Similar comic strips represent similar thinking, which is valuable since everyone is thinking the same thing. Divergent comic strips give allow us to explore our scope - we can ask if these are valid and maybe spend some time on them or we can ignore them depending on what they represent.

So far we have explored the problem, how about the solution. Comic strip conversations can be used for that to.

This time we put ourselves in the future and describe the experience we want our customers to have once we have built our product.

As I mentioned in my previous blog, asking people to imagine what they would want to hear people talking about is a great way of thinking about the experience we want to create for our customers. In NPR speak - "What would turn our customers into advocates?"

This time, we have an additional thing we can extract from the conversation: features.

Features are things we need to build in order to bring about this experience. We still have observations and assumptions but the assumptions are slightly different - these could be assumptions that are based on us building our features. So assumptions could be present now or they could be assumptions that we will only realise once we have built our feature.

Since we have already done this in some detail, I will call out the features only which are all in Cell 4:

"There is an app that someone can use"
"We can calculate the number of tiles you will need for a specific job"
"We can predict the best place to start tiling"
"Different size tiles mean different calculations"
"Different tiling patterns mean different calculations"
"Common planning problems are avoided"

All of these are features that support the experience we are describing. There could well be more but by just looking at the experience we want to create, we can focus on what will directly support or generate it.

Done in a larger group you will end up with several types of experience. You can then order these however you wish, allowing you to focus on the ones that create the impact you want to have with your customers.

As a product team, look at what we have to kick our project with:

• Assumptions we might want to test or convert into risks if we decide we want to continue
• Observations that support our product idea and help us find customers that will benefit from it
• Features that generate experiences that we want to create for our customers

Next steps are up to you but you could take the scope from this and go straight into a story mapping session. The advantage of focusing on the experience means that the scope you have will directly contribute to what you need to build for your customer.

Did I mention it's fast?

I would love to hear your experience of using this. I have documented the method I have been using and provided templates for creating your own comic strips which you can download from here. Let me know how it goes.

Experiences vs Value

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.