Practical Product Ep 11: JTBD (Jobs to Be Done) – What it is, why it matters, how to use it, and a real life example

“I don’t want a drill, I want a quarter inch hole.”

If you’ve worked in product long, you’ve probably heard that phrase talking about Jobs to Be Done (JTBD). The goal of the framework is to help you think deeper about why your customers buy or use your product. Often, it goes much deeper than you’d expect, and are even more significant than wanting a “quarter inch hole.”

Over the years, I’ve found learning the Jobs to Be Done for your product to be incredibly helpful not just for product teams, but also to inform sales and marketing materials. When you know the true, full buyer’s journey for your customers, you can attract more of them faster, and know how to better meet their needs.

Yet, most PMs are terrible at Jobs to Be Done, even if they claim to know what it is.

They pay lip service to the phrase, kind of like how some people think they’re a “lean startup” because they keep a tight budget. 🤦‍♂️

That’s why ever since I learned how to properly do a JTBD interview from the creators Clayton Christensen and Bob Moesta at a seminar in 2012, I’ve taught many friends, colleagues, and clients how to do Jobs to Be Done interviews, too.

In my experience, doing a live example is the best way to learn it, which is why I’ve typically taught people by doing an interview of them with a recent purchase.

While that works, it doesn’t scale well.

That’s why this week’s episode of Practical Product is a live recording of doing one of these interviews.

How to do a Jobs to Be Done interview: Why it matters, how to use it, and a live example for you to follow along to

On this episode we sit down with my former client, Ryan Findley, to go through the buyer’s journey and Jobs to Be Done for Ryan buying a new mattress.

Ryan, who is the Chief Learning Officer at Learn to Win and has spent his career working at startups and scaleups. He’s a builder who helped launch his current company, Learn to Win, and served as the company’s founding Head of Product (which is when we worked together).

In this episode, we show you:

  • How to do a JTBD interview
  • How to map what you learn to the buyer’s journey
  • What to do with what you learn in an interview
  • Common pitfalls to avoid and key moments to recognize

Highlights of the episode include discussing:

  • (0:35) – Introducing JTBD: What is Jobs to be done?
  • (3:03) – Setting the stage with the product Ryan recently bought
  • (3:45)- When did you first start thinking it was time for a new mattress?
  • (4:34) – Who was involved in the purchasing decision?
  • (7:51) – How did budget play a role here?
  • (9:14) – Where did you go to get ratings and reviews?
  • (13:45) – Zooming out: Black Friday & Forcing Functions
  • (21:36) – The purchase moment
  • (33:37) – How did this purchase differ from other things you buy?
  • (47:17) – Did you visit any third party locations when you were in the process?
  • (48:39) – Digging into Ryan’s experience using what he purchased
  • (49:59) – Advice for marketers applying JTBD
  • (54:53) – Ryan’s thoughts on this experiment

Key Show Notes & Further Reading:

We covered a lot of ground in this episode, so we have a ton of links for you to check out.

Mapping the Buyer’s Journey

The image above is the timeline we discuss in the episode. As you do a JTBD interview, you will learn what the various steps were in your buyer’s journey from “First Thought” all the way to “Buying” and “Consuming.”

If you want to follow along more closely in the interview, open up this companion post on how to do the jobs to be done interview. I use this post and the questions listed there every time I do an interview.

Additional helpful links:

Learn more and connect with Ryan Findley

Want to be the first to hear about new episodes of the Practical Product podcast, and blog posts I write about Product Management? Sign up here:

How to Write a Product Thesis to Communicate Customer Needs to Design and Engineering Teams

Ever been handed a 10 page product spec that no one wants to read? Ever write one yourself? Tired of struggling to communicate what needs built next to your designers and engineers so they really understand the who, what, when, where, why of the next feature you need?

I’ve been using customer development, analytics, and information from my team to learn to build the right thing for years, but I always struggled communicating all the information locked in my head to the rest of the team. They needed to know why we were building it and all the necessary information to build the right thing without endless meetings or a massive spec they won’t read.

Fortunately, when I joined KISSmetrics, Hiten and I got to learn a better way from Josh Elman, who worked on product teams at Twitter, Facebook, and Linkedin.  Josh taught me about the Thesis, which is a lightweight way to communicate all the essential details your product team needs.

Now that I’ve used the Thesis on dozens of projects and tweaked it based on what I found worked best, I’m going to teach you how to write your own thesis for the next feature or product you build.

The Product Spec Alternative: How to Write a Product Thesis

> Know when to write a Product Thesis

The biggest crime product managers can commit against their team and their profession is to make up answers to critical decisions. Don’t be that guy/gal.

If you don’t know the answer to one of the sections in the Thesis, go find out. Dive into your analytics, talk to customers, run a survey, talk to your sales/account management/support teams that interact with customers regularly. You will gain the full respect of your designers and engineers if they know you always have a customer story and/or data to back up everything they may ask you about in the Thesis.

The following are all sections of the Thesis. I literally use these as headings to break up the parts and try to keep each section to 5-10 bullet points or a few concise paragraphs.

1) Why are we working on this next?

Every company, and especially startups, are resource constrained. What you choose to build affects your company’s bottom line, their standing in the market, and what your team thinks of your judgment. Use this area to concisely present your case for why this is the most important thing to work on right now.

I try to have a mix of qualitative and quantitative data here. If a mandate came from the leadership team to focus on this area, or sales needed it for a big customer, I make sure to include that. The more your designers and engineers can understand why this matters, the more interested they will be in working on it. In the end, you’re a team and everyone on the product team wants to be sure they’re building the right thing.

2) What are the use cases for this?

Most products end up having a variety of different users and ways that people use the product. To help your team better design a specific feature for the right part of your customer base, you need to detail who this new feature is for.

Be specific! A use case section that is just something like, “As a marketer, I want a mobile app so I can access my data away from a computer” is total weaksauce. Instead, provide the kind of context and detail that paints a picture of the situation:

  • On their way to work on the subway, content marketers like to check how their blog traffic is doing for items they published that morning or the day before. It helps them get into work and know how they’re doing before they sit down. If a number is low, they may try promoting it extra to try to raise the number. If the number is high, they may share the win with others on the team.

Could you picture that situation in your mind? Can you see Jenn the marketer opening an app on her iPhone while sitting on a subway car? I bet you could. Your team can too and they can also then start thinking about what the perfect (not just good) solution would be for them.

Write out as many use cases as you feel are needed. I often have as many as 4 or 5 detailed cases for a big feature.

3) What Problems do we need to solve?

Features are really solutions to your customer’s problems.  It doesn’t do any good to build a feature that doesn’t actually solve the problem, so it’s important to detail what problems you need to ensure the solution your team creates addresses them.

Problems should either be existing problems your product has (especially if you’re iterating on an existing feature) or the problems related to the use cases you just described above. Some example problems may be:

  • Performance Problem: Customers are experiencing frequent crashes. This feature is critical for customers and they are constantly having to refresh and start over, losing their work in the process.
  • Design Problem: Customers are having issues with the current UI. They can’t find key features that exist that they asked me for (Include a markup of the interface to show these.)
  • New Problem: Customers spend hours manually copying numbers to a spreadsheet and making their own visuals for their VP. If we automatically make those reports, we’ll save them time and can then have the VP see our branded reports frequently.

I usually write out 5-7 problems that a feature addresses in bullet form. If it only applies to some of the use cases I described, I’ll specify that as well.

I also try to rank the problems, so that the most important issues get the most attention.  Top problems may be because it affects the most people or functionality issues like the feature crashing constantly. When it’s time for tradeoffs when building the feature, having these detailed, ranked problems will help you make sure the right things avoid being descoped.

4) What are Future Considerations that must be accounted for?

Products are always evolving. Startups can be unpredictable, but you still know generally the direction you may be heading, especially if you’re driving hard towards product-market fit. Help your team anticipate what’s coming next whenever you can.

Depending on the feature, this could be very short or long section. If there are things you know are not going to make the first version of this feature but expect will be needed to be added later, be sure you tell your team! This section is all about avoiding hearing from engineering, “I wish you had told me that before we built [X]!” 

Balancing the present and the future is a constant struggle for a product. The best thing you can do for your team is give them the key information you know so they can do their best to balance their work against the present and future as well.

5) What is our KPI for this Thesis?

You should ask yourself, “What would make this new feature a success?” A KPI (Key Performance Indicator) is the most common way to determine that success since ideally you will tie the success of the feature to one or more of your company’s key metrics.

It’s okay to have more than one KPI, but keep it simple or there will be too many things to measure. When I’ve had multiple KPIs for a feature they’ve been things like:

  1. Support requests will drop by 90% for this feature after relaunch.
  2. Usage of the app will grow by at least 50% after relaunch.
  3. Because this feature affects the sign up flow, we expect a 5% lift in conversion after this relaunch.

You will fail sometimes, but by forcing yourself to quantify what you expect to happen, you will keep you and your team honest. By setting a number that you must hit you can also know when you should go back and iterate.

6) Further Reading:

Your main document shouldn’t be longer than 2-3 pages, so Further Reading can act as an Appendix for you.  In this section, I include links, screenshots, early mockups of ideas, markup of existing features for UX issues, and anything else that I believe would provide additional, helpful information and inspiration related to the project.

Remember: You want all the detail you can without the fluff and verbosity that makes engineers and designers skip reading it. Further reading is a great place for specific information that didn’t fit in the above sections and may be relevant to specific team members.

How does your team document what features need built next?

 

How to do a Jobs To Be Done Interview

Jobs To Be Done (#JTBD) has gotten a lot of attention as a valuable method for product and marketing teams (if you’re not familiar check out the the famous Milkshake video that started it all).

For the product team, they can better understand the motivations and needs of their users. As a marketer, you can understand the journey a future customer goes through to go from considering finding a solution to their problems to actually choosing your product. This is priceless for your marketing site and copywriting as well.

There’s a lot of great posts coming out on why Jobs To Be Done matters, but I haven’t seen much on how to actually do the interviews. Since I’ve done them a bunch myself, taught a number of my friends, and written previously about how to do customer development interviews, I wanted to share the process I’ve learned and evolved:

How to do a Jobs To Be Done Interview

Getting in the right mindset

These interviews are very different than a traditional customer development interview, usability testing, and other common customer interview practices. It’s a lot more free form than other processes that usually just want to uncover a few problems or learn some basic customer demographics.

For JTBD, you need to think of yourself like a detective interviewing a witness at a crime scene, or a documentary filmmaker trying to tell a story. Believe it or not, there’s a significant process a user goes through to become a customer and it’s often measured in weeks or months. Once you finish this process you’ll be able to fill in a timeline that looks like this:

jtbd-timeline

The key is to get users thinking about their purchasing process and filling in the gaps while they remember the various events along the way. Your users won’t think of them with the words of that timeline, but you’ll see where those things happen.  Fortunately, the questions I’ll show you will help your interviewee remember the various steps.

Here’s a quick cheat sheet of the terms on the timeline with an example of a friend who bought a new car.  Skip down if you already understand the timeline.

1) First Thought: What caused the first thought to think about making the purchase? When was it?

– My friend owned a Prius and it was a few years old. One night when he was driving home from work, he hit a neighbor’s trash can that had rolled onto the road. He looked at the front of the car and saw it was kind of scuffed up, but not enough to take it to the shop. This made him think, “Maybe it’s time I got a new car.”

2) Passively Looking: What did they do while they were passively looking? For how long?

– My friend started thinking about what kind of car he would get next. He knew he wanted a fast car and was focused on luxury brands. He started browsing Audi, BMW and Lexus sites to look at their cars.

3) Event #1: What happened that switched them from passively to actively looking?

– My friend’s wife would need some convincing to agree to a new car. As it turns out, about a month after the trash can incident, her brother mentioned he needed a car. My friend could give his car to his brother in law and kill two birds with one stone.  With permission from his wife, he could now actively look for the car.

4) Actively Looking: What did they do while they were actively looking?

– My friend started looking up reviews of the various cars he was interested in and asked friends that owned the cars for their opinions. He has a long time mentor that he in particular appreciates their taste, and so he asked their opinion.  My friend is an Apple fanboy, so craftsmanship is really important to him as well. Both his mentor and his own research pointed to Audi being the brand best committed to those ideals.

5) Event #2: What was the event that made him decide to make a purchase at a specific day/time?

– My friend had two events that combined to push him to finally make the purchase. He was scheduled to have surgery soon and he wouldn’t be able to drive for awhile after surgery. Christmas was coming soon too.  He wanted to get the car before his surgery so he could enjoy it a bit first and not put off the purchase that much longer and knew he could claim it as a Christmas present to justify the purchase then. (Now those luxury ads about buying cars as gifts make more sense, right?)

6) Deciding: What helped him make the purchase?

– Now that my friend was ready to buy, he went to the dealerships and test drove the cars that were finalists (a BMW and an Audi). He had a great time speeding down the highway in the Audi, so combined with his friends recommendations and his own research, he was finally ready to buy the car.

Unfortunately, the answers don’t come out that cleanly. You will get bits and pieces of the various steps during the discussion, which is why these interviews have to be more exploratory. You should be able to assemble the timeline afterwards though and start to see how you can market to future customers like your interviewee and alter your product to better fit them (like helping them see the most important value sooner).

The Jobs To Be Done Interview Script

Ok. We’re finally here to the script. Remember, the goal of the conversation is to help the person you’re interviewing remember the steps and key moments in the process that led to the switch.

A few rules for the interviews:
  1. Find people who recently purchased. Most people won’t remember well anything more than 60 days ago. The more recently the event happened, the more likely they are to remember all the details you’ll hope to capture in the interview.
  2. Don’t interrogate. You want your conversation to feel like they’re just talking to a friend.
  3. Pauses are ok. The interviewee is likely going to have to think hard to remember details. Give them time and they’ll often remember things so don’t be afraid of 10-20 seconds or more of silence.
  4. Bounce around the topics. Being non-linear in your questions often leads to new discoveries. Circle back to different things you talked about throughout the interview.
  5. The best stuff comes around 20-25 minutes in. Keep digging and listen carefully. You’ll have a real *woah* moment right around then.  For above timeline example, my friend didn’t initially realize the trash cans started his car buying process.
  6. Take notes & record the interviews. There’s lots of gold in these interviews. You don’t want to forget anything, and be able to review and share them with others later.
  7. Work in teams. A pair often can do better at examining all areas of the moments you’re trying to understand and help with taking good notes. While one person is writing a key point, the other can be asking a question.
  8. Talk to more users until they all sound the same. It generally takes 7-10 interviews to get the patterns of everyone. I found out the root cause of churn for a company by interviewing a bunch of their recently canceled customers and it was very different than what people said it was in an exit survey.
  9. Organize your findings with the Timeline and Four Forces. That’s what they’re there for. You can learn about the Four Forces here. And an image is below showing them.
  10. Don’t lead the interviewee. Try very hard not to ask Yes/No questions. Instead leave room for explanation and listen. Ask lots of “why” and “tell me more” questions.
  11. Timing Matters. Try to find out the day/week/month/hour something happened. There’s often patterns to be found in that timing and it can also help them recall other details as they concentrate to remember.
TEI 057: Applying the Jobs-to-be-Done Framework - with Chris Spiek

Jobs To Be Done Questions to Ask:

Unlike other kinds of interviews, you don’t need to always ask every question in the exact same order. These are all just ways to explore the process of their purchase and help them remember their story.

  • When did you first start thinking about your purchase?
    • Was it in the morning or evening? What time was it?
  • Where were you when you made that decision?
  • Was anyone else involved in the purchasing decision?
    • Why?
  • Visualize the environment you were in when you made the decision to purchase…where were you? What was around you?
  • Tell me more about that…(When you hear something interesting/intriguing)
  • Did you consider any competitors? Which ones? Why?
    • Why didn’t you choose them?
  • How did you decide between what you bought and the other options?
  • Why specifically did you buy that day versus any other? Why then? What was unique about that day?
    • What else were you doing that day?
    • Did anyone contribute to sparking the decision that day? Why?
  • What were you using before you had X?
    • Why did you use that? What did you like about it?
    • When did you start using that?
    • What were its shortcomings?
    • What does the new product do that your old solution couldn’t?
  • How do you normally approach choosing a new product?
    • What was your process for this product?
      • Why was it the same/different this time?
  • How do you use the product you’ve purchased?
    • Are there features you use all the time? How?
    • Are there features you never use? Why not?
  • If in doubt, ask them to tell you more about whatever tangential thing they bring up in the discussion.

You’ll notice as you do the interview, certain moments on the timeline will fit what they’re describing. I wouldn’t try to fill in the timeline perfectly until after the interview, but while you’re interviewing you can mark in your notes when it seems like it fits with some part. If a certain area isn’t seeming to be filled in, probe more around that part in their process.

To help make this more real for you, here’s a live interview from my Practical Product podcast showing the example of someone choosing to buy a mattress:

But will this work in my situation? It’s special/hard/unique.

If you can get the interviewee on the phone or to meet in person, then this will work in your situation. I have seen this work for all of the following cases:

  • Buying a car
  • Buying a scanner
  • Buying steaks online
  • Upgrading to Evernote Premium
  • Buying analytics for their business
  • Getting a gym membership for the first time in their life
  • Understanding why customers churned a SaaS product
  • Buying a 2nd iPad for a family with children
  • Buying a milkshake from a fast food chain

Even if multiple people are involved in the decision making process, any one person in the process is likely able to recall most of the key moments.

Want to be the first to hear about new episodes of the Practical Product podcast, and blog posts I write about Product Management? Sign up here: