What Jobs to Be Done Teaches us about Interviews

Over the past week I read through When Coffee and Kale Compete by Alan Klement to get an idea of how Jobs to Be Done (JTBD) can be applied to internal products.  JTBD is the idea that people “hire” products in order to get jobs done. There’s an increasing realization that it’s more useful to look at what jobs people are trying to get done (customer jobs) than trying to figure out what products people use based on shared characteristics (personas).

While JTBD mostly applies to products for external use, there is some applicability for working inside an organization. Particularly when it comes to conducting interviews.

Here are four things to consider when interviewing stakeholders prior to working on an internal product, inspired by Alan’s book and my own experience.

Why are you doing interviews?

As a starting point, understand why you are doing interviews.  And no, the reason is not because you want to get some information from your stakeholders.  It goes deeper than that.

Unless you are an overt extrovert that constantly seeks a reason – any reason – to talk to people, you need to have a purpose for your interviews.

That purpose is to see if existing systems are working the way they should or to figure out a way to reach a particular outcome. Specific cases include:

• You don’t know what a particular internal product is used for (this is often the case with reports that have been in existence for a long time)
• You need to support a new business process
• People in your organization have stopped using an internal product that was supposed to be critical to their job.
• You suspect that your internal product may be an inefficient solution
• Hidden business opportunities for your existing internal products emerge

Who are you going to interview?

The reason for your interviews impacts who you talk to.  Focus on specific people to avoid collecting data that is all across the board and tells you nothing.

• Learn what your internal product is used for by interviewing people who’ve recently started or stopped using your internal product.
• Support a new business process by talking to the people who currently do the process manually.
• Maintain usage by speaking with people who’ve recently stopped using your internal product.  Find out why they stopped using the internal product and what they are using instead.
• Uncover inefficiencies in your internal products through talking to people who use the internal product but also have work arounds for certain steps.
• Find innovation opportunities by examining people who use your internal product in novel ways.

When you limit the number of people you talk to based on the reason for your interviews, you reduce the likelihood that you get a great deal of extraneous information that confuses rather than clarifies.

How should you interview them?

Let’s face it, when you talk to people about how they use an internal product (or any product really) they will lie to you.  Most do not do this intentionally, rather they try to answer questions in the easiest way possible, or they give you an answer that they think you want.

To avoid this problem, Alan suggests using a technique based off of Customer Case Research (CCR) created by Gerald Berstell and Denise Nitterhouse.  The general premise is instead of asking people about what they think they would do in a certain situation, have them tell actual stories about what they have done.

Focus on scenarios where they have seen some form of behavior change around the use of your internal product.

This idea is not new to software development. It’s roughly the same idea that Kent Beck had when he came up with the concept of user stories:

What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. [For example,] if I type in the zip code and it automatically fills in the city and state without me having to touch a button. I think that was the example that triggered the idea. If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it? — Kent Beck via personal email, Aug 2010 From User Story Mapping by Jeff Patton (Affiliate Link)

The only difference is instead of describing something the internal product does, describe the behavior change we want to encourage through the help of the internal product. Consider that the next time you get overly obsessed with writing user stories in the proper format.

Understanding the behavior changes as well as the pain before the change and the satisfaction after the change can help you identify the Job that someone is hiring your internal product to help them accomplish.

What information do you want to get?

Since you want to know about the behavior changes that drove people to start or stop using an internal product, the questions you ask need to get at the things that drove the behavior change and the results of the change.

Alan suggested some questions that help you do that:

• Before you began using (the internal product), how did you solve these same problems?
• When did you realize your old way didn’t work?
• Was there a deadline or specific event that forced you to make a change? If not, what finally made you change?
• What alternatives did you consider before using (the internal product)? What was good or bad about each of those alternatives?
• What was the hardest part of figuring out what solution to use?
• Was there any point where you got stuck?
• With (the internal product), what can you do that you couldn’t do before?
• Did you make this decision to change by yourself, or was someone else involved?
• Besides starting to use (the internal product) did you have to make other changes in order to start using (the internal product)?

What’s Been your Experience?

Have you been able to apply Jobs to Be Done in your work, or asked your users or customers to tell you stories about how they actually use (or don’t use your product) instead of whether they would like to use your product?  Share your experiences in the comments.

If you’d like to know more about JTBD, you can pick up a pdf of When Coffee and Kale Compete at www.whencoffeeandkalecompete.com.