Harry: 0:00

The fundamental is the need, it's not the job. The job is a response to the need. And so, getting incredibly clear about what the need is, is the task.

Narrator: 0:19

You're listening to Traction Heroes. Digging In to Get Results with Harry Max and Jorge Arango.

Jorge: 0:29

Harry, it's good to see you, sir.

Harry: 0:31

Hey. Good to see you too, Jorge. thanks for making time today for this.

Jorge: 0:37

I always make time for these conversations. I always get a lot out of them and I'm hoping to get a lot extra out of today's conversation. 'Cause I was gonna propose that we do something a little different.

Harry: 0:51

Hmm.

Jorge: 0:52

I mean, I'm sticking to our format where there's a reading involved, and I do have a reading that I'm bringing to the table, but I was hoping to use our time together today to think out loud about an issue I'm having that is keeping me from getting traction.

Harry: 1:09

Oh, I love this. This is great. Let me grab my coffee and we can get the show on the road.

Jorge: 1:15

I'll say right off the bat, this is a longer reading than I usually bring. And I have clipped out a lot of stuff here and I'll make sure to make clear when that is happening. Alright, here we go. "Is innovation truly a crapshoot or is innovation difficult because we don't know what causes it to succeed? I've watched so many smart, capable managers wrestle with all kinds of innovation challenges and nagging questions, but seldom the most fundamental one: what causes a customer to purchase and use a particular product or service?" And here I'm gonna skip a little bit. "Customers don't buy products or services. They pull them into their lives to make progress. We call this progress the 'job' they are trying to get done. And in our metaphor, we say that customers 'hire' products or services to solve these jobs. When you understand that concept, the idea of uncovering consumer jobs makes intuitive sense." I'll skip a bit more. "We define a 'job' as the progress that a person is trying to make in a particular circumstance. This definition of a job is not simply a new way of categorizing customers or their problems. It's key to understanding why they make the choices they make. The choice of the word 'progress' is deliberate. It represents movement toward a goal or aspiration. A job is always a process to make progress, it's rarely a discreet event. A job is not necessarily just a 'problem' that arises. The one form the progress can take is the resolution of a specific problem and the struggle it entails." I'll skip a bit. "Second, the idea of a 'circumstance' is intrinsic to the definition of a job. A job can only be defined, and a successful solution created, relative to the specific context in which it arises." I'll skip a bit. "The circumstance is fundamental to defining the job and finding a solution for it, because the nature of the progress desired will always be strongly influenced by the circumstance." I'll skip a bit. "Finally, a job has an inherent complexity to it. It not only has functional dimensions, but it has social and emotional dimensions too. In many innovations, the focus is often entirely on the functional or practical need, but in reality, consumers' social and emotional needs can far outweigh any functional desires. To summarize, the key features of our definition are: a job is the progress that an individual seeks in a given circumstance. Successful innovations enable a customer's desired progress, resolve struggles, and fulfill unmet aspirations. They perform jobs that formerly had only inadequate or non-existent solutions. Jobs are never simply about the functional, they have important social and emotional dimensions, which can be even more powerful than functional ones. Because jobs occur in the flow of daily life, the circumstance is central to their definition and becomes the essential unit of innovation work, not customer characteristics, product attributes, new technology or trends. Jobs to be done are ongoing and recurring. They're seldom discreet events."

Harry: 5:15

Wow. That is so awesome, man. And I have so much to say about this. I can't wait to dig into the conversation with you.

Jorge: 5:25

I'm sure you already know who wrote this. This is from a very famous book. I'll call it out anyway, it's called Competing Against Luck. And it has four authors, but the most famous of the four and the person with whom this idea is most closely associated is Clay Christensen.

Harry: 5:46

Yes.

Jorge: 5:47

And I'll just mention the other co-authors, Karen Dillon, Taddy Hall, and David S. Duncan. And this is, as far as I know, the book that articulates this concept, this theory of Jobs To Be Done that Christensen is so famous for. And I think that the passages I read are like the money shots, right? Like it's the part of the book where they actually like tell you what they mean by jobs.

Harry: 6:13

Let me back up just a second and tell you that I think where my book Managing Priorities: How to Create Better Plans and Make Smarter Decisions fails is gonna be answered in this dialogue. Because the way that you've presented the crux of the issue here, I have a very coherent well, I'd like to claim I have a very coherent way of thinking about this, but I did not address this on the nose in my book. But I did attempt to address it in my book. I was taking furious notes as you were reading, because I'm a big fan of Jobs to Be Done Theory and the work that I did over the last twenty plus years, it really started at Virtual Vineyards, which became wine.com, was a lot of deep thinking about innovation and innovating. And the first thing I'll say is, my time at Dreamworks, where I worked, I had my office right across from Richard Chuang's office. And he was one of the kind of silent co-founders I think, of PDI, Pacific Data Images, which was acquired by Dreamworks. That's where we made Shrek and Shrek 2 and all that good stuff. And I had many conversations with Richard. He's just a brilliant, brilliant very humble man, but has a lot of deep philosophical perspectives on things like innovation. And one of the things he says is, there's no such thing as innovation. There's innovating. It is a gerund. It's an active process of problem solving to address a valuable need. And so, the first thing I wanted to say, just to put it out there, was this notion of innovation, the word itself is a nominalization. That is to say, it's taking a process and freezing it into a noun, which makes it impossible to see. You can't put it in a basket, as they say, and you can't see the activity behind it. So the first thing that I would say is, from the point of view of getting our definition straight, let's say there's no such thing as innovation. There are innovations, right? There are nouns, which are the result of the process of innovating. But innovation as a process is a misleading term because it's a frozen noun. So let's just park that and move it aside. Then, where I would adjust the conversation is to say that the focus is not in my mind on "a job to be done," as much as I love that theory, and I think it is absolutely brilliant because the Jobs To Be Done theory gets underneath the underserved or unmet need and looks at what somebody would "hire" a product or a service or an experience to do to address that need. But the fundamental is the need, it's not the job. The job is a response to the need. And so, getting incredibly clear about what the need is, is the task. And where this gets really interesting to me and where it does touch directly on the book and into this conversation and right back to your reading about circumstance in that particular topic is that I address in the book a a concept called a context of purpose. And you and I are probably very philosophically aligned about what a context of purpose is. And I often use the idea of a shoe store as an example. Because going into a shoe store, you're crossing a boundary of a context of purpose. And it's not just necessarily one context of purpose, but let's for the moment limit it to the context of purpose of commerce, Where you pass through the threshold, this invisible boundary where you step into the shoe store, and there is a place you can shop and learn and buy and experience things for your feet that are gonna help you move in a comfortable way. And the closer you can get to finding something that addresses the needs that you have, and those needs may be practical, functional, they may be aesthetic, they may be status related. There are all sorts of dynamics going on inside the context of purpose and how it addresses the needs that you have, and then how those needs are expressed in a job or jobs to be done. And so the first thing I think it's crucial to understand as you, as you step into this world of Jobs To Be Done and thinking about addressing underserved or unmet needs, is to recognize that there are five fundamental different types of context. There's commerce, as we mentioned, there's entertainment, which I touched on, there's civic, there's educational, and there's art. These are the five that I've defined. I believe it's possible to define more, but when you boil 'em down to the simplest concept, my sense is that these are the foundational contexts. And underneath them, you will find more refined sets of context. So for example, civic, you can get into law enforcement, you can get into government. In commerce, you can get into products or services or experience sales, right? There's all sorts of stuff underneath each of them. And then of course, they're not necessarily completely mutually exclusive, right? They can overlap, right? You can have an educational context and a commerce context meet. And the center of that would be educational commerce, right? We see all sorts of products and services related to that. So, I do want to call attention to the fact that these are not as, as McKinsey would say, MECE, right? Mutually exclusive and collectively exhaustive. They're highly overlapping concepts and they can be nested in ways that I don't know that I could do justice to. Now, where this gets practical and where it might start to address the conversation as we're moving forward is that a context of purpose implies a set of real human beings that have a set of needs and desires or needs and wants. They have a set of expectations, which are, an expectation, being the sum of a set of demands and desires or needs and needs and wants. But that's very fuzzy. So how do you define what those unmet or underserved needs are? And, this is a place that I do touch on it in the book, and that is through the definition of what I call outcome drivers. And you could think of an outcome driver as the simplest possible expression of a problem. And I think we've talked about this on the show before, right? It addresses what is a current state in the most basic, succinct terms. And then, how is that a problem for somebody or some persona? And then, how is that problem or opportunity good or bad across some spectrum of, "Well, it's not terrible" to, "It's absolutely horrific," right? And in any context of purpose, a person or or a persona will have one or more outcome drivers. And that outcome driver expresses a compelling reason to make a change to get from whatever the status quo is or the current situation to a desired situation. And once you've defined that, the compelling reason for change, then what you can do is start to spell out, well, what would success look like? And who is that success for? What is it that they would say they want? What does that get them that's even more important from a psychological or "spiritual" point of view, right? And money question is, how would they know when they have it, right? What would the sensory evidence be? What would they see? What would they hear? What would they be able to touch? And that itself exists on a spectrum of barely sufficient to hopelessly idealistic. And hopelessly idealistic may be technologically impossible and barely sufficient. May be barely sufficient today, but it may be insufficient tomorrow because time evolves our sense of needs. And then, this is the notion of a desired outcome. So you have a context of purpose, one or more, that imply a set of personas that have a set of outcome drivers, which are compelling reasons for change, which are spelled out through a desired outcome, which answers seven questions that we've talked about before. Basically, who wants it? What's wanted? What does it get them that's more important? How will they know when they have it? What stops them from having it today? What unintended negative consequences could come from them achieving it? How will they know I'm gonna have it? And then finally, what steps would they need to pursue in order to achieve reaching their desired outcome? And that sets up a path for creating some kind of agreement where a promise is gonna be made to address those outcome drivers. Because if you can say, "Hey, look, in this situation, I realize you have this need, it solves this problem, here's how we're gonna address that problem, and we can spell that out, not in fuzzy abstract terms, but in concrete sensory evidence." Then what you have is the beginning of what you and I might call a specification or an experience specification or a technical specification or a marketing requirements doc.

Jorge: 17:16

I'm glad that's where you landed because that's the challenge that I was hoping to bring to the table. Let me tell you a story. I worked on a project several years ago through one of my agency design partners. We were working with a company that had grown and they had acquired one of their competitors. And in the process of doing that, they decided that they were going to unify their product and the competitor's product., And I was brought on board to help with the very tricky kind of semantic structures around such a thing. When you bring two different systems together, there's going to be overlap between functionalities and there's going to be gaps of functionality, and you have to be very mindful of what you call things, what labels you use, how things are structured so that the resulting product can be cohesive and coherent to end users. And the artifact that we work towards to express that structure is a conceptual model, diagram that represents the parts of the system, what they're going to be called, so how do we label these both for external consumption and for our own internal use, and then the relationships between those parts, whether they're hierarchical or chronological or there's some kind of choreography as information moves through the system. I realized that this is something very abstract, but the end result is a diagram. Okay? And for a complex system, that diagram comes in advance of doing things like drawing user interfaces. Because that diagram is going to inform things like, what do the navigation bars look like? So we did this project and, we worked on creating conceptual model, and for complex systems, it's a tricky challenge and one that involves a lot of conversations with stakeholders, understanding user mental models, that kind of thing. And the process of doing that is often as valuable as the final diagram, because it's the sort of thing that sparks conversations that people often don't have, but that are important in achieving alignment between the people in the organization who are working on this thing. The diagram itself also has value, and oftentimes the value comes in the fact that it informs user interfaces. This project in particular had a very gratifying final act in that after my involvement was done and the conceptual model was finished and the team had gone on to design the user interfaces, then we wrapped up the project and we had a kind of postmortem meeting with the client. And the client was happy with where things had landed and one of the things they said as part of that the diagram that we had made to define the conceptual relationships between the parts of the system, they'd started using that diagram to onboard new people into the company.

Harry: 20:49

Yeah.

Jorge: 20:51

And I might have told you this before, and I don't know if I've shared it in the show, but to me it was a very gratifying experience, because it was validation of the work. And I think it was very valuable to have that diagram so that designers could go off and create the user interfaces, but I think that the value that came from aligning everyone internally on how the system works and what we call the parts that go into making the system work so that we can develop the shared language that allows us to work together and having that be validated through the fact that it was now being used to induct new people into the organization, to me that has even more value than just this thing that informs the UI.

Harry: 21:42

That's right.

Jorge: 21:43

And where I'm going with this story is, when I sell my wares, when I tell people about what I do, I'm talking about the fact that I'm helping design software. But in a case like this one, the Job To Be Done, in my mind, was not necessarily helping inform the design of the software. It was the value that came from giving people in the organization a shared understanding of the thing they're working on at a level that facilitates conversations that they would not be able to have otherwise. It's a much, much more valuable exercise than the mere design of a user interface. And now I'm going to leverage Christensen's famous example of the drill, he talks about people not wanting a drill, but wanting a hole in the wall, right? It's like in this case, the internal alignment is the hole in the wall, but the "UX consulting" is the drill. And I feel like I'm leaving a lot of value on the table by selling my wares as UX consulting. And the question is, what do you do about this? Because you were talking about outcome drivers and context of purpose. I think that your... and like your, the person for who I'm creating value, their context of purpose is different if they think, "I'm hiring someone to help me design software," than "I'm hiring someone who's going to help bring alignment internally to the organization." I think that's a completely different modality. It might even be different buyers. The question, is how do you talk about that?

Harry: 23:34

Yes. So you might hate the answer, you might love the answer, But what you're describing is the process that forced me from being a technical writer to being a UX designer and from a UX designer to being a systems designer and from being a systems designer to being a product leader. And I started off in technical documentation, and at some point when I was at Silicon Graphics, I said, "You know, everything we're documenting is a defect in the product, because it should be self-evident how this stuff should be used." And they were like, "Well, what would you do?" And I said, "Well, I would start by taking this 140 page installation process and turning it into about 12 pages of documentation that people only reference if they get stuck." And then spelling out what that installation process should be, and then having them redesign the installation process to match that documentation. That was the day I left technical documentation. And then, my boss' boss from Silicon Graphics reached out to me years later and said, "Hey, I wanna start a company." And this was in 1993, late 93. And he's like, "Yeah, the Internet's booming. And you know, I'm thinking about creating a way for people to buy stuff online, but I'm not sure how to go about creating the user experience for that. Would you consider being a co-founder with me and working on this company? I'm gonna call the company, Virtual Vineyards, but actually it's gonna be a wholly owned subsidiary of a company that is gonna do commerce on the internet." That story's in my book, by the way. So I designed what turned out to be, in retrospect, the first usable online shopping cart. Who would've thunk it? And that process of, of, of coming up with that design was merely the process of knowing that if I had to explain it, it was a defect. And then, of course, you know, Virtual Vineyards became wine.com, that sort of went its own way. I got started getting hired as a consultant and eventually, you know, people wanted me to do product design and so on and so forth. And my trajectory turned into like, there was no way to explain what I did without saying, "I'm a product leader." Because it has nothing to do with UX and yet it has everything to do with UX. It has nothing to do with documentation, but it has everything to do with documentation. And the punchline here is that now when people call me, they're like, "Yeah, we've got this problem. Can you help us?" And I look at the problem and I'm like, that's not a product problem, that's a methodology problem. And when people say, "Well, what are you?" I'm like, "Well, yes, I'm a player coach. Okay. I'm a fractional executive in product design and development space, but I only work in situations where I can coach and work with the executive team and work with the folks below there." Because I don't see myself as a product leader anymore, I see myself as a methodologist. And my job is to bring clarity to the organization, and that's what I do now. And of course, I can't explain it to my mother. I'm a methodologist. Well, what's that? I come up with methodologies. But what is the Job To Be Done? It's about bringing clarity to the organization and bringing a level of focus and understanding to every level in the organization, whether it's facilitating the conversation around the founder or executive vision or helping to translate that into a cogent strategy or taking that strategy and painting a picture of the goals and deconstructing those into OKRs. And then, ultimately, helping people shape the work that needs to be done through prioritization. But in this very long-winded way, I have found it nearly impossible to explain the value that I create and what I do by talking about it in terms of roles or functions. And what I have to do is I pulled a page out of Trout and Ries, the book Positioning, and I purely talk about the benefits of what I do and the impact it's gonna have to the org. And that's the thing that seems to lead to referrals and recommendations into situations that people cannot describe what the problem is, but they want the benefit of that. Sometimes it's UX, sometimes it's a product turnaround, sometimes it's succession planning. Sometimes it... I never know what the job is gonna be, but in the end, it's all about bringing clarity to a murky situation and allowing folks to see a clear path to get where they want to go.

Jorge: 28:48

What I'm hearing there is be aware of what it is that is the ultimate value that you are bringing to the table. But I'm also hearing be aware of the circumstance in which they are approaching you so that you can reframe that job that you can do for them, how you can add value, in ways that they find relevant enough to engage with you.

Harry: 29:18

Yeah. And just to maybe put a finer point on it, I do try to steer away from the identity level descriptor. I do not talk about myself as a methodologist. Get away from the identification of the role and talk about it in terms of the benefit. So not what you do, but what they get.

Jorge: 29:43

That's great advice. And I expect that perhaps this conversation was a bit more self-serving than our normal ones. I don't know how much that advice is going to help other people, but it certainly helps me, so thank you for that.

Harry: 29:57

Fabulous. I loved the reading. Thank you so much.

Narrator: 30:02

Thank you for listening to Traction Heroes with Harry Max and Jorge Arango. Check out the show notes at tractionheroes.com and if you enjoyed the show, please leave us a rating in Apple's Podcasts app. Thanks.