Implementing the Jobs to be Done Framework with Bob Moesta and Andy Busam

You are listening to Build what's Next Digital Product Perspectives. I'm your host, Josh Lucas, and at Method, our vision is to connect technology with humanity for a simpler digital future. Join us as we speak with leading experts to discuss industry trends, best practices, and emerging technology that can help you and your organization craft better digital products and experiences. Hello, everybody. You are listening to Build what's Next. This is Method's podcast on the digital product world, and we are excited to be here today with a special guest. I'm sitting here with Andy Busum, who is a colleague of mine here at Methen, and we're sitting down with Bob Mesta.

Thanks for having me, guys. I'm excited to be here.

Thank you for coming. We are going to be talking about jobs to be done, and Bob is gracious enough to be giving a presentation here, here in the Method studio a little bit later. And so we were trying to be greedy with your time, pull you in for another opportunity to sit down and have a little bit more candid conversation. So thank you for joining us.

Thanks for having me. And this is kind of like the pre show to the show.

Yes, exactly.

Behind the scenes.

Exactly. So if you're listening to this, we get done and you're saying, hey, I really would like to know more. Bob has multiple books and no shortage of podcast interviews, but we will also have his presentation on our YouTube page as well that you can check out afterwards for more detail. So let's dig in. And before we get too far into the weeds, I want to do a level set.

Yeah.

Because I like to play the role of. Because oftentimes this is who I am. Of the novice in the room.

Yeah.

I'm not the expert in this conversation, but for the folks who also are new to this subject matter, Bob, can you give us like a 101 brief flyover of what is the jobs to be done framework?

So jobs to be done is this whole premise that people don't buy products, they hire them in a very specific situation to help them make progress. And what that means is that it allows us to actually understand that context that they're in and the outcome they want actually drive them to actually buy something or to choose or to change behavior. And so ultimately, I've been studying what causes people to change because I've been a. My mom would tell you, as an engineer out of the womb, I've been breaking things since I've been two. I've been fixing things by the time I was four. I've been building things since I've been eight. And so I've worked on over 3,500 different products and services, but ultimately, I never built them for me. I always built them for somebody else. And so part of this is being able to understand what causes people to say, today's the day I need a new pair of tennis shoes, or I need a new CRM, or I need a new marketing campaign. And you start to realize that it's not random and it's caused. And again, being an engineer, it's trying to understand what are the causal mechanisms behind it so we can actually figure out what to build next. And most consumers don't know what they want. They don't know how to describe what they want. They don't know what's possible. You know, it started with, you know, where's the voice of the customer? But I realized that I had to learn a different way in which to get this information. So I went and learned criminal and intelligence interrogation in the late 80s to learn how to understand what people really meant by when they said easy. What does easy mean? There's like 22 dimensions of it. And most of the time, marketing would come back with easy, fast, you know, convenient, like all these big words. But like, it's a difference between communicating it, which marketing has to do, and engineers who have to actually cause it to happen. How do you cause fun, right? And so that's. That was kind of the quest around those things to understand where does value come from. And it turns out it's about understanding how people change and understanding that those moments where they change because we are creatures of habit.

Hmm, that's really interesting, Bob. I've sort of was introduced to you through Jobs to be Done. That's how I learned who you were and more about you. I'm curious, how did you sort of stumble into or discover jobs to be done?

So like I said, I was building things very young. I ended up having three close head brain injuries before I was seven years old. I was labeled as dyslexic at that time in the early 70s, they just put you into a room. And so my mom, who was a remedial reading teacher, basically took the time to help me understand how I learned. So, like, when we saw a paragraph, right, the first thing I'd see is the spaces. My mom would go, like, what? I'm like, yeah, there's a space here, there's a space there. She's like, okay, where are the big words? And I'm like, well, ever there's big spaces between things. And she's all right, let's work on these five big words. And so she taught me how to read by just circling the five big words in a paragraph and then seeing what those words would have in common and guessing. And to be honest, I've been doing it for over 50 years, and that's kind of how I. How I think now. And it's one of those things where I would say it was. Most people would see it as a disability, but I see it as a super ability because it forces me to think in a very, very different way. And so part of this gets back to is when marketing would bring me the research reports of what they had to build. None of it made sense to me because I couldn't get context. I couldn't get, what did they mean by these words? And marketing is more kind of aggregating the words. And so. Well, everybody, the common theme here is easy. Well, that's one thing. But, like, what do you mean by easy to open, easy to buy, easy to install, easy to trade. Like, there's all these different things. And so part of it was just my curiosity to understand, and wanting to build things is really where it came from. And so, to me, honestly, it was a hack that I would say I built very early on, and then ultimately, I started to share it with people. And so there's a team of people in the early 90s that I did this with, Rick Petey and John Palmer and people like that. But ultimately, Clay Christensen and I. Clay is one of my mentors, and we started to share it with him, and he kind of helped turn it from a method or just an approach or like my hack into a theory. And he helped popularize it, obviously, as well. And I've been developing products my whole life, and I can't actually develop a product without using this notion of jobs to be done.

That's super interesting. And I think the keyword there that you mentioned that I want to call out and dig into a bit more is context.

Yes.

How do you understand the context of your product or service within your customer's life? How do you do that? And is that what jobs to be done ultimately is?

So think of it as. It's a little bit of looking backwards to find the variables and then using those variables to then look forward to say, what are people gonna do next? And so part of this is that I don't go talk to people or interview people who want to buy a house. I talk to people who bought a house because they actually have to go through the entire journey and they actually understand the trade offs they have to make along the way. And ultimately you can actually see like though they say they want stainless steel appliances, hardwood, but what did they actually buy? And when you see how what they bought, it's like they had to make trade offs along the way. And that's actually where you learn kind of the all the variables that relate to the context. The family's growing. The fact is, you know, the current house isn't big enough. My kids are going to school and I want to move to school. Like, there's all these underlying things. And then once you understand that that's what actually causes people to move, not just a beautiful house.

Yeah. I was curious because in preparation for our conversation here today, I was listening to some of the other talks that you've had with other individuals and you come back quite often to pain being a motivator to make this change happen. And so I guess my question is, does that seem to always be the case? Like, is it always a pain point that forces change?

So I want to, I want to fix the word because at some point, pain is one of those things that's a threshold that something could be painful to me, but to you it's not painful at all. And so this is why I call it a struggling moment. A struggling moment is. It's a little bit, could be below a pain, but it's this notion of like, I want to do better or I can do better or. Or this isn't good enough anymore. So to me, the real key is finding the struggling moments in people's lives where they're willing to take action. It's a horrible phrase. I apologize for saying it. But it's like I always say, bitching ain't switching. This is where people can complain and complain and complain about something, but it's like they're really not going to move anyways. This is where people like I worked at Basecamp. So the guys, David, Dhh and Jason and Ryan and those guys, and we'd hear people say, oh, we want resource allocation, we want this, we want this. And then they all threatened to leave, but the reality is like, they never left. And so part of it is to actually understand what causes people to move on or causes people to change. That's what we're trying to look at. And ultimately, to be honest, when we start to think of what to build next, I use the struggling moment as the guide to say, like, because every new innovation I create actually solves one set of struggling moments, but always creates a new Set of struggling moments in a completely different domain. Yeah. So think of the iPhone, right? At some point, it started to actually get more and more powerful, but then the battery went bad. Right. And then all of a sudden people were willing to do things around, and then all of a sudden the camera became the next thing. And so every time you solve one thing, there's always another thing that basically is the next on the list. So, for example, one of the things we do in the companies that I work with is our roadmap is not a roadmap of features. It's a roadmap of struggling moments we're going to address because we don't know that underlying technology we should use 18 months from now. But I do know that this is going to be a struggling moment that we have to dive in and solve. So ultimately, we're going to use the technology we have at the moment that we want to basically go build something.

If you don't mind, I'd like to take a step back and some of what you're saying here, because I'm not immersed in this world all day, every day like you guys are oftentimes. And so I would love some clarification here. And maybe there isn't a distinction, but when I hear a lot of what I hear people discussing around jobs to be done, it sounds like a form of empathy research.

Yes.

And so I guess my question is, is that what it is, or is there more to it? Is there a difference between jobs to be done specifically and the generalization of empathy research?

Yeah. Yeah. So, first of all, one of my ahas is that something, sympathy is an emotion, empathy is a skill. That's the first thing is to realize that we all need empathy. We need to actually be better at empathy. Right. But this is actually more than just an exercise in empathy, because what happens is, is that most people try to look and they'll do multiple interviews and they'll find common empathetic pieces across it. I'm not trying to do that at all. I'm actually trying to figure out the pathways of how people choose to do something new. And there's never one solution. There's never one job. There's actually multiple jobs. And so you start to realize that at some point in time, it's not only about the context, but it's the outcomes. They seek that pairing that actually does this. And so one is, I can have empathy, but I need to codify the data. Most of the empathetic becomes in the art world, it goes into the kind of the gestalt aspect of things. And I'm taking the empathy and actually moving it into the engineering world of saying, like, what has to happen to make you ready to say, today's the day. I need a new microphone. It's very specific conditions that have to be wrapped around you, and then there's specific outcomes you have in mind. And it's the pairing of the pain, or, if you will, the context and the outcome that make up a job for me. It's. I guess it's more complicated than that. And what happens is ultimately there's a contradiction in everybody's words. And what I always say is the irrational becomes rational with context. When you hear somebody's story and it becomes irrational, most people go, oh, that's an anomaly. We're going to leave it alone. But the reality is, is what that really means is you don't know the true context of wrapped around it. And when you actually unpack the context around them, the irrational becomes very rational. I don't believe anybody acts irrationally. I think their context is distorted to cause them to act irrationally.

Interesting.

I paint. I'm an artist. I do a lot of graphic design kind of things, but at the same time, for me, I just love to build things. And so part of me is the art side is being able to understand the phenomenon, but I still have to unpack it down to the elements of how do I cause it. Yeah, that makes any sense. So the other thing is, marketing is built on a world of thesaurus, which is basically, I want to get common words and language to basically get to the most universal word of, let's say, convenience. But in the end of the day, is like, people are looking for very specific things. I need it simple, so it doesn't have so many steps. I need to make sure that I don't have to memorize so many different things. Convenience has an equation to it, and we need to unpack it. And so for marketers, they just want to talk about the phenomenon, but for engineers, I got to actually get it down to the what are the steps I need to actually create to make that happen? So they say convenient or they say fun.

Well, so that maybe is a good lead in to the question of when you see people who are trying to implement best practice, where are the pitfalls? Because I'm assuming people will take it and run with it without fully understanding it. So what are the common mistakes that we can help people avoid? If they're new to it or maybe they're in the process of using it all the time, but maybe doing it not as effectively as they could be doing it.

So I think the real big danger is sitting in a conference room and talking about jobs. Because at some point in time, from the framework perspective of what's pushing you, what's pulling you, what anxieties you have, what habits do you have to break to make progress? Like, we can all brainstorm those things, but this is not a brainstorming exercise. This is more of, like, an archeology exercise. And so the biggest mistake people make is they don't actually go talk to customers because they can't get access to them. And so then they assume they know what customers are talking about. And what happens is in the conference room, everything becomes rational and logical, and you start to realize, like, that's just not how the world works. And so it's this notion of being able to go talk to people. And to be honest, as engineers, we're typically more introverts than extroverts, so it's very hard for us to have these conversations. But ultimately, once you start to realize how to have these conversations and pull this out, it's the patterns in it. So it goes back to my reading. Most people are trying to find the answer. I'm trying to find how many different answers are there, and then ultimately, which one do I want to start with?

Interesting.

Very different. The other part is most people think that it takes a long time to do the interviews. And what we would say is we have a process that takes about two and a half weeks to actually just go interview 10 people, find the variables, see the patterns, and then basically start to think about product ideation wrapped around that. And so it was really built because most research I had to do when I was in big corporate was it would take six months to do it. Like, there's just no way to do fast, quick learning around what people meant and language. And so the other part is to make sure that it's in the spirit of a sprint. It's in the spirit of, like, I'm here to learn. The last thing I would say is that one of the bigger mistakes people make is they have a hypothesis going in. And I call this hypothesis building research. Like, I have no idea why you guys bought a new CRM. Not a clue in the world. And I could have some ideas around it. But this is kind of the gift of being a dyslexic is, I can admit I don't know, most other people have to have a hypothesis going in and saying, yeah, I know what I like, that's what it is. And what you start to realize is you learn so much when you actually go in with I don't know what the answer is versus I know what the answer is. And so this is why I don't recommend a list of questions. I recommend just literally, you know, that they switch from A to B and literally just extract their story of what the heck had to happen for them to say, today's the day, I'm going to stop doing this and start doing something else. Because it's a really monumental event for people that most people. Even buying a mattress is hard. Nothing is actually easy. And so you start to think about all these things we buy. And it's one of those things. As humans, we don't connect the dots. But when you start to connect the dots, it might have taken 18 months to buy a new mattress.

Yeah.

We would say there's no such thing as an impulse purchase. It's just the fact you didn't plan to buy it that day, but you weren't sleeping for 18 months before that. And you finally said, today's the day I'm going to buy a mattress.

Yeah. Bob, one thing you said a moment ago was around the concept of access to customers.

Yes.

We work with a lot of clients in the healthcare space and some other regulated industries. It's so tough, I guess. What advice do you have for teams who are trying to innovate or build products in those spaces?

So I use a place called Respondent IO. At some point in time, I did something on lap band surgery. Right. And it's one of those things where we were working for a healthcare network and it was like HIPAA got in the way, you couldn't talk to him. So we literally went to respond and said, hey, has anybody had lap band surgery? Are you willing to talk about it? And we got a whole bunch of people to talk about kind of like what caused them to say, today's the day I'm going to, you know, go into the surgery and have these things done and what were the outcomes they were hoping and how do they follow through with it? And to be honest, it was very, very interesting in terms of being able to do it. But, like, we could have never done it inside the system, we had to go outside the system. And banking is the same way. So it's the same kind of thing. But ultimately you need to find surrogates or at least find a group of people who are willing to talk about it. The other thing is, most people say, well, I want to talk to my customers specifically. And I think that's the ideal situation. But if you can't, like, whether people switch from AT&T to Verizon or from Verizon to ATT, it's the same story. Right. It's like, what was going on and what was happening. And so ultimately, hearing the causation of the story, it's really about being empathetic to them. And. And so I really talk about this notion of, like, how do you study the customer? As if you're playing a part, you're going to feel what they feel, you're going to hear what they hear. And so it's almost becoming an actor or an actress around that aspect of the customer, because that's what's going to help us become better engineers, better developers.

I am curious as you're referencing the interview process.

Yeah.

I have to imagine that it isn't always the easiest to get people to start relinquishing information.

Oh, you know what? It's. It's way easier than you think it is. Oh, it's. So I start out the conversation the same way. Look, I'm doing very early research to understand what causes people to say, today's the day. I need a new bed. Right. And to be honest, I don't have a long list of questions. It's literally, I just want to hear your. My understanding is you just bought a new bed. I just want to hear your story. And ultimately, I'm going to have language around it, and you're going to say, oh, it was comfortable. And I'm going to be like, what do you mean by that? And how do you know? And I don't want you to make up any of the answers. And ultimately, I just want to hear that story. And to be honest, it flows. I can talk to somebody for 90 minutes about that. And it's the setup.

Do you ever feel like you're playing counselor to people? Or, like, did you ever get out of interviews and people are like, I had no idea.

So, by the way, there's two things I would tell you. If you can get people to cry in an interview, that means you're getting to that emotional side. Like, most people are afraid to get people to cry. My thing is that's where the emotional part comes, just real quick.

Not because you're scared.

No, no, no, no, no. Not because they're scared, but it's like they're connecting dots because a lot of times you don't realize, like, all the reasons what was happening. So it's like I interviewed a guy about a mattress, and he is like, yeah, total impulse. I bought it on a Saturday at a Costco, and he had three kids with him. I'm like, dude, are you insane? You're buying a mattress at Costco on a Saturday with all the kids? He's like, it was a total impulse purchase. And then my next question was, so how long haven't you been able to sleep? Oh, that's been 18 months. I. And then he talks about his journey, about all these different things along the way to get there. And so most people, when you acknowledge who they are and what they're about and to empathize with what was going on, they'll actually tell you way more than you actually want. And so this is not an exercise in Freud. This is not an exercise of, you know, kind of blaming mom or dad or something. This is an exercise of what are the things that are wrapped around them at the time that basically make them compelled to do something different, and what are they hoping for on the other side? Because almost all the purchases we're talking about happen in the mind first. And then the second part is then how do we actually map the experience of what's in their mind to set the right expectations so they can make the progress? So they buy progress, and then they actually achieve progress by using the product. And so it's those two things together. And so a lot of times we actually have to understand both of those at the same time.

Yeah. How do you think about moving from the anecdotes that you learn from people, the individual stories, to themes, and turning that into some insight?

Yeah, yeah. So I have a process where we do the interviews. Right. And typically with the interviews, we have the person we're talking to, the interviewee. Right. There's two of us, and there might actually be four or five or six other people listening at the same time. Right. And so part of this is about gathering the language and building the language for the team. So once we're done with the interview, we have a debrief process where we talk through a couple things. One is, what are the underlying mechanisms that cause them to say, today's the day, they have to do it? So we actually codify the data into what are pushes, which are things that are happening in their environment that actually make the old solution not work, has nothing to do with the new solution, but, like, I gotta do something different. Once they see the solution, there's pulls. There's a mechanism that could basically pulls people towards it. It's like, oh, Gosh, that's going to be so much easier. Well, what does that mean? And, like, what could you do today that you can't do tomorrow? Right. So we talk about those two things as the fuel of the change. And then there's the friction of the change. Again, very engineering. Sorry about that. But the friction is. Becomes the anxiety of the new. Like, well, how hard is it to learn? And how much does it cost? And like, all these different kind of questions that they have along the way. And then ultimately, what are the habits they had to give up, things they loved about the old product that they were willing to abandon along the way. And so when we're doing the interviews, we're actually gathering all of that kind of information, but as a team, then we actually then take the time to literally argue about what we heard. And I love the angles of some of the ads today where it's like, check the record. It's like we go back and say, I heard this. No, I heard that. But it's building a common language around what easy means or convenient means. And it makes it very, very tangible. So the first thing is we keep all the stories intact. We'll do 10 stories and. And then what we do is we start to lay the stories on top of each other to say, where are their patterns? Oh, this one had this push and this one had that push. Oh, are they together or different? And, oh, they wanted the same outcome or they wanted a different outcome. And so you start to realize there's pairs of context and outcomes that then lets you see how many different jobs there are. To be honest, I take the variables, turn them into math. We actually use eigenvector math to basically build clusters. And then from there, we basically then compare and contrast the clusters to each other to then get to what are the four or five different jobs. So there's a book called the End of Average, where most people are averaging everything and trying to make a common theme across all the interviews. And I actually say every interview is very, very different, but there's some that are closer to others. And that's how you find, like, the weird angle for me is, like, at colleges, they have pathways of how students walk. And so it's that kind of thing of, like, what's the walkways that people take to get to buy a new product.

I'm so glad you brought that point up, because I think a lot of people think of jobs to be done as a purely qualitative method. And so it's really interesting to hear you say that. There is a quantitative aspect of this. We're blending those two methodologies.

Well, that's right. So the first thing I would say is that we're doing qualitative research. So, you know, the significant digits is still 0 or 1. Right. And so the variables we're creating are just a way in which to describe what's going on. But ultimately, we can pull it back to saying, like, how many people are in this context? How many people want to actually make this progress? How many people are struggling with these things? And. And so you can size the market based on some of those things. Yeah, My first language is math. I can do math equations in my head. Everything's about relationships and entities and directions. And so, like, even words become, like, when people talk, I actually write an equation in my head around kind of like what the talk is about.

Oh, interesting.

Again, it's the gift I was given because I'm dyslexic.

I'm curious about how you think about taking your learnings from research to implementation. And I bring this up because we have teams of people who specialize in doing research and design and product development. And so we span the full range. And what's often really difficult is taking the insight you learn during a research or a discovery phase and making it real to the engineers who are going to bring that product to life.

So this is maybe a little bit of a controversial answer, but I believe that part of the problem is that we've become too efficient. Meaning, I have researchers who do the research, and then I have basically insight people who might process, and then I have designers who are going to go design. Right. And the reality is, is, like, I think of it as more of a horizontal process than a vertical process. And so instead of delegating the research to the researchers, how do we actually teach the team to actually start to do some of the basics of the research or participate in the research? And what you realize is an engineer, you're going to sit in a qualitative interview. They don't know what to do. Right. And so part of this is to realize, like, we have to actually start to build more horizontal skills as opposed to, like, I feel like academia has forced us to actually build these silos and ultimately these handoffs. And I feel like the handoffs are actually becoming more and more inefficient. Though we can be very efficient in our research, we're very inefficient in our handoff. And then ultimately, we end up with an inefficient process. And so we actually end up always having cross functional teams we work with. Like, I've been doing this so long that it's one of those things, like, if you want to work with us, here's how this works. And we know it's gonna work, but it's gotta be cross functional. It's gotta be, we say five plus or minus two. So it's like five people, no fewer than three, but no more than seven. I need the people who are actually gonna be part of the project. I don't need any development opportunities for people in the room. Like, this is hard work and you gotta be able to jump in and do it. And so this is where I feel like that's an important part of it, is that most people try to distill it back to PowerPoint and you can't do that. PowerPoint is just too flat. And so ultimately it's about understanding those variables and understanding the context and hearing the stories. And what's really cool is when you can get a team member, you know, five, six months after we've done the interviews, recall an interview with ridiculous amounts of detail and about why they were doing it, and then ultimately seeing how that feature can fit into their life when they're in that moment and having that struggling moment. And so it's about implanting these stories into people's brains as opposed to kind of giving them the essence of it, if you will. And it takes more time and energy. It's just, it's a harder process, but in the end it has way bigger benefits on the back end of being able to build better products. It's like you gotta go slow to go fast. And that's the slow part. As soon as everybody understands the customer better, everybody can move a lot faster. But if we don't, we end up always going back. Like, what did you mean by that? You hear the communication problem very early.

Yeah, it makes a ton of sense. And I think just even thinking about your earlier comment around structuring roadmaps, around struggling moments becomes possible when the team that's going to execute is a part of uncovering the struggling moment.

That's right.

Well, and this kind of goes to what we were talking about a little bit this morning in preparation for this, which my assumption, and based off of hearing the two of you talk, then it sounds like I maybe was incorrect in this assumption, which is, I think it's easy to assume that this belongs very upstream and only upstream in the process. The product lifecycle versus having the lifespan that travels all the way across.

So I've worked with a company called Intercom. I don't know if you guys know who Intercom is. Yeah, I've worked with them for almost 12 years and their jobs have not changed. But for example, they use the interview process as a way to onboard their new employees and look for new language, but also to help people have their own stories, to know the people and what they're trying to do. And so they do this on a regular basis just to actually make sure that people have that language. And so you can start upfront, but you can also start on Churn. Like, I have a company I'm going to help next week where all we're doing is looking at why in the world do people leave the product? By the way, when we learn that, we're going to learn why people came to the product, and we're going to also learn why people leave the product to figure out kind of like, what are the two things? And you have to realize growth is a function of getting more people in and making less people leave. And so it's actually both sides you have to fix.

So we talked a little bit about the pitfalls that come along that oftentimes people maybe get excited about this. They run in, start implementing it before they fully understand it. I'm curious of any examples, like, what are your favorite examples of where this has been implemented?

The simplest example that I would tell you is Snickers, right? And I'll talk about it a little bit later as well. But Snickers is one of those things where, like, if you think about a Snickers versus a Milky Way, they're made by the same company. They literally sit next to each other on the aisle. And for all practical purposes, we would say they compete with each other. You either want a Snickers or a Milky Way. But when you take a step back and you say, when's the last time you had a Snickers? And you literally go like, oh, I missed the last meal. My stomach was growling. I've got a whole bunch of work to do. I just need to actually get something in my stomach so I can actually fuel myself to go do this crappy.

Work I want to go do.

It's literally like mainlining food. And you're like, okay, well, what else would you think of A sandwich, a Red Bull, a coffee, a walk, like these other things. But a Milky Way never comes into the set. And if you think about the last time people had a Milky Way, it's like, oh, something emotional happened, something bad, something good, whatever. But it's like I. I do it alone. It's a moment where I'm eating it to actually enjoy and get hedonic pleasure. It's making me feel better. And it competes with brownies and a glass of wine and a run, right? And you start to realize, like, Snickers and Milky Way don't compete with each other at all. And once we understood that, we actually changed, for example, on the product side, change the layering. Think of it as, you know, when you bite into a Snickers. The first part is we change the penis from the bottom to the top so it's hard. We actually raise the melting temperature of the caramel to make it more sticky. So now when you chew it, it masticates into a ball, and you swallow it like it's food versus a Milky Way. You bite into it, it almost like melts in your mouth and it's liquid in your drinking it down. And so ultimately, by doing that, we were able to kind of change the experience of eating the Snickers. And then the second part was then the advertising, which is where you're not you when you're hungry. And so it took it from about 600 million in sales to over 2 billion in sales in less than 10 years.

Wow.

And it's a little bit of product, little bit of marketing, but it's aligning it to the real outcomes of what people were really hiring them. A Snickers for you're not you when you're hungry. They're not hiring it because it's packed with peanuts. Right. This is where you start to realize features and benefits. It's helped us get to a certain point, but I realize that features and benefits are actually probably the things that's going to confuse more people. If we actually talk more about the context they're in and the outcome they want, they're actually going to resonate way better than packed with peanuts.

I want a Snickers now.

Exactly.

The popularity of jobs to be done.

Clay. I give it all to Clay, because at some point in time, it's one of those things where it's something I did. I've done it in every one of my startups. I've been helping other people do it. So it was kind of sweet. Where Clay, in 2010, he had a heart attack, a stroke, and cancer all in the same year. Oh, wow. So Clay Christensen is a Harvard Business School professor that has been my mentor. I got four hours a quarter with him for 27 years with no agenda.

Wow.

So I would just show up and we'd say what we were working on and we'd talk about things, and I would ask him a bunch. He just loved me asking him questions. And it was, there's nobody else usually in the room because at Harvard there's lots of smart people. But I would say I'm more like you, Joe, where I'm asking the basic questions just to say, like, wait, I don't get this. Why is this not happening? That kind of stuff. And he really liked that. But in 2010, he basically said, I can't go. I have to turn jobs into a theory. And I had no idea what he meant, but I said, whatever you need, we're going to do it. And so over that period of time, then he assembled a team of Karen Dillon and Taddy hall and Dave Duncan and myself, and we basically helped write that book, Competing against Luck. And out of that it became popularized. And so that is probably the greatest gift that he has given me. And now I feel the obligation to kind of just perpetuate and make sure that it continues on.

Absolutely. In some ways, it feels like it's kind of taken on a life of its own, because I know that there are multiple interpretations and ways of doing the work.

There's a little story behind that, too.

Yeah, I'm curious. I'm curious.

So there's different thoughts of it. And I think the thing is, is that different people have basically made claims that they started or didn't start it. And there was a trademark case where somebody tried to trademark it against me. And so I had to go back and basically come back and say, like, no, no, no. I, like, I showed a document from 1989 where I started talking about jobs to be done. Right. And so it's this aspect of. It's been around for a long time, but what I realized is if I trademark it and copyright it and control it, it's going to limit the ability for people to try to use it. And so there's this risk and trade off of, can I get more people to understand it, though, that more people will probably use it poorly, but can I get more people to actually realize and elevate themselves and elevate the game to do that? So instead of taking the trademark, I actually made it public domain. And so what you find is there's a lot of people, they're making it better, which is fabulous. Right. And again, I would say with AI, like, there's a whole bunch of stuff that's going on with it. I have some doubts around some of it because at Some point it's still averaging. It's not using clustering kind of methodologies. But like, I love the fact that people are iterating and trying to make it better and trying to make it their own and doing their own with it. And so the risk was then having people oversimplify it and make it die. Right. Which happens with all methods. So my thing is, is trying to keep the standards high, trying to basically make sure that we understand what it is and then eventually evolving it to the next level of things, which is, I think this is more about helping customers make progress. And jobs is the method by which I actually figured that out.

Yeah, absolutely. I feel like I can tell you're a true engineer because that's just open source.

Yeah, exactly.

And every good engineer I know loves open source.

I'm one that really is focused on trying to leave the world in a better place than I started and at the same time realizing like, I can make as much money as I probably want, but like, having too much money is a bad thing as well. And so part of this is being able to have that balance of all those things. And so think of it this way. I'm a dyslexic, illiterate 18 year old who happens to meet Dr. Deming when I'm 18 and takes me to Japan and just pours all this notion of Lean and Six Sigma and, you know, all that stuff into it. And then I meet Taguchi and then I meet Clay and like, I have to pinch myself when you look at my mentors, but at the same time I feel the obligation because now they're all passed. It's my job to actually pass it on. So these aren't. I don't feel like they're my ideas. I feel like they're their ideas. But my job is to keep moving it forward so we don't forget.

Yeah, that's awesome.

I know you've got multiple books that you've written.

I write really strange books, by the.

Way, and I know that there's a lot of opportunities for people to hear other interviews you've done and presentations you've been talking about putting this out for people to build on. Are there other resources that you would recommend pointing people to, to learn more about this?

There's a good community out there. I think if you look it up, there's different schools of thought, which makes it very useful for you to kind of figure out which school of thought fits with you. There's Tony Ulwich and Outcome Driven Innovation. There's Alan Clement there's just a bunch of other people doing these kinds of things. But for me, it's. I'm trying to now apply it to really taboo places. We're in the midst of wrapping up a book with Michael Horn and Ethan Bernstein around what causes people to switch jobs, switch from one company to another company. It's not random. And so I apply the whole theory to basically HR and say, what progress are employees trying to make? And what you start to realize is if you look at how turning the employee into the product and understanding the outcomes that they're trying to make for the company, you start to realize most job descriptions are literally wish lists of just like, I wish they could do this, this, and this. And then we try to get this person to fit into that wish list, and then we penalize them for the five things they couldn't do that we knew they couldn't do to begin with. And so instead of framing the work around what they're really good at and taking away the things of what they suck at. And so it's this whole notion of how do we actually use this to understand what progress are you trying to make in your career? And ultimately, that's kind of my next book, and I've got one around this notion of how do you find a partner? At some point, finding a partner is very hard. And most people just. They think the line is endless. So they just date and date and date and date and date. But they never take the time to realize, like, well, what was fun about that one? What was bad about that one? And building their own criteria so they can design the way in which they can find their partner.

I'm curious, from all the examples that you've rolled this out, is there one you can think of that the weirdest application, or was there ever a time where you thought, if it's not going to work, it might be this scenario, or do you feel like it just works all the time?

So I don't actually start to build until I know that there's enough energy for people to want to switch. Once I can understand the context and outcome of where people are and what they're looking for, the two things is building the product is actually way easier because most people build the product and then they try to go find of the 8 billion people who need it, it's like, that's a needle in a haystack, by the way. That's the thing I was told as a student is like, it's the biggest lie. Build it and they will come. Dude, that's just a lie. It just doesn't work. Yeah. Right. And so this is how do I find hotspots where people want to do something, but they can't? And ultimately, when you get there, you start to realize the product actually doesn't even have to be that good. Right. So think of QuickBooks. Is QuickBooks the best accounting package ever? No. Does everybody love QuickBooks? Virtually nobody loves QuickBooks. It's a $9 billion business, and it's because people need to make progress. And it starts with, how do I get paid? How do I pay my vendors? And then all of a sudden, the next struggling moment, how do I pay my employees? Hey, I need a credit card. Hey, I need to be able to do taxes. And you start to realize, like, every struggling moment comes out of it. And that's why, you know, Intuit basically built out QuickBooks, and then they went and bought Mailchimp. Because the next round of struggling moments were marketing. Yeah. And so you can just see that there's companies out there who are doing this that just literally know how to progress this.

I feel like I've heard repeatedly with new product teams or startups, there's a pivot. The first version of the product that goes out is never where they end up a year, two, three years later. Is the pivot always necessary? Or if those founders had started with this mentality and using this framework, could they have avoided the pivot?

By the way, great question. And I would tell you from my experience, is a pivot's always necessary because I feel like it's going between levels. There's a level of organization where everything kind of seems to fall together. And then when you go to the next layer down, there's a layer of chaos, and then the next layer down is a layer of organization. Like, I feel like the pivot is them going through kind of these layers of order and chaos. And when they get down to where it really is, then they can actually do it. But they need to get enough scale and enough energy and less friction to basically make the progress. And most people start up here, but the real business is down here. And so it's them unpacking it down to the right level to basically get there. And so I don't think of it as more of a pivot, but more of like a. A funnel effect of basically getting you to where you need to be. The other thing I would say is that sometimes there's entrepreneurs who have a vision of what they want to build. And what I would tell them is, go build it because what happens if they try to go talk to customers or potential customers around it? They end up only hearing what they want to hear as opposed to what customers really are saying. And the moment that they actually kind of get their idea out, then we can start to talk about how you might modify it. And so that's the other reason why you sometimes need a pivot, is because I do believe that a lot of entrepreneurship has an art aspect to it of building something for themselves and then figuring out how to make it work for others.

Yeah, absolutely. Kind of reminds me of that Voltaire quote, that perfect is the enemy of good.

Yes.

It's also the enemy of done. And so I think that one of our operating principles here is, you know, simplify and go. And what we see too often is sort of overcomplicating and taking too long to get off the ground. And so I think part of the origin of that question was thinking through how much time do you spend upfront doing research with customers and balancing that with actually, just go, execute. Go build something.

So in the book Learning to Build, we talk about the five essential skills. And one of the big skills is prototyping to learn. What you start to realize is that way that we were taught as engineers is prototype to verify what's your hypotheses? How are you going to do it? Okay, show that you can do it. But the reality is there's way more unknowns than knowns in your project, and most people spend all the time on the knowns. And what I say is, like, no, we're going to spend all the time on the unknowns, because once we make the unknowns known, it actually makes the project way easier. But most people work on the knowns because that's what they're familiar with, and they leave the unknowns to last. And it ends up having them to rework 90% of what they already did. And so to me, it's being able to find those unknowns, articulate those unknowns, and then understand what hypothesis can I build about in terms of getting rid of those unknowns.

I love that.

So where do you typically see hesitation for people? I'm assuming like you're being pulled into workflows or projects because people have made the decision that they know they need this framework to be implemented.

No, most people just know the what they have isn't working. It's kind of like, okay, if that's not working, I don't really have any alternatives. Let's try this. So some of our busy time is like, November, December, because they have budget, end of the quarter. And it's like, hey, we can try this thing, but we know what we're doing isn't working. Let's just try this. Like big corporate. We get some of that, that goes on.

And when you're in the middle of it, typically once you're in motion, people are on board, or do you get a lot of pushback?

So the first thing we do is we don't talk about the product at all. So when they say, oh my God, I love this feature, we're going to say, why do you like that feature? And they want to say, well, tell me about the feature. And I'm like, I don't want to. I don't care about the feature. I want to know what does it enable you to do today that you couldn't do before? And so ultimately, we're always moving away from the product, back to the people. And so you start to realize they're going like, you're asking all the wrong questions. We're not getting the information we need about the product. And my thing is, we don't need that. We gotta be able to understand why in the world are they even here and what are they thinking about and why is that feature important? Because that feature like, so for example, at Basecamp, we had these people keep going, like, you need to give us a calendar. Because Basecamp didn't have a calendar at the time. And it was like, we need a calendar. And it's like, well, why do you need a calendar? And they couldn't articulate. So we went and did some interviews. And so as they're starting to plan out like an 18 month thing to build calendar, it turns out when we did interviews, it was like, look, Basecamp will tell you when you have tasks and when you're supposed to do things, but it doesn't tell you where you have free time. And so all we did was actually take the task list they had on the calendar and basically say, where's the free time? And create a reverse of it. And it was literally a three week project to literally say, here's where free time exists. Everybody said, thank you for the calendar. We never built a calendar. Right. So this is where you have to take the time to understand. And once you do, it's like it goes from a big project to a very small project that actually has a really big impact.

Yeah, because I'm just thinking through the manpower, the money, all of that, and now all of a sudden you've freed all that up to Be divvied up wherever else is needed.

One question. I worked with a client recently who hired an independent consultant to do quote unquote jobs to be done research for them. This consultant went out into the field, did the research, and delivered a set of jobs to the client.

And it wasn't me, was it? No. Okay, I got it.

And so the product team was essentially told orient around the jobs. I'm curious how often you see that as sort of an operational mechanism for teams.

That happens quite a bit. So I'll say some of the other design firms, they'd end up either doing their own ethnography or they doing some of the other things, but they'd find kind of the threads, but they wouldn't find the pathways. And so there's times where people have hired the design firm and then we did jobs and there's time when they hired us and then we feed the design firm and I find some of the bigger design firms will do the jobs part and they've realized they can't do it to the degree we can do it. And they can actually design way better product along the way. But it's about actually understanding. Because the bigger part is most of the ethnography doesn't talk about trade offs. It doesn't talk about hierarchy of what's more important than another thing. And so you, you end up with a lot of soft things, but not enough things to actually know how to build it. And so we get pulled in to help do opportunity identification. So one of the phrases I use is contrast to create meaning. So I will build a set of prototypes so we can actually use it to verify that we know what doesn't work and knows that what works. So then the design firm can have a range of things to then use as fodder to go be creative within the box, if you will. Right. I'm not a big fan of open ended blue ocean kind of strategy stuff because it's just constraints actually force us to be way more creative. And I like to have multiple constraints simultaneously to help me kind of look at the levers that I can pull as opposed to kind of trying to design something from scratch, which I'm not very good at.

It's interesting. I've seen jobs to be done applied more often and sort of going from, you know, 1 to 1.1.

Yep.

But I feel like in some of the conversations I've heard you recently had on other podcasts, it feels like a methodology used maybe more popularly going from.

0 to 1, 0 to 1 or 1 to 2 or 1 to 3. And so part of this is the phrase that sticks with me when I worked in Japan was they kept saying like, I want to know what the customer wants without telling me what it is. So how do I get technology agnostic requirements from the customer so then I can figure out what's the best kind of technology to put in there. So most of the time we end up with something that doesn't have the answer in it. It's the hole we're trying to fill, which then I can actually put multiple technologies in it and realize like, there might be five ways to solve this.

Absolutely. And you're not constrained by some solution and trying to fit their situation into it.

Well, eventually you have to connect it to the supply side of what they have access to and what their infrastructure is and everything else. But part of it is to realize like nine times out of ten, I feel like, at least for me and the way I was taught as an engineer is I over engineered the shit out of it. And it's like a kick ass half is way better than a half asshole. Yeah, right, right.

Yeah. So absolutely.

Sorry. Are we allowed to swear?

That's the title of the episode.

I believe that's a paraphrase of this Ron Swanson quote.

Jason Freed actually said Jason Freedom Swanson. Ron Swanson probably have said it too.

Never half ass anything. You should whole ass one or something.

It's a derivative of it. It's very simple. But like, I just remember when I was young, it had to have 15 features and we could never get all 15 features done. They'd all be a kind of a mishmash of thing and be like, okay, here it is. And be like, ugh, if you just nailed three of them, it would have been perfect.

And this is a great reminder for me, coming from an art background in the fine arts, it was so hard for me to relinquish and say, all right, I can step away, I can let this go. Because to me it was. It had to be, well, I could do a little bit more. I could do a little bit more. I could do a little bit more. And it's like, well, but then you'll never be done.

So the interesting part to me is that I learned basically the sprint aspect very, very early. So we iterations. And so what I learned is that the first iteration, if I can get 20% to get me to 80%, that's awesome. If I do a second iteration, I go from 80% to 96% and if I do a third iteration I get from 96 to 100. So most people are trying to do one iteration to make it perfect. And if I can do three iterations on top. So if. If I've got 10 hour or nine hours, they're going to spend all nine hours trying to make it perfect. And I'm going to spend the first three hours learning something, the next three hours learning something. This is how I was able to help Ford reduce product development cycle time by half. We went from 72 months to 36 months, but it was about how do we learn faster? So all of this is about learning. This is the hard part is mo we think of development as having the answers. And this is where I think employment has changed over the years. Where when I was hired, I was hired because I had the answers. And now I believe you're hired because you know how to find the answers. And so I think that's the thing is, is that the workforce that can learn the fastest and iterate the fastest will always win.

One of my favorite things to here are just stories of success. And I know that I asked you earlier, but I'm just curious if you have another favorite case study that you like to refer to as far as, hey, this was really cool what we were able to deliver, as long as.

You don't reveal it for later. But I'll say it for now, which is. So Clay and I are sitting in his office, we're just wrapping up, and he goes, you know what? I've been thinking about this. Tell me what the greatest innovation you've ever worked on in your entire life? And my first answer is like, oh, the next one. He's like, no, no, no, no, no, no. Here's the deal. You're dead. You're on the pearly gates. There's a list. St. Peter has a list. And what's on the top of his list that's going to get you into heaven? I'm like, holy crap. Like, wait, what? And I'm like, okay, I got to think about it and come back. So I'm thinking like, okay, well, first of all, the guidance system for the Patriot missile is going to send me to hell. Like, there's just no question that that's like. It was, by the way, amazing project. It was just so complicated. It was just wonderful. And Pokemon, Mac and cheese, as delicious as it is, is probably still gonna send me down. And then I realized that there was a project that I did in 1987. It involved me driving Dr. Deming around. And the whole thing was, is we had a Hertz rent a car. We were in Des Moines, Iowa, and we're running to the airport. Cause he had no sense of time. And we're literally rushing. And I'm like, oh God, I gotta fill up the car. And I'd literally pull into the gas station and I'd look in the mirrors and I couldn't find the like, which side is this damn thing on? And eventually Deming's in the front, said, this is a problem. We need to solve this problem. Like, no, we need to get to the airport. I need to get gas. Like. And eventually it became like, after time after time after time he talked to my boss and said, and Deming didn't really know my name, he just called me the kid. He goes, we need to get the kid to work on that. On the gas tank problem. So from 1987 to 1992, it took five years. But I helped build the little arrow on the gas tank that tells you which side the filler cap is on. I make no money from it. I had to research it to the nth degree of accidents and number of things that was going on around airports and. But ultimately it's ubiquitous on every car. There's no protection to it. And my belief is like, it's the one thing that'll probably get me into heaven.

It's funny you say that because most.

People either don't know what it is or they're like, oh my God, like, that's amazing.

I just ran into that exact scenario three weeks ago. Traveling for a wedding in a rental car, pulling into a gas station before I get back to the airport, and I'm like, where is the gas tank? And then I looked and saw the oil in there.

I wouldn't say I single handedly. It was like part of a team effort and everything, but it was like, it's the one thing where, from a spiritual perspective, like, there's no money, it saves arguments. It's one small little good thing in the universe.

But it all comes back to struggling moments.

It's right, exactly.

You know, and struggling moments, I think when I first heard that phrase, they're everywhere. But when I first heard it, I thought like, oh, wow, it's big. It's got some sort of level of criticality to it, but it doesn't have to. It can be these micro struggling moments, like not knowing which side of the car to fill the tank up.

So one of the cool parts is I worked with a woman in the past called Kathy Sierra, and she talk about mental leakage it's like these things that you've got to remember, like, did I unplug the coffee pot? Like, you know those. Like again, none of you have this problem, but like when I grew up, those were all the problems is like these things you have to remember that you just can't remember.

Right. Did I lock the back door?

Yeah, exactly. Right, Exactly.

The amount of times where my car is halfway in the driveway, halfway in the street and my wife. Did I turn off the curling iron? It's like, why would I know if you turned off the curling iron?

And the simple part is just put a timer on and people will go like, they'll never pay more for a timer. Are you kidding me? Everybody pays more for the timer. Because it's like, I don't want to have to think about it. Yeah, yeah. So this is where value comes from, these struggling moments. The other part to me is that most people get value confused, is that there's value on the demand side, which is what I'm willing to pay you to help me make progress. And then there's value on the supply side, which is how can I actually help you make progress? And how much does it cost me to do that? Which is profit. They're two completely different. They're actually independent sets of value. And you need to actually understand both. And most people understand profit first. They don't understand progress. And so ultimately, how do we actually understand the progress people are trying to make? That's the essence of jobs to be done.

Yeah, it's interesting. We often talk about sort of the DFV lens, the desirability, feasibility, viability. And I think that oftentimes jobs to be done as a tool get sort of put in the desirability camp. Like we're going to use jobs to be done to figure out desirability, but it's really much bigger than that.

Right. Because it helps with feasibility in terms of what are the trade offs I have to make. And from a cost perspective. Right. I think of it as the foundational research that I need. That helps marketing, it helps sales, it helps product, it helps engineering. It's like, it's the fundamental part that most people aren't doing and they don't want to take the time to do it. And so we've made it small enough that you can actually just kind of like, let's take a step back and just understand what in the world, what causes people to say, today's the day, I need a new widget.

Well, and I think this is from the outside Looking in when I first started coming to terms of what this concept even was coming to terms.

Yeah, it's a weird term. It's total jargon, and I totally get that too. But it's like I had to differentiate it from Personas and like, all these other things. And so it's. And it's all based in engineering and function, right?

Yeah.

Well, I just thought it was interesting that when I first started hearing about it, because again, my background, not in this work. And so as I started having conversations with people around this, it did. It took me a while to realize, okay, so what is it? How does this work? Why do we need it? And it's things that when you really unpack it, you realize how vital it is. But if you don't take the time to unpack it, you can, what we've been talking about for so long, you can run to step three and four and five without ever actually understanding truly the need that your end users are going to have.

So I wrote a book that's just kind of like tips and tricks kind of book. But I wrote a book called Demand side Sales. And one of the reasons why I wrote that book was like, most people hate salespeople. And what you start to realize is that salespeople, like, having gone and got my mba. Sales is the hardest of any of the skills that you have to do when you do a startup. It's like, it's hard and you realize there's no training for it. Like, there's no sales professors. Where's the sales professor? Like, you learn marketing, you learn finance, you learn strategy, you learn this. But why is the hardest thing of all not actually even in the curriculum?

Yeah.

Right. So it's one of the reasons why I teach at Kellogg. Craig Wortman is head of the Kellogg Sales Institute, and he teaches basically people how to sell. But what I did is I took the book and I said, stop worrying about selling. How do you just help people make progress? And so you start to realize, like, most people have to sell all the time, but if you reframe selling as helping people make progress, you start to realize, like, oh, my God, this is actually kind of fun. And you start to realize people like teachers, teachers are salespeople. They sell a lesson to a student. The student has to do the work. The teacher doesn't have to do the work. And so ultimately a nurse or a healthcare professional has to sell the rehab program. And so ultimately it's all of these things we have to do is to help convince people to make progress in their life. And when you frame it from I'm going to sell you a product to I'm going to help you buy, all of a sudden it almost disarms the whole situation.

Yeah. And one of our salespeople here is very talented guy. That's one of the things that he always talks about when it comes to the sales process is like, I'm not here to sell you anything. I'm here to figure out how to help you make progress in what are you struggling with?

And so this is where you say, what are the top three things? Most people say, like, let me tell you what yet. I do. It's like, no, tell me the top three things that you're struggling with right now. Because look, if it's not on the top three things, what I do is not going to be relevant. And then I can say, like, when these things happen, you should call me and people call me.

Now you've mentioned a couple times now the books. I am curious though. You talked earlier in the interview just about how reading is not my deal. Right. So how do you write a book when you.

Yeah, so. So what's interesting is I found a company called Scribe Media. We framed the book as a job, set of jobs. Like, who's going to pick up this book? Right. So we. The who. And then it's like, when, where and why are they going to pick up the book? What are they struggling with, what's going on around it? And so we talk through all that and then what we do is we get on a whiteboard and we kind of whiteboard the processes of what they need to learn along the way. And then what would happen is they would come and just talk to me. They do like the podcast and we do 10 three hour sessions where they would talk to me about basically each chapter and then they go off and write it for me. When you read my books, it's like, I'm talking to you. Because I am. Yeah, right. And what I realized is like, a book is an important aspect because to be honest, most of the books I've written are about. I want to move on to something else. Like there's so many questions that people have is like, oh, here, read this book. And so if they do the homework and then they come back, we can now start at a different level of conversation. And so I wrote a book called Choosing College with Michael Horn. So I did most of the research, or Michael was part of that research as well. But ultimately I usually partner with somebody who can either write or I Find a company that basically can write on my behalf. And they're short, they're easy reads and they're full of stories, but they get the principles and points across.

How old were you when you wrote your first?

So I helped on competing against luck in 2016, relatively recent. So in the pandemic. So people ask me a lot, how do you do all these different things and work on all these different projects? And like, you're always moving. And one of the things I realized is that time is the most precious of all my resources. And so when I was 20, one of my mentors, Dr. Taguchi gave me a watch, gave me a Seiko watch, and it's one of my most prized possessions. And he said, he goes, you need to understand that time is the most precious of all your resources. You can't save it. You need to spend it wisely. And people will steal it. They're worse than a thief because you can't get it back. And so treat your time very preciously. And then what happened is I realized that there were people that I met who had near death experiences who valued time like 10 times more than I did. And so I kept going, like, how do I build that mindset? So my mother, like, she just helped me throughout my entire life. But she died when I was 25. She kept saying she was going to be, I'll do that when I retire. I do that when I retire. And she ended up retired. Four months later, she passed away from colon cancer. And so I took her birthday and her death day and added it to mine. So I say, I have 1402 days left right now. That's three years, more or less. My mom died three years from now, more or less. And so what I did is I said, what do I want to spend my time on? The first thing I did is I got rid of all the bad people in my life. You start to realize, like, if I've only got this much time, I got to do these things. And then you start to realize, like, what else can I do? And that's where all of a sudden, I'm going to write a book. I have no idea how to write a book, but I got to get this out. Because if I'm going to die in this time period, and so this is a lie I've made up to make myself productive. But the reality is the 1402 days is bonus. So it's literally a lie I made up that's forcing me to make way better decisions and have me value the moments that I Have like spending time with you guys today. The other part to me is I realize every single day when I go to sleep, I have no energy left in my body and I wake up full of energy. And so I want to spend every ounce of energy I have every day helping people. Yeah, that's what I do.

How did you arrive at that level of clarity? Because you're clearly making strategic choices.

Yes, I'm making a blind to force me to do things that I probably shouldn't want to do.

Right, but you could be doing a lot of things with that. 1400 days.

That's correct.

And you're choosing to spend it giving back to people.

Yep. But also spending time with my children. So one of the things when I started this, I had seven years and I'd see my kids once a quarter. And what I would say is like, think about seeing your kids only 28 more times in your life. It's like heart wrenching. Like, I can't do that. So now I ski with my kid. Like I skied with two of them last week. I'm gonna ski with a couple of them next week. I'm always trying to make sure I have time with my kids because at some point, like that's the other legacy that I have. So it's a combination of family and helping others. And to be honest, there's still so much in my head I gotta get out. So I'm working really hard to kind of build the mechanism to let my brain get rid of some things.

Well, you've succeeded in this conversation because I learned so much from you just in the short amount of time and couldn't be more thrilled to have been a part of it.

Thank you for having me. Thank you so much.

Yeah, Very appreciative of your time. I've learned a lot. I'm sure this has been great for our listeners and. And again for the folks who are listening and you want more. Bob, in just a little bit is going to be given another presentation here at Method. We'll have that available on our YouTube page. You can check that out there. And Bob, thank you so much.

Thank you for having me.

Appreciate your time.

Thank you so much. Be well, guys.

Thank you for joining us on Build what's Next Digital Product Perspectives. If you would like to know more about how Method can partner with you and your organization, you can find more information@method.com also, don't forget to follow us on social and be sure to check out our monthly tech talks. You can find those on our website. And finally make sure to subscribe to the podcast so you don't miss out on any future episodes.

Roads.

We'll see you next time.