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.

So, who is the customer exactly?

The term customer is often used in agile teams to represent who we are delivering value to.

The problem is that the larger the organisation, the more difficult it is to separate value in terms of things software teams can deliver and financial value placed on those things by the institution buying them.

In a previous role, my company sold software to the NHS. Part of my challenge was to connect developers with the value they were delivering. The challenge with this was the sheer number of people that were involved with the software, each of whom derived a different value from what we sold.

The NHS is split up into trusts, which are spread throughout the country. You don't sell to the NHS, you sell to a trust and each one is independent even though they all contribute to the same national charter for healthcare.

The trust itself could consist of multiple sites which offer services, each of which might have different requirements depending on the services they deliver. Each trust has it's own IT departments and generally a project team for a large deployment. The project team will be looking after how the solution is implemented. They will also have accountants looking after the financial aspects of the project.

The project team work across the different departments that will be impacted. During a tender they will consult with the heads of department and consultants that work in those departments. There are also doctors, nurses and other support staff who may be consulted.

As you can see there is a bit of chain forming and each level of this chain is looking for a different aspect of value from the delivered solution.

At the top you could say this is predominantly financial - how much the thing costs to implement, support and run. The project team are interested in the financials, but more so about what the solution does and how it fits in with their existing infrastructure. At the bottom you have the people who use it, who's concerns are solely with the software itself. They have no interest in how much it costs, just what it does.

For me, this does not still describe the true value of the systems the NHS use since the customer is actually the patient. They do not use the software but without them there is no point to the rest of it. Continuing one level further down the chain reveals a better way of understanding the value we deliver. In this example, everything should positively impact the care of the patient.

Indirectly, this could be reducing costs for the trust. Lower costs mean more funds for the care of patients, however the trust chooses to deliver it. Directly, it could be managing the information gathered by the hospital to provide the best care for the patient by the doctors, nurses and specialists who use the software.

In every system, there are multiple customers and the value they want from the system will vary. In each case, there is at least one core person or group who benefits - removing them, removes all value from the chain. Finding that person is key to understanding the true value of what is being delivered.

Connecting developers with the customer's problem

The holy grail may be that developers engage with their customers but there are plenty of situations where this can be difficult. Sometimes, it is also unclear who the customer is especially when the product is sold to public institutions - is the institution the customer or the members of the public that it serves?

I found many companies still have barriers between the developers and customers. Although they are often working to break these down, institutional change is usually slow. The more people in the way, the more chance the 'why' is lost and the problem is not addressed.

I wanted to come up with a way to connect the developers with the concerns of the customer irrespective of how removed they were. Collaborating with Dan Rushton, we started to think about conversations that would help make that connection.

All the way through this, I had Melissa Perri's excellent phrase 'Problems not features' ringing through my ears. I wanted to expose the problem we were trying to solve for the customer.

We eventually came up with a concept where we imagined the developer overhearing support calls in a call centre. We saw this as the primary interface for many customers with the companies that provided them with services. We also felt that this would be how a company would get most of it's feedback about it's service.

We thought that overhearing the customer explain the problem they were experiencing would provide excellent context for the developer to better understand why we were building something to solve that problem.

Our first thought was to simply role play a conversation but felt that this would not involve the whole team and could make people feel awkward. We wanted it to revolve around a conversation that was focused but also collaborative.

We then started to think of a storyboard that we could create to convey a conversation. Knowing people can be a bit funny about drawing in groups (unless you work with creative types of course who usually ask for more art materials), we came up with the a neat idea that we called a Situation Card.

The Situation Card is a bounded box and contains a single character in the form of a stick man. A simple conversation needs only 2 types of Situation card - one for the customer and one for the call centre member of staff. More complex conversations can use more types of cards - we created ones for people doing surveys, developers working at their workstation, people on their mobile phone etc.

The character is in one corner and has no face allowing the team to add speech bubbles, thought bubbles, facial expressions etc to convey the content of the conversation.

We found A5 was a nice size. Laminating them means you could re-use them. Here is an example of a Situation Card for a person on a mobile phone:

The conversation is told through a series of Situation cards laid out like in a line or columns like a comic book or story board. You can limit the amount of cards so that the conversation is short and concise - you can also refine or refactor pretty easily since cards can be removed and rewritten easily.

The idea is to tell a story and link the problem the customer has with the feature of your product that solves that problem. In telling the story you can use cues like 'If you could hold the line, I just need to check with my manager' to stimulate conversation in the team and check facts or confirm understanding before continuing the conversation.

The conversation can start off as a complaint and then be refactored to a support call, where there is a happy ending since we have the perfect feature to the solve the customers problem. The process of creating the conversation allows the team to better understand the role of the feature. We also think it could be a good way of exploring if a feature does what we think it does, although we have not tried that yet.

In the experiments we have had so far, we found this useful for connecting the problems of the customer with an unseen bit of infrastructure or service which has no interface as such but still has a part to play in the service being provided.

Still a work in progress, I will post up some examples as soon as I can.