May 27, 2020

Perspectives and Challenges of Jobs to Be Done: Livestream Recap

Jim Kalbach

Jim Kalbach is a noted author, speaker, and instructor in customer experience, experience design, digital transformation, and strategy.

Jim’s newly published book, The Jobs To Be Done Playbook, offers techniques organizations can follow to turn market insight into action.


Tony Ulwick

Tony Ulwick, Strategyn Founder and CEO, was one of the principal architects of the Jobs to Be Done theory, and he continues the development of this ideology through his innovative work of today.

MURAL Imagine kicked off last week with a riveting discussion of the Jobs to Be Done theory: JTBD pioneer Tony Ulwick, founder and CEO at Strategyn and author of Jobs to Be Done: Theory to Practice, spoke with Jim Kalbach, head of customer experience at MURAL and author of The Jobs to Be Done Playbook.

Tony and Jim shared insights on the differences between emotional and functional jobs, how JTBD relates to design thinking, how to better understand innovation and market needs, and so much more.

This livestream was part of MURAL Imagine—a multi-week event in which we explore the future of imagination work and remote collaboration. If you're not already signed up to participate in MURAL Imagine, register now to get access to updates about all the upcoming content. 🪁

You'll find a replay the discussion below as well as a mural of the livestream created by MURAL's own Mark Tippin.

📹 Replay the Perspectives and Challenges of Jobs to Be Done livestream here:


👀 Access the MURAL here:

JTBD MURAL Template


📝 Transcript


Jim Kalbach: Hello and welcome to the webinar perspectives and challenges in jobs to be done. My name is Jim Kalbach . I'm the head of customer experience at MURAL, and I'll be your host today. I'm thrilled to be joined by my very, very special guest and pioneer in the field of jobs to be done. Tony Ulwick, the founder and CEO of strategy.

Hi. Hi, Tony. 

Tony Ulwick: Jim. Thanks for let me be here. It's excellent. Looking forward to it. 

Jim Kalbach: My, my, my pleasure. And, um, as many of you listeners may know, I just published a book on Jobs to be Done called the Jobs to be Done Playbook. And that's really the culmination of about a decade and half of my investigation and exploration into jobs to be done.

And my first introduction to jobs to be done came in about 2003 when I read your landmark article, Tony in Harvard business review called turning our turn customer input into an innovation. Uh, and at the time I was [00:01:00] working in, um, you know, design teams practicing human centered design, and it really resonated, really resonated with me.

Um, and since then I've been a fan and advocate of jobs to be done, but there's also been a lot of interest recently as well too, in the past five years or so, a lot of, uh, a lot of interest in jobs to be done. Even some hype. Which we might even get into, uh, later. Tony. So after, uh, after Tony gives a short presentation, we're going to have a discussion about some of the principles and practices and issues in jobs to be done.

My colleague, Mark Tippin is going to be creating a mind map of the conversation on the fly as we talk. Um, and then at the end we're going to do a Q and. A. So if you're listening and you have a question, please put it in the Q and a pane of your webinar software. You should have two options. One, a chat.

And the other is a Q and A pane. You can say hello and talk to each other in the chat. In fact, I recommend that you do that right now. Let us know where you're calling in from. We'd like to see the countries in the locations, so say hello in the chat, but if you want Tony and I to answer a question, put that in the Q and A pane.

[00:02:00] Um, you can also follow us on Twitter as well too. So it's at MURAL. You can follow us at MURAL on Twitter and use the hashtag imagine 2020. So this is the first event of a, of a multi month program. We have over 40 speakers, uh, in this event called imagine here at MURAL over the next two months. And you can go to mural.com/imagine and see more sessions.

This is the first one of the series. And you can you use the hashtag again? Um, imagine 2020. So again, if you have a question, put it in the Q and A pane, we'll, we'll be taking some of those at the end. And you know, with that, Tony, I'll pass it over to you. 

Tony Ulwick: Jim. Thanks for that. Appreciate it. And again, thanks for inviting me here.

Uh, I think we all, everyone here has a similar goal. We're trying to take the guesswork out of innovation. It's been, uh, you know, a goal of mine for the past 30 years or so. So what I wanted to do is just start with some basics. Now, what is innovation? I think we need to define it. We define it as a process.

I always have. It's the process of devising solutions, [00:03:00] that come up that address unmet customer needs. Now the, the goal of innovation is pretty straight forward. We're trying to conceptualize products that a certain twin in the market that would be ideal. And the thought here is we want to be able to exit, exit the innovation process with a, um, with a concept that a certain to get the job done better and more cheaply.

That's our goal now. Um. We separate the innovation process from the development process. I want to make that pretty clear because that's going to be pertinent to part of our discussion as we go forward. I think we would like this, what we're trying to do, we're trying to do the right things and then we're trying to do them right.

Now let's talk about the state of the state today and where we are with the innovation process. Uh, there's two approaches generally that people follow. One is what we call the ideas first approach. And we say this is inherently flawed because it never reveals. All the [00:04:00] customers' needs. It's a constant iteration and guessing game.

So people have an idea. It might be based on some unmet needs, but they don't know all the unmet needs. They don't know all the needs. So when it goes into development, they start through this generative process. They learn that they don't have all the needs, or maybe the need was incorrect for those sorts of things, so they have to come back and refine the concept.

And then go back again and iterate and so on. So it's a very inefficient way of learning what all the needs are. So ideally we'd flip this around and have all the needs upfront so we would know what are all the needs. Which needs are unmet other segments of people with different unmet needs. And once we know all that, we can come up with a solution that will address all the unmet needs.

We can see concept tests against that set of needs, and we can know with certainty before we go into development that the product we're building is going to address the pertinent unmet needs. That's ideal, right? [00:05:00] But why doesn't that happen even in this needs first approach? Well, let me ask this question, Kim.

If you initiate the polling, is there agreement on your product team as to what a customer need is? We'll give you a few seconds here for a response, but is there agreement on your product team as to what a customer need even is. 

Jim Kalbach: Yeah. So you should have, you should have a poll that just launched as well too, so you can go ahead and take that.

Oh, um, there we go. I see that. 

Tony Ulwick: I can't vote. 

Jim Kalbach: You can't vote. Okay. Your bandwidth. Yeah, I can. I can see it. It's still moving. Got a couple of hundred people coming in. I'm just going to give that in another second. Tony, it's seems like there's still activity there. 

Tony Ulwick: Okay. 

Jim Kalbach: Still a little bit of activity.

Starting to slow down. All right. I think that's slowed down enough. I'm going to share the results. Okay. Tony?

Tony Ulwick: Sounds good.

Jim Kalbach: Okay. [00:06:00] Share results. So I think that showing on the screen now. 

Tony Ulwick: So that's pretty interesting. So we've got about a third of the population says they do agree there is agreement and about two thirds say there isn't agreement as to what a need is.

So this I think sets up the issue quite. Uh, quite clearly if two thirds of the product teams out there don't agree on what a need actually is. And the other funny part about that, those of you who think there is agreement may want to second guess that has, well, and this is what we see constantly in industry.

There isn't agreement as to what a need is. There isn't an agreement as to what types of needs exist. Well, what inputs are required to make innovation predictable? So this is what we've been working on for all these years, is to take what seems to be. A mishmash of terminology and to figure out, well, what is a need?

We see companies use all these different terms interchangeably as if [00:07:00] they're all decent inputs into the innovation process, but just like any other process, you can't expect any input to produce the desired result. Maybe we need to be more specific, and this is where jobs theory really comes into play.

This was the eye-opener. You know, people buy products and services to get a job done. Now what we can do from need standpoint is make the job that, you know, analysis mean we're no longer seeing everything through the lens of the drill maker was seeing it through the lens of the homemaker. And when we do that, we define markets and needs and opportunities to segments and strategy very differently.

So this is all part of the outcome driven and innovation process. It starts by defining a market, but not as a product or a technology, but as a group of people, we're trying to get a job done right. Then moves into defining customer needs, but not as excited as are delighters or any of those other terms, but quite specifically as the metrics that people using to measure success when they are trying to get that job [00:08:00] done.

Can we look for the opportunities and opportunities aren't technology to actually underserved and overserved needs. So we want to quantify them to figure out where the market's underserved from. Generally willing to pay more to get the job done better, or overserved where there's room for cost reduction.

And when we talk about segmentation. We don't segment around demographics or psychographics. Segments are groups of people who have different sets of unmet needs. So with this lens, it changes the way you approach the innovation process. And of course it impacts the result as well. So when you have these insights, you can formulate a strategy that aligns the actions of marketing and sales and development, R and D around this common understanding of customer needs, which allows you to bring predictability to the innovation process.

So the way this begins, or the question I should ask you is what customer inputs bring predictability to innovation? So we printed needs framework that I'm going to [00:09:00] introduce here. The first thing we want to ask as well, there's customer inputs. Who are the customers. And this can often be a bit confusing as well.

There's three types of customers that we see. One is what we call it, the job executer. That's the person who's actually using the product to get a job done, but there's often more customers than that. We have the product life cycle support team. These may include people that have to install a product or maintain a product where dispose of a product, anything through that product life cycle, and then there's people that buy the product.

And people who buy it maybe different than, than people who use it and people who support it, and they have a different set of needs as well. So recognizing that there's three types of customers sets up the next level where we can start thinking about, well, what are these jobs that people are trying to get done.

The one that we focus on and define a market around is the core functional job. This is the reason why people are buying the product, but [00:10:00] if we studied the core functional job, we can figure out ways to get that core functional job done better. But there's other inputs as well. One is what we call related jobs.

So as people are trying to get the core job done, they may be trying to get other jobs done too. And if we knew that and we knew what jobs were underserved, we could potentially help them get multiple jobs done on our product platform. That makes our product platform more valuable. The other is emotional jobs.

People want to be perceived a certain way as they use a product or feel a certain way as a result of executing the job effectively. Understanding the emotional jobs. It helps us better position from a marketing perspective. The other set is the jobs related to consumption. As I alluded to, people have to receive a product and install it, set it up, learn how to use it, interface with it, transport it, clean it, store it, maintain it.

Everything through the product life cycle. Now, of course, people aren't buying [00:11:00] the product so they can install it and learn how to use it and transport it, right? They're buying it to get that core functional job done, the related jobs and the emotional jobs, but if we fail to deliver along these consumption jobs, we could lose in the marketplace as well.

Then of course, it's the buying job that the financial decision maker purchase decision makers trying to get done. So the next layer is the outer layer here. These are all the inputs that we capture to use as the ingredients into the innovation strategy. What we say is on the other edge, the outcomes, those are the metrics that people use to measure success when getting the job done.

Now when we think about needs, we wanted to find them again, very specifically, we're defining them as that outer ring, the hundred plus metrics or so that customers use to measure success by executing the job to be done, and we call those metrics the customer's desired outcomes, and that's where outcome driven innovation gets [00:12:00] its name.

When we think about outcomes or very specific structure. Um, and I'll talk about the rationale here. In order to get a job done better, you can get done faster, more predictably, or with higher output and throughput. That's true of any process, right? You can get it some faster, more predictably. So there's no variability from instance, to instance.

And the desired result is achieved each time. So what that suggests is that we can figure out from a speed standpoint, we can minimize the time it takes to. Achieve something in a certain context. That was one form of a desired outcome statement. And we've tested many variations of this over the years to see which ones make the most sense work the best in practice.

These statements have to be knowable. They have to be discoverable, they have to be unambiguous. They could be stable over time. They have to be inputs that marketing [00:13:00] development, R and D, uh. And a strategy and planning group can all agree on and get behind. The other type of statement looks more like this.

So if we're trying to get the job done more predictably or higher output throughput, and we want to minimize the likelihood that, I kind of say that bad things happened, right? What are the things that are causing it to go off track or. Causing it to be inefficient and we want to minimize the likelihood of those things happening.

So this is the basic structure concept. So let's just take you through a quick example. In the middle. Very see maintaining the health of your teeth as the core functional job. Here's what a few outcomes might look like. Like minimize the time it takes to move particles from between your teeth. These would be outcomes on the core job itself, but then we have related jobs.

Keep your teeth white. That's something you might want to do. In addition to maintaining the health of those teeth and emotional job, maybe I want to be perceived as affluent consumption chain outcomes [00:14:00] might be, minimize the likelihood of damaging my gums from using the products where minimize the likelihood that harmful germs are harbored in the product itself.

From a financial standpoint, I want to minimize the cost of product waste as an example. So you can see this gets fairly complicated, but inputs that you're capturing from customers fit into these categories. In other words, if you were to talk to customers about what they're trying to accomplish, they would fit in these buckets.

And knowing what these buckets are and being able to organize them upfront in the innovation process is what brings predictability to innovation. In other words, we want to know all these needs. We want the developers to know all these needs. So as therapy being assigned a specific outcome to go address or a specific solution to build, they understand the rationale behind it.

And it's so gorgeous, so they don't have to then take it upon themselves to go back out to customers and figure out this, figure out what all the [00:15:00] needs are and how they interact and their interdependencies. I think it's important mentioned as well that. It's not as if customers have five or 10 beats.

Right? On the core job, there's often 50 to 150 different metrics that they use to measure success. When getting a job done, there might be 20 or 30 related jobs that might be 10 or 20 emotional jobs. We may have 20 to 80 outcomes on the consumption elements. There could be 15 to 50 financial metrics that the purchase decision maker is using to measure success.

Now, that may sound like a lot, however. Once you have these set of inputs because they're stable over time cause they're attached to a stable unit of analysis, the job to get done, you don't have to go refine these or refresh them every six months or three months or a year. They're stable for years. And that's one of the big benefits of using the approach.

Once we've defined all the needs, we can use them for years to, [00:16:00] uh, take the, uh. Inefficiency out of innovation. So it comes back to this. What we're trying to do is figure out what are all needs, which are unmet other segments of people with different needs. Target those that we think we should in order to create the most value for our customers.

And devise the solutions that will address them, and that's how we exit the innovation process. Knowing that we have a solution that will address those unmet needs, doing that makes the development process much more efficient. It brings agility to at child development because you're not guessing if you've started from the race turning point, you already know you're building the right product right upfront.

And Jim that really I think sets it up of what we're trying to do here is take the guesswork out of innovation. And if you do want to learn more about, uh, outcome driven innovation, we have the opportunity to download a free book. It's an audio book or an ebook. You can get it online. The jobs we've done, book.com and Jim, I think that leads us [00:17:00] into the next part of the conversation.

Jim Kalbach: Yeah. Great. Thanks for that. Thanks for that introduction. Um, took a lot of notes there and I'd like to unpack a little bit of that and then get into, uh, some of the perspectives and challenges around that. I'm going to ask my colleague, Mark Tippin actually to share his screen and he's going to be kind of Sketchnoting or mind mapping our conversation.

Um, Tony, yeah, thanks for that. Well. Yeah, we got you. We got you. Mark. You can, you can zoom in there. Thanks for that. Yeah, you bet. Um, one of the things, Tony, when, when I started first exploring jobs to be done, particularly that kind of perspective and framework that you just laid out was the difference between a job and a need.

Um, and it, it, it took me a while in my mind to kind of separate those things. And so, correct me if I'm wrong, your framework actually does separate those things, correct? 

Tony Ulwick: Yeah, that's exactly right. Getting the nomenclature down is absolutely critical. You know, having a common language for innovation and describing the.

How the peak, what the pieces are and how they fit. I think it's really critical. And so we [00:18:00] call it the, the job is what the customer is ultimately trying to accomplish with the product or service. A need are all the metrics they use to measure success along their journey. Right? So there's, for one job, there might be 50 to 150 different.

Needs or outcomes. And so we, it's a, it's a tiering kind of thing. So that we were kind of like building out a puzzle or map, right? For that high level job. Here are all the metrics people use to measure success, right? So it's not enough to just know what the job is. That's the starting point. You need to go a layer or layer deeper.

Jim Kalbach: Right? And then in between there, correct me if I'm wrong, again, you would have steps, steps in your job maps so you can take a job and break it down into its constituent constituent steps, um, in that kind of middle, middle layer. So you don't just have to think about maintaining your teeth, uh, your health, that that you can break that down into steps as well too, right.

Tony Ulwick: Yeah, thankfully you can, Jim, and you know, early in the days when we were doing this, we didn't have a job map and we didn't get the [00:19:00] job. We would just capture all the inputs on the high level job and we'd have 150 inputs and then we would organize them. Um, and then we realized that jobs follow a pattern.

You know, there's a planning step up front and so on. So we created the job map. We introduced that in HBR back in 2008. Right. That's been a very helpful tool. And, uh, just, just completing a job map is extremely insightful too. Because from there you can figure out, uh, you know, are your products getting the entire job done?

Action your portfolio. Uh, what about your competitors, right? Uh, what parts of the job are they getting done and do they have a possibility of a platform level solution that will get the entire job done? So just even going that far into the process starts revealing pretty interesting results. 

Jim Kalbach: Yeah, I'm glad you said that.

Cause I actually did write down here, how can people just use parts of that framework. There is a lot going on in that circle and you look at those, you know, three job executor's and all those jobs and all the needs. And if you told them that up, it's hundreds [00:20:00] of needs. You know, how, how could, how could somebody listening just do a part of it, um, uh, you know, step into, into your framework and still get value out of it.

And I think the answer that you just said is a job map. A job map has a lot of utility, correct. 

Tony Ulwick: Well, it does. So that's certainly one of my, but we can even start before that. Um, a lot of companies make hundreds of products and they actually don't know what markets they're in from a jobs to be done perspective.

So, um, one of the first things we recommend is for a team to define the markets. The company is already in through jobs to be done. Lens, you may have 50 products, but you may be in. Five markets, you know, they only maybe five job executes trying to get jobs done, but it's, it looks more complicated than it is.

And just by defining your markets through this lens, you can begin to see if there's inefficiency or duplicate resources and things like that that are aiming to do the same things. But you're, you're organized around product versus the job. Right. That's a great [00:21:00] benefit. 

Jim Kalbach: And you know, along those lines too, I wanted to get into those related jobs because I also find when I'm talking about jobs to be done in general in the workshops and talks that I give, that not only is the difference between a job and a functional job in a need is something that people have to be clear about, but also related job.

And when does my job and then a related job start and how do you define that? But then. You know, if you, if you're working in software, for instance, they're actually, your piece of software might actually cover lots of related jobs. Um, and it can get very murky when you start talking about related jobs.

I've found.

Tony Ulwick: Well, absolutely, especially software products. They get multiple jobs done. So, um, you would have multiple core jobs that you'd want to study. It might be the same individual getting that job done. So you have the same job executer executing multiple jobs. You'd have to break down each job separately and right, and follow the same line of thinking, but in each case, so you'd still want to know what are the related jobs associated with that job, that [00:22:00] core job that they're trying to get done.

And, uh. They're, the reason we're looking for those is to see if there are more. Underserved related jobs that you could build into your platform. And of course, knowing this upfront, you could architect a platform that will eventually get many jobs done, right? Even though you may not start getting many jobs, you just pick one, right?

But you can lay out your plan for growth over a period of three to five years. 

Jim Kalbach: Right? So we, we wanna we want to get this core job done really well right now. And related to that, or, you know, some other things. So if you're talking about financing, you know, it might be, you know, planning for your longterm financial wellbeing, but guess what?

Daily spending and you know, how mortgages, and there's other things that are related to that. But if you get that. That's that core job done first you, you have a path forward to grow your business, right? By going into those related jobs. 

Tony Ulwick: That's exactly it. You know, you, you build your core, you create something profitable, you create something that's going to fund the growth into those other areas, and that [00:23:00] becomes your strategy.

Jim Kalbach: Right. 

Um, so, uh, I'm, I'm going to switch gears a little bit and talk about progress because Clayton Christensen, who we generally point to as kind of a, an origin of modern jobs, thinking that, you know, modern jobs practice, right? Um, the actually in, in, in the last book that he wrote, a competing against luck talks about job, a job being the progress that somebody wants to make in their lives, right?

Um, and which from my standpoint, I'm just going to throw this out there and let you react to it. Tony, it's when you start talking about progress, you're actually, you're actually aggregating related jobs. And kind of looking at what the aspiration of that is at a different level of abstraction. So I always see a relationship between progress and a job or a core functional job as one of abstraction that if you look at several related jobs, okay, I want to, you know, get my finances in order and manage my daily spending.

But what do I ultimately want from that is, you know, financial peace of mind [00:24:00] or something like that as progress that I make in my life. And I'm curious, how do you see the, the progress, um, perspective of jobs to be done in that, in the equation? 

Tony Ulwick: I think from a theoretical standpoint, it makes pretty good sense.

It's, it's elevating up to a higher level of abstraction to say, yes, people are trying to make progress. From a practitioner standpoint, I think it takes you in the wrong direction because, um, it takes you away from anything you can measure, right? So how do you measure progress in your life. Well, let's just go back to the basics of jobs to be done.

You know, people are buying a product to get a job done, right? Let's figure out the progress in getting the job done, right? So how do you measure progress in getting a job done? Well, that's where the outcomes come back into play, right? If we know how people measure success when getting a job done right, and we create products that get the job done better.

That's how we can bring, you know, measurement to progress. So I think it's, uh, you know, an interesting layer of abstraction from a theoretical standpoint, but [00:25:00] it's not something we really concern ourselves, you know, as practitioners. 

Jim Kalbach: Yeah, I, I agree. And, um, you know, I've, as you know, kind of a design practitioner and leader and workshop facilitator, I've gone into many sessions.

Where are the problem that we were going to solve is, you know, giving people financial peace of mind. And it's a really bad starting point because there's any number of ways that you can solve that. And. I always say that you, you want to work at a level of abstraction that you can actually affect that, you know, I'm in, I'm in this business and, and, and, and we intend to, to, you know, have a market motion or to bring an innovation to the market.

What can you, what can you, um. What can you affect first and foremost, and let's solve that problem before it, before you start, you know, solving world peace, you know, cause solving word visa is a bad, bad place to start innovation, right? 

Tony Ulwick: It certainly is. It's a, it becomes an actual, pretty quickly. It's hard for me to find a job the way we do and we define it as a verb with an [00:26:00] object of control and a contextual clarifier if you define it that way.

More or less, more than more likely than not, you'd be defining a process that you could execute in that go act on like parents who were trying to pass on life lessons to children, for example. That's past life lesson onto children, right? So verb, object of the verb, contextual clarifier even, you know, cut a piece of void in the straight line.

You know, very specific things that people are trying to achieve. And then you can measure. Progress along that job. Right, right. Gotcha. But you need it. You need a solid starting point. And this is why we don't define the markets around the emotional job or that high level of stress. And because it's the wrong starting place, we include the emotional jobs after we define the core functional job that we're trying to execute and then build around it.

Jim Kalbach: Right? Yeah. And the thing that I like to remind people that it's a job to be done, and those, you know, those higher level abstraction, uh, descriptions, those aspirations are, there's often no end endpoint to, you [00:27:00] know, peace of mind is, when did it begin? When did it end? Um, but, um, uh, yeah. Um, I also, I also think though that, um.

Um, yeah, again, just, just being able to, what can you realistically effect? So if you make, if you're the maker of drill bits, um, you know, do you want people to have a home, a happy home life? Uh, but you know, so you're sitting here making drill bits and you know, that is, is that a problem that you can actually affect, right?

Tony Ulwick: Yeah. Kim, to that point there, I'm sure you've heard this before, you know, you talk about. People want to create the quarter inch hole. And then others will argue, well, maybe they want to hang a picture, or maybe they want to work in a more productive environment. Now maybe they do, but this is, this is one of those sketches and the job she'd done steaks, as soon as you asked that question, you've changed the, you, you've changed the, uh, the problem you're trying to solve because the drum maker is already in a market, right?

And so the question for the drill maker is, what market am I in? Right, and they're serving [00:28:00] tradesmen who are trying to create a quarter inch hole. There's no doubt about that right now the question that others are posing is, should that company pursue other markets? Should they get in the frame market?

Should they get in the decoration of the room market? Right? Those that's now a market selection decision. And as you start embarking on this and asking yourself what, what. Where do I begin? Don't fall into this trap and say, okay, I'm in a market, but should I be in another market? Separate the two exercises one's a job, a market selection exercise, and the other is a market definition exercise, right? Getting that clear is absolutely critical upfront.

Jim Kalbach: Right, but you can change your market definition, by going up a level of traction. Maybe you want to be a picture frame  business. I'll just make that up, and now suddenly you've widened your scope of vision. As, as a business targeting a market because your market is bigger or... 

Tony Ulwick: Yeah, and that's changing markets, right?

[00:29:00] Because before you were creating quarter inch holes and now you're hanging pictures on the wall, right? So two different things. However, like you could use the example of the kettle maker who boils water, right. Creates a product that boils water. Yeah. But, uh, the customer is trying to get a bigger job done.

They're trying to create a hot beverage for consumption. Right? So then you could, you could elevate it there. They're still in the same plane, if you will. They still give you a way to grow from your starting point versus the other. The drill maker has no starting point to hanging pictures on the wall because.

They're not in the frame business. They're not. Right. So I think those are some of the key distinctions. But the basic, um, you know, uh, recommendation is make sure you separate market selection, discussion from market definition discussion.

Jim Kalbach: Right. Yeah, I understand that. And the other way that I like to explain it too is, um. Your starting point should be that unit of analysis that is defined, has it done state and is something that you can [00:30:00] affect. But no, knowing that aspiration is also important for other other motions, product design, marketing, for instance, it is important to know that somebody who's planning their finances wants peace of mind.

Right? So it's not unimportant to know that. Correct. So to know that progress at the aspirational level, right, Tony? 

Tony Ulwick: Yeah, that's exactly right. And that's why we include, we call them emotional jobs and we include them in the framework. There's generally between 15 and 25 emotional jobs that we capture in qualitative interviews for any giving um, marker and critical part of the process were exactly as you, you say, uh, if we know what emotions, and this is very interesting as well. Um, just a quick aside for a second, cause we know what needs are unmet and you decided to go address them. Let's say there's five unmet needs that you go target. We can run a correlation analysis to see which emotional jobs correlate them the best. So in your marketing message, you could talk about how you're improving [00:31:00] function and the emotion that elicits and tie the two together statistically.

That's our view of how they should come together. So all the ingredients are there, right? You want to capture this. There's emotional jobs, and when it comes time to marketing you, you, you know, you want to correlate them with the function that you've improved so that your message is optimized for the target that you've defined.

Jim Kalbach: Right, so, so you, you know, there, there are different perspectives and that's what we're here talking about some different perspectives in jobs to be done. Um, and I, you know, I kind of started, uh, you know, with the, with the idea of progress to, to open up, uh, another perspective of jobs to be done. The way that I explain or harmonize those is, is twofold.

One is, it's a matter of sequence. Where are you starting? And then, and then do you move up. Right. Or to go to the aspiration level. And then the other one is just thinking about, you're thinking about things at different levels of, of abstraction as well too. So it's, it's the, it's the process or your starting point, I should say.

I don't want to say the word process, but it's, where are you [00:32:00] starting to innovate, um, is different in these different schools of thought and then at what level of abstraction and are you working? But I think a lot of the thinking is the same though, behind, behind, behind the different perspectives that are out there.

I don't know what your take is on that, but... 

Tony Ulwick: Well, there's so many perspectives. So, um, can you pick one for me? And, um... 

Jim Kalbach: I mean, let's just say Clayton Christensen, you know, the, you know, what he talks about in competing about competing against luck. 

Tony Ulwick: Well, you know, so let's just talk about the milkshake marketing example.

Jim Kalbach: Yeah, there you go. 

Tony Ulwick: So, um, I find it interesting. I mean, it illustrates some of the key elements of job's theory. However, um. It starts with the question that says, you know, you have a, uh, uh, a chain that's trying to increase the sales of a product. Uh, and that's how the story begins, right? So we would say that, well, you've, the goal of innovation is to create products that people want, [00:33:00] not necessarily make people want things, right? So you could take these concepts and apply them on the marketing side. And I think that's what the milkshake marketing example does. It says, I have a product, how do I sell more of those? But let's look at the jobs that people are trying to get done with milkshakes and then market around those jobs.

So it becomes a a marketing activity or demand creation side of the equation. And that's all well and good. I mean, that's certainly something that you might want to do. Uh, however, that doesn't really inform innovations to the degree that it needs to be informed. So my take is, well, let's just figure it, let's, let's make the right products, right?

Let's make sure that the products are getting the job done and then it's going to be a heck of a lot easier and less expensive to put a marketing campaign to push those products. And, um. And by the way, it informs the marketing as well. So once you have that set of needs, you can innovate and you can mark it and you can plan your R and D [00:34:00] efforts and you can plan your digitalization strategy and all that.

Once you know all the customers' needs and which are unmet, you can't do all that if you approach it from the demand generation standpoint. So in essence, I think it's somewhat limiting. You know, it might be, it might be great in certain situation, but if your goal is to, um, you know. Get a greater return on innovation, then you should focus job's theory on creating better products, creating products that people want that are, you know, making people want things.

Jim Kalbach: Right? Right. Yeah. Um, exactly the way, again, you know, I'm going to throw this out there and let you react to it. The difference, it might be semantic too, by the way, that for me, the goal of innovation is, is adoption. That I want somebody to adopt my tool, which is, which is not consumption or demand. It's, it's, it's actually in that we, you get their job done, they internalize your solution.

They've internalized and brought and pulled it into their lives. So it actually helps them get that done. So for me, again, [00:35:00] it might be semantic, but the outcome of innovation or the goal of innovation should be adoption. Adoption. The goal of marketing or go to market is, is demand. As well too. So I use the I, for me, it's the difference of do you want people to adopt your product or do you just want to create demand?

It might be very subtle, but I think there's an important difference there. 

Tony Ulwick: Yeah, that's interesting. You know, I think the key here is, you know, you want to create products that customers want and then you want to market those products and have people pull them into their lives. But the key to all this working is that you have a great product, right?

If you don't have a great product, you can. Market all you want and try to gain adoption. Uh, and it just doesn't happen. And we have companies come to us quite frequently and say, you know, we put this new product into the market. It's not gaining adoption. Can you help us gain adoption? That's an interesting question because the answer may be, no, we can't help you gain your doctrine because your product doesn't get the job done correctly.

But we can then point out where it's failing to get the job done and then they can make the appropriate corrections. [00:36:00] But when it had been nice, if they just did it that way to begin with. 

Jim Kalbach: Right, right. And the way to do it, I'm just going to shift here a little bit cause I want to talk about your use of the word lens.

You brought up the word lens in your presentation. I've, I've heard you say that as well too. And I say that as well. I call it, call it a lens or a way of seeing. I see. For me, jobs to be done. It's a language, like you said, it's very rigorous. It can be a very rigorous language that gets teams aligned. So you have a clear definition of what a need is, but it's also a lens.

And that lens I find is very, very important because you're not looking at individuals. You're not looking at human beings through the lens of your brand. You don't, you're not seeing them as consumers of your product or your brand, right? You're looking at them as gold seeking actors in the world, and you want to first understand what they're trying to do.

And, and I call it almost flipping perspectives, looking back at your organization from their perspective, right? So for me, I sometimes talk about an out of body experience that it lets an organization, you know, see itself outside of its own brand for, even if it's a [00:37:00] moment. So that they can understand things from a different viewpoint.

Tony Ulwick: Yeah. I think that's a great way to look at it because it is a perspective, and I often hear people say that, you know, once they see the market through this perspective, they can't unsee it. It's like, you know, you live in solution space and you think markets are about technology and needs or solutions and opportunities with technologies and so on and segments or demographics.

But when you look through the lens of the, the homemaker, not the drill maker, it looks different. What I see in it, you know, there's a group of people trying to get a job done and they measure success along each step of the way. Once that switch flips and you know, Oh my God, it looks, everything looks different.

It can never look the same again. And I think that's, um, that's one of the things we, we've always tried to figure out is how do we get people to flip that switch and see it through this different. Lens cause it's, it's really reforming the way people think about innovation and where the starting point is.

Jim Kalbach: Yeah, no. And you know, like I said, when I do some workshops or talks, I'll, I'll give some [00:38:00] rules of formulating a jobs to me. Don't, don't include any technology or solutions in your job statement. Right? And then people go do the exercise and they include the job or the solution in there that we're just so good at talking about ourselves or what we, what you know.

We're looking at what people are trying to do through the lens of a solution that is actually hard. It's actually hard to do that, but once you get there, I think you're right, like you said, is that you can't, you can't unsee that. Once you, once you, once you kind of see the light or there, get that perspective under your fingertips.

Tony Ulwick: Yeah. I think it's innate for us to think about solutions. I think that's just generally the way people are wired there. They think in the problem solving. Space like solution space as opposed to defining the problem space. Right. And it's a, it's a train discipline. Like if you didn't look at Edison, Thomas Edison, and you know, he failed at his first product and he realized he created a product that people didn't want.

And he said, you know what? I'm never going to do that again. And he adopted approach of thinking that said, I'm going to make sure that there's. Uh, but whatever I'm [00:39:00] creating is satisfying and unmet need. And he went on to be, of course, a very successful inventor. So even he, as you might consider him to be a born innovator, uh, you know, he had to, um, train himself to think like a born innovator, you know.

Uh, and I think that's what lives in each of us, right? We have the capability to, to be like that, but it requires a different lens. And what I love about jobs to be done in ODI is it gives you that lens. 

Jim Kalbach: Correct. Yeah. Correct. And, and, and, um, you know, that, that, that's what, when I, when I do exercises with, you know, in workshops and things, that's what we try to, we try to practice that, that type of thinking.

And to some degree, from my standpoint, Tony, um, if, if you can adopt that, that type of thinking, which is truly problem space, you're looking at the whole maker only, right then for me, you're, you're, you're doing jobs to be done. Um, whether whether it's exactly your framework or you have different labels, or you're only doing a piece of it.

It's that perspective for me, that makes jobs, jobs. Yeah. 

Tony Ulwick: I'm with you. And [00:40:00] that's why just thinking through that lens can be so valuable just to finding your market through that lens is valuable. Just to finding a job map is valuable. 

Jim Kalbach: Right, right, right. Yeah, and that's what I, that's what I tried to do in my book.

That's why I call it a playbook, because I wanted to kind of atomize it and say, flip your perspective, and then you can do one thing or a series of things or all of ODI, but you can still have that perspective and you can bring that that in it. It's max. Now, to be clear though, you know, understanding the problem space as such, we'll smack up against the solution space inside of your organization.

There are natural forces that will always make that happen, so you don't have to worry about that not happening, right? That's going to happen, but, but just allowing that to happen, I think gives us. Yeah, different it, it triangulates what you're trying to do in a different way that you, you, you bring that in and then, you know, regular marketing motions or usability testing or whatever you do product about agile, that'll happen anyway, but you'll have that perspective going into it.

That's, that changes the [00:41:00] playing field on the solution side of things. That's what I've found. 

Tony Ulwick: Yeah. Uh, we find exactly the same thing. You know, uh, people, companies aren't short on ideas or, you know, the ability to ideation that's going to happen. Like you say, it's just defining the problem effectively so they can focus their creativity on what really matters.

That's critical, right? And we've got companies gain insights quickly. I'll just give a quick example. Just running like a three day workshop where no on day one you cover some of the Obi or Josh season principles. You bring customers in. Do a customer immersion. You work with them to define the job. Um, to find a job map.

Day two, they come back in same customers. You work with them to create a set of outcome statements and then you have them, even though small group people haven't prioritized them for importance and satisfaction, you can see where the bigger opportunities are. Put them in front of the team, let them do some ideation work and they can walk away.

Uh, knowing that they've created some product feature set or concept that is tied to an opportunity, um, based on [00:42:00] unmet customer needs. So even something like that, it's very transformational. It's quick, but it takes companies from a position where there isn't agreement on what a need is. And we saw that earlier, right?

66% of this audience is saying there isn't agreement. What indeed is. Can you imagine just going from, we don't agree on what a need is to, we agree on what all the needs are. That's huge. Right? And that's the kind of thing that you can do. And they have a one day, a customer immersion activity with a set of customers focused on that topic and that market there.

Jim Kalbach: There you go. There's the out of body experience, so that you, that you offer as a service offer to, to let them to have that experience. That's, that's great, Tony. Um, I just got one more topic and then we're going to go into some Q and A here. And that is, uh, where, where jobs and needs actually come from.

And I know I've heard some rumblings out there that you know, your, your approach or jobs to be done in general isn't based on research, that it's people sitting in a room making this stuff up. [00:43:00] And I know you've heard that too, because I was on a tweet where a 

 where you were defending that as well too.

So where do jobs and needs come from? 

Tony Ulwick: They come from the customer, right? So, um, this is why we start off our process by defining. So who is the customer, right? We wanted to, we want to know who we're creating value for it. We call that person the job executer right? And then we go to that job executer we get a bunch of them in the room and we ask them.

What job are you trying to get done? And we study that we will, it may take two or three hours just figuring out with them what job they're trying to get done. They may not initially agree. They may be looking at it from different levels of abstraction. So we'll work with them for several hours, however long it takes until we reach consensus on what.

The job to be done is so that's the first step, but it doesn't stop there. Now we're going to go create the job map. Often it's with that same group of people. It could be others, but that may take two or three hours as well, and when you're defining the job [00:44:00] map, you may realize that you define the job incorrectly because now you've got this knowledge of all the underpinnings of what that higher level job is, and you can go back and refine that high level job statement again.

That's done. With customers, everything's done with customers. So, um, yeah. I don't know where, how else can you do it? 

Jim Kalbach: Right. I don't know. Yeah, I mean, the, the jobs, the jobs, PR projects that I've, I've done either, you know, ODI in full or parts of it have been the research that I've done. Qualitative and quantitative has been more rigorous.

Than other methodologies that are out there that I, that I'm familiar with, that, you know, engage with customers, that just the depth that you have to go in. I mean, just the words that you said at the beginning, trying to uncover all needs. How do you uncover all needs without talking to dozens of people, right.

With in depth interviews, right? 

Tony Ulwick: Yeah, that's right. Well, you can't miss the answer, right? I mean, you could, I suppose you could sit there and try to make them up, but why would you do that? You know, the [00:45:00] way we've designed these customer immersions, um, and if you follow the path of, you know, getting consensus on the job, and that might take two to three hours, get consensus on the job map that may take two to three hours.

Now you're in day two with the same set of customers work all day to get a set of outcomes, 

right? And now within two days you've got 50 60 80 outcomes that are in good shape that could go in a survey. I mean, you've, you've already made a tremendous amount of progress. So contrast that. One of our last master classes, a gentleman in the back of the room raised his hand and said, so Tony, you need to tell me that we didn't have to go do 50 ethnographic interviews over six month period and all these different geographies, we could just have a group of people in a room for two days and capture all these needs, and the answer is yes, that's right. Sit in the room, capture all these needs, and then go validate that set of values with people all around the world so you can get a worldwide set of validated customer needs. That's much more efficient approach.

Jim Kalbach: Right, right, right, right. [00:46:00] Yeah. So, uh, I think this brings us up to a question that I saw a fly by. Uh, I, I would like to get into the Q and A, and I'm going to ask Mark and Jonathan here to kind of point me to some of the questions. I'm not quite sure where they are, but I saw one of them go by. Uh, there we go.

Thanks. Um, one of them was, so, you know, fields like design thinking, not, not product design, but design thinking, which is separate than the design of a product, uh, is also a needs first approach. So from your perspective, what, what do you think the difference between design thinking and jobs to be done is?

Tony Ulwick: Yeah, so you know, jobs to be done. The way we've always used it is for the process of innovation. The fuzzy front end of innovation where the output is a product concept, right? It's a well-defined product concept. You know what the features are going to be. It's all that, right? Design thinking begins. Next.

Right? So in the fact design thinking was created by designers for development purposes, [00:47:00] right? So it's then take those inputs and carry it through the development process. I've seen them as two distinct things for distinct purposes. Um, what works in design thinking doesn't necessarily work. And, uh, the front end of innovation, what works in the front end of innovation doesn't necessarily work in development.

Right? So let's separate these two pieces out. You know, there's product planners and strategists that are responsible for putting products into development. They have to get it right. That's where our application of job's theory of ODI comes into play. And design thinking designers have to design it, right?

That means they need to understand the needs of people as they approach the user interface. No, we don't cover that upstream. They need to understand the needs of how to make the product easy to install or easy to clean. We don't cover that upstream. Right? Those are all design related jobs. So I think design thinking really addresses a lot of the consumption jobs or needs [00:48:00] related to product consumption.

And um. And of course, you know, they have to get the function right on the product, but the, the definition of the function should come from the product planner and I'll be defined and settled upon before anything's approved for development. Right? Yeah. I feel like people are going to approve products with development that they know a hundred percent going to win, and the only guarantee would be if someone could prove they address the unmet needs that have been discovered.

Jim Kalbach: Yeah, I mean, I think I would take issue with that design thinking at least. So are you familiar with the double diamond approach? 

Tony Ulwick: I'm not. 

Jim Kalbach: Okay. Um, yeah, we'll, we'll have to talk more about that in detail, but, um, yeah. Design thinking has an upstream get the, get the right product, um, phases to it, where it's discovery and definition that are outside of the development cycle upfront.

So design thinking, which again is different than actual product design actually does have. It's own set of techniques that are in the problem space, [00:49:00] uh, for planning purposes as well, too. Um, so, um, yeah, I th and I think I see some comments going by, uh, here about, about that. So I, I would, I would, uh, I would encourage you to look at design thinking.

Well, the word thinking changes changes it. And it's actually a problem because the word design is in there. So people think it's about product design. It's not. It's about applying a creative mindset in the planning phase as well too, and a very human humanistic mindset there as well too. But the idea is to come up with needs to define needs and use those to define what is the right thing we should be going at.

It is about the, what's the product concept in a planning. In a planning mode. Yeah. So that does exist and it's, it is different. It, it overlaps, I think, a lot with jobs to be done, jobs to be done. And I think that's where there's a lot of this kind of reactive backlash from the design community because they say, yeah, we have design thinking and other planning types of things that are actually upstream from development.

Tony Ulwick: Well, you're hitting on, I think, a very [00:50:00] key point there. So this is, I think, you know. Product planning has to be executed effectively in order for design thinking to be only focused on development. In other words. If here's what's happening, uh, the product planners aren't getting their job done correctly.

They're not coming up with products that are going to win in the market. So those products get put into development, and now the developers have to go redefine what the product should have been to begin with. So it's forcing designers to become product planners. And so that's why you see a lot of design thinking techniques that are moving upstream to take over this role of what the product planners should have done.

Right now, what we're saying is product planners get your job done, right? Right. You can do it if you follow this approach. Developers downstream won't have to become product commanders because you've done your job correctly. You've identified all the needs that the developers are have to be privy of in order to go [00:51:00] create their products effectively.

And so I think this is part of the. The issue. Um, if product planners could get their job done perfectly, would developers have to do the front end of innovation. They wouldn't right there. They would be focused on the design portion. And so I think that's the problem. Designers being forced to be product planners.

Jim Kalbach: I agree in some of it, you know, like I said, it's a double diamond. It's two diamonds that are linked together, get it, get the right product, and then get the product right is the other diamond. A lot of that is because if you're downstream and you get handed a set of requirements, you're one day into designing that thing and you know it's not the right thing. And that we have developed that to fill a gap that shouldn't be there on the one side. However, however, I would also argue that planners can also be creative. And I think there's, there's a mindset that, you know, designers have being human centered, uh, exploring options, right? Um, some of those things that I think, cause when you say planner, you know, it sounds like, uh, an engineering [00:52:00] task almost, right?

So I think. You know, having that design mindset, which is really what design thinking is about in the planning phase. That's not a bad thing in and of itself is either, I don't think, you know. 

Tony Ulwick: No, not at all. In fact, we encourage them. A lot of the product planners on our team are actually designers as well.

Right. That fact, I'm not, uh, others are, but I think that's the perfect combination of skillsets to be, uh, you know, to be able to do all the stuff we already talked about in terms of identifying needs and segmenting and conceptualizing products. But then if you have the knowledge of design with you as well, that can't hurt and coming up with better product concepts, right. Or at least stating them in such a way that makes them easier to, to design. So that interface between the planning team and development team, correct. It goes much more smoothly. 

Jim Kalbach: Correct. Correct. And I think, I think that's a big component of it as well, too, is not only planners not doing their job, quote unquote, rate and not having a creative mindset, but I think, you know, injecting or, or bringing some of the design [00:53:00] mindset upfront also makes a better and a smoother transition. Because one thing that I found, Tony, is, you know, you can talk about problem space going into solution space or getting the right thing versus getting the thing right as well too. But I've also found downstream the solution may then open up a new problem.

That you may go down a path that you then say, Oh, I need to now explore this related job. So you may actually go back. And so it's not, it's not linear. I don't think. I've never experienced it as completely linear, particularly on the, in the very early stages of development, say, Hey, we got this thing, let's go.

But when you start seeing it or feeling what the experience should be is, Oh wait, we've got to go back and understand that. So the solution may levy a new. Opening of a problem space as well too. Do you see it as a loop or should it be just linear? 

Tony Ulwick: Well, theoretically it should be linear, in practice,it's not, just as you described, right?

So let's get like this, to the degree that you're extremely successful at understanding all the needs up front, it [00:54:00] can be linear, but it's, you don't know what you don't know and it's nobody's perfect. So, so for the foreseeable future, let's say. It's not going to be linear. 

Jim Kalbach: Great. Okay. We have about five minutes left.

I do want to take another question here. I haven't been looking at them. I won't. I'm wondering, Mark Tippin, I don't know if you're reading any of these, is, is there something that's burning, or Jonathan, that we can go to here in the last couple of questions? 

Mark Tippin: Uh, you bet there's some, um, clarifications on the model.

I thought there was some that were interesting around the customer, right? Or early on we had some customer, their outcomes. Um, so, you know, we're talking about involving customers. Do the customers really know what they need? 

Jim Kalbach: I thought I'm gonna let you answer Tony. 

Tony Ulwick: I love that one. Um, the customers know what they need.

Yes and no. So do they know what solutions they need? No. Do they know what they're trying to accomplish? Yes. Right? And when we're studying the customer's needs, we don't ask them what solution do you want? [00:55:00] Because they don't know what solution they want. They're not engineers. They're not scientists.

They're not material experts. We as researchers, should not expect the customer to tell us what the solution is, right? That's the job of trained scientists. What customers can tell us is what they're trying to achieve. So, of course people couldn't say, Oh, I want a microwave oven. Cause they don't even know what that technology was.

Right? But they can't say, I want to minimize the time it takes to cook a meal. I want to minimize the likelihood of overcooking or under gripping a meal. I want to minimize the time it takes to clean up after cooking. They knew all those things and they could easily state those so they, they know what they're trying to do.

Right. And that should be your goal of, um, of, uh, customer needs gathering is to understand what are those metrics are you using to measure success is to try and get their job done 

Jim Kalbach: Right. 

Tony Ulwick: Jim this is why I also say there's no such thing as latent needs. There's only latent solutions. Think of it like that.

Customers know what they're trying to do. They just don't know how to do it. So they can [00:56:00] talk about their, their solutions. Right, right. So when these solutions come up, people are referring to them as latent needs. They're really latent solutions. 

Jim Kalbach: Right. I agree. And the other thing though, I would, I would agree with that and throw in there too, that people don't talk in need statements.

The way that you had it formulated that you, when you're doing that research that we talked about, you have to be able to kind of infer what the need or to listen in a way that you recognize that as a need because they may not even be expressing it as a need that we would recognize it in job's language, but you have to translate that into the jobs language.

Is that correct? 

Tony Ulwick: That's exactly right, Jim. What we do is we'll sit in the room with the five or six customers with a screen behind us, and we're typing into a Google doc what the needs statements are. So we're training them to give us inputs in the format that we're looking for. So they may tell us the story.

Most say, Oh, you're trying to minimize the likelihood of overcooking or under cooking the meal. Right. Great. Okay. And then after they see three or four of those, they start saying, Oh, you know what? I also want to minimize the likelihood of that [00:57:00] happening.

Jim Kalbach: They start talking and they start saying that themselves then. 

Tony Ulwick: That's right. Because think about what happens in a typical interview. If people don't agree on what a need is, and that means the interviewer and the interview week. I don't know what inputs that try to end up with, right? 

Jim Kalbach: Interesting. 

Tony Ulwick: What we're trying to do is to make it so that the interviewer knows exactly what they're trying to get, outcome statement and we're going to train the interviewer or the interviewee, uh, to give us outcome statements.

So now we've done this with surgeons and others. You know, surgeons are great because they're very process oriented. After 10 minutes they're in, they're in outcome space, they're talking outcome language. Can we keep them in that space? We never talk about products because as soon as we do, they're back in product space.

Right? So that's great. Getting them in that mindset and keeping them there is really...  

Jim Kalbach: Okay. That's great. Do you talk about that in the book? I've never heard that. That particular technique to get the interviewee to speak in outcome statements. You talk about that anywhere. 

Tony Ulwick: I know we have it in our online courses, but I [00:58:00] can't recall if we have in the book or not.

Jim Kalbach: I don't think I've ever come across that. 

Tony Ulwick: Now we have it right here. 

Jim Kalbach: There you go. It's recorded. And I would say, Tony, you should try MURAL for recording that instead of a Google sheet next time. Did you get you get this? You know, this where we're going here.

Tony Ulwick: Yes, I've been impressed. It's, it's something we're gonna look at.

Jim Kalbach:  Mark's an absolute master at this too, and maybe you could even hire him to do this for your session. 

Mark Tippin: I'd be glad to learn. It'd be a, it'd be a win win. 

Jim Kalbach: There you go. There you go. No, only joking around. Hey, I see we're at the end of time, so I'll have to leave that little MURAL reference there as the way that we, that we sign off here.

Um, Hey, Tony, you're doing a webinar tonight, I think with, uh, with Dan Olson. Is that right? 

Tony Ulwick: That is right. Um, so, um, that will be, I think at six o'clock this evening it begins, or 6:15. 

Jim Kalbach: Yeah, Dan on a webinar, I think. Yeah, we, we've, we've talked to Dan as well too. It's a good guy. I talk about him a little bit in my, in my book, [00:59:00] and of course he talks about your framework as well too, in his book as well too.

So there's kind of an interesting connection there. 

Tony Ulwick: Yeah. 

Um, 

Jim, let's stay in touch. Yeah, it's a busy over at MURAL. Um, we are here writing. Keep interviewing, great to chat with you. Thanks for the invite. 

Jim Kalbach: Yeah, no, absolutely. A pleasure to have you on here. And I think, I think the folks that joined, uh, hopefully they got something out of this session.

I know I did. Uh, I always learn, every time I talked to you, I always learned something new, so I re I really appreciate that and I appreciate it. Uh, your contribution to the book as well too. You, you pushed me in a few directions. I think that was good. And you also contributed, uh, you know, to the back cover a little blurb.

So I just appreciate your support in general, Tony. 

Tony Ulwick: My pleasure, Jim. 

I wish you great success. 

Jim Kalbach: Yeah. Okay, great. So thanks everyone for joining. Um, we will be in touch with, uh, we're recording this and there'll be a wrap up for the imagine series. Again, the imagine series is a, is a six week long program. We have about 40 speakers, so go to.

A MURAL, that [01:00:00] CEO slash imagine. And you can sign up for some of our other events that we have going on there too. So, again, thanks everyone for attending. Thank you, Mark, for joining and for Tony, for, for being our special guest today. And with that, we'll end the session today. So, uh, thanks everyone again, and we're gonna sign off here.

Mark Tippin: Sounds good. Take care everybody. Bye bye. Take care. 

Jim Kalbach: Bye. Bye.