Recharge Unconference: Jobs to be Done and Libraries

December 11, 2015

Back in October, I was able to present the jobs to be done interview framework to librarians at the Recharge Unconference. It was a great opportunity to think through how “jobs to be done” could be applied to libraries and user interviews.

A little background

I first learned about jobs-to-be-done from the (defunkt) Successful Users podcast. They devoted several episodes to an interview about buying a car. One thing that intrigued me about the approach was that it really tried to get at behavior and motivation. I have often found that UX work is very goal oriented (and rightfully so). But sometimes by focusing so much of if something happened or not, you don’t really get at the underlying causes for the behavior. So the lesson has to be relearned the next time you’re developing a product or service.

The framework came from research done by the business professor, Clayton Christensen. The idea really comes from the world of market research where the norm (at least in Christensen’s argument) is to divide the world into product categories and market segments. Marketers then need to find the right combination of categories and segments to be successful. You can download the paper, but it’s not free.

The world according to jobs to be done, however, is more fluid. People approach products from the point of view of a “job” they need to accomplish. And these jobs can be very idiosyncratic. In the case of milkshakes, Christensen’s team found that people bought milkshakes to occupy their time in the car.

Thinking about the world this way really forces you to unseat your assumptions and bend your brain around the weird things that people do. A perfect topic for a unconference all about recharging through new perspectives.

The presentation

I did two sessions of the presentation, which proved to be a bit more challenging than I expected. In either case, presenters were (re)charged with conducting a very hands-on, interactive workshop for the participants. Accordingly, I structured the presentation in the following way:

  • Short presentation and overview of the framework
  • Brainstorming session
  • Short user interview
  • Interview analysis

I really made sure to get to the last part, because one of the harder things about UX work (I’ve found) is understanding how to take the very messy data you get from your research and making sense of it.

To accomplish all of this, I gave the participants two worksheets: an interview guide and an analysis worksheet. Feel free to use these and let me know if they’re helpful at all.

Who is the master now?

One of the personal risks that I took was presenting these ideas as very much in flux and something I was actively exploring with the group. I very openly said to each session, “I need you to help me understand how this applies to libraries.” The first group I felt was a bit more receptive to the approach and it goes to show you never quite know what kinds of expectations people bring to professional development events like this.

Aside: When I planned and ran pd events for teachers this was always an issue. Some people wanted to absorb information from an expert whereas other wanted to test out new ideas and explore. Not to say one is better than the other, but it can be hard to please both groups in span of just a few hours.

I think the groups came up with interesting insights form their interviews, but I realized after the fact that I hadn’t done enough to help people make the mental flip that “jobs to be done” requires. Getting at that underlying motivation and the problem that transcends product categories and market segments is trickier than I expected, but certainly worth the effort.

Handouts and presentation