"Is Jobs-to-Be-Done Just Watered-Down UX?" with Jared Spool!

Part 3

Jared Spool is the founding principal of User Interface Engineering and co-founder of the Center Centre, both of which have provided invaluable UX education for the software industry.

He and I were recently engaged in a Twitter conversation about Jobs-to-Be-Done's place in the UX world, and it spilled out into a phone call. All 3 hours(!) of it were recorded so that it could be shared with you. Enjoy!

This is Part 3 -- be sure to check out Part 1 and Part 2 first if you haven't yet!

Jobs-to-Be-Done 101

Samuel Hulick:

(I'm cleaning up this janky-ass transcription for your beautiful peepers right now -- please check back in a bit for something more useful!)

Well, let me, let me give you one more story and we'll see if that, I'm sure it won't work, but let's just try. Let's just, let's clap for tinker, tinker bell here. Okay. Alright. So I recently found out or heard a story also of, of a company who creates software for construction workers for contractors. So you can say there's a, a kind of person that is a contractor kind of person and they build software tools for those people. Okay. Okay. And by consequence of better of understanding their user base or they are the kinds of people that they're serving, understanding that it clearly they created, I don't know if it was part of their software or the or the kind of the whole thing, but there was some sort of interface that would let you look at a, a plot of land and, and do some sort of accurate measuring and diagramming based off of that as far as I could tell. Okay. Okay. And it turned out that they were, they were looking at the people who are using the product and it turned out that, uh, instead of projects from contractors who were like, like a project like, um, uh, like diagramming, like a kitchen remodel, for example, instead of that, uh, the same tool was being used by archeologists who were using that to document and explore archeological dig sites. And so I think again, looking at where we can agree, I think we can both agree that the tool was not made for archeologists type people. It was by coincidence that it wound up being useful for them, but it's useful for the contractor type people and the archeologists type people in the same way it serves the same need. I wonder if that's true on a functional level. It will, you know, organizing things in a spatial, whatever it is that it does. The same tool was useful for two people to do the same basic operation for two different reasons. Oh, okay. Okay. I guess my question is, did that, is that, is that the case if you really went and watched the archeologists using this thing that wasn't built for that, would you notice that they, their usage pattern is really more of a hack? Of course, of course there is. It's a novel use of software. Yeah. Yeah. No, no, no, no, no, that's not what I mean by a hack. I mean they are, they are making the tools fit their needs. So one of the things we noticed when we studied carpenters working on construction sites is that they would, um, they would use as a power drill to hold down their blueprints. Okay. So they'd have these sketches are blueprints. If they were working from. They were out to the worst sites. The wind would pick up papers and blow them around. They needed something to hold it down. That was fairly substantial. And so they would use their power tools to do that because the battery packs provided enough weight that the tool would, uh, uh, wouldn't hold the paper down if they used a screwdriver or some other tool and they had to use tools that they didn't need very often because if they needed the tool or the minute they picked up the tool, the paper would go away. So one could say that a job of a drill is to hold papers down because based on the amount of time in use, that was the number one thing these people use the drill for. If you just measured how much time it was doing something useful, the number one thing was holding papers down. Yeah. Right. So, so, and so to this point made when, when drill manufacturer, I learn this, they built clips into their drill packaging so that you could swipe the paper and it would stay in better. So if you go and buy a commercial Bhaskar a dress, uh, uh, uh, uh, attracting who the other big brand is, a, um, w with dewalt, if you go and buy a it, if you go and look at the wall drills, one of the things you'll notice is, uh, the commercial grade carpenter drills. I have this little clap stick outcropping and it's like, what the hell is that for? Well, it's the whole papers. And that came out of our research. Now is this kind of like the, the airbag that you don't have a choice in getting kind of an example? No, no, that's not where I'm going. Okay. You don't have a choice if they only make them with the clips now, but the, uh, you know, sort of Cup holders in a car, right? What if you don't have any cups or waste? Um, the uh, uh, but it's a hack, right? And really what they need is they need a way to keep papers down that isn't just using a tool. But the problem is they want to minimize the amount of weight that they carry. So they, so they have things. So wondering if from the archeologist, if, if you actually studied at once, you discover that the archeologists for user group, which I agree, if you set out to say we're gonna study users of this tool, you would only end up with the contractors. You wouldn't end up with the archeologist. Well you're not going to push back against because you're, that's, that's deterministic from the get go because you're deciding to build a tool for contractors to from to begin with. Right? But, but, but, but then you, the way you discover this as you say, well let's look at who else who's buying this. So I did a project years ago for for 37 signals to base camp people were, which led to version two of basecamp and the research that we did where we explicitly said we don't want to go visit anybody who uses base camp to build websites. We want to go visit people who use base camp for things that aren't websites because it was designed for websites. But Jason and Dhh and Ryan all knew that, uh, those weren't their only users. And they knew this because they were getting support calls from people and they were seeing, you know, accountants and doctors and theater companies sign up for this. So they wanted to go visit it. So we went out and we studied people who did that. We didn't do anything different in our user research. Then we would have had really studied people who, who were designing websites with base camp, except for the fact that when we set our initial selection criteria, we made it a different criteria. And we said explicitly, nobody who's doing web design, we only want to talk to me when we went out and visited a, the adler planetarium. And we did this, did which uses basecamp to track all their school groups. We visited a at a real estate agent, uses it to track every property they sell. They have a different base camp project for every property. We used to go to a theater company that used that had a different base camp for every, uh, for, for base camp project, for every production that they had in play. Uh, and we learned a tremendous amount of things. Am I correct in understanding, you were saying instead of focusing on people who want to manage website building projects, you just, you, you wanted to focus on people who want to manage projects of any kind? Yes. Okay. Yes. And, and, and we learned a lot of things that actually be wed to version two of base camp, which I still contend is, is the best of the three versions. Okay. And, and, and without, without getting specific, the nature of the things that you learned, am I correct in understanding that the, the, the learnings were about the people who you researched? Yeah. Well it was about the people and what they were trying to do with it. Yes. Okay. And texting. It worked. Here's a question for you. How much of your user research, what is it fair to call it user research? I don't want to put words in your mouth. How much of your user research involved researching how to manage projects more effectively in general? Well, all of it. Well it sounds like you're saying you, you were researching people who want to manage projects, not the management of projects itself. Of course there are quarterly, we're looking, we were looking at in depth as to how they had adapted base camp to meet their needs. But the needs belonged to the people you were studying. Yes. They were an aspect of the people. Yes. And if so one of the things that came out of this was we, we identified a whole new group of people that we didn't know existed. Okay. Can you, can you see the difference between the things that they want to do? Being an aspect of the people versus the people being an aspect of the thing that is wanting the, the managing of the project? No, I don't know. I don't see that distinction. Huh? Okay. I mean they go hand in hand. You can't, you can't have something somebody wants to do without having somebody and, and, and there were things that everybody wanted to do and there were things that were unique to the situation of the theater company or the planetarium and there were, there were small clusters of things. One of the things we focused on in the project was in tableting to do lists because it turns out that there were a bunch of folks who wanted to not start with a blank slate of, to do's for every new project, but in fact wanted the to do's from, uh, from another project too, uh, uh, to, to, to basically propagate over but not have themselves checked off. And so we spent a lot of time looking at this idea of reusable to dues because every time the planetarium had a new school group they wanted to. Do, you know, if the, if the group was going to eat lunch, there were a whole bunch of to do's around eating lunch. If the group was a fifth graders who had a particular science requirement. There was a whole bunch of views around that particular science requirement. If the group was third graders and they didn't the science requirement, but there was a difference in live to do. And so, so they wanted to be able to pull a sets of, to do's into a project when they signed up the school group to come. And then they would divvy out those to do's to a team of people who handled the various aspects of the school tour. And um, there was a tax accountant who was using base camp who did the same. Basically the same thing with every new client that they picked up so that as they were getting ready for the tax preparation for the year, they had clumps of to do's that they would use to, um, uh, to define what made that client what they needed to get done for that client. And they would pull those things in and we looked both at the way they were using to do who's then how different users were using to do is and how they were the same and different at the same time that we were looking at the users. And that accountants and planetariums are very different. But they had this one thing in common which was they kept repeating the same activities over and over again. And they were trying to figure out how to make sure they didn't leave anything out. Okay. And and so, so, but we only got there by first understanding how accountants, how that accountant does it, does project management and how that planetarium does project well and with, with base camp, with base camp and no, I mean we looked at, we were looking at how they did project management outside of base camp. We were paying very close attention to things that they didn't use base camp for that were essential to the project manager. Okay. So we were looking at that in depth too. So we were looking at the whole project management spectrum. Is it the process of getting the taxes done and the process of having the school group come through. We're looking at the whole picture and seeing what part of it base camp was currently taking advantage of. What made that easy? What made that hard and what other things could base camp do? Because at the end of the day, all they were at 37 signals was interested in was how do they make version two of base camp. They weren't interested in building a different product even though they had different products. They have a campfire that high rise, it had a whole bunch of different products. They were focused purely at this instance on base camp and and that was, that was there. That's where they put their blinders up. Had when we found something that would have changed their mind about hyperized for campfire or something else. My guess is we would have opened that door and looked at that for awhile because that's who they are, but what we did so they didn't. Okay. So just so to you, to you the. Do you see it is it is conceptually inextricable to consider a someone who is managing a project from the idea of managing a project in the abstract? Yeah, yeah, yeah, yeah. Because everybody we met managed projects will do differently and, and you could find overlapping elements, but you could not find two people who manage the project the same way. Even in the same organization. Even at the planet. When we talked to different people, they were using base camp slightly differently and that was really interesting. They did not. They did not have a uniform way of doing it and that caused problems for them and one of the things that they were hoping we would fix is somehow enforcing uniformity. Okay. Well, so, so looking at this from a process standpoint, you conducted the user research and then I assume you summarized it and some kind of documentation that you shared with, with base camp would as they're currently known, correct? Uh, no, no, no. We did the research with them so they were on every visit. Okay. In fact, they went on visits I didn't go on and uh, and then we synthesize the results together. And what was the end result of the synthesization a shared understanding. There was no documentation. No, there's a small group they didn't, they don't document. Okay. And then how do you know that the understanding was shared? You can see it in base camp too. So, so you, you, you went out, you conducted a, a collaborative investigation with base camp and then the tool all arrived at the same conclusions and then con and then translated those into a new product and you're sure that the, there was a consistency of, of, uh, insight of throughout that entire process. Well, while we were try, when I would talk to her folks individually, they all have the same story. So yeah, I, I, there, there, there are a group that works very well together. I mean, and they, they've worked very well together for a really long time so they are very much of a shared mind. Okay. Well let, let, let's, let's talk about it in a more general sense though because like you're talking about personas and scenarios as basically being, again, I don't want to put words in your mouth, but your summaries of user research, it sounds like, is what you've, you've essentially said it and, and, and, and to your, to your, to your point earlier about wanting to approach design in a better way and get rid of bad design. That sounds to me very much like a core concept or a, a, a value that you, I assume hold dear, is a, the concept of like falsifiability of being able to correct mistakes that you might make. Okay. How do you, how do you correct a persona? How do you find out which parts are, are, are, uh, are accurate and not you keep researching? So there's only one way to evaluate personas, which is do they, do they accurately summarize your research or not? Yeah. Do they do it? It's like any sort of modeling, right? Does the model predict the outcome that you get when you look at the world? And then what? And then however that's borne out in the product is just so, so, so if I, if I have a model that says there's a, uh, whenever I drop something it falls down not up. I conduct experiments on a regular basis and, and, and if suddenly I let go of something and it follows it up, my model's broken. Okay. Right. When does the model of a persona get broken? Because it seems like it's never. We never actually go out into the world thinking you're going to see something the same and you don't. So user researcher with the model doesn't predict what you, what you thought. Okay. But then, but then those findings get translated into, into product planning, right? Sure. And the theory being that the better the user research insights are, the better the product will turn out to be. Yes. But there's also an element of, of understanding there. You can have fantastic research insights, but if everybody doesn't understand them, then I'm then then the product will probably not be much better. Okay. So everybody has to have that shared understanding. So what, uh, what, what in your opinion is taking place when you have the user research findings and you're translating them into a product? What's happening in people's heads there, do you think? I think what I think what happens is people are trying to put themselves in the seat of the user to what a lot of people these days refer to is empathy right there. They're trying to to become the user and go through the process of, if I was that accountant creating a new project, how would I, how would I interact with this design and if I have to design choices, which one will get me to helping my customer better. And then I asked the question and say, well, okay, well what if I'm one of the planners at the, um, uh, uh, at the planetarium, which of these design choices get me to an outcome and that's better. And uh, that's how you use, that's how you use personas. It's, it's, it's a way to swap in and out the roles. Did you play when you, when you're designing, so you can ask the question, if I'm this person doing this thing in this context with this objective, does this design get me? They're better than the old design or a different design. So you're like running simulations in your head, kind of. Okay. I think that's how people design. That's my model. And you think like, and maybe this was a, let's see, how do I put this? Are you holding up the way that base camp? Uh, the, the base camp team specifically, are you saying that they are extraordinary in their way to have everyone's heads in the same place or do you think that that generally speaking, you give a team personas and scenarios and people will run the same stimulations in their heads? Uh, you know, if you have five different people on a team, you're going to have one series of simulations that those five people share, or do you have five different things that are happening in five different heads? I think the latter, it happens more often, but I don't think the, the base camp team is unique. I've met other teams that could do that. Okay. But it's the exception to the rule. I'm not going to make a rule whether I'm going to say is, is a statistically they are west common. Okay. Again, I'm just, I'm tipping my tip in my hand a little bit here, but I think I think that it's at least a two step process that if you look at the personas and scenarios and of course there are other kinds of of user research documentation as well as ux design competency documentation, but let's just hold those two up because they are. I think we would agree are the most common. If you hand a designer a and again all of this I want to couch in the caveat that of course designers should also be conducting user research stone and so forth. I'm just saying if, if, if you are in a in design mode and you're referring to personas and scenarios, I think that even putting yourself in the place of the user, it's still at least a two step process. You need to be able to kind of look at the world through their eyes and then you also need to manufacturer a sense of what their priorities are in that given moment. Yeah. So far so good. And, and, and I. and what I find is that step one and step two is roughly speaking. Yeah. And then you and then you translate the priority is just step two is that, well again, it's, it's for me, it's who you're helping, what they want help with, how you help them do it and, and so the, what they want help with. It sounds like you're saying the who were helping as personas and what they want help with is scenarios and the how we help them do it as the tool that the product that you make. Yeah. Okay. So, so it's unfortunate that we almost always refer to it as personas and scenarios because the way I see it used in the way I recommend that you do is you start with the scenario. Okay. And then you used the persona. Okay. Hey Jared, we agree on something. I think. I think that really, I think that in a lot of jobs to be done a lot of perspective and a lot of the reason that presenters get pushback that they do is that a lot of teams, whether they are, you know, again, a true scotsman or not like one which is a reference to a. I don't know that. Okay, I got it for people who may or may not be home, I just wanted to reference that. If that was totally sounded crazy, we'll put that in the show notes, but, but whether they're a real quote unquote practitioner or not, um, I would say that a lot of people skew a lot more to, toward personas then scenarios in general, but, but if we it, which I don't think is a good idea. And, and I think that user research, user research as a methodology biases people who again, are maybe in that shades of gray between absolute master practitioner versus complete new person. There's a lot of blame and cooper a little bit for that. Okay. Because, uh, because hey, I like to blame Allen Cooper for thing, but be a. because in the inmates are running the asylum, he spent way more time on personas and west time on talking about scenarios, but Kim Goodwin and a design, anything in the digital age and in her workshops spends 80 percent of the time on scenarios and only 20 percent of the time on personas. So let's talk about scenarios because I, that is, that's an area that I think we can both, we've set the stage, I'll have to a very great deal in this conversation and I think we will be able to analyze those in a, in a meaningful way. Okay. So in my experience working with companies who do do scenarios, which is already kind of the minority, a lot of times what I find is that they, they, they, they are a rife with, with bias and, and it's, it's a number of different biases. One bias is that it's only a summary of the people that you've researched to begin with. So it's already limited from that, from that degree or from that perspective. Another thing is that a lot of times they're just so stories where you say, uh, you know, busy beatrice wakes up at 6:00 AM every day and is fearful of new technologies so she doesn't like to get with our phone right away and then does her hair and makeup and then commutes to work and kind of creates this whole fabricated a like a, like a, like a, like a story, you know, literally just a, a, an invented parable of sorts. Right. That's not how you, I mean that, that, that, that's a, that will not get you the results you want to get if that's how you create scenarios. Right. And so I think that when you look at scenarios again as a, as a, as a kind of documentation, a lot of times you get, what was the term that you use, like a, a user narrative or is that my term? Sure, that was your term. But, but I like it. Okay. Um, and that's what you get and I know, but here's the deal. You probably can't if you had one of those scenarios and you had a, a one that actually will help you develop a great product side by side. You probably couldn't tell the difference just by reading them, but, but that's such a huge amount of translation for someone to do in their head to go from like a paragraph saying, this person wakes up and does these things during the day too. Oh, and then Ergo, there's a in a, in a con, insanely, as you mentioned, order of magnitude more complicated or more complex, uh, a product than a car. That's a huge leap. Oh No, no, no, no, no, no, no. Scenarios have the same granularity as, as anything else, right. You, you, you break it down into things. So here's a scenario for a radio company based on real research. May I, may I interrupt you very briefly because I want to, I want to state something be. I don't want it to seem like I'm catching you on something. Want another. Another major concern that I have with scenarios is that they are basically descriptions of how to operate and interface at time. No, no, no. Then they're done. Well, no, no. I would highly recommend you look at Kim's work. It sounds. It sounds like I should take a much closer look for sure. Yeah, because she goes way beyond that. Okay. I don't disagree that lots of people will write down how you operate something. I mean, you sent me that thing on, on what was it, that weird version of task analysis, right? You sent me a link the other day. Well that was, that was, that's how we, that's how we got here. As you were claiming the job done. Right. And my point was if you think that's task analysis, you're not going to do task analysis in a beneficial way. And, and, and the same is true with scenarios and the same is true with agile. The same is true with. I'm sure it's true with jobs to be done it, it is true with anything, right? If you think you're doing it because you, you latched onto a word or phrase and, and, and you do that thing, but you're not going back and reflecting and saying, did that actually get me the outcomes? Am I actually, am I actually, uh, uh, doing everything I can be doing to get a better outcome and so, you know, any methodology, it's basically a package of activities that we use to, to achieve better outcomes than if we didn't do the methodology and a scenarios falls into that category and the activities that, as Kim describes them, I haven't seen any other prescriptive ways of doing scenarios, but I've seen lots of bad scenarios so people make up their own a methodology, but the way Kim describes it, you create scenarios are very different weighers. So you might have a scenario which is basically a very general scenario. I book a ticket too, a Lisbon on wine. All right. Then on the day before the flight, I go online and then I check in for my flight and I download my boarding pass. And then are you describing how to operate the interface? I check in for my flight. I download the boarding pass. Aren't these? This is how. This is how you make your describing. Just describing. I'm not at all. I never said it at all. I didn't say anything about what the interface looks like, what I typed in, what I clicked on. There's no description. I think downloading something is a pretty clear interface operation. Okay. I, I could have easily said get my boarding pass. Okay. All right. Fine. Okay, so. So sure. Download big might be a bit interface, but I am describing the scenario of me interacting with the touch points. I can have a different one which is booking a trip to Lisbon and I fly in two weeks and I get to Lisbon where I describe the interaction with the touch points at all or I can create scenarios where I dive in deep into what it's like to book my trip, what it's like to get my boarding pass, what it's like to to check in at the airport and I can describe those touch points and interactions in way more detail. All three of those are specific scenarios that go into the scenario collection of the entire burden and when you get it into service design that you're talking about, right. You're talking about all the things that happen in. In order for me to have the vacation I want to have in Lisbon, and is this a comprehensive organization of all of those that shows them in the context as they relate to each other or are they. Are they illustrations that are held up as as individual examples there. There there are artifacts that we use in the process of design to make sure we're all on the same page and we zoom in and zoom out of the levels depending on where we are in the design process and we use the documentation of the scenarios to make sure that it matches our internal thinking of what we're doing. Because if you create. If you are in charge of the in airport experience and you create a series of things and I look at what you've created and I say, wait a second. I thought I was doing that in the APP before they got to the airport. We have a conversation that we have to have and the only way we discovered that was that you created this document and shared it with me and I looked at the document and it didn't match my understanding and so that gave me an opportunity to raise the flag and say, Hey, your understanding of my understanding doesn't seem to be the same thing and is this more like a blueprint or these more like color swatches that show you examples of what it could be like you can, you can create the artifacts in lots of different ways. There's, there are color, swatch style style artifacts, and then there are detailed blueprint style artifacts. Can you then be a little addition, stout artifacts? So what was the last one? So I just didn't hear what you said. Artist's rendition. Okay, Gotcha. Uh, so, so I've been, we have a project to rebuild our house and the architect keeps giving us documents and sometimes the documents are what you would think of as a blueprint. You know, something that construction company would actually work off that has very explicit measurements and thicknesses of material with this. And all these things, but they also gave us these sketches of what the rooms would work and it was straight or actually sketched out the rooms and they worked off of those blueprint documents to get to the sketches, but they added a detail that wasn't in the blueprint. They also built me a three d model of the house out of foam core. And each of those look very different, but each of them give me a perspective and each of them were actually built out of the same modeling software. So, uh, which I found interesting. I'm uh, and they are all accurate representations but they are not representing the same thing. Okay. And they, and they helped me see the project in very different ways. Sure. And the combination of all of them gives me a bigger, better picture than any single one of them. One. Uh, okay. So scenarios when you build them a are common multiple forms and so and so the forms that you used depend on what type of communication you're trying to make at that moment. Let me ask you this question. So in the case with your, with your house and the example with your house, you've got the foam core model and you got the artist's renderings and you got the different, you know, all the different sort of aspects of the experience, um, highlighted in different ways. Yeah. Okay. Um, if, if that collection of things like, let's, let's say that those are in a way you ux documentation of sorts. If, if you were to hand that to a home building team or let's say you were to hand that to 10 different home building teams, how consistent do you think the, the resulting structures would be from one team to the next? Well, the, uh, fairly consistent, um, uh, builders and architects have worked extremely hard to develop a common language which is how the blueprint works. Okay. And um, uh, but they also, you don't, there are all these meetings that I sat in on and many more to come between the builder and the architect where the Ark were. The builder brings up all these questions where they think there's a lack of specificity in the blueprint. And the architect then takes a lot of notes and then answers their questions, but more importantly it goes back and updates the blueprints and because we were dealing with multiple contractors, we were, we were showing these diagrams to multiple contractors and uh, and every time the architect was going back and changing the diagrams and then giving them to the next contractor, the questions for changing and we weren't getting the same level of, um, lack of specificity. So that back and forth was really important. That iteration over those diagrams was really, really important. Okay. So the and the architect did not expect that the first round of documents would be conclusive. They went in expecting lots of questions and that they were going to update them. Okay. So it sounds like you're saying the blueprint specifically was a central organizing document that was also a living document that was updated to reflect the, your update and understanding as it, as it evolved. Right. But there's an important element about a blueprint and an architectural building setting, which is, that's a skill that's trained in school for both contractors and architects. So there's a, there's a, there's a language there, a visual language that is trained, not assumed. And I'm uh, uh, the, I'm a, the, the language, uh, is learned over time, but it's not without it. Uh, what would you say? A learning curve? Uh, no, no, it has a learning curve, that's for sure. But that's not where I'm going. Uh, it, it's not without its uh Huh. My vocabulary server's down. Idiosyncrasies, idiosyncrasies, but also, uh, uh, inability to be completely clear, right? It, it's a, it is there, there you can have a blueprint that you think says everything and someone else can read it and come back with a different impression. So you have to constantly check against that. And so one of the interesting things about the blueprint set is if they actually cleared out blueprints of the same thing from different perspectives, so they'll show the floor plan with the walls, but then they'll also have diagrams that show the walls as if you were staring at them horizontally and everything better match up with the floor plan. And if they don't match up with the floor plan than a that's then someone raises a flag and says, how come you said that it was this over here, but it's this over there. And the architect would come back and say, oh, that's a mistake. Or Oh, I wasn't being clicker. I need to to update this so that it doesn't ensure clarity. No understanding. But, but, but this is, this is coming from a place where the question was with the homebuilding documentation being what it is, can you hand that off to 10 different teams and, and, and achieve something along the lines of 10 different or one similar result across those different things. And it sounds like you're saying especially because of the but, but, but there will be places where interpretation has done on that blueprint that Western intended that will get you results. Yeah. Or Beethoven's ninth is performed differently even though the notes are the same on the, on the sheet music. Exactly right. Here's my question though. If you take personas and scenarios that are done a well that are done to a very high degree of quality by quote unquote real user experience or a experience design practitioners are user researchers. If you were to take those personas and scenarios that are well made and you were to hand them to a software team, uh, or to attend different software teams, how similar do you think the resulting software would be? Uh, it depends on the teams exactly. And that I think is a major failing of, as a planning document. No, the planning document doesn't, isn't a substitute for, for actually iterating over a design. The planning document is just a sketch. It's a way of communicating a lot of information in a single throw. So what do you consider the quote unquote blueprint to be? If it's not the personas and scenarios? I don't think we have a notion of a blueprint in, in digital design and, and, and this jared is where I am, I am a boldly going to posit that, that in accomplishments framework as we've been discussing it, or at least my representative that would be any better of a blueprint I disagree with. I very respectfully disagree with you. I, I take, I think it will provide insight, but I'm not sure it provides any more insight than we're already getting. You're also dismissing something that doesn't really exist as that you're not familiar with. Right? Oh, okay. So, so what you're saying is you're going to build something to fill this gap. I do believe that in the same way that that sheet music exists to, to have people, uh, arrange their behavior around a common Lee shared symbolic vocabulary vocabulary. Uh, in that same way, I do believe that there's a huge gap that needs to be filled between here are the people who are using the product and what we know about them. And here are the features and functionalities of that product. I think that there's a gulf between those two and that having gone to avoid reinventing the design specification, I think that it's helpful to have a product scope, but I think that needs to be based off of something that's more translatable then caricatures of people. Yeah. But that's it. No one's suggesting you base the product scope off of caricatures of people, so I don't understand. I mean that, that, that's, that that's a straw man argument. Do you agree that there's a void there whether you agree or not, it can be filled. Do you agree that, that there, that there's a lot of mental heavy lifting that's being done because of an absence of, of documented information? Absolutely. Okay. And do you think it's possible that someone could conceive some way of improving upon that even slightly? Sure. I think lots of people who've been working on that for a long time. Okay. So yes, I think whoever does will will have a dramatic impact on how we produce great products going forward. I think that's the holy grail. Well, whether we call that jobs to be done or user center design, uh, my goal for this conversation was to agree on something and I think that is ultimately a, one of the purest expressions of what we both hold, dear. Sure. Yeah. If I understood that that's where we were, you were going, we could've saved ourselves a lot of time. The, uh, uh, I mean, I think that that's, that's absolutely true. Uh, I don't see jobs to be done even close to helping with that and I don't. And, and it's definitely not what, uh, anything in user centered design is trying to do. So, um, uh, know what you're talking about is something that paired programming xp, waterfall type specifications have tried to do, but it's clear that none of them are succeeding. Um, it's not a question of documenting the scope of what we build. It's a process. It's a question of documenting the scope of why we're building something and that's not just, that's every product management document ever created. I think that, that, that, um, and, and nothing out there does a good job of that. And I think it's because of that people are falling into, in, in a, an unconscious bias blindness or bias at least because they're either thinking of it in product attributes or people attributes. And I really that, that part, I, I lose you at that moment. At that moment I, I. because I don't see people doing that. I mean I just, the folks who are creating decent products are definitely not doing that. And, and yeah, the folks who are consistently creating crappy products, I don't even think they're getting that far so. So it's just, I just don't see that as the, as the thing. Do you agree? Do you agree that even people who are doing it well are translating user research insights into product features? And by features, I don't mean like a feature, I mean like a quality of a product. Do I think that the people who are doing it well are translating user insights into. Yeah. And when do you end. Do you think it's possible? Let's take airbnb. Hold on. Do you think it's possible that there's an interstitial step that people don't even realize that they're skipping? Well, if they're skipping it, then it's not a necessary step. Isn't it necessary to build a product that that works? Well? I mean you can, you can build a contract. It's not a product that works well and they're skipping the step. Maybe I'm not understanding the question. You seemed like you were about to say something. Do you want to run with it? Well, what else? I mean, I don't think you can separate what, what the product needs to be doing, what people want to use the product for from the people. I really just don't. You can't do that. Do you think you can separate what the product needs to be helping people with from the definition of the product itself? Like do you think it's possible to have like a map and terrain kind of difference between the two? Well, sure. I mean either the product does it or it doesn't and if it doesn't do what they needed to help with then then there are different. Right. And the documentation and the doc products probably don't do exactly what the user's needs them to do it. So I guess in most cases that's true, right? And so the documentation that we organize our efforts and literally and figuratively get on the same page about when it comes to what it is that we're helping people do. Are in your mind satisfied through scenarios? No, no, no, no, no, no. I never said that. That all the documentation you need is, is, is through scenario regarding what it is that we're helping people do. I'm saying that that scenarios, again, you have to separate the shared understanding from the actual documents, the shared understanding of the scenarios. If they are well researched and complete, we'll get the team closer to a product that that meets, that meets users' needs than a team that doesn't have a shared understanding of those scenarios and they can be beautifully documented, but if no one's read them, that's useless. Well, of course I'm saying is there anything that you think right now scenarios and personas fall short of documenting that could and should be documented? No, I, I, the organizations that I see that are using scenarios really well, I would put, you know, the first one that comes to mind that, that is sort of a generally understood case study is, is airbnb where they have this beautiful set of scenarios that they have researched incredibly thoroughly about what it's like to, to, uh, look for a property, what it's like to be a host at a property. Every aspect of the service they have. They have taken it apart. They've done a beautiful, beautiful job. Um, and uh, they, uh, as a result, their, their product does a really good job for people. People are, you know, you talk to users. They are, but they are very happy with it. It feels like it really matches what they're trying to do and uh, organizations that, that, that do, that will get that result that you don't see the frustration of, I just want to do this thing and the software won't let me. Uh, um, so it, uh, I think that having a really well researched, well defined set of scenarios will get you there. Uh, but not everybody who does scenarios gets there because, uh, uh, there are lots of ways to do it poorly and of course, some of that's training and some of the, that's the tool itself. Well, I don't, I, I, I would, I would like to look back at this and in a few years and say, wow, we have come a lot further than, than the, the, uh, the limitations of our perception might've indicated during this phone call. Okay. I, I've enjoyed the phone call. I'm glad. I'm glad you had a pleasurable experience and I wiped it. We're calling it a phone call even though neither of us are on a phone. Exactly. Do you, do you have any, any closing thoughts? Um, I have no closer to understanding jobs to be done. I'll tell you that, uh, I, the thing that struck me that's really interesting about this, uh, that I think you did help me with is this idea that, um, uh, uh, the accomplishment as you put it, the thing people are trying to achieve, I'm a, is, has to be in balance with what we understand about the users and that and that if we're not keeping it in balance a week, uh, we get ourselves out of whack if we focus too much on users, but we're not thinking about what they need. That's not helpful if we focus too much on what they need and we're not actually thinking about the nuances that makes, makes users different and changes how those needs either our manifest or it may have changed. In fact, what the actual need is, um, that, uh, that gets us into trouble. And so that, that there's this balance that we have to keep to, to understand, uh, that we're, we're getting there. And um, uh, and that balance, like any type of balance is really tricky to maintain. Um, and, and we don't talk about that a lot. And I think, I think we need to talk about that more. So I think that's the big takeaway. Other than you are, you are very delightful to have long conversations with. That would be my other big takeaway I could do. I could do this on a regular basis. This would, this would be fun. Uh, uh, you, you, you are obviously very sharp and, and, uh, uh, you, you are thinking about the right things. I'll be it. Sometimes I don't understand exactly why I, I'm, I'm grinning from ear to ear. I, I, uh, you know exactly how to, how to get on my good side. But yeah, no, I think this was interesting, right? I think that there's, there's definitely something, something here. Um, uh, as I, as I have said about jobs to be done, I think there's a pony in there somewhere. I'm just having trouble seeing through all the bullshit or all the horse shit to get to the pony. I don't know if you know what that, references that. That was a, it was a Ronald Reagan was, wants handed some document. I don't remember what it was, but you can look it up online for technically if you type in, there's a pony in there somewhere, you will find a story about Ronald Reagan. And he basically told the story after reading through this document. He just launched them to this story and the story was about it, uh, uh, a traveling salesman going to a farm and that he meets the farmer and they talk and the farmer says, let me show you something. And, uh, uh, he goes to the back of the bar and he opens his door and as soon as he opens the door, all this horseshit starts streaming and flowing out of the door and the farmer says there's a pony in there somewhere you can have. And a, uh, basically the idea is, is yeah. Huh? Sometimes, uh, we have to work really hard to figure out where the pony is because the portion is just so immense. And I think unfortunately, the way the jobs to be done world communicates what it's trying to do. There's way more hardship than bony. Well, on that note, I, uh, I, I would, I would like to think that, um, that we can have this conversation again sometime in the future and I will make it my personal goal to produce something pony like for us to, to talk about before that time comes. That sounds awesome. Excellent. Well, thank you for encouraging my behavior, Jaron, and uh, it's been a real pleasure talking with you about this. Oh, it's been fun. Thank you. That's a nice way to spend an afternoon. Yes. Well thank you. Thank you again for your time. And, and, uh, is there, I guess if I'm pretending to be a podcast to you, do you, is there a. How can the listeners find you? Oh, I'm, I'm the one who's, who's, who's complaining about things that Jim Spool on twitter. I guess that's the easiest way. Jim Spool and the center center center center. Yes. Our school and a US senator. Senator you. Yes. That's, that's the company.