The following is a transcript of an interview with the Product Popcorn podcast on Jobs to Be Done.

Welcome and Introductions

Kimberly: Hello and welcome to Product Popcorn- the podcast that explores topics related to product management … Most of the time. We talk with product managers and also designers and engineers that work on product teams, and only sometimes discuss the possibility of artificial intelligence taking over the world.

You can always read more at productpopcorn.com.

Today on the podcast my guest is Brian Rhea. I recently saw Brian speak at Rocky Mountain ProductCamp and he did a presentation on Jobs to Be Done Theory and I definitely wanted to share it with my podcast listeners. I had never heard of Jobs to Be Done (JTBD) before seeing Brian’s presentation, and now I am absolutely obsessed. It’s changed the way I think about my product and its features. Use this theory when you’re scoping out requirements, thinking about your product’s competitors and, especially, working with your UX team. When I originally saw Brian present on Jobs to Be Done at a product event, he talked about conducting JTBD customer interviews, demonstrating how to elicit the “job to be done” from the customer, and examples of a Job to Be Done.

Brian has a free email course about Jobs to Be Done, and the fourth and final email focuses on how to conduct these types of customer interviews. If you want to delve deeper, I highly recommend signing up for the Jobs to Be Done emails on his website.

Let’s go! I’m Kimberly and I’m a product manager.

Adam: I’m Adam and I’m a front-end developer.

Kimberly: We have Brian Rhea on the podcast today and he is going to talk about Jobs to Be Done. I’m super pumped. I saw him talk about this at Rocky Mountain Product Camp and it was great. It’s kind of a big topic in product management right now, so you should all really listen and take this one to heart. We are going to intro Brian right off the bat. Brian, you have a development background and now you freelance and do product strategy.

Brian: Yeah, so the career trajectory has been odd and winding, because even before Front-End Development, if you scroll all the way to the bottom of my LinkedIn profile, you’ll see I was an art teacher for five years. I got into the internet in 1994-95 because my dad owned the ISP (internet service provider) in our small town. When I was about 14 years old, he said, “Hey, Brian, I think the internet is going to be big, so you should learn how to build websites.”

And I was like, “Cool, let’s do it!” He would go around selling websites to the businesses in town, and then bring them home to his 15 year-old kid build.

So that’s how I got my start. Then I went to college and got into Art and Art Education, but got back into the internet after a bit of a winding road. My background was in HTML, CSS and JS and so I was a freelancer in the Dallas area. Then we moved to Boulder, where I joined a startup.

Kimberly: Which startup?  

Brian: It was Mocavo, a Foundry-backed, Techstars company. It was an amazing team to join. And through that experience is where I went from front-end development, to UX, to a product strategy role. And that is where I first started to learn about JTBD, and fell in love with the strategy side of things. But I also found that I just can’t give up the “maker” aspect of it all. So that is why this position now, where I do product-strategy consulting and also build MVPs (minimum viable product), is such a great fit for me.

Defining Your MVP

Kimberly: Before we go into Jobs to Be Done, there was something that you said at Rocky Mountain ProductCamp that I thought was really interesting and I wanted some feedback on it. We also had a listener question that was very similar to this, which is: how do you prioritize?

You said that product teams typically need to build much less than they think. When you work on an enterprise product, like I have for the past few years,  you have people above you saying, “This is your MVP,” when you know the MVP should really be cut in half or more. So how do you accomplish that? How do you whittle it down?

Brian: This will definitely be related to what we talk about later. But if the person assigning you that scope says, “Here is the MVP,” and if they have a true appreciation for what MVP (minimum viable product) means– which is, maximize learning while you minimize investment and minimize risk– then what you should do first is determine: what is the core problem that we’re attempting to solve here? And, what is the cheapest and fastest way that we can get to that?

So often I see the “MVP” is actually just the first tolerable version that the stakeholder can allow themself to release. If what you can help them answer is “What is the Core Journey?”, or, put another way, “What is the primary outcome that we’re going to get from this?”, then you can agree on that. And from there, you will be able to look with them at all the rest of the scope that has been defined, and determine from there what is not actually required.

Adam: Would you say that there needs to be a certain amount of “shame” about your product? Like, you should be a little bit ashamed of it because it is so minimal? [laughter]

Kimberly: We talked a few episodes ago about how you should be ashamed of the first version of your product, or else you’ve launched too late.

Brian: Yeah, totally – and they recently made a joke about just this on [the T.V. show] Silicon Valley! You might might kind of be embarrassed because you know that it’s not finished. You know this thing you’re releasing is not your whole grand vision. But that is always true. Software is never finished. You could spend a year building the perfect “cathedral” product, release it and what happens? You’re going to get customer requests. You’re going to start getting feedback. You’re going to change it.

So you might as well get to release faster.

The Different Types of MVP

Kimberly: Things become outdated so quickly, too, which is something I don’t think people understand. And competition catches up and software does become junk in a few years, unless you’re continually improving upon it.

Brian: Right, and you should be. There’s a great chapter in Cindy Alvarez’s book “Lean Customer Development,” where she he outlines about five or six different types of Minimum Viable Products. For example, there is the pre-order Minimum Viable Product, where you’re just putting up a fake thing. Another example is “The Wizard of Oz” Minimum Viable Product, where it looks automated, but there’s lots at work behind scenes keeping it running.

But one of the types she talks about is the “Single-Use Case Minimum Viable Product”. From what I know about Enterprise organizations and that style of approach, the product manager’s role is to be advocating for the customer’s outcome. You’re saying, “This is the thing that we think is going to matter the most. This is what’s going to have the biggest impact for them and, therefore, our business. So, can we refine it down to this single-use case?” And then nail that.  After you get that, you can go from there.

Kimberly: There you have it. That’s how you get your MVP winner.

Jobs to Be Done

Kimberly: All right. So let’s get into Jobs to Be Done. First off, you said that there’s a little bit of ridiculousness around Jobs to Be Done and how it started.

Brian: If people are learning about Jobs to Be Done for the first time right now, what I can almost guarantee is that they’re going to start following a couple of people on Twitter who are the big names. And then they will start seeing this really weird tension and rivalry, which is bizarre.

I originally heard about Jobs to Be Done through Jason Fried and Ryan Singer at Basecamp. They started talking about how they were using Jobs to Be Done on their product, and being a huge Basecamp fanboy, I started looking up everything I could about it.

Clayton Christensen on Jobs to Be Done

Brian: I found this YouTube video of Clayton Christensen, who is the author of “The Innovator’s Dilemma,” where he shares a story about him and his consulting partners working with a fast food chain. They had been brought in to help them improve their sales of milkshakes. The fast food restaurant had done all this market research, focus groups and everything, but nothing was working, which is why they brought in Clayton Christensen and his guys.

He and his partners sat in the fast food restaurant for about 12 hours. As people were walking out of the restaurant with actual milkshakes in their hands, they would stop them and say, “Pardon me, what job did you hire that milkshake to do?” And they actually phrased it more like, “Why did you buy that milkshake just now?”

And the pattern they observed was that in the morning people were “hiring” a milkshake to keep them occupied on their long, boring commute. A milkshake fits in your hand; it fits in the cup holder; it’s thick; it takes forever to drink; it gets your stomach full, so you don’t have mid-morning stomach grumbles.

Compare this to a donut, which is messy and gets all over your hands. Or compare it to  to a banana, which is clean, but it’s over in about six bites. So the milkshake gets that “job” done perfectly.

It’s through that story that I started to think through the framework of hiring a product to “do a job” in the way that a company hires an employee. The company starts to feel the pain of “We need another designer” or “We need another Product Manager.” When that happens, they put out a job posting and find the right fit. When you feel pain as a person in your everyday life, or you’re not making progress in an area of your life, you post a “Job to Be Done.”

Kimberly: That’s a great analogy. I hired [virtual-assistant device from Amazon] Alexa to play the correct playlist for me, except she doesn’t listen to me. So I think I should fire her and find somebody else to do that job, because it still needs to be done. Now we’re getting way off topic. [laughter] Okay, what is the new book by Clayton Christensen?

Brian: His newer book is Competing Against Luck.”

Theodore Levitt on Benefits vs. Features

Kimberly: Yes, Okay. So then, let’s talk about Jobs to Be Done and what it’s used for. And now we can go into the drill bits. Who is Levitt, by the way? This is Levitt’s quote.

Brian: Ted Levitt was a professor at Harvard in the early 1960’s, and that is when he said the famous quote: “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.

That gets to what we still talk about about, which is selling benefits instead of features. When you design a feature, its normal to want to Feature, Feature, Feature. And I’m guilty of this, too.

Kimberly: That mindset is really helpful. I heard a quote on a business podcast the other day – I can’t even remember where – but somebody was talking about the railroad industry a long time ago. The railroad companies didn’t get into airplanes and flights because they said, “No! We’re in the railroad industry.” And the guest corrected the host, and said, “No, they were in the moving-people-around-industry.”  I thought, “That’s a job to Be Done!” People don’t care that it’s a train; they hire the train to get them to where they need to go. And that’s kind of the same job that a plane does, just not in as effective of a way. But it’s jobs!

Brian: That is spot on!

Jobs to Be Done in Product Design

Kimberly: Can you walk us through any specific scenario or scenarios were Jobs to Be Done would be useful?

Brian: Sure! Jobs to Be Done is most useful in a setting where you’re trying to develop something new. For example, you may have the Job to Be Done right now of:

Help me produce a quality podcast.

What if we were to try to design a new product around servicing that job? Okay. There are about five things we would look at. They include:

  • the progress that you want to make
  • the context that you’re in
  • the obstacles that you’re currently facing
  • the hacks that you’re currently using to get that job done
  • and finally, how you might define quality.

Unfortunately, it’s like PCOHQ, so it makes a terrible acronym. [laughter]

So in our example, the progress you’re trying to make is “help me deliver a quality podcast.” The context that you’re in is that you, and many thousands of people, are now self-producing podcasts. You’re not in an official, formal studio. And that is your context.

The obstacles that you probably come up against probably include finding guests and everything associated with that. You have to find people to come on the show, prep them a little bit, and send them an outline. And also, when you do the recording, you have to edit out all of Adam’s swear words [laughter]. When you upload it, you have to worry about compression and stuff like that. So those are the obstacles that you come up against.

What are you hacking together currently? You’re using email, maybe using GarageBand to slice and dice things, maybe your phone to get some audio, and who knows what all else. You’re putting all these different things together and so finally, what would quality look like to you?

To answer that, you might say that what would be helpful is to have a system that managed the people you reach out to you, your schedule, people who are appearing on other podcasts on these topics, and just the different things to piece that together for you.  You would be able upload it, edit super easily and then distributes to all of the different places.

So through identifying those five things across 12 or 15 interviews with other podcast producers, you would start to be able to see if there’s enough energy here that people are willing to pay for a solution. You would either see that there’s a market for this and it’s worth putting some effort into building or that yes, people are all struggling with this, but not struggling enough.

The core thing that Jobs to Be Done tries to describe is, “How much struggle is there, for it to actually be a ‘Job to Be Done’?”

Want to Level Up Your Product Design Process?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.

Jobs to Be Done and the Forces of Progress

Kimberly: That was one of the things I remember most from your talk at ProductCamp was you had that visual, which I can put in the show notes, but it was that user have to struggle enough to make them make a change. I think you used the analogy of changing cell phone companies or something like that.

Brian: Yes. That’s the “Forces of Progress” diagram. Basically, the algorithm for change in customer behavior is Push + Pull across the top of the diagram, and that is over Anxiety + Habit. Imagine “push” is like something sucks, and you hate it. And “pull” is something looks great and new, so you’re being drawn to it.

Jobs to Be Done: Forces of Progress

Those two are over anxiety and habit on the diagram, and so “anxiety” is like saying: well, I may do that new thing or I could switch to that new thing, but then I have to learn it and what if I suck at that or what if they’re lying? And then “habit” is saying: well, I don’t love what I’m currently doing, but I at least know how to do it.

Push + Pull has to be greater than Anxiety + Habit in order for a new behavior to happen.

Kimberly: This is why we’re all using Jira at work. Habit. It’s habit! It’s like our anxiety with it isn’t quite high enough to pull us to something else. We can go into Jira rant at any time that anybody wishes we.

Brian: But the habit is probably so ingrained–

Kimberly:  It’s so ingrained, and even though we know that it’s just hacked together and we know that they just kind of throw out features to try and solve individual problems and it doesn’t really go with the overarching flow of software, we keep using it. I think it’s it’s a good idea. It’s a good example of something that everybody hates, but the anxiety just isn’t quite high enough to make everybody go to Rally.

Jobs to Be Done and Market Competition

Adam: I’m curious how you would quantify this. I know you’ve given a formula here, but how much anxiety does there really have to produce to create a change– and not just for Jira.

Kimberly: Like when I change from Android to an iPhone? It was causing a lot of anxiety. Also. I wanted to be cool. [laughter] So that was that. I’m trying to think of another example. Adam, what’s Shutterstock’s biggest competitor?  iStockphoto? Getty?

Adam: Yeah, they’re the same.

Kimberly: Do you ever have users switch over to Shutterstock from those competitors?

Adam: I don’t know numbers or percentages or anything like that, but it makes me  wonder. A lot of people know Shutterstock– it’s a multibillion-dollar company– but a lot of people don’t know it. I think that  they’ve seen stuff from Shutterstock and they just don’t make the association to where it came from; the brand doesn’t necessarily stick in their head. And I think it’s actually the same thing for Getty, where people see a lot of iStock’s and they don’t necessarily realize, “Oh, that’s from iStock,” even though it says “iStock” on the photo.

Kimberly: I would just be really curious to talk to your sales team or product managers to know what are the anxiety or the pain points that are going to make a user switch from Getty to Shutterstock. It would be interesting to see.

Brian: Relating it back to the milkshake example from earlier, where the milkshake is not competing against other breakfast products. It’s competing against a banana. I guess a bananas is somewhat of a breakfast product, but I think you get the meaning, and so I wonder if Shutterstock is competing against Getty, but is also competing against royalty-free images. As a freelancer, I’ve definitely purchased credits to Stockphoto services, but I’ve also used plenty of free services, like Pexels.

So, it’d be really interesting to find people who have just hired Shutterstock or people who have just fired it and talk to them. Like, talk to people who purchased some credits, use them all and didn’t repurchase again, or had a subscription and canceled.

Kimberly: You made a good point when we were talking back and forth about Jobs that you don’t necessarily have to innovate and build some fancy new technology that has never existed in the world. Sometimes, it’s just assembling various available technologies to do the job in an innovative way.

Jobs to Be Done and Innovation

Brian: Yes. That was what I was kind of mentioning a second ago, that the hacks that people are currently using could be the beginning of a new product. When you have somebody who is using Microsoft Excel and Trello and a notepad and something else, then you may have a product on your hands. A good example is when Intuit released  Snaptax, which was where you just take a picture of your taxes. It does all the Optical Character Recognition (OCR), reads everything for you and submits your taxes. They did not invent the camera phone or the internet or taxes or OCR.

Kimberly: Can you explain what OCR is?

Brian: Optical Character Recognition, which is where computers are able to read typed words.

And so they didn’t invent any of those things. They observed people struggling, so they assembled these different technologies together. Another example is Airbnb, who didn’t have to invent any of the things that are the are core to their business, including actual real estate. They have assembled those things in a way that makes them what would be the largest hotel chain in the world.

Kimberly: Yeah, that is crazy to think about. I think working in technology, I’m just constantly reading about what Google’s doing with AI and what Uber is doing with self-driving cars, and so on, and it is just a constant stream of new technology and new discovery. But really, a lot of these companies that are these big Tech Giants, they’re just assembling existing technology in a new way.

Adam: I’m glad you bring up Airbnb because I’ve noticed that they come up with really great design and UX Frameworks. They’re constantly making sure that they are the standard. And if you look at Airbnb and go through the website, you can see a lot of really clean design. Even Shutterstock applies some of their design standards. You know that certain things and flows are successful and you can see that reflected across the web in a bunch of different websites. It seems like being able to innovate to that degree is what can help you be successful.

Kimberly: Innovate from a design aspect, you’re saying?

Adam: Yeah, but also, they even have technology frameworks and stuff like that.

Kimberly: Yeah, they just do what they do so well. And now they have that “Experiences” feature that has just launched and it’s like what we’ve been talking about – they don’t own a tour company. It’s just allowing people to become tour guides where they live.

Brian: It’s kind of great what you’re just mentioning about how we hold Airbnb up as this really high standard of design because it totally ties back to what we were talking about with MVP (Minimum Viable Product) very early on. Have you seen the very first Airbnb page ever? It is a stinking pile!

It is horrific, but they proved through that simple, terrible design that there IS a need here, and over time they’ve iterated and iterated and iterated. Now, they are the standard.

Kimberly: Yeah, you’re totally right. I’m just thinking through more examples, and about the push-pull again. I’m thinking about Craigslist, which is still a stinking pile of crap. But people still use it because it’s their habit, and their anxiety with the terrible design of the website isn’t high enough to make them use Facebook [Marketplace].

Jobs to Be Done and Customer Personas

Kimberly: Let’s talk about product managers and how we can use Jobs to Be Done more effectively. You mentioned context is more important than personas.  

Brian: That is something that gets a little bit of heat out there.

Kimberly: Yes! We’re so used to making personas as product managers. Part of our existence and our identity is personas, personas, personas. When we’re talking about this, it seems like people are moving away from that a little bit.

Brian: The great thing about personas is that what it indicates is that the people who are designing software, developing software and trying to prioritize what we ought to build are trying to relate to the human beings on the other side of it. That is fantastic.

But when you define those people by attributes instead of their motivations or their desires or their job to be done, and don’t ask, “What are they actually hiring your product for?”, then unintentionally, there is a disconnect there.

I think that the way that Product Managers can use Jobs to Be Done to make better decisions and be better advocates for their users is not to focus on the age, income, education, and whatever else a Persona might be constructed of. Instead, they should know the context in which these users are are using our application and where they’re trying to go. By having a deeper understanding of that, you can be a better advocate up the chain to higher-ups who are insisting, “This is the thing you’re going to build.”

Jobs to Be Done will give you a better argument, and you’ll be able to say, “I understand why you might want to prioritize that, but I would suggest that instead we do this other thing, because what we’re observing and what we’re hearing from our users is that this is where they’re trying to get. This is the progress that they’re trying to make.”

Kimberly: It’s interesting to think about this from a marketing standpoint. I work on a Big Data marketing tool and I do a lot of competitive research. So, for example, I might look at what Facebook’s or AdWord’s advertising platform look like. And always when you’re targeting people for a product, it is always by gender, by age. When really, we should be targeting people by something bigger than that, like somehow looking for their motivation within their profile.

Jobs to Be Done and Non-consumption

Brian: There’s a big a big piece in Jobs to Be Done, if you start reading up on it, that’s all about non-consumption. There’s a large segment of your market that is currently not using an advertising network. So rather than looking only at what your competitors are doing, look at the people who are not hiring any of us. What are they hiring instead? What are they doing instead? And why? Is there a way that we can absorb that, design a solution around it, monetize it.

Kimberly: So this can kind of change the way that product managers do competitive research, too. Instead of just looking at what all my competitors are doing, we need to be going a lot deeper.

Brian: Right, and not defining your competitors by the other people in your industry, but by what do the non-consumers hire instead? There’s definitely a sense where you can abstract it too far. Disney has talked about this for forever, that Disneyworld does not compete against Universal Studios; they compete against camping and they compete against family nights at home. So they’re not saying anyone else ever that has offered a product is our competitor. It is looking at: what what are the functional, social and emotional jobs that people are hiring us to do, and what are the other alternatives out there that people choose outside of our industry?

Kimberly: This has been awesome. Is there any any other last words or any other ideas that we should know about for Jobs to Be Done?

Brian: I think we’ve I think we’ve covered Jobs to Be Done basics.

Adam: Thank you for this topic because I feel like it’s a very exciting idea, and deserves more exposure.

Kimberly: All right, that’s all we got. Thank you so much, Brian. I was so excited to record this podcast today. Thanks everybody. Thanks for listening to Product Popcorn.

Want to Level Up Your Product Design Process?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.