This website or its third-party tools use cookies which are necessary to its functioning and required to improve your experience. By clicking the consent button, you agree to allow the site to use, collect and/or store cookies.
Please click the consent button to view this website.
I accept
Deny cookies Go Back
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

KBP Media

Just-in-time resources for product people

  • About
  • Blog
  • Contact
  • Follow
  • Login

Kent McDonald / May 3, 2017

What Jobs to Be Done Teaches us about Interviews

Photo Credit: https://unsplash.com/@alejandroescamilla
Photo Credit: https://unsplash.com/@alejandroescamilla

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 over 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.

Filed Under: Product Management

Inside Product

Previous Post: « KBPUpdate April 19, 2017
Next Post: KBPUpdate May 3, 2017 »

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search this Site

Free eBook and More

Join our Free Member Content Library and receive access to all our free content, including the free eBook: Product Ownership in the Wild!

Sign Me Up!

RSS Inside Product Latest Issues

  • Business analysts’ questions about agile December 7, 2019
  • BBC Questions – Roles November 23, 2019
  • You aren’t product focused if you don’t care about outcomes and outputs October 26, 2019
  • You are not alone October 11, 2019
  • Context is key when learning about product management October 4, 2019

Connect

  • Email
  • Facebook
  • LinkedIn
  • RSS
  • Twitter

Footer

Contact Us

3232 190th Street

Prole, IA 50229

515.344.3290

About Us

KBP.Media provides services and resources that help product people deliver powerful internal products. 
Learn More

Inside Product

Get a weekly rundown of just in time resources for product owners, business analysts, and product managers. 
Signup

© 2019 KBP Media · Rainmaker Platform

Privacy Policy

  • Home
  • About
  • Contact
  • Privacy Policy