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.

Bulk Estimation at Speed

So, today I faced a new problem. The forecasting I have been using for a while has been throwing out some dates that 'feel' very pessimistic. I want to trust them but they look wrong so I find myself with a dilemma of how to test the forecast in a sensible way.

A previous observation was that whilst asking people how big something is gives a wide range of results whilst asking them if something can be done in a set amount of time is easier to answer and is just as easy to use and interpret as a number.

So given I have a backlog of about 50 things I need to test, I welded these 2 things together and came up with the following session that I ran with my own team.

The only prep you need to do for this is to prepare 2 question cards. The first question is based on the ideal time it should take to do a story. At time of writing, my team want every story to be 5 days or less. So the first question card would be "Will it take 5 days or less?". The second question card, is the opposite extreme of that. So for us, it has gone terribly wrong if it will take 2 or more sprints which is what we have on the second card.

There should be a gap between these which is your middle ground. The observant among you will realise these options look like T-Shirt sizes - which they are! We don't ask that question - we ask is it bigger than X or larger than Y giving a wide difference. If it neither then it must be in the middle ground.

So here's how we ran the session:
Print out your backlog with title and maybe a narrative (as a... I want... so that)
Stack them in the same order as your backlog, highest priority first
Grab a selection of developers and include some QA

Put the question cards and middle ground card on the table

For each card and ask the questions

Expect discussion but keep it short:

* Encourage listing assumptions if that would make it easier to answer, document these if you can

* Re-iterate the ranges using days ("So if you started on Monday, it would be finished by Friday")

* Use comparisons ("Remember that piece of work on X that took 2 sprints, is it as difficult as that?")

* Watch out for unknowns which drive up estimates, mark these for later investigation/refinement

* Use timeboxing if you think it makes sense

Stack the card on the relevant answer card

Scoring a story whilst telling the story

I was quite surprised as how fast my team did this - 52 stories in 1hr. We can then visualise the backlog in order and colour code the cards to show us the sizes from the team. You would expect first stories to be all green and then progressively turn orange then red as we head further way from the top of the backlog.

That's not what we found. 

We found a mix across the backlog that we needed to verify. We discovered that this showed what the team did not have a good understanding of, allowing us to focus our time on refining the cards that were big because we were scared or confused by them.

As far as validating the forecasting, we could now model a series of sprints based on how long they might take which looks a little like a gant chart but is throw away so I will allow it. More importantly it allowed us to see how we might reduce some of the risk in our delivery but tackling the unknowns upfront and ensuring we only develop the smallest stories we can, which are far more predictable.

More importantly, the team found this useful as a confirmation of what we would be doing and in what order allowing them to spot things that had been overlooked. They did this by telling a story of what the system would look like as they developed each story. 

They checked the system by also finding places where a demo would make sense and the system would provide end to end functionality that could be seen and understood by stakeholders. We found having a system diagram very useful in this as the developers can point to what they are talking about and everyone understands the context.

They even asked if they could do it again, which is surely the sign of good times :)

Experiments with Emergent Leadership

My self and a colleague recently attended Tobias Mayer's Emergent Agile Leadership workshop. Part of the corporate sponsorship deal we have at my current place is that when you come back you share your notes or what you learned.

I added the acceptance criteria that whatever we did should be something interactive with the community we have, since I think note taking is subjective and nobody really understands the context. That and I hate writing notes - I am terrible at multitasking!

Then we went on the course and realised what an enormous challenge we had set ourselves. Tobias guided us through 2 days of very thought provoking discussion, mixed with some games and interactive exercises. At the end, he left us with this closer:

What is your intent on leaving here? This workshop has supplied no formula, no model, no process.

The workshop was a journey of discovery. Not something that you can shrink wrap. It was something that you can only experience. Leaving us with a lot of head scratching to do - how do we introduce some of these ideas to our community? How do we get 2 days worth of thinking into an hour?!

We started to think about how we could re-create elements of this. We wanted to create a little discomfort and we wanted people to engage in deep discussion, which was something we realised we did very little of but got a lot out of.

I also wanted a bit of quirk! So, here is what we did.

We came up with a game. In separate teams they all had to cross a river (one side of the room to the other) using only the stepping stones (a3 pieces of paper). The goal is to get everyone across, racing the other teams. There are rules but they have to uncover them. A judge will let them know when they have broken a rule - the whole team has to start over if that happens.

"Maybe, we all need to be on a stone at the same time?"

The judges are told the rules away from the group. There's actually only one - don't let them all cross! Essentially, they randomly get the team to start again. I know it's cruel.

This is to cause the team to communicate and experiment. We suspected people would jump forward into a leadership role and some would follow. We also wondered if the leadership role would be with a single person or would move through the group as they fail miserably to complete the task. Would leaders step back when others stepped forward? Would the leader help at all?

At the end of the game we asked everyone to point to who they thought was the leader. We then separated the leaders and asked them:

Were you aware you were the leader?
Why do you think people saw you as the leader?
Were you trying to lead?

The others, we separated into groups and asked them these questions:

Why did you see them as the leader?
Did you choose them or did they step forward?
Was there more than one leader? How did they share?

We then explored some of the themes from the groups. We noticed that in some groups there was no dominant leader - so it was emergent and moved around. This allowed us to explore leadership as an energy that anybody can bring on demand. We also talked about how participation is a central part of being a good citizen.

We then re-created a discussion session from the workshop, using Tobias' own content so they had the opportunity to explore and think about a specific theme. We finished up with asking the community how they would like to proceed and if they would like to explore some of the ideas a little more deeply.

Although this cannot replace the workshop we went on, we think it did get people thinking a little differently about leadership in their own teams. Many thanks to Tobias for helping us 'see it' a little more clearly.