How to Interview for JTBD

Photo by rawpixel on Unsplash

[T]he Theory of Jobs to Be Done [..] focuses on deeply understanding your customers’ struggle for progress and then creating the right solution and attendant set of experiences to ensure you solve your customers’ jobs well, every time. — Competing Against Luck

Here is how we do JTBD interviews at Cete, in meticulous detail, to help you get the best possible results.

Interviewing

The process we’ve been following so far:

1. Define a problem space
2. Find customers
3. Setup the interview
4. The interview
5. Codifying results
6. Iterate
7. Generate Insights

1. Define a problem space

Pick an area that you want to focus on, and get the Jobs To Be Done for that area (either come up with some yourself, or use previous interview results — see Step 5: Codifying Results).

Grab the top 3–4 Little Hires (ie; practical things the user wants to make progress in within the problem space). These form the basis of your hypothesis going into interviews.

You stop interviewing when you have enough knowledge to accurately predict if your hypothesis will be true or not before an interview — ie; when you learn nothing (or very little) new for each new interview, you’re done.

2. Find Customers

You want a range of customers:

• Happy with current solutions (aka: Hires)
• Dissatisfied with Current Hires
• Non consumers
• New users
• Old users

They can be one or more of the above, in one or more of the Little Hires from your Hypothesis.

3. Setup The Interview

First Contact

Leverage your network to start. Reach out to them with a friendly “hi”, and ask if they’d like to help out on the project.

It can help to sweeten the contact by offering to buy them lunch or a coffee.

Here’s an example sent via a Twitter DM:

Hey Sam, As part of the events platform, I’m doing research into how organisers manage their speakers. I’d love to get your insights and experiences with running [event] if you’re happy to share?

We’d go over what your current processes are and any pain points you have as part of that, followed by a quick walkthrough of a prototype.

If you’ve got an hour free this week for lunch or a coffee, I’d really appreciate your time and thoughts.

For cold contacting someone, you might need to change the language slightly. Here’s an example:

Hi Jessica,

My name is Jess Telford (https://www.linkedin.com/in/jesstelford), I’m the CEO/co-founder of Cete, a new platform for managing local, structured tech events based here in Sydney.

I recently saw your two events on [website X], which linked out to [website Y]. It piqued my curiosity about your reasons to list on [website X], but take registrations on another, custom site.

It’s early days for the Cete platform, so to make sure I’m solving real world problems, I’m initially focusing my research into how organisers manage their speakers. I’d love to get your insights and experiences with running these events if you’re able to share? I’m not trying to sell anything.

It’s an hour of your time, where we’d go over what your current processes are and any pain points you have as part of that, followed by a quick walkthrough of one possible prototype. Hopefully what we build can ultimately improve your experience running your events.

If you’ve got an hour free this week, I’d really value your time and thoughts!

Regards,

Jess.

Asking interviewees for introductions is very useful too — you can often find people you would not have come across otherwise this way.

Booking a time

Avoid the back-and-forth of “when are you free? How about this time? blah blah” at all costs. Have an easily sharable calendar that the user can click to setup a time. I’ve found success with Appoint.ly.

Find a location

Go to them. Don’t make them work for it. They’re often busy, doing this out of their lunch or spare time, and probably don’t really know what to expect.

The best places are cafe’s that have light / lunch food, or not-so-busy restaurants.

You want somewhere you can setup your laptop (to take notes), but that is relaxed, and not so noisy you have to yell.

4. The Interview

This is the most important part.

There are lots of techniques about for how to interview, and I’ve adopted some of their points for conducting mine (for better or worse).

I usually follow a timeline something like this:

• Greetings & thanks for taking time. Also confirm they’re happy that you take notes.
• Background on what I’m doing / why I’m doing it (“I love events, have been involved for many years, etc”)
• Background on why this user is someone we want to talk to (“Hopefully our platform can help you!”)
• Gather some demographics info
  a) What events / groups / talks submitted / etc
  b) How long have you been doing that?
• Start building up a timeline in reverse.
  a) Ask when was the most recent instance of X? (ie; most recent time you submitted a talk, or most recent time you organised an event). Eg; “When was the last event you organised?”
  b) Ask about the details of the instance itself; “How many people” / “Where was it?” / etc. Eg; “And it had how many speakers? And those speaker’s bio info was listed on the event?”
  c) Step back in time and ask how they got there for one specific detail. Eg; “How did you get that bio info onto the event page?” “Ok, you copy+pasted the details in”
  d) Step back in time again a little way. Eg; “How did you get those details in the first place?”
  e) Occasionally stop to replay the timeline forward to make sure everything is correct. This gives both of you a chance to see where a hole exists, some gap in steps that were taken. Don’t be afraid to jump back in and fill those gaps before moving on
  f) Don’t be afraid to go very very far back in time. It’s ok to keep pulling on the thread to see what else unravels.
  g) Pay special attention to the tools they use, and the way they solve the JTBD from your hypothesis.
• Go through the JTBD of your hypothesis with them to make sure you covered everything, and to see if it triggers some other memories.
• Ask “Why? Why do you [run an event|speak at events|attend events?]”
  a) Really unpack their motivations, don’t settle for “Because they were looking for an organiser”, probe deeper “When you saw they were looking for an organiser, what were you thinking you’d get out of being that organiser?”
  b) This is important as it informs the Big Hire Job To Be Done, which is the underlying motivation of why people might seek out our platform if we’re able to address that Job.
• Now is the only time that it’s ok to ask a generic “Is there anything I’ve missed? Any blanks you want to fill in?”
• Thank them for their time
• Ask for introductions to anyone else they may know who had similar experiences.
• Ask if they would be willing to test out a prototype in the future.

Things to avoid:

• Don’t ask generic “What are your main pain points?” Most folks can’t answer off the top of their head, and if they do the answers are often too generic, or oddly specific / minor.
• Avoid leading questions / examples. You want them to use their own analogies and examples, and don’t want to take them down a path they otherwise might not have gone.
• Don’t run over time.
• Pay attention. It’s hard to multi-task (note taking and engaging in conversation), but it’s 100% important that you show you’re present for everything they’re saying and can keep the flow of conversation going.

After the interview

• Thank them for their time (via email, twitter, etc).
• Send through a blurb they can forward on as an introduction to others. For example:
• Here’s that blurb that you can send on to other organisers you know:

“Hi, my name is Jess, I’m based out of Sydney, and have been looking at the platforms available for managing in-person events. In particular; Recurring Tech/Design/Product focused events in the 20–200pax range. *I’m not trying to sell anything*, I am after your advice and experiences with events so I can get a better understanding of the current landscape and how we might create a better solution. Would you be willing to spend an hour sharing your experiences with me in the next week? My email: [email] , or DM on twitter: twitter.com/jesstelford

Thanks!”

5. Codifying results

This is the most labour intensive part.

The goal here is to take the unbiased notes that are in a stream-of-consciousness style, and break them up into little chunks suitable to be later analysed for insights.

We log everything into an AirTable, which gives us the ability to remix and analyse it again in the future (our structure is somewhat similar to Polaris UX Nuggets).

You’ll generate a series of artefacts from the interview notes, but the 3 important ones are:

1. A Sample
2. Jobs To Be Done
3. Contexts

A Sample

A user interview generates notes. A sample, along with the demographic information, associates that user with the notes for future reference.

Jobs To Be Done

This is an atomic Job. It has some qualifying attributes, but it is mostly unassociated with a particular user, instead describing only the thing a user might be trying to make progress in.

Contexts

A Context is a linkage of a Job To Be Done with a Sample, providing information on the specific circumstances and feelings (ie; context) that the user experienced while attempting to make progress in the Job.

6. Iterate

Once you’re able to walk out of an interview saying “I didn’t learn anything new”, it’s time to iterate on your hypothesis and initial Jobs To Be Done.

This takes the form of repeating steps 1–5.

You should be able to do this after no more than 10 interviews.

7. Generate Insights

Insights are answers to, ‘what do these observations mean?’ In other words Contexts provide evidence for assumptions — strong beliefs loosely held.

After 1 or more iterations (preferably more), patterns will be emerging within Contexts and how regular the Jobs To Be Done are referenced there.

Acknowledge these patterns, and codify them as an Insight.