One of the usual ways to design a product is by looking at the average characteristics of the target users using personas. This approach to make products useful has been around for many years. It the standard used by product makers and marketers.
Clayton Christensen, who popularized the Jobs to be Done approach, argued that people with very different characteristics use a product generally the same way. A highly educated grandfather in the suburbs will use the radio the same way a young girl from a remote settlement area would. If we were to base product design on characteristics then, we are sure to fall short. There has to be other ways that will help determine if a product is just right, or needs more work.
The Jobs to be Done approach opens up the perspective of what a customer needs and what motivates them to use a product. By getting into the perspective of the user and seeing how a product is used, the Jobs to be Done approach is an efficient way to cross-check whether a product has the correct features that is useful for the customer.
Marketing A Milkshake
In the early 2000’s, Clay Christensen shared the results of their research study that tried to improve the sales of a certain restaurant’s milkshake. Using the Jobs to be Done approach, they tried to answer the questions, “What is the job that the milkshake should be doing? Would customers hire the milkshake for that job?”
In the iconic Milkshake Marketing study, morning commuters and drivers hired the milkshake to do what this big, bulky breakfast case does.
The research team examined when, how, why people buy the milkshakes. They also looked at the alternative products people buy instead of milkshakes. They discovered that customers were “hiring” the milkshake to be breakfast-on-the-go that’s easy to get, consume and dispose before getting to the office. People bought the milkshake because they were driving and sitting in traffic on the highway. The thick milkshake was slow to consume and could last the trip. They could suck on the straw and have a meal whilst driving. It was also in a container easily held by one hand, plus usually had no spills. In contrast to other breakfast on the go products, having bagels or doughnuts was messy while driving to work.
Once the research team understood the job to be done, the restaurant understood it didn’t need change the product, rather they improved the method of delivery. The store introduced a way for people to buy it faster using dispensing machines so they could buy it faster on their way to work. The results were extraordinary.
However, don’t throw away your personas just yet! They are still useful for crafting your marketing messages.
How to Make Products Useful
For product makers, this approach can be done following simple steps. Imagine your customer telling you their story why they need your product.
1. Fill in the blanks to determine the customer’s situation, motivation and outcome desired. This quick formula is from Intercom. (Thanks, Intercom!)
[ When _____ ] [ I want to _____ ] [so I can _____ ]
‘When ____’ focuses on the situation,
‘I want to ____’ focuses on the motivation, and
‘so I can ____’ focuses on the outcome.
2. See the workflow of how a customer uses the product. Determine the friction points that make it difficult to use.
3. Compare the other products being used to arrive at the same outcome. Sometimes they will not be products of the same kind, like milkshake and bagels, but still satisfy the customer for the same purpose. See if the competition addresses 1 and 2. What would you do about that to make products useful?
4. What are the things that people would protest to before they use your product? What would you do about that in your design?
5. What are the cool things about your product that people would like? Would it address the user’s motivation, outcome desired, or do away with a friction point?
6. Don’t make your product do the entire customer workflow. To make products useful, choose the steps where your product can add value. Stop focusing on workflow steps that are already being commonly provided by other established products.
An example to bring jobs to be done to life
Let’s take for example, a food delivery mobile app. Hungry customers are more impatient than the usual impatient customer. There is no space for the luxury of empty seconds with hungry customers. They want the assurance that food is on its way the second the mobile order is received. The only challenge to hurdle for the food to start moving is finishing that order on mobile. Using this method, we can think:
“When a hungry customer decides to have food delivered, s/he wants to quickly get the order over with and be assured the food is coming, so that the hungry customer can proceed with the tasks that kept the customer from making food or going to the restaurant in person.”
From this general statement, one can have a more itemized string of needs. A customer might say, “When I am hungry and want to order through a mobile app, I just want to see first if I can order from that restaurant so I can move on to the next restaurant if not.
- Is the restaurant open?
- Does it deliver in my area?
- Does it accept my payment options?
If I can order from the place, I go in to the app,
- Put all my info (this long typing on the phone is nerve wracking for me when I am hungry, but I have to, so that’s fine.)
Then I want to
- See the food items (“When I’m in a hurry, the name of the dish and pictures are enough for me to order.”)
- See how much each item is
- Quickly tick off what I want and
- Put how many
- Check the total, and
- Be told that that order got through.
From this brief story, one can now gather a list of features that will be useful for customers.
The friction points can also be identified, such as
- Quickly determining if the restaurant can deliver food
- Typing addresses over and over (everyone hates typing in the same info each time!)
Further examination could be into competitor restaurant apps, other ways a busy person will get food, and other reasons why a customer will not use the app. This will guide the designer to provide a seamless ordering experience, temporarily satisfying a hungry customer that food is on its way.
The Job Story
After examining your customer’s story, replicate the steps and look at the many situations the customers will end up in while using your product. These are called the job stories, or the jobs that your product has to do.
Decide if that job story has to be addressed as a feature, or if it should just be ignored. As I always teach, exercise restraint to develop the best product there is. I blogged about how restraint helps make products useful here.
If you understand why people hire your product (“the job”), then the product will flow from that. Everything becomes much easier.
Tell me what you think! Is your product ready to be “hired”? If you would like to share about any product you think is doing what it should or shouldn’t be, comment below.
I’m out like personas for product development,
Ebook: Intercom’s Jobs to be Done