Transcript: Kyle Fiedler on the “Jobs to be Done” Framework

by Tim Wright

This is the transcript for The Dirt episode, Kyle Fiedler on the “Jobs to be Done” Framework

Mark: Oh my God. I saw the biggest, fuzziest, wooliest sheep testicles last weekend. Ram testicles, I suppose.

[Music]

Tim: Hello, and welcome to The Dirt. I’m Tim Wright, and today I’m here with Mark Grambau.

Mark: Hey, Tim.

Tim: Steve Hickey.

Steve: Good morning.

Mark: And all the way from Philadelphia covered in pine tar from Thoughtbot, Kyle Fiedler. Kyle, welcome to the show.

Kyle: Hey, thanks.

Tim: How are you doing?

Kyle: I’m doing pretty good, a little sticky.

Tim: Yeah. I figured. [laughter]

Mark: Understandably so.

Steve: That will happen.

Tim: We’re on, no one can see the video, Kyle. We’re on Skype with Kyle, and he’s rubbing a Yankees hat in our face right now.

Mark: I’m not offended. I grew up in New York. It’s all good.

Tim: Yes. Sport ball.

Mark: That’s right, sports.

Tim: We wanted to talk about Jobs to be Done framework, which to my understanding, is a better way to do personas.

Where they’re more goal-oriented or task-oriented, rather than creating mythical creatures that you attach to somebody in your real life.

Steve: I think personas can be part of it, but I think Kyle can explain the overall framework to us.

Tim: Yeah. Kyle, why don’t you take us through your thoughts of Jobs to be Done?

Kyle: Okay. Yeah, the general gist is you’re thinking of your product as solving different jobs for your users.

You’re not thinking of your users, and then the things that they want to accomplish. It’s more of: your users have a problem, and they’re hiring your product to do a job.

The main example that Clayton Christianson, who came up with the idea gives, is milkshakes. He got hired or one of his friends got hired by a fast food joint.

And they wanted to increase their sales in milkshakes. So they studied why people actually have milkshakes. And I guess one of the big reasons people have milkshakes is…early in the morning for breakfast, which confuses me. [laughter] But…

Mark: I don’t know. It sounds amazing.

Kyle: Yeah, I mean…not very nutritious. But I guess for their drive in to work, they’d grab a milkshake before they start the trip in.

So the job was kind of like, to entertain and fill them up while they’re driving in to work. And they didn’t want something that they could hold. They just want something to drink.

And so what they did was they made their milkshake thicker and better. Longer-lasting. So it
could last throughout a long drive, [laughter] …it thus, increased…

Tim: …Obesity in America?

Kyle: …sales for the milkshakes.

Steve: That’s insane, but it’s a really good example of how that works, I guess.

Mark: Think about it: when you make it thicker, it goes from milkshake to frap, and then all of a sudden, you’re just having ice cream for breakfast.

Steve: Ice cream. Yeah. There is an actual difference between a milkshake and a frap.

Mark: I didn’t even know the word frap until I moved up to Massachusetts.

Steve: I think a frap has actual ice cream in it.

Kyle: So I guess they also made some more healthy, like…instead of just milkshakes, they started to make…

Mark: Like Broccoli shakes? [laughter]

Steve: Smoothies and things like that?

Kyle: Yeah, smoothies and stuff like that. So it was more healthy, I guess, than having ice cream.

Mark: I say we just drop the Jobs to be Done topic for the show, and just talk about ice cream for the next 20 minutes. I’m down with this.

Tim: Well, I had actually heard that, this may not be recent, but McDonald’s milkshakes are just digestible plastic.

Steve: Okay. [laughter]

Mark: That’s exciting.

Steve: I don’t know if that’s true.

Tim: We’ll put a link in the show notes. Yeah. We’ll look that up for you.

Mark: I think that largely qualifies most of their food, is digestible plastic.

Steve: So the simplest explanation I’ve seen of Jobs to be Done for the layman is that a user doesn’t want to buy a drill with a quarter inch bit. They want a quarter inch hole.

That’s it. They don’t care how it gets get there, or what causes it. They’re just hiring something to create a quarter inch hole.

Mark: I really like this general framework to try and focus how you develop your product: from the marketing, to the initial conception, to the design.

I don’t really care for personas as a way to try and understand your users. And there are 20 different ways of thinking about personas, and characters, and Jobs to be Done. There are a lot of frameworks in UX, and I always find personas to be these weird imagination exercises.

Steve: They’re fake.

Mark: They’re just so chockfull of bias, and they are just begging to be misunderstood, and full of stereotype.

Inevitably, you’re going to end up with like, “Bruce the businessman wears a suit, and smokes cigars,
and likes to drive his Chevrolet. And Janice, the grandma.”

It’s just like it’s…and inevitably people, to your point Steve, we were talking about this a bit before the show.

People just graft the idea of the persona to someone they know in their life, and they are stuck on this bias. And it’s something that only they have to use as a point of reference.

Tim: When I was working at USC, we hired 37 Signals to come in and do an experience map or user stories, for our redesign project.

And a part of it was we had to break off into groups and develop personas. I hated personas at this time. So you would imagine what I would do.

I convinced my group, we had to do a mobile user, so I convinced my group to create this persona for this woman who has a Motorola Razr.

And they created this whole story about her relationship with her boyfriend. [laughter] And how they were kind of on the outs. Her camera didn’t have a phone and then some interrupted him and said, “Oh, actually, Motorola Razr has a phone.”

And I’m like “But oh, not her. The camera actually broke, because she dropped it in the toilet once.” It’s just this ridiculous story and they had to cater to it, because it was a persona. And I’m like, “I’m proving a point that these are stupid.” [laughter] Just FYI.

Steve: Mark, were you still at Vistaprint the time we went around the building and we took all of the persona portraits that were hung up, and we replaced them The Muppets?

Mark: No.

Steve: I think the point was lost on the executives, but again personas, we feel like they are a bit silly. [laughter]

Tim: So Kyle, is this…Jobs to be Done, is this something that you use at Thoughtbot?

Kyle: Not explicitly, or at least not yet explicitly. One of the things that we’ve always approached are design sprints…which is what we do to kick off projects, is approach the problem that the businesses are trying to solve. As opposed to focusing in on personas or users.

Which is pretty much what the Jobs to be Done framework is about: it’s solving a problem for your users, but not explicitly.

We haven’t been like, “Hey, we are going to use the Jobs to be Done framework here.”

Mark: I’d say we are in a similar boat.

Steve: It’s more of a mode of thinking. Your personal process is influenced by what you know about this. I guess that’s probably how we think of it.

Tim: So if you’re building out, if you’re using this Jobs to be Done framework, are you picking multiple problems that the application can solve? Or if you have only one that it solves, are you just doing that one track for it?

Kyle: So we’re usually trying to solve the main problem. At least the first thing is: “What is the biggest, hardest problem you’re trying to solve?” And we’re trying to solve that.

And then everything else should stem from that. So we end up with, like a problem statement at the end of the sprint. And we’ll readily reference that.

Like when we start building out features and coming up with features, it’s like, “Is this feature solving this problem directly? Is it yes or no? Is it kind of maybe?”

And sometimes for those maybes, it’s like, “Okay, this is actually solving a problem related to that, so we’re going to push it off to the side. And still think about it, but it’s not going to be our main purpose for now.”

Tim: It sounds like a good way to figure out what MVP is.

Kyle: Yeah. It really helps cut down on all of the features that basically everyone’s coming up with. It helps eliminate a lot of the cruft that ends up coming up.

Mark: I’d say that Steve and I used this on other projects a couple of months ago that…I cannot wait until we can actually talk about this project when it’s actually public.

Because we’ve actually danced around naming this thing 10,000 times in the show, but a large public mapping project.

Steve: You should just ask them. [laughter]

Mark: Yeah. And as I said with the mapping project, it’s often about navigation and getting somewhere. And we used a bit of a Jobs to be Done structure to help guide our initial thinking using the jobs stories.
Right?

Steve: Oh yeah. I think it’s probably more analogous to, I like to start my projects with what I’ve been calling a definition statement.

Which is just after we do a lot of our initial research, I just come up with at most two sentences describing the project. And then everything that comes after that has to feed those two sentences somehow.

But then we started thinking about in terms of job stories instead of user stories for when we were figuring out specific functionality, which I thought was pretty helpful.

Mark: Yeah, and that was the notion of saying instead of… “Because Jane likes to do X, Y, Z, she’s motivated to X, Y, Z,” There was a structure.

Steve: It’s focused more on motivation.

Mark: Yeah.

Steve: That’s the underlying principle.

Mark: We built, to your point Kyle, like you were saying, using Jobs to be Done with this general structure to try to build a single central thing.

I think we came up with basically two almost like heads of the tree. Two top points to a hierarchical diagram that are the be all that end all jobs to be done here.

And then within there, we’re able to find all of the subgroups of that and all of the deviations off of that.

And it became sort of these two almost triangular structures.

Because we could say, “All right. This is the one main goal: you want to get here or you want to go from there and then from within there, there are sub pieces.”

And it helped us really map out and prioritize what had to be done, when it had to be treated for the user. It was a nice structure to help us…just unify the purpose. Because it was sort of a massive project.

Someone could potentially do a lot of different things, but it helped us group the goals.

Steve: So there was an article recently on Medium by Alan Clement about replacing personas with characters.

And I kind of want to talk about how this approach meshes with Jobs to be Done, because they do mention it in the article.

And I don’t know if you had a chance to read through this Kyle, but it was basically pointing out all of the flaws that we talk about in personas…

…and then trying to fill the gaps with what feels like just more information to me. Creating more of a character.

Kyle: Yeah, so the way I was thinking of it earlier, and we already mentioned the first half of this, is that when you have a persona, people have this subconscious desire to morph the persona into a person they know.

This helps aid their understanding. And unfortunately, it means they assign all of these invisible biases to the persona that the other people around them can’t figure out. Whereas if you think about it like a character, I guess I would think of it as the way I think of Walter White, for example, from “Breaking Bad.”

When you start watching a television show, you start to know the character to the extent that the creators of the show allow you to know the character. And a lot of that is based around what motivates the character to do what they are going to do next.

You think primarily in terms of their motivations as opposed to all of these minute trap-like details that you know about their life. Because you can only see what the television producers want you to see about them.

So like a good character, you’re sitting there going, “Okay, so why is Walter going to hide all of this money?” Are we still on spoilers for “Breaking Bad?” Can I say things like that?

Mark: I haven’t watched a single episode, so I’m just going to…

Steve: Why is Walter going to hide all of this money in the desert? What’s his motivation?

Tim: “Da, da-da, da-da…”

Steve: It still seems bold. Kyle, what’s your thoughts on having something that’s problem/solution focused and also is going to help the persona…about before?

Kyle: So I haven’t had a chance to read the article. I like the idea of assigning Walter White

to someone and then making everyone in the company watch “Breaking Bad.”

[laughter]

Steve: It’s like, “Okay. Before we can start this project, everybody has to watch the entirety of Breaking Bad. I don’t even know how we are going to relate to you if you don’t understand Walter White.”

Mark: To summarize just the article, is it saying instead of using these biases that everyone is building this ambiguous character they are taking from someone in their own life, taking someone that everyone has a common knowledge of, someone…a fictional character that we all know, you know: R2D2…

Steve: What I’m noticing about all of these different frameworks and ways of thinking is that people who write about them tend to be dogmatic about what they use.

But people who use them tend to read up on a lot on these things and then filter out the things that work for them. So we’ve tried different pieces in different projects for a good long time.

And what we’ve been doing is figuring out what works from what framework. And then adapting that in our personal philosophy. So we moved from user stories to job stories a while back, and then we realized that job stories weren’t giving us the full motivational context we needed.

So Richard came up with this, to be frank, pretty complicated framework for figuring out a user’s motivations. But you can chop pieces off of it, and use just what’s necessary. And that’s what’s been pretty helpful for us.

We’re learning and absorbing from all of these different ideas people have, and then adapting to the way we work instead of sitting down saying, “Okay, this is the thing we’re going to use forever now.”

Mark: They’re all attempts to systemize empathy and discipline.

Right? You’re trying to systemize understanding human beings, and trying to take what is emotional non-verbal cues, getting over your own biases.

You’re trying to systemize that as well as discipline of not exploding a product into doing everything for all people and trying to focus. And that’s what it comes down to, and I think the amount that people stick to these frameworks depends on their own discipline and their own empathy.

If you are a very disciplined person, but you have difficulty getting over your own biases, then you may want to focus on a framework that accommodates that.

And vice-versa, if you have poor discipline, a Jobs to be Done one may be helpful because it helps you a little bit: “No, no. They need to do this thing. They need to solve this problem.”

Tim: So Kyle, you mentioned that you had been using design sprints, at Thoughtbot lately. Is that based off of the Google Ventures model?

Kyle: Yeah. I think we started off of what Google Ventures does, and what Ideo does at the beginning of each of their projects. I guess Google Ventures just comes into each one of their portfolio projects, and does it when they’re tackling a big feature.

But we’ve adapted it so that we kick off each project with a design sprint. And then whenever there is a bigger feature coming up, we do another design sprint.

And the idea is that basically…come up with a ton of ideas, consolidate them, and then prototype and test it.

Steve: Is that a huge impact on the way you guys go about your projects? Do you feel like that’s been affecting the overall quality?

Kyle: Yeah, I feel like the quality has…started to get better. Within one week, we’ve been able to help validate an idea for businesses…or invalidate, I guess. [laughter]

That’s the biggest benefit, right? Sometimes at the end of that week, we have invalidated a large chunk of one of their assumptions that they made at the beginning of the week.

So it’s helped us kind of either steer them into a better direction…or I believe there was even one time in San Francisco when the client just said, “This just isn’t going to work,” and dropped the project all together.

Steve: Wow. I know that’s the point. You need to figure that stuff out. But that’s crazy. I wonder have they been trying to move in a new direction, or did they just sort of, throw the towel in completely on that?

Kyle: I was not a part of that design sprint. So I’m not totally aware of what happened afterwards. But I know they loved the week. They loved figuring out what it is their product was going to do, and what the problem was going to solve.

And then at the end of the week, it was just totally invalidated.

Mark: But that’s incredibly valuable, because you’d rather spend the amount of money, and the time, and the effort to spend one week really digging in deeply into something.

And then realize it’s not going to work than spending six months, two years building a business that wasn’t going to go anywhere, wasn’t going to function, and people weren’t going to respond to.

Kyle: Yeah, exactly. And that’s totally the point of doing it.

Mark: I’d say we’ve had a few similar successes as we’ve worked on these systemized methods where we’ve had, the more we’ve systemized some of these things, I think some of the biggest benefits have been in the first few weeks of a project where we really clarify goals.

And it helps us when we do get into the actual work have a much clearer sense of what we’re trying to do and what we’re trying to accomplish. And it gets a more reasonable balance and understanding across the board.

They understand what we’re doing. We understand what they’re doing much more when we dig in that much more deeper, more systemized from the start.

Steve: I think one of the problems we were trying to solve at the beginning of our projects was, and the way we explain it to our clients now is:

“We’re good at what we do. And we’re going to try to figure out what you need, but the fact of the matter is you’ve lived with your business for years, and we’re just getting used to it. There is no way that we can easily get by the fact that you know way more about this than we do.”

“So can we take the next couple of days to go through these exercises and ideas that we have so that we can just immerse ourselves in what you do as quickly as possible.”

And part of that is being new to their ideas. We’re going to see things that we didn’t see, but we need
to understand the underlying principle as quickly as possible if we’re going to do our jobs right.

Kyle: I’ve also been impressed by how well we’ve been able to ask questions for clients, and make them think about their product in a different way than they had been up until that point.

Steve: Yeah. When you’re really close to something, it’s hard to see how things, how ideas have changed around you. You just really get absorbed in what you’ve been doing for a while.

That’s why I love going into projects where I don’t know that much about the underlying subject matter,
because it allows me to ask really, I would say, like naive, childlike questions.

Which I think actually get to the heart of how we do our jobs a lot more quickly than if I was an expert in some of the subject matter.

Tim: And that’s why we go through these exercises, Jobs to be Done personas. If you do them. Characters, if you move over there. That’s why we do these deep investigations, and we can ask those questions that may be obvious to them, but are not obvious to us.

Mark: And I don’t know about you guys, but after a solid one of these days or weeks of these deep investigations, I am so mentally exhausted.

I’m usually like really excited. I’m super pumped, because it’s this adrenaline high of you just became, you’re not an expert, but you’ve got an entire world opened up to you that you had no idea about.

But your brain is so full and the input/output modes in your brain, all the circuits are fried.

Tim: They are exhausting.

Speaker: They are exhausting.

Tim: They really are.

Speaker: But they are so much fun.

Tim: Kyle, I had one burning question for you. [laughter] Yeah…I know, right? Of all of the apprentices that have come through Thoughtbot, [laughter] who is your least favorite named Steve, and who is your favorite?

Kyle: Named Steve or just…? [laughter]

Tim: No. Your least favorite, named Steve, and then your most favorite. they’re separate questions.

Kyle: So I’ve only had one named Steve.

[laughter]

Tim: Must be your least favorite.

Steve: For the benefit of our listeners, I was an apprentice at Thoughtbot. [laughter] Sorry to ruin your little underhanded joke, Tim.

Tim: Who is your favorite?

Kyle: I don’t have…they’re like all of my children. I don’t have a favorite.

Steve: So, Tim, you should understand this. [laughter]

Tim: So what we can take away from that is that Kyle doesn’t have a favorite, but he certainly has a least favorite named Steve. [laughter]

Steve: Thank you, Tim, I appreciate what you’ve done here.

Mark: I think that’s good.

Steve: That’s good. Right?

Tim: So, Kyle, do you have any parting thoughts on Jobs to be Done?

Kyle: Not really. [laughter]

Steve: We’ve covered it all. I think this is interesting, and I know I say this every week, but I think it is an interesting topic, or we wouldn’t be talking about it if we all didn’t think it was interesting. Really.

Mark: It would be a terrible show otherwise.

Steve: It would, and I think we’ve had some…

Mark: Terrible shows. We’re like, “Hey, how about that topic that’s in the news there? Stuff.”

Tim: Kyle, if people want to get in contact with you, what’s the best way to do that?

Kyle: It’s kyle@thoughtbot.com for my email. or on Twitter, just KyleFiedler.

Tim: And you can get Thoughtbot on Twitter at Thoughtbot. And I tweet them all the time. Sometimes they reply. Sometimes they don’t reply. [laughter] I don’t know why when they don’t. But this is the life.

Steve: I don’t know if it’s still this way, but when I was there, whenever somebody tweeted at Thoughtbot, it automatically got tossed into the Campfire Chat Room.

And anybody could pick that up and reply to it, so what that means is that everyone at the company
isn’t interested in talking to you, Tim.

[laughter]

Mark: You guys can just feel free to use that Spam/Mark as Abuse button when Tim tweets at you, because more often than not, it’s both.

Kyle: Okay. I’ll start doing that.

Mark: Yeah, get him banned from Twitter. [laughter] That’ll be good for promoting our show.

Tim: Kyle, we want to thank you for taking time out of your morning in Philadelphia to come chat with us. This was awesome.

Kyle: Yeah, thanks for having me. It was fun.

Tim: Cool, and we have an event coming up here at Fresh Tilled Soil.

It’s Global Accessibility Awareness Day. It’s May 15 here in the Watertown office. I just added some more tickets, so you can register for free at fts.io/gaad.

I invited Thoughtbot, but they didn’t reply, so we’ll see if they’re there or not. [laughter]

Kyle: I can’t come. I’m in Philly.

Tim: As usual, you can get us on Twitter at TheDirtShow and please send your long-winded comments to thedirt@freshtilledsoil.com. Please review us in iTunes, Stitcher or wherever you listen to us…it will be great.

And that’s all we have for today. Right? Thank you for listening, and we will try and do better next time…

Steve: Will we?

[Music]

Steve: I like marriage. Because: a) Tax write-offs, b) I have a friend who can’t tell me to go away, and I’m sure there’s a C…

About Fresh Tilled Soil

Fresh Tilled Soil is a Boston-based user interface and experience design firm focused on human centered digital design