Product Agility

Beyond User Stories: How Jobs to Be Done Unlocks Real Customer Value (with Jim Kalbach)

• Ben Maynard & Jim Kalbach • Season 3 • Episode 1

Share episode

Send us a text

In this week’s episode of the Product Agility Podcast, Ben is joined by Jim Kalbach, an expert in design, innovation, and the Jobs to Be Done (JTBD) framework. Together, they tackle one of the biggest blind spots in product development—our over-reliance on user stories and how shifting our focus to customer jobs can unlock real value.

This episode also marks the start of Season 3, and we’re excited to continue bringing you insightful conversations that bridge the gap between agility and product! 

Are We Asking the Wrong Questions?

For years, product teams have structured their work around user stories, assuming that if we document needs well enough, success will follow. But what if user stories are only capturing symptoms, not the root of what customers truly need? In this episode, Ben and Jim explore:

  • Why the traditional user story approach often fails to predict what customers really want.
  • How Jobs to Be Done flips the script—shifting focus from product features to customer outcomes.
  • The dangers of making product decisions based on assumptions rather than real human behavior.
  • How to integrate JTBD thinking into your product discovery process.

Practical Takeaways:

  • Start with the job, not the product. Instead of asking what customers need from your product, ask: What are they trying to get done?
  • Identify hidden competition. Your product isn’t just competing with direct alternatives—it’s competing with workarounds, habits, and even inaction.
  • Test assumptions early. Don’t assume you know what customers want—validate their unmet needs through interviews and observation.
  • Use job stories as a tool. A JTBD job story helps teams focus on the real-world progress customers seek, rather than getting lost in feature requests.

🔥 What’s your take? Are user stories holding your team back? Have you tried Jobs to Be Done in your product work? 

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility


Listen & Share On Spotify & iTunes


Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

We're, so we're so used to looking at the market through the lens of our own product. Those are consumers. They need to consume more. I need to sell more, we need better branding, right? And again, that's not bad way for a business to think. But what if we just said, hey, what are people trying to get done and understand their outcome first and then work back towards the technology, not the other way around, right? So it's a way to shift your perspective away from yourself, away from us and towards them, the people that we serve. Welcome to the Product Agility podcast, the missing link between agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello, welcome to the Product Utility podcast. My name is Ben Maynard, as you probably know, and this is my best podcast voice. For those of you that have asked me for a podcast voice to during meetings at clients, I tend not to pull out this voice for for clients. This is purely for the podcast. It's a special voice I I've designed just for these occasions. And today we are joined by Jim Karlback. And Jim is here because he's a specialist in a certain topic, a certain topic which when I found it made me realise that so much of my life had been based upon chance in product development, I think. And of course, the number of hours, weeks, years of my life I'd spent in my the agile days to what user stories and user story maps and all this great stuff and customers when we really honestly just missed the point consistently until I found the thing, which we're going to be talking about today. But I'm not going to say what that thing is, but I'm just about need to say I'm a huge fan of the thing. But before we talk about the thing, Jim. Would you mind introducing yourself to the listeners, please? Yeah, sure. Hi, Ben. Great to be here. This is my actual voice, not my podcast voice, but my name is Jim Callback. I'm the chief evangelist at Mural, one of the leading online whiteboards. I've been with the company for about 10 years and prior to that I had a career in design and innovation. So I worked for several companies in the design and innovation field. I wrote a couple books. That's kind of where I got my skills and my perspective, one on mapping experiences and the other on Can I Say the Thing? You can say the thing now. Jobs to be Done. I wrote the Jobs to Be Done playbook in 2020. Congratulations. Yeah, Jobs to be Done. Did you enjoy writing the books? No, I don't like writing books. I've actually, I've actually written other books too, so I have 5 books to my name and each time I do it, it's like pulling teeth. So there's some, I don't know, sadistic or masochistic. I forget which word that is that I process that I go through. I torture myself to write a book. I like to think and explorer and you know, have a point of view and things like that. And then at a certain point in time, it just oozes out of me. And I and like, I got to write a book. And then I, I, I'm all excited about writing the book. But the problem with writing a book is you got to write a book. Like, you got to sit down and write sentences after sentences and paragraphs. Yeah. And it's usually early in the morning or on Saturdays and Sundays. I don't know how you do it, man. I I told you, if I did write the book, they say everyone's got a book in them. I'm not so sure that's true. Well, you have a book in you. You, everybody has at least a book in them. It, it's writing. And that that's the point I just made. Writing a book is not about having enough knowledge. It's about having the wherewithal to sit down every Saturday morning for a year and ruin your weekends for a year or more. Actually writing it. I've, I've never heard anyone say everyone's got a good book in them. To be fair, I believe, I think they do. They just, they just, you just need to, you just need to know how to tease it out of you. Well, do you know what that's teasing? I'm going to wait for that day when I retire, perhaps. But there's something I was going to talk about there. But no, there's now not the time to talk about my own personal things here. This is the time to talk about jobs to be done because jobs to be done, I think is rather wonderful and, and not just for the things that maybe people are thinking it's wonderful for. And today I just want to spend some time with you, Jim, exploring it. And I mentioned about user stories and my time in early agile. I think, you know, I'm a, I'm a keen believer that Agile could have been, had much more longevity in success if it actually embraced a lot of the things which the product world have gone to really major in. I think that Agile was really, really valuable and toyed with some excellent ideas, but it just wasn't developed enough. And you know, I think maybe because there wasn't enough money to be made right from teaching people jobs to be done. But there was a shit ton of money to be made given people CSM certificates and safe certificates, right? And now that that gravy train's coming to an end, at least at this point in, you know, March 2025, thankfully that that train has been derailed somewhat. And I think now there's lots of people out there looking at their careers, looking at the past. So well, what do I do next? And I think that if this question, this conversation today is really important for those people. If you haven't heard of jobs be done, so Jim, could you give us a bit of a, let's not say a sales pitch, but could you give us an infusing articulation as to what the value and, and just what the hell jobs to be done is? Yeah, yeah, absolutely. I think there's a couple of different ways or different levels that that we can approach jobs to be done on. And you know, 1 is a little bit more theoretical because there is a, a theory behind it. And then there are jobs to be done is also a framework with methodologies. There's also community there. So there's lots of different facets or ways that we can understand jobs to be done. But let me start with the more theoretical, the high level first. And then I think Ben, we can get into some of the nuts and bolts of the methods and things like that. Great. Jobs to be done was it has its early roots back in the 60s and 70s, but really the the phrase came into being with a Clayton Christensen who kind of coined the term or popularized the term in his book The Innovator Solution, which was his follow up to the Innovator's dilemma, right? So fundamentally, it's about innovation. It's about finding new ways to create value for your customers. And what the theory holds is a fundamental perspective shift in your mindset and in how you're viewing the people that you serve can uncover opportunities that you might have otherwise overlooked. Another way to say that is we're all kind of biased by the assumptions we have around our own solution or our own brand or the offering that we bring to market. And as a business, we want people to buy more of that. So therefore we should focus more on the product and the price point and the go to market motions, which are not unimportant, right? But most organizations are really, really biased by the fact that they make an assumption that the market needs the thing that you sell. Jobs to be Done says is that's not necessarily the case. Let's take a sidestep and look at what the heck people, human beings, individuals in the world are trying to get done independent of not only our solution, but any technology. What is the fundamental goal that people have and the Jobs to be Done framework carefully expunges any reference to technology or solutions, including yours. And then you're able to assume this mindset shift, right? Sometimes I call it like an out of body experience, right? We're so we're so used to looking at the market through the lens of our own product. Those are consumers. They need to consume more. I need to sell more. We need better branding, right? And again, that's not bad way for a business to think, but what if we just said, Hey, what are people trying to get done right and understand their outcome first and then work back towards the technology, not the other way around, right? So it's a way to shift your perspective away from yourself. Away from us and towards them the the people that we serve. So from that standpoint, I think I like to characterize jobs to be done as a way for businesses to understand human behavior and to better predict adoption, right. Why will people choose your solution and pull it into their lives? I don't mean just buy it. I mean get value out of it, right,'cause it's not about the purchase decision. It's about I wanna create something that people go, wow, that's, that really helped me, right? And if you can, if you can understand why people adopt one solution over another, you can increase your product market fit. You can increase the pull that you get from the market, right? But in order to do that, you have to put yourself aside. It's only temporary in jobs to be done. We put ourselves aside and we say, let's focus on them and their goals and their behavior and see if something emerges that the bias of our own offering would have otherwise obscured. Right. So that's that's kind of the theory to summarize is people want solutions that help them get their job done better. Therefore, if as an organization we can understand that job first, we can create better offerings that provide meaningfully unique value. Yeah. And I think that's interesting, isn't it, Because it isn't. We're not talking here about how the people necessarily better use our correct, correct, which I think is a trap that maybe people fall into. If that's the trap. Yeah, yeah. If we just think about let's observe what they're doing. That's what they're doing. Let's try and make it more efficient. But then with that desire to make it more efficient, we missed the point of maybe making it more effective, which understanding why are they choosing our products correct over over a competition or why, why should they? And this is a valid statement to say, but then why? Why should, why would they continue to choose our products over the competition, Correct. And that's at the core of Clayton Christensen's disruption theory is that an incumbent in an industry so that the, you know, some of the early players, right, they focus on themselves over years as the market matures and as they're offering matures and they lose sight of what's the underlying jobs to be done. And they think about how can we make our tool more powerful? How can we charge more for our tool? And they kind of get wrapped up in themselves. It's a type of navel gazing. If you, if you say, and what jobs to be done does is it allows you to just take a sidestep and look at, well, what's the thing that we originally or that has maybe changed overtime? What's that thing that we should be paying attention to, namely an unmet need in the market. So jobs to be done helps you find unmet needs in the market, focusing on yourself and doing things like usability tests and focus groups and, you know, performance improvements and more branding and marketing. You you color your view of the market so that you miss those opportunities and jobs to be done helps us step take a sidestep and, and, and unbias our our thinking. Now, it may not lead to new conclusions, but it's not that difficult to have that viewpoint, that perspective. It's a fundamentally unique mindset and perspective that jobs to be done asks you to assume, But it's fairly easy to get there. It's not that hard to get there, considering how much money you invest in all those other things. It's like, let's just take a fraction of a percent and a month or whatever you know, the time period is. I'm just making that up and let's just look at it from a different way and see if we see ourselves different. Yeah. So what you're saying it saying is that this is an additional lens. It is another string to the bow. It is not a replacement for a thing that has to exist or it currently exists, correct. You're not pulling the tablecloth out from the China and hoping that it all stands and then put something back under it. It actually complements a lot of things like Agile. It complements design thinking, it complements a lot of UX motions. It works well with lean and lean testing. I work with marketing teams and sales teams to help them do better discovery calls or marketing campaigns as well too. So it's very, very much complementary. So you take that, you assume this new viewpoint of the people that you serve, you're looking at your market at basically you're looking at your market as human beings, not as consumers of your product, right? And then you bring that together with the fact that you're a profitable business that needs to grow and make money to survive, right? So you bring that back in. So it is a layer. It's a layer on top of all of that. And I suppose I've been using this lens that you are, it forces people to be more specific. Yeah. Because I think one of the issues is, particularly when you're doing things like strategy work, is that people feel that strategy work at whatever level you're talking about. Strategy has to be kind of really broad and not very descriptive and not very specific. And whilst it may be Australia and so then it ends up just being a bunch of wishes. We wish to increase our our revenue by this much. We wish to have this many more users. It's like, yeah, but they're just wishes. That's right. And if you're going to be really specific about it in your strategy, then it's worthwhile doing that sooner rather than later. So you can focus in and jobs to be done doesn't allow you, this is a question. Yeah, jobs to be done. It doesn't allow you to be non specific then because you have to focus on a particular type of customer or user. Yeah, no, that's absolutely correct. I think you hit the nail on the head and that's for me. You know, I mentioned that I have a design and innovation background. I know a lot of innovation frameworks. I know a lot of, you know, design frameworks, design thinking, contextual inquiry, design sprints. I've, I've done a lot of that type of work, a lot of innovation work as well. And for me jobs to be done brought that specificity that I think a lot of those other frameworks lack and the rigor behind it as well too. That's one of the big differences I think of the jobs to be done framework to other existing frameworks because we have the real problem. You know, I mentioned this complementary mode or aspect of jobs to be done, but it brings up a problem in sometimes conceptually for folks because they say, well, isn't this just human centered design warmed over? And it's like, no, it's actually more specific because you're with that specificity, Ben, you're able to better tell the business what to do and to actually break down that high level strategy. And to some degree, I think strategy does have to be high level, right? Because it needs to cover everything that a business does, right? But it's you're able to then break that down and tell a product team or a marketing team, here's the unmet need to go after, you know, let me just give you an example. You know, you might have an OK R just making this up object and key results goal, something like make it easier for customers to onboard into our product. And and then you said, well, easy is kind of a fuzzy word. You get a group of developers and PMS and designers around. They're all going to interpret the word easy in different ways, right? But with jobs to be done, we can be really granular and really specific. Right. And say it's the, it's the, it's the time or the effort that it takes to do a specific thing, right that we're going to 0 in. So it helps you get more granular. And I think, I think that's, that's the type of business thinking that a lot of organizations need these days, these days, particularly in a hyper competitive global environment right to out to out maneuver your competitors. You, you can't just be walking around saying, we want to make it easier and we want to grow. Every business wants to grow and have their product easy and and those generic things. But what is it specifically from a custom? And that's the viewpoint shift from the customer standpoint, not from my product, you know, marketing team standpoint or whatever. It's from the customer view. How do customers view the, the, the, the space that you occupy and then find that very specific thing, go after that, you'll beat the competition. Yeah, I mean, it's fascinating, isn't it? Because I think, well, I, I find it fascinating. I, I was trying to think of a way of articulating this, but imagine that I create a, a software tool which helps you track software defects. OK, right. And I know that you know, and I'm thinking, OK, well, I've worked in financial services a lot. So I'm going to like really focus on financial services like this, ignoring the fact that they're kind of the people that might be creating bugs and managing and tracking software defects. Actually that that is a job to be done across many different industries. It isn't just in financial services. And say that if I only ever focus on financial services and they wanted to grow the business and they weren't and they wanted to go then across, it wouldn't be any point in me. If the job to be done is the same across industry. There's little point in me focusing on one particular over indexing on a particular industry because I'm missing opportunities of the same similar job or same job which has been done in others. Yeah. So it helps create that other does. It can help create that extra length, which is saying we'd rather have your industry vertical, which you're able to say. And then what cuts across? That's right. But what jobs do we do? Yeah, what jobs cuts across the different industries? That's right. And this mindset shift helps you see see things in a different light, including your competitors, right? Because when we describe the objective that people are trying to accomplish independent of technology or solutions, suddenly you realize that the your defined industry field as defined by analysts or you know your, your, your, your company category or your product or your product suite. As you know, defined by the, the, the name or the type of service. When you assume that lens, you assume you compete with other software products in the case that you mentioned that do exactly that same thing. But if you look at the fundamental job to be done, it opens, it opens things up, right? For instance, there was a there was a book in Jobs to Be Done field called When Coffee and Kale Compete. You know, coffee and kale, how do they compete? Because if you if you're a cafe or a coffee bean roaster, let's say you're a coffee bean roaster, Ben, Right. You think you compete with other coffee bean roasters, right? But why do people drink coffee in the morning, right. And if you yeah, to get energy in in the jobs to be done language, we would say get energy in the morning. How else do you get energy in the morning, Ben? I could go for a run. Run. Physical activity. That's a big answer that we hear. Yoga. Physical activity, right? Yeah. I could try illegal substances. Yes, I've had that answer as well, too. When I do this, little thought exercises. Often people say something like a cold shower before they get illegal. Yeah, I just. I went to illegal substances. Yeah. You went right to a cold shower or even having some. Yeah. Some tasty food. Some light, tasty food. There you go. What about a kale smoothie? Yeah, well, I'll give it a go. So if you. Right. Exactly. I've had people say Red Bull and things like that. And like, I drink Red Bull in the morning. And yeah, I drink Red Bull in the morning. People drink tea, Diet Coke, right? Whatever that is is like, oh, wait a minute, I'm a coffee bean roaster. But I compete with Red Bull and I compete with exercise and loud heavy metal music because what people want is getting energy in the morning, right? So that shifts your viewpoint of who you even compete with and what that. And and then when you bring that back into the, you know, the solution team, the product team or the marketing team or whatever it is, right? You bring that in, you go, OK, what if we didn't compete with other coffee providers? What if we compete with yoga, cold shower and loud music? OK, that's gonna change the way that I think about providing value to customers, right? Yeah, that's the mindset shift right there in a nutshell. So how can people get started with this? Yeah. Well, I think there are some, some simple steps that that you can take and that's that's kind of my approach and why I wrote the job speed on Playbook. The field has been around for three or more decades and there are practitioners in the field, mostly consultants that have a, a fairly heavy process that that they'll bring into your organization with a lot of rigor to find this very specific unmet need, right? And that's, that's great, right? I love that. And that's where I learned a lot of things. But as a designer working on innovation teams, you know, in my career, I was like, yeah, but you know what? I don't have, you know, 6 figures to spend and, you know, three months for a big study. I'm just working on this project right here. Can I use that mindset shift and some of the some of the emotions and, and approaches from jobs to be done just to solve a simple problem that I have. And the first thing that you need to do is you need to isolate and define what I call the focus job or a target job. If you want to say. So you were talking about what tracking, tracking bugs or something like that. Software defects, right? Software defects, right. So we could say that. And who would do that? By the way, what who would be what I call a job performer like a software. I'm gonna say, yeah, let's go, let's go for the customer services type. Customer. Customer. Yeah, customer services, customer service. Oh, right. Yeah, customer service manager, something like that. Yeah, we could work on the actual description of that, but we could say the job that I want to understand is they want to track software defects, right? So if I can isolate that as a core job that's both relevant to the people that I want to serve and it's relevant to me, So it needs to be relevant to you as well, right? Then we can break that down. So I isolate that that focus job, and then I can break it down and I can say, well, what are the steps of getting that job done, right? And we describe those steps without using technology solutions or methods in them at all. So it's timeless. It's timeless, right? It's not and it's not, and it's independent of any specific software solution. So one of the first things we do is we create what's called a job map. Which are the sequential list of steps to getting that job done independent of solutions. And that allows you again, to kind of rise above looking at your own interface and like, oh, the button on the third screen is in the wrong placement. Like no, no, no, no, It's what are they? What are they trying to get done? And we can also then query where do they have the biggest struggles? Where do they have the biggest pains, right? We can also look at their emotions as well too. So there are other categories of information that we would try to research. Once we have the focus job, we then go out and research it. There are other categories of information and the one that's really powerful are the success criteria is what would that customer success manager or customer service manager, I think we said what would they use as personal success criteria for getting that job done well, right? So the steps show how they do it. But what what is, what is their definition of success? And we can get very granular on that, right? They want to save time, they want to save effort. They want to minimize the chance of something happening, right? So they want to reduce the chance of missing a bug, right? I'm just making that up as something potential. We could then even explore that even further. What are the drivers of what are the drivers of over overlooking a bug, right, that are missing a bug, right? So we can get very specific and very focused on their success criteria that they bring to the table as well too. Once we do that analysis, we then have now a very clear target. We need to solve this specific problem for that, for that customer type, right. I hope that was clear. Yeah, Yeah, it was. Well, this was for me, yeah. If we wind back a little bit, you mentioned about kind of talking about the I was the job map about mentioning the solution. Yeah. How so in the example, I've got software defects practically. How is that? Yeah, done just to give you an idea of how you would articulate this step. So what would OK, so I'm a I'm a service manager and I want to track software defects. What's what's 1 of the first things that I would need to do? Determine, determine which software to monitor or something like that. Yeah. So, yeah, which particular product to look at, Right. So, so the first step might be determine, determine software to monitor. OK, right. That's one of the first things you do. The next thing might be determine how to track software defects. Another one might be define, define what a defect means, right'cause you have to when it when is a defect a defect, right or determine the scale of defects, right, Yeah, OK, so I just named 4 steps. None of them had technology or solutions in them, right. And I would carry on with that and say, you know, the next steps would be something like identify, identify defects would be another step that we have to do identify defects. And then it would have to be monitor, monitor, no, probably be something like record the record defects, share defects with, you know, engineering team or I don't know what happened after that, right? And then it might even be monitor progress towards repairing the, the defects, right? So I could describe that job, even though it's technical, right? Because I think, I think why I'm seeing your eyebrows go is like, wait, this is software. How can I talk about software without mentioning product or technology or solution? But I kind of just did, right? Yeah. And it's not, it's certainly not any brand. And it doesn't describe it. None of those steps describe exactly how you're going to do it, right? It's just saying I need to identify, I need to decide on what a defect is. Oh, yeah. How do you, how do you define a defect, Right? That's another question. But once I have that flow, I can then say, OK, what are the success criteria for how you do it? Well,'cause you'll notice a lot of those steps that I just gave, they're, they're vanilla, they don't tell you anything. It's identified defects. OK, great. What's gonna determine my success? And one of them might be eliminate the chance of overlooking a defect or missing a defect, right? And I'm going to have a long list of that success criteria. So the first thing we do in jobs to be done is we define that focus job. And then we go out and do research and able to get that chronology. But we're also looking for what are all the success measures that people bring with them to get that job done well. And what you want to find are the success measures that are important but not yet fulfilled. That is, they can't do them well. OK, OK. Important success criteria that's hard for them to get done or that they can't get done well today. That's what you want to go after. And it's tends to be very granular, Ben, to bring come back to that granularity. So that's a little bit of the nuts and bolts around how you do it. And what type of skill set have you found in your experience? Generally, yeah, it's the right skill set to apply to of going on this, doing this work. Yeah. So actually doing the analysis, I find that kind of the, the researcher mindset, either a market researcher or UX researchers often very good. And that's where that overlap happens. When I, when I work with UX researchers, they're like, yeah, that's what I do all the time. And I'm like, yeah, great. Now just, it's really just about, OK, go out and talk to people. But the way that you capture the insights is, is jobs to be done specifically. That's for a lot of UX researchers. That's the only change for them is I just want you to formulate things in a certain way and categorize the information in a certain way. So the jobs to be done framework comes with categories of insights that you're looking for, specific categories of insights. The job steps and the success criteria are two of them. So I go out and talk to people and I'm listening and I'm like, oh, that's AI, just heard a job step. I just heard a job step, right? And then you collect all of them, or I just heard a success criteria and you put them in the buckets. But then each of those buckets has rules of formulation. So the information is very regularly formatted, right? So you have this very high consistency of how you're capturing those insights, which allows you to then compare apples to apples. And it also allows you to then quantify things later on, which is a, a, a, A secondary step is I can actually run a survey with all the success criteria. Once I collect all of it, I can go out and ask a quantitative sample of people which ones of these are most important but least fulfilled for you, right? And then I can get some really clear signal on what the unmet need is in the marketplace. But it tends to be upfront. It tends to be a very researchy kind of mindset. Sometimes PMS, you know, product managers can do or want to do some of that market interaction. But you do need to go out and talk to humans and you need to be able to work with abstract concepts around human behavior. And so this is the type of work which is done pretty. That's his pre product backlog. Pre pre team is actually working on it. This is the upfront kind of discovery, understanding empty building work. Does it have you seen it happen? Since its relationship is strategy, do you find that often it creates a strategy or drives it or you find that it's often invented after someone has decided what the strategy will be? I think it might even be an input into strategy. So from that sense it, it can inform strategy. So it's not only ahead of product and product development, it's potentially ahead of strategy. Yeah, no going after the next quarter or the next year even. Yeah, No, I mean, I've absolutely found that because I think the, I mean as as an alternative to maybe more, yeah, to other types of user research, right. You need to know if you're gonna be choosing to focus on a on a particular target. Yeah. And you're gonna add some value to that particular, that's right, subsection then. Yeah, actually having some data which says, yeah, it's gonna, this is what they want means that your strategy becomes infinitely more feasible than if you didn't have that. I, I think so. But you I, you know, I would argue too, I kind of just mentioned this that, you know, my approach is, you know, you're, you're you're a mere mortal working on some agile Sprint and you just want, you just want to be more informed about how to do that local thing that you're trying to do. I believe jobs to be done can help at that level as well too, that you can bring jobs to be done at that level. Does that help you sort of the software development teams then have conversations with the users, customers? Well, yeah, it's a way, it's a way of bringing that outside in perspective in, right. Yeah. I was just giving a workshop yesterday and I asked the team, it was a product team. I said, how many people go out and talk to customers regularly? There's 30 people in the room. I think only four or five people raise their hand. Guess what? They were UX researchers and UX type of people. I think the PM raised his hand too. He was, he was turned on to that as well too. And I said you're in a privileged position. You get to go out and talk to customers and a lot of people in the organization don't get a chance to do that. It's up to you to bring that insight back into the organization and tell stories and narratives around what you saw, right? And I believe the Jobs to be Done framework at a very local level can also be part of that storytelling mechanism. To go back in because I, I mean, I don't know about you, but product teams that I've worked with, they're hungry, they're like, what does the user need? Please tell me in clear terms, right. And I think jobs to be done is a mechanism to do that, again, with more granularity and specificity than other types of, of that, of that nature of research, that more generative type of research, right? And it's, and, and then you as the, you know, maybe you're, you're doing the analysis, but then jobs to be done can also be the storytelling mechanism that you bring back into your teams. And in fact, one of the easiest targets in the Jobs to be done framework, we're getting a little more granular here now, Ben, is what's called a job story, which is like a user story if you know what a user story is. User stories describe software functionality, right? As an admin of the system, when I change permissions of user settings, the the permissions are changed or whatever the user story is, right? And then an engineer can go off and develop that and test it. They press the button, yes. OK, the settings were changed, right? Yeah. A job story describes the problem that you're trying to solve independent of technology, right? But it's a story. So after you do, after you do this research that I was talking about and this analysis is, you know, here are the job steps, here are the success criteria. Oh, there's some emotions over there. You can actually bring that back together in a single artifact called a job story and walk into a Sprint or a planning session. Go here's the customer problem we're trying to solve, right? And it's a compressed way to tell that story back to your team. Yeah. But that's why I think it's the missing link. I mean, these stories are great, but I think it's really. And I think people have approached these stories in in loads of different ways. And I think a lot of the times maybe they really hit an end of the head and they've really tuned into that. But it was the one thing that I was always coaching teams to do is to tune into like, like, what are they actually trying to do? That's right. That's right. What what problem are they trying to overcome? Why are they going to bother using this new thing? That's right. Because when these stories are just like create the thing so that they can do the thing, that's a whole part of that really important narrative. I agree. So from that sense, I don't believe job stories replace user stories at all. If you Google job stories replace user stories, you'll find people talking about job stories replacing user stories. I don't think that happens at all. You still need the user story because somebody got a program. You still need to describe the thing you're building, right? But what job stories? So in that sense, job stories are a little bit more upfront than the type of thing you would bring into a Sprint, for instance, or even a planning session, right? What do we do in this next quarter? Let's let's look at the and you might have multiple job stories. By the way, you don't usually don't end up with just one.

You end up with about 3:00 to 6:

00. You say, here are the things that we need to and it's it's, it's a customer problem described in terms that aren't self-centered, right? Here's what they're trying to do, right? And you would bring that insight in before you then start writing user stories, for instance. Yeah. So to keep an eye on the time. And it's quickly disappearing. Oh, man, I know it's terrible. I get. Yeah, the more you enjoy yourself. I got a lot to say too. So I'm not helping you here, Ben. No, it's good. I mean, I'm just wondering, I mean, because we are, we are getting towards the end and maybe this point in the podcast episode where people are near the end of a dog walk or maybe not paying attention too much. So I'm wondering, have you had any successful traction in kind of using this or introducing this at Mural? In in Mural, yeah, I've used it in several ways, typically more lightweight ways. I have done a couple of of these, more full analysis where I define a a focus job, I write and create the job map, collect all the success criteria and prioritize that. I've done that both internally and externally here at Mural in the past. And that gives you some really interesting insight into what you should focus on because here's, here's what I found. Ben, I'll get back to your question in a little more detail, but here's one thing that I found is that I have never worked with or for an organization that lacks ideas on what they should do. Yeah. And I, I, I test this all the time. I say is the, is the problem your organization has You just don't have any ideas. You're sitting there going, oh, we don't know what to do. We don't know where to improve, right? And it's usually like, no, usually it's the opposite problem. There's a backlog of of things to fix. There's a backlog of potential innovation topics. There's a backlog of ideas on how to improve everything. The question you have, but that's what is the definition of a backlog, right? The question is what should we focus on 1st, right. And if you want to be a customer centered organization, you would bring some of the rationale that jobs to be done provides you to the table, right,'cause very often think about how do you prioritize things in an organization. It's very often by feasibility, by money, by resources, what the CEO wants, things like that. It's like, don't you want the customer at the table for prioritizing your backlog? And just holding up a simple job story might help you think about how you're prioritizing your backlog differently. So and that's, and that's how jobs to be done compliments things that are already in motion. It doesn't replace them. It brings in a new logic of rationale. It brings it gives your customer a seat at the table inside of your organization That I mean, that that's how I see it. Yeah. And that's, that's a fantastic thing to do. And I think it's incredibly worthwhile. Yeah, has a whole realm, of course, systematic coaching. That's right. Yeah. There's lots of things where you, you imagine the person that your customer or your future self or your grandchild in the room and how would you explain your decision to them? I just wanted to get back. Sorry. I just wanted to get back to here and Mural because I didn't really answer your question. That was all a precursor to say, one of the efforts that I did here in Mural. We had all these, We had a bunch of issues. It was around developer velocity. We wanted, you know, to developer velocity. And I did this prioritization and I even quantified it. And I'm reading off all these, you know, success criteria statements. And the head of engineering said, Jim, we've known about all of those things for a very long time. What's amazing is to hear the priority that you're giving them. Right? So the thing I brought in was I was able to bring in a logic and a rationale that suddenly made a long mess of potential ways to to address the problems. And I was able to bring a lot of Christmas sharpness and focus to that long list of things. Yeah. And I think that's so important, isn't it? I think it's that I think it ties into what I was going to say is that there's an element here of jobs to be done is creating that an accuracy of role based empathetic understanding and actually tuning into within that person's role. Like what are they trying to achieve? How are they feeling? Where are the pain points and where is the current solution leaving their needs unmet. And if we can focus on their specific unmet needs, then we are in a great position to find ways to fulfil them. But the question is, yeah, and and the art of this and it's really understanding, how do we get to really knowing that what those specific unmet needs are holistically. And we're not talking about just having a person understanding, right, chucking over a document, Yes, what we don't know is that holistic understanding. So, but the developers are saying, well, that's right. I now understand why this is a priority. Now understand what they're trying to achieve. That's right. Brilliant. Yeah. Let me loose. And and, you know, I think a lot of people look at jobs to be done and they hope the clouds are going to part. An array of theme is going to come down and hand them this thing and they're going to have some great revelation. But that moment that you just described, sometimes that can feel underwhelming because you're like, yeah, we knew that thing. We knew that thing was an issue. Thanks for prioritizing it to me for me. Now I'm going to get back to work. And you know what, that's OK. Because if you do that over and over again and you're bringing, you're giving your customer a seat at the table and you're using that as a rationale to prioritize your backlog. You're, you're, you're going to excel in the marketplace, you're going to outpace your competition and you're going to, you're going to have natural growth, this organic adoption that I was talking about, right? But it could feel fairly underwhelming. Yeah, but I said it's interesting and we need to wrap this up in a second. But I think about the idea of. I mean, pushing aside the underwhelming piece because that just makes me feel sad, but the the this idea of customer centricity and I think of everyone says we want to be customer centric and then like we use a centric or whatever it might be. Yeah, this the idea of that focus, you know, it has to start at the beginning. So whilst you may have someone saying that we want to like we need a successful product, that's great. Are we going to get a successful product, somebody at some point that has to say, OK, well we need to focus on this particular section, whichever kind of section, how are we going to invent that trickle down through a whole so that customer centricity is a thread that should run through from the very top. If you're going to be, if you're going to increase your chances of success, because if it is just introduced at some point, like someone says, going back to early one, we need to increase subscribers and you haven't got any research and you are just kind of picking ideas out and you do focus in the wrong area and you don't do that that research as needed, then your chances of success will be limited. And you used that term in your introduction. You said you real you've realized a lot of your career you were leaving things to chance, right? And in fact, Clayton Christensen, who I mentioned his before he passed away, he wrote a book called Competing with Luck, because a lot of organizations are competing with luck. They're, you know, they might have data and things like that, but the actual decisions, particularly when it comes to customers, they're not specific enough. And they, they end up with these broad stroke strategies that are really based on, you know, luck, crazy crossing your fingers and hoping you got the right thing. And there are, you know, lean technology, lean methods, you know, build, measure, learn. There are ways to go out there and reduce the amount of of chance that is in your typical business motions. But if you add jobs to be done to that, you're going to reduce the the, the likelihood of failing lower. So no guarantees. It's just really about reducing the likelihood of failure. Yes, No, that's it, right. It's no guarantee, but it is about reducing the likelihood of failure. And I think what I do with lean product discovery course, so Jeff and Josh's course here just again is a big part of that. And it's the one thing that really invigorates people. And really it's amazing to see how much people and say, well, no, let's go and talk to these people and let's really understand it. Yeah. What obstacle are we looking to overcome? Yeah, we had absolutely situations where the the obstacle which was assumed existed the moment they wrote it down and thought about it. And then when I spoke to the person, they realise that that person does not see that as an obstacle at all. It's not, it's not the five hours a week, 10 hours a week they thought it was. It's, you know, it's like an hour, an hour a week at best. And there's no point in trying to improve their life in that respect because it they've just, it does, it's not a big deal. The element that was missing in your scenario right there is that's great for the person that went out there. How do you bring that insight back into the team and have that team empathise with it and internalise it? That's the difference because we got the team doing it. Oh, you got the team doing that's, that's, that's one of the best ways, right? And jobs to be done can help you do that in a systematic way as well too. But there's this notion that we talk about here at Mural, we're calling a customer centered collaboration. And that's you use that customer insight as the centre point of your, of your team meetings and your collaboration, right. So you for me and for me, that's the biggest sign of a, of an organization becoming customer centric, right,'cause every organization out there has some kind of customer centric imperative. And they say, well, how do you actually do that? Great, you're waving your hand and you're saying it. What does that actually mean? And if you, if you say, I see my team using customer insight as the starting point for their debates and conversations and planning sessions and I hear people asking what's the customer benefit, right? Those are two biggest signs for me that you have a mature customer centric organization. Beautiful. And then John that Tim would leave it. Thank you very, very much for coming along. There's so much what we could talk about and maybe and maybe we can get you back on at some point. Absolutely. Part 2 coming up. Yeah, we can go. We can go a lot deeper, but yeah, we're we're at time. If people want to find out more information about you, I assume they can go to LinkedIn. Yeah, I spend anywhere else they could go. I spend a lot of time on LinkedIn. I like to connect with folks if they want to, if they want to reach out and connect with me. Otherwise, I have a resource called the Jobs to Be Done Toolkit. It's JTBD, toolkit.com, and we have some free downloads there, as well as some public courses and an online video course and things like that. This was a very, very brief overview of all of the richness of the Jobs to Be Done framework that you can learn about there. Yeah, awesome. Well, I will be checking that out because I'm keen to kind of learn more. I've, I've, I would say I've dabbled, but I'm yet to go deep. So I can't wait to learn even more and then get you back home. And I've probably got some better questions to ask. So thank you very much for coming on, Jim and everyone, thank you very much for listening. I know we missed an episode last week. It's because I've got really popular and everyone seems to want my time. But we will be picking up the weekly episodes again. And my intention is to record 1 without video, but from a hotel room next week whilst I'm off of a client. So any ideas or suggestions you have, what you want for next episode to be about, feel free to contact me on LinkedIn, Let me know. It's been lovely. I've actually quite a few people the last few weeks reach out and say thank you or ask me a question or engage me one-on-one. I love it. So if you listen to this and you want to ask me a question or you've got an idea for a future episode, by all means connect with me on LinkedIn and just ask, right? Don't ask you don't get. So Jim, thank you again for coming on. Thank you very much for listening. This has been the Product Utility Podcast.

People on this episode

Head Shot

Ben Maynard

Host