In our experience, structured customer development work is right up there amongst the most valuable things a founder can do in the early days of their startup. Once you have an idea that feels strong, it’s imperative to speak with customers about it. But good customer development is tough to do. It takes a long time, think 10-20 hours of interviews plus preparation and digest time, and conducting structured interviews with strangers is outside the comfort zone of many founders. So lots of entrepreneurs skimp on this vital piece of work. That’s a bad decision. It leaves you flying blind when with a little hard work you can be seeing clearly.
Let me use the Jobs To Be Done (JTBD) framework for product development to explain why.
Reams have been written about the JTBD framework. I will give you a high-level summary here, but if you are building products then I recommend spending some time with Google to find out a bit more.
The core idea of the JTBD framework is that customers use products or services to do a job for them (in the US many people say they “hire” the product or service to do the job, but that doesn’t translate too well into UK English so I prefer “use”).
For example, I used my bike to do the job of getting from home to work this morning. I could have used a bus or a tube, but I used a bike.
That job breaks down into component parts. I have to access the mode of transport, pay for it, travel, dispose of the mode of transport at the other end and maybe get from the disposal point to my final destination. With my bike that breaks down to getting it out of the bikeshed in my front garden, no payment, cycle for 15 mins, put it in the bike rack in our office garden, and then walk five metres to my desk. If I was getting the bus the breakdown would be walking to the bus stop, paying with my iPhone, sitting on the bus for 30 mins, getting off the bus, and walking 200 metres to my desk.
Each of those component parts has associated outcomes that I’m looking for. Some of those are functional and others are emotional. Taking the travel component of the job, the functional outcomes I’m looking for include speed, comfort, exercise and predictability whilst the emotional ones include safety, anxiety, and consistency with my identity as an active person.
Those component jobs could be broken down further and then there would be outcomes associated with each job at the next level of detail down the stack. Part of the art of using the JBTD framework well is picking the right level of detail to work at.
The work I’ve described so far is a desk exercise. That’s valuable, but the real insight comes from talking with customers to discover what’s important to them, how satisfied they are with their existing provider, what needs to change and how much they would be willing to pay. The focus should be on the outcomes they want and their answers will tell you what features you need to build and where the opportunities for differentiation lie.
Before you start you will probably have a gut feel for the answers customers will give you to these questions. I originally titled this post “Two compelling reasons to do structured customer dev” because unless you do it you won’t know whether you are right or wrong until you’ve invested the time and money it takes to design your MVP, build it, release it and find some customers. Now that we all follow lean development methodologies mistakes are much cheaper than they used to be, but they are still a hell of a lot more expensive than 10-20 hours of customer dev.
Common mistakes which lead to wasted effort include building a feature to drive an outcome that isn’t important to customers and not realising that an outcome provided by competitors is important for customers. This second one is particularly dangerous as it will result in low conversion and might lead you to the erroneous conclusion that your point of differentiation isn’t resonating (a false negative).
The second reason to do structured customer dev is that the interviews can yield insights which drive marketing. An example from Photobox. They sell personalised photo gifts, photo books, mugs, calendars etc. Using the JTBD framework they established that one of the jobs they do for their customers is help them remember when a birthday or anniversary is coming up and they need to give a gift. Through the customer interviews they discovered that remembering and not forgetting had very different emotions associated with them. Remembering something is nice, but not remarkable, whereas not forgetting means avoiding all the anxiety associated with forgetting something important and letting someone down. They used this insight to change the subject line in some of their reminder emails. The message moved from “remember XYZ” to “don’t forget XYZ” and the response rate was much improved.
I could go on for ever about the importance of customer dev work. It really does make a huge difference. The reason many founders skimp on it is that the benefits often seem a bit nebulous. I hope they seem less nebulous now.
A quick shout out to Dave Wascha from Photobox who was kind enough to spend time with the Forward Partners team on Monday educating us about the JTBD framework. His talk was the inspiration for this post.