UserOnboard

Samuel (00:00:15):
Hi, I'm Samuel from UserOnboard.

Yohann (00:00:17):
And I'm Yohann, also from UserOnboard.

Samuel (00:00:20):
And today, our episode is focused on the first pillar of the three pillars of healthy growth that we outlined in the previous episode. That first pillar being Path Design. And Path Design ultimately, to us, is looking at the process of getting somebody from point A to point B as reliably and enjoyably as possible. So a lot of times, by contrast in the software world, we will hear something like this: "Our invoicing software gets you paid faster," or something along those lines. But there's a lot that goes into having an invoice get paid. You have to create the account with the invoicing software, you got to create the invoice, you've got to enter in the client's details, you got to enter the invoices details. You got to send it to the client. The client has to see it. The client has to decide to pay it. The client has to actually pay it. The person has to receive money. There are a number of different steps that go into just the basic operation of delivering on your value proposition.

Samuel (00:01:30):
And for us, we have tended to find that over-fixating on your software as a product that has immutable features and that you just hope that people wind up having success with it is generally not the way to create an ideal process of getting from point A, where the user currently is and what they're asking you to help them with, to point B, which is where they ultimately want to be and want your help in getting to. Fair introduction, Yohann?

Yohann (00:02:04):
Totally fair. Your product is just a small part of everything that needs to happen between your starting point and your resulting point.

Samuel (00:02:15):
Hopefully less small than it needs to be. So maybe we could use an example like going camping, where if I wanted to go camping, there would be a whole ecosystem of different software offerings that would enter into that picture at different moments. Maybe I would be using Google Maps to figure out how to get there. Or I would be looking to buy a cooler on Amazon because I don't have a cooler; some nightmare scenario like that. There are a number of different things (that you might use an app for) that you're incorporating into the overall process of going camping.

Samuel (00:02:59):
And if you can identify a process like going camping that has a big enough market of need, then you can choose to really out-serve that particular process and create something that's super streamlined and that your software covers from beginning to end as much as possible rather than saying, "Oh, we happen to pop up in the part where you're deciding when to reserve a campground," but everything else is totally left up to the user and they go somewhere else to do that and they figure that out their own.

Samuel (00:03:34):
Any time that your end-to-end process of point A (where the user is when they come to you) to point B (where they're hoping that you can help them get to), anywhere in between that, if you say, and then "the user figures it out": bad idea, bad strategy. You don't want to be counting on the users to have to fill in all of the blanks in a process of getting to a place that you should in theory be the expert to. Really in the case of the users, they're probably coming to you for help because it's maybe the first time that they've ever even encountered this kind of thing. And so to defer to their expertise and have them just improvise some sort of, all of the rest of the part of it to me is a lame strategy and ultimately is doing a major disservice to the users of our products that do contribute whatever they currently do.

Yohann (00:04:29):
We haven't talked about this. Even both of us, we haven't talked about this as yet, but these last few days have been calling it "app chauvinism."

Samuel (00:04:42):
I'm intrigued, Yohann. Tell me more.

Yohann (00:04:45):
This idea that we're product people and that the product is the most important thing that we're creating. And everything gets second bench to the product. Marketing, second bench, customer success, second bench. The product is the most important thing that we are focused on. And it's a conversation for anything that's part of our offering but not the product to make it into the product. I've been in conversations where if we need to provide technical help because someone can't complete a particular step inside the product, providing some help there and putting in a technical document or an article, it's a huge conversation to have because "you're making a change to the product."

Yohann (00:05:40):
And thinking of the product as the be-all end-all is really what we're trying to change, and we're saying the process should be the be-all end-all and the product is just a small part of it. You think of your offering as product plus rather than product only.

Samuel (00:05:59):
Product plus what?

Yohann (00:06:01):
Product plus everything else you can do to support the process, whether that's-

Samuel (00:06:06):
Well, and I think to me at that point then, you've decentralized the product to such a degree that it's not even product plus, it's just help. It's just process help, you know?

Yohann (00:06:18):
Right, right, right. Sending emails, articles. That content marketing part of the journey, why don't you think of that as part of the experience from getting from point A to point B?

Samuel (00:06:31):
Absolutely. And then on top of that, once the marketing signups have become products users, how much does product focus on making good on the value propositions that marketing brought the people into to begin with? To me, even when people are saying that they think in a Jobs To Be Done sort of manner and that they understand that they're serving needs instead of serving demographic categories or whatever, it is mind-boggling to me how much of Jobs To Be Done is sales and marketing-oriented rather than product-oriented. Which is, if you're saying that that is the main thing that you offer, why would you not shape the main thing that you offer around the Jobs that you're ostensibly serving? It's immensely frustrating to me to see so much of Jobs To Be Done literature positioned as a different way to position your sales and marketing rather than a different way to fundamentally ensure that you are bringing people to the successful point that they're hoping that your offering will get them to.

Yohann (00:07:47):
And that's the essence of Jobs To Be Done. Jobs To Be Done was created to help you innovate on product rather than figure out what to put on your board outside the shop.

Samuel (00:08:01):
Yes, very much so. The Clayton Christensen article that introduced me to jobs to be done way, way, way back embarrassingly long ago was intentionally titled Integrating Around the Job to Be Done, to say, "This is how we can integrate our business, not only offering, but even possibly our business structure in even our internal organization around fulfilling this particular job." Because if the user goes from the marketing website, to the onboarding third party plugin, to a sales survey, and then finally gets into the dashboard of your product, they might feel like they've gone through like seven different products along that way, where for the user it should feel like one continuous thing.

Yohann (00:08:52):
You're absolutely right. And Value Paths takes that to the next level. Path Design is how you do what Jobs To Be Done was saying you should do, which is integrate around the Job that the user desires.

Samuel (00:09:06):
It is our humble offering to take a mindset that we really like, which is Jobs To Be Done, and turn it more into a methodology that people can actually practice rather than just something to keep in mind while they go about conducting business as usual.

Yohann (00:09:27):
Right.

Samuel (00:09:29):
All right. And so with that being the case, this episode is intended to explore the ins and outs of what Path Design is and how to do it. And the first recommendation that I would make when you're approaching, "How do I improve the process of getting somebody from point A to point B," is to really, really intimately familiarize yourself with the ins and outs of what point B is, and to get a very clear understanding of when people come to us for help, it's always because they're imagining some better situation that they're in on the other side of the use of our product.

Samuel (00:10:11):
Every product use, every session, every account, every time a product comes into somebody's life, it is within the context of them trying to do something outside of the product and to get as clear as possible as you can on what the nature of that intended outcome is is what I really strongly recommend starting with. Rather than thinking of, even an example that I used earlier like going camping, where you could say, "Oh, well, in order to go camping, you got to get marshmallows so that you can make s'mores, which means that there's going to be a campfire and you should probably get one of those things that keeps the bugs out there."

Samuel (00:10:50):
There's a million different things that you could think of that would go into going camping. But ultimately, what you really want to get clear on is what is the end outcome that the person who's going camping is seeking and how do we align as much as possible around getting them from where they currently are to that point? Does that resonate with you, Yohann?

Yohann (00:11:12):
It does. It does. And s'mores could very well be a part of that path, but you don't start there. You start with the outcome so that you know how to structure things other activities like s'mores.

Samuel (00:11:29):
Right. You don't know if you're taking care of the basics if you aren't even clear on what the fundamental requirements are. And the fundamental requirements are dictated by the future situation that the user is pursuing, and all of the context should ultimately be stemming from that and reverse-engineered outward from there.

Yohann (00:11:58):
Right.

Samuel (00:11:59):
So no argument there . So the first recommendation is to think of it as getting people from point A to point B and to really emphasize and study point B so that you're really clear on what that is. The next recommendation is to get really clear on where point A is. And point A is not up to you. Neither of them are up to you, actually. Where the person's trying to get to and where they currently are are not factors under your control and should not be assumptions in your design process. Or at the very least, whatever assumptions you have should be articulated and you should gain some sense of consensus within your organization that these are truly the case, rather than just leaving it up to open to individual interpretation.

Samuel (00:12:54):
So back to what I was saying after I interrupted myself, or before I interrupted myself, so point B, we are clear on now. Point A is not where we decide that people start; it's wherever somebody is when they come to us. And so we want to learn as much as possible about the conditions of their current situation so that we can tell where in the overall timeline of help we're coming into so that we can gear our recommendations and our offering around getting them the rest of the way there, rather than having them go through the entire beginning to end process that everybody else does.

Samuel (00:13:41):
This is a term that we call desire triangulation, where we're trying to get a sense of, what do we know about the person currently so that we can make some really educated guesses around where they're trying to go? And then how do we confirm that and put effort into closing the gap between where they are and where they want to be?

Yohann (00:14:02):
I want to jump in with a question here. One of the challenges, and it's not easy to change the way you think about these things, so this still is a challenge for me, is when you say get really clear on the outcome situation and get really clear on the starting situation where people are, how do you think about something in situational terms? Because it's very easy to fall back on characteristics of the person or characteristics of the product rather than the outcome. How do you think about outcome characteristics?

Samuel (00:14:43):
The way that I would distinguish outcome characteristics along the lines that you just outlined between the attributes of the person versus the attributes of the situation that they're in would be that at the end of the day, what drives product usage is people being motivated to make a sequence of decisions that your offering is involved with and ostensibly can help with. And when you look at the attributes of the person, and this is Jobs To Be Done 101 stuff, Clayton Christensen said something like being six... Well, he wasn't six feet tall. He was like seven feet tall, but, "Being a 45-year-old white male does not cause me to buy the New York Times." That there are situational motivations that drive somebody to do different things. And the more that you can orient your offering around the assistance with that, and the more you can familiarize yourself with the ins and outs of that, the better.

Samuel (00:15:59):
So to tease apart the idea of people versus situations, instead of looking at age, demographic, information, so on and so forth, what we would want to be focusing on more are moments in time and the forces that act on people that motivate them to make a particular change. So instead of thinking of the person as an immutable object that has enduring characteristics, instead thinking there are these transient temporal situations where somebody might be on a road trip and have to pee, and that is a Job To Be Done in some sense. Whether you can build a business around it or not, I don't know, but that's not a kind of person, that's a kind of situation where you have external circumstances that are acting upon you and motivating you to make a particular set of decisions, or take a particular sequence of actions to change your current situation into a more preferable one.

Samuel (00:17:11):
And anytime software gets used, it is under those sorts of contexts. And most software exists in a way that is pretty blind to that, I think at least in part because I don't think we really take the time to articulate what those temporal forces are and what they imply people are trying to do with the product because of that.

Yohann (00:17:35):
So I'm looking back at my own experience, changing my mindset to stop thinking about people and start thinking about situations and just reflecting on the language that I've been using. The language I used to default to was, "This person is." And that's the stuff you were saying that's Jobs To Be Done 101, where you don't want to think about who this person is really, whether they're 45 or whether how tall they are, or you don't want to think about details like that. You want to go a level deeper. But thinking about my own journey, I went a level deeper but still didn't get to situational thinking, because a level deeper from is, is, has: "This person has."

Yohann (00:18:27):
And I often fall into this trap even now where we are talking about a starting situation and you say, "Describe the starting situation to me." And my first instinct is to say, "Oh, well, people in this situation have X, Y, and Z. They have teams of this size, or they have this particular role, or they have these particular tools at their disposal." But what you're saying and what I'm picking up from you is, what you really want to do is get a level deeper than that even, which is think about "when". So go from "is" to "has", and then "has" to "when", because "has" doesn't really bring in the timing aspect of it, but "when" does. "This person is in this situation when..."

Samuel (00:19:28):
I very much agree that your market, when you think of TAM, total addressable market in software terms, you're oftentimes looking at characteristics of people rather than looking at characteristics of "when-type" situations. And to me, the when is really the driver of the usage and the usage is the driver of the business model. So I think it is very deserving of consideration. And I think that a lot of successful software companies right now might offer a suite of different features that help for a whole host of different "whens".

Samuel (00:20:14):
They might have a lot of different point As and a lot of different point Bs that they can facilitate people going through. But if you don't know which of those point A to point B approaches is what's really driving revenue, you're just going to be putting out a bunch of different features that conceivably could be cobbled together into meaningful use, but without actually defining what the meaning of the usage is beforehand. And that I would generally recommend against doing.

Yohann (00:20:49):
So another tough question here.

Samuel (00:20:51):
All right.

Yohann (00:20:53):
When we think about the outcome situation, are you still thinking about "whens" instead of "haves" at that point? So in the previous episode we talked about one of the characteristics of the outcome situation. One of the indicators that you've chosen the right outcome to design for is you can tell whether it's happened. So you can't tell whether you've lived a good life or whatever, but you can tell whether you have scheduled 20 tweets to go out without your help next week. At that point, are you still thinking about to think about the outcome situation and what users are equipped with when they reach it? Are you still thinking about "whens" rather than "haves"?

Samuel (00:21:53):
Well, the distinction that I would draw is a word that I've danced around a little bit already in this conversation, which are... Well, maybe not a word, a phrase, enduring characteristics, where you can... Like I'm six foot tall and I will, as I get older, maybe I will shrink, but for a long time I'm going to be six feet tall. And so you could think of that as an immutable characteristic of who I am, but at the same time, you can think of that as one of many characteristics that I currently am existing within. And when we talk about a term, like "when" instead of "has", what we're really saying is that the forcing function that drives the motivation for someone to want to use your product is a temporary arrangement of characteristics within their life, that they're like, "This is not a good fit."

Samuel (00:22:59):
A really easy example would be I have a doctor's appointment but I don't remember what time it was. I know it was on the 26th but I don't know whether it was two o'clock or four o'clock. And there's maybe a long process of me having to go to my email and find the email from the doctor and then log into some stupid patient portal and then go through their own onboarding and all that stuff, just to be able to find out what the time of my appointment is. So I know point B is knowing what time I should be leaving, and point A is a combination of all of my "immutable attributes" like being six foot tall and things like that. But most saliently, it's a combination of me knowing that I have a doctor's appointment and knowing that I don't know the time that I should be there. And those are the two major prominent factors that you could say are a situational mismatch with my sense of wellbeing that drive me to be motivated to resolve that in some way. Is that fair? Is that a good example or too esoteric?

Yohann (00:24:12):
No, I think it makes sense. You're trying to find out of all the characteristics of the situation, which are the most relevant that need to be resolved between starting and resulting point?

Samuel (00:24:24):
Sort of like if you buy toothpaste or over the counter and stuff like that, sometimes on the box it'll list the ingredients and then there's active ingredient, that's separated out from the other ones. I think of it like that, where like, yes, the toothpaste comes in a white paste and gets squirted out of a tube and things like that. But the active ingredient is the thing that actually is what's cleaning your teeth, which is what's prompting you to be using toothpaste to begin with.

Yohann (00:24:56):
Right. And the difference between — and difference is a concept we should definitely talk about in more detail — but just for now, the difference between the starting situation and the resulting situation is this active ingredient has changed somehow to make the situation different.

Samuel (00:25:18):
I would get slightly semantically clearer and I would say that the active ingredient has contributed to change rather than it itself has changed. But I guess this metaphor is getting pretty deep too so we could try zoom out a little bit.

Yohann (00:25:35):
Yeah, yeah. Let's zoom out. I've cleared up both of the questions I had to ask.

Samuel (00:25:40):
All right. So what we can say is that point B is a cluster of characteristic that come together to form a desirable situation for the user. And point B is a cluster of characteristics that have come together to motivate them to desire point B. We're good on that part so far, right?

Yohann (00:26:02):
Yeah.

Samuel (00:26:03):
So then the question becomes, how do we increase the likelihood, how do we fill in the gaps as best as possible between point A and point B? And that is an aspect of Path Design where we would be looking not in terms of points in a timeline, but we would be looking at a sequence of changes or actions or steps or stages (the words themselves are not important)...the concept of achieving progress in chunks is how you get from point A to point B. You don't just say, "Oh, we've learned that our users want to go from point A to point B and so we've created some video courses about it and a knowledge based article that nobody knows about," and so on and so forth. You actually want to reverse-engineer, what are the required steps? What are the things we know have to change in order for some who's in point A to arrive at point B? And the-

Yohann (00:27:07):
I think in the previous episode you called it a "critical pathway."

Samuel (00:27:11):
I did.

Yohann (00:27:11):
Figure out the critical pathway.

Samuel (00:27:12):
I didn't want to repeat myself, but thank you, Yohann, that is correct. The critical pathway to me is what is the least that you know has to absolutely change in order for somebody who's in the cluster of characteristics of point A to arrive at the cluster of characteristics of point B?

Yohann (00:27:31):
And I want to emphasize how helpful this is from a process point of view, from a designing the process point of view. The critical pathway is a compression algorithm. It compresses unordered, near infinite information into a hierarchy. And that hierarchy is the sequence of changes that you're looking to design. And thinking about what... There are an infinite number of ways that you can get from point A to point B, but thinking about the critical pathway helps you manage all of that in a way that you can actually deal with.

Samuel (00:28:20):
I agree, that there's almost a fractal nature to it where every little... Well, and I guess we can acknowledge also that when we're talking about in terms of process and stages of changes or steps or actions, again, like the terminology's loose there in the English language. But when we talk about chunks of progress, those chunks of progress are themselves made of chunks of progress. So if I want to turn a piece of tree into a couple pieces of lumber for my house, there's a part of the process where I have to chop down the tree, and then there's another part of process where I have to turn the fallen tree into lumber, at least. We know that chopping down the tree is almost certainly going to be a requirement here.

Samuel (00:29:19):
And then if you just zoom into the chopping down the tree, it's like, "Well, am I using a chainsaw or am I going to try to chop it down with an ax?" And if so, let's imagine you're using an ax, then even just going and getting your ax, putting on your gloves, wearing the appropriate chopping down clothing material, going out and walking to the tree, hitting it for the first time, seeing what kind of hole the ax left in the tree, chopping it again, it's a whole sequence of processes. And even just the chopping of the ax, you can say, well, there's the grasping of the ax in your hand and then you lift it up and then you bring the ax down until it thunks into the wood. And then you pull it back out again.

Samuel (00:30:00):
You can just zoom in it forever, for literally forever down to the molecular, then the neuron in the person's brain sends the electrical impulse to the arm to have its bicep tighten or whatever. You could go really far if you want to. And right now, when we talk about, let's say somebody's taking a traditional product approach where they are making a fixed state product with a fixed state person in mind, and they have a persona that has a couple goals listed, that's infinite level complexity to consider. That we are just all coming to different and inconsistent, subjective conclusions about what that means exactly.

Samuel (00:30:43):
And then we're trying to decide on what the correct composition of rectangles on any given screen is so that it can facilitate all of these things that are just floating around in our heads. And that's the thing that we are strongly opposed to, I would say, where really you want to be thinking, at any given moment, do we tell what needs to happen for the user and how do we facilitate that happening rather than how do we create a really, really slick pseudo-object that has a bunch of different screen states that people can pay money to access?

Yohann (00:31:18):
Right. And what needs to happen is a great place to start. That's where the zooming in begins. So your critical pathway is almost like version one that you start with.

Samuel (00:31:32):
Yeah. It's the biggest, if you think of the... If we're saying that getting from point A to point B is a change and that that change is made of changes and the changes are made of changes, then that forms a sort of hierarchy where you wouldn't be grasping the handle of your ax if you were trying to turn the tree into lumber, because that's totally irrelevant at that stage. Doesn't make sense temporally at all. And so the idea being that you want to have a general idea of, how do we choreograph the smaller actions so that they can all contribute to the bigger changes that all then roll up to contribute to the ultimate point A to point B change that we're talking about?

Samuel (00:32:22):
And as an organizing principle, having a general sense of hierarchy around, "Well, wait a minute, why is the person putting on work gloves again?" Knowing what's happening in that process... This is not the best example. I wish I had come up with something different, to be honest, but this is what we're rolling with here. But having a sense of why the person is doing what they're doing in pursuit of what sort of situation is something that your product should always have in mind. It's waking up in the person's computer, "Whoa, you summoned me to you. How can I be of service? What would you like to happen?" And getting any sense of what the user's current state is and being able to guess based off of that, what their desired state is, and then creating a system that at least accounts for the most basic, most critical, most important changes that happen in between seems pretty common sense to me.

Yohann (00:33:23):
Now I'm thinking of apps as living inside objects that you have to rub in order to get the app genie to come out. Rub my water bottle and a genie pops out and he is like, "Ooh, did you drink enough water today? Here's my interface."

Samuel (00:33:43):
So the idea here being we've established the concepts of point A and point B, which we also call the starting point and the resulting point a lot of times. And the idea that there are a number of changes that happen in between and that those changes are made of changes. And so to me, the really important question once you get to this level of granularity is, does the order in which the things happen have its own logic to it? And this is a term that we've referred to in the past, in past episodes as "compounding sub-outcomes", where we're saying, we're not just building our theory around what all the cool things that we think could happen between point A and point B. And we're not even building our theory around just the things that we know have to happen between point A and point B.

Samuel (00:34:30):
But how do we know the order in which things should happen given a user's current point A and desired point B? And knowing where they're at right now and knowing what the next step should be and why that should be the next step and being able to communicate that to the user and say, "We know that you're trying to get to point B, and in order to do that, point A2 is the next thing to do to get there." And you hopefully should be able to explain that in a way that is clear to the user and sets a context where they go, "Oh, I can see how this helps me get to where I'm trying to go. I will proceed volitionally doing this," rather than, "You're just telling me to tell you how many employees work at my company has nothing to do with what it is that I'm trying to do. And I'm just moving forward in a pure compliance standpoint."

Samuel (00:35:34):
You want to be sequencing these actions almost like a dance that gets people from where they currently are to where they want to be, not a clunky set of interfaces that imposes its own artificial sequence of stages by the, probably the fact that it was not designed with getting people from point A to point B and breaking that process down as much as possible in mind.

Yohann (00:36:02):
And from a design point of view, an artificial sequence is way harder to design, because if you look at your product as a blank canvas where anything is possible, then there's so much pressure on you to figure out how things on that blank canvas make sense for a whole bunch of different situations. You don't know the order in which people are working through changes so you just have to clump them together and hope that they make sense. It's so hard to design a canvas where anything is possible. It's much easier to design in steps. It's much easier to say, "Okay, and then this needs to happen and this screen is going to facilitate this one action." Instead of, "There are 10 people who are going to visit this and they all have different goals because our persona sheet says so, and I've got to put 15 different things that you can do here and somehow organize it in a navigation that makes sense."

Samuel (00:37:06):
Right, right. And just, good luck. That's the message that's sent to the users. Enjoy figuring that out yourself because we have not taken the time to do so on our end.

Yohann (00:37:19):
Yeah. So it's hard on you. It's hard on the user. And being intentional about the sequence is just easier for both parties.

Samuel (00:37:29):
I concur. And you can see it in the way that a lot of product experiences are currently set up. Like I have been studying user onboarding forever and there are so many times where like, let's say, I'm just going to use Blue Apron as an example. I've never used them before so that's total just pure just common point of reference here. No claims on their design. But I imagine that part of the value proposition of Blue Apron is that I can go there and I can indicate my culinary preferences to some degree and then I will receive physical food in the mail that I can then assemble somewhat easily into a dinner. Is that your understanding of the value proposition too?

Yohann (00:38:15):
Yes, it is.

Samuel (00:38:17):
Okay. And so if you think about, let's say point A is somebody who's the combination of situational characteristics is that they're tired of cooking for themselves or maybe they live in a household who's the person who usually does the cooking is leaving for a two-months vacation and they want to find something else. I don't know the ins and outs of their business, but there's somebody who wants the service that Blue Apron offers. And we know that there's a point B where they are enjoying, let's say at least their first meal that has been provided by Blue Apron. And if you think about that process — what are the things we've got to get people to go through in order to radically increase the likelihood that more people who are in the situation where they desire something that Blue Apron offers are getting to the point of actually enjoying their first meal with it?

Samuel (00:39:17):
And if you start and you're like... Especially knowing that the early stages are among the most important, because that's when the trust is the lowest, that's when the lock-in is the lowest, that's when people are just feeling you out and seeing if you're actually going to be helpful or not so you're losing a lot of people. So the stuff that happens later is not even seen by the vast majority of the people who sign up anyway. So you're thinking, "All right, how do I really kick this off well? How do I set this whole process up for success?"

Samuel (00:39:46):
And then there are products out there, again, not speaking directly of Blue Apron, who would kick that off with like, "Let's do a survey. Tell us more about yourself." I can't tell you how many times I've seen people start the relationship of somebody who just signed up for their product with, "Tell us about yourself. Tell us more about you. Let's start things off with that." What a nice continuation of the value proposition that is. And then they got to jump through a bunch of hoops so they can answer questions that ultimately decide whether the sales people are even going to reach out to them or not. And then finally are dumped into a dashboard that's got like 20 different tool tips and hotspots going everywhere. This is not generally the speaking the way that you would start off on the right foot when it comes to trying to increase the likelihood that people are going to enjoy at least one dinner from you.

Samuel (00:40:41):
I got on a little bit of a rant. Anytime onboarding comes up, it is a dangerous subject with me. But the basic idea being that if you look at the process, your own product is oftentimes inserting hurdles for the users to overcome en route to the desired outcome that your product is ostensibly supposed to be helping them get to. And so the idea of clearing the way for them as much as possible, understanding what they're trying to do, framing it in a way that's not, "Tell us about yourself and let us know if we should bother selling to you," really, really surgically think about how you're starting things off so that you can make it more likely that people survive that initial flake out period and actually want to persist through all the other steps that are involved and actually wind up getting the dinner and cooking it and getting to sit down and eat it.

Samuel (00:41:38):
And so from a Path Design perspective, looking at the sequence of steps that are required for a user to get to not only in the bare bones critical pathway we know this has to happen in order for them to be eating dinner kind of sense, but also looking at the steps that you require as part of your process and knowing that people have to go through your account creation process and pick a password. And maybe you're asking them to invite friends before they've even seen it. There are all of these steps that well-meaning product teams, marketing teams, sales teams, et cetera, insert into the very beginning of these kind of processes that actually hinder people's ability to move forward and results in a decrease in the likelihood of people actually getting to the desired result.

Samuel (00:42:34):
And so not only do you want to fit your entire experience around getting people from point A to point B, but you also want to make sure that whatever the steps that are included are, are not one-sided, exploitative steps. That they actually exist to help propel the user forward rather than acting as ultimately an obstacle course. So from a Path Design perspective, we ask questions like, "Is this step actually contributing to the user's ultimate goal? Is it being framed in a way that lets the user know that this is contributing to their ultimate goal?" If not, if no to either of those questions, can we just get this step out of the process entirely? And if we can't, can we at least delay it as much as possible so that we have more people surviving that early flake out period as we can and we have in theory more relationships that we can nurture to get them to the point where they're getting to eat the dinner that they want?

Samuel (00:43:33):
So, can we remove the steps? Can we delay them? Can we reorder them so that it makes more sense to the user? Can we nest them in some sort of hierarchy that helps paint the bigger picture of why doing this one granular activity is going to help contribute to getting to the bigger activity, et cetera? And that's really the heart of Path Design. But it sure takes a lot of discussion just to be able to even start exploring that terrain, just because these are concepts that we have tended to find are just really not represented in the design literature, so to speak.

Yohann (00:44:12):
So we've talked about identifying your resulting situation, identifying your starting situation, and then as a next step, thinking about what necessarily needs to change between those two points, and then designing your sequence of actions around those points of necessity. I think it's a good time to talk about how you actually come up with those necessary change. Some vocabulary that's been really useful as I've gone through this process is thinking about causes. And I know it's a new term to throw in the mix. So far, we've been talking about changes and outcome and situations and now throwing a new word into the mix can be pretty confusing. But one exercise that we typically do once we have identified a resulting situation that we are interested in is laying out the characteristics of that resulting situation. Can you walk people through how we do that, Samuel?

Samuel (00:45:27):
How do you get clear on the desired end outcome? One example I can give is I was thinking about the process of grilling steak on a charcoal grill. And what I imagined was let's say that I am sitting down at my table. And if I want to go from that current situation of desiring steak to the outcome, the point B situation of having delicious charcoal-grilled steak for me to eat, of course, that's going to require a ton of different, just obvious changes in between. I know I'm going to have to go get some steak, I know that I'm going to have to start the charcoal grill. I'm going to have to put the steak on the grill. I'm going to have to so on and so forth. There's all kinds of different things that would have to take place in order for that to happen.

Samuel (00:46:21):
But instead of going in and just listing all of the different things that could happen or should happen or might happen while going through that process, I was like, "I should get really, really, really clear on what the end outcome that I'm trying to generate is, and then reverse-engineer everything from that. And so what I imagine was I'm sitting at a table, this is point A. Point B is I'm sitting at the table with the delicious steak in front of me. And there are particular conditions that are different in that point B.

Samuel (00:46:56):
This is embarrassing, but it's true, I imagined the... I don't even know if I've told you this, Yohann. I imagined Rosie the Robot from The Jetsons for some reason. And I was like, if Rosie the Robot were to go through the whole process of grilling a charcoal-grilled steak for me and get me directly from point A to point B without my involvement at all, what would Rosie do and how would I be able to tell whether Rosie did a good job or not?

Samuel (00:47:24):
And so I imagine... there were initial models that I had that accounted for the fact that I knew that I needed steak to be involved. There had to be a steak, but if Rosie came back with the steak raw, then that's no good. Or if it's raw on one side, then that's no good. Or if it's overcooked, then that's no good. Or if it's perfectly cooked but it's not served on a plate, then that's no good. And eventually, I got clear on like, well, what are the aspects where if I... What's the least possible I could describe about the reality of the point B situation where I wouldn't say "No, no, no, Rosie, go back. You have to sear both sides of this steak," or whatever. I don't know why this is so funny to me.

Samuel (00:48:10):
But so the idea is eventually I came to a pretty clear list of what the characteristics of a grilled steak that I would be able to sit and eat immediately would be. And then I tried to figure out how to go from maybe not even having steak in my possession to every single step that I would need to go through in order to create that combination of compounding actions that would turn me having no steak, into me having steak, into me having a hot grill, into me having steak on the hot grill, so on and so forth, all through all the different steps that my theoretical Rosie the Robot would do.

Yohann (00:48:56):
So in this case, the difference in situation that you were pursuing had to do with the steak. And so when you were trying to articulate that difference, you articulated characteristics of the steak, right?

Samuel (00:49:23):
Yeah. And so what I ultimately wound up with was not just that there had to be steak present, but that it also needed to be at a particular temperature and needed to have different conditions like it being on a plate and it having both sides cooked to a particular degree. And I personally like to have salt and pepper as the seasoning on my steak, so also having both sides of the steak seasoned with that. But even in this case, that's an interesting example.

Samuel (00:49:58):
Kind of like the balance bike example that we talked about in the past episode, where when I'm grilling steak, I put the salt on before I put the steak on the grill so that it can absorb into the meat. And then after it goes on the grill or after I take it off the grill more specifically, that's when I put the pepper on, because if I put the pepper on before it goes on the grill, then the pepper would burn and it wouldn't taste as good. So just the getting the sequence of changes correct can have a major impact on the success of arriving at that end outcome or not.

Yohann (00:50:35):
And the way you up with the critical pathway is to look at each of those outcome characteristics that you care about, that if they weren't present, you would tell Rosie to get out of here.

Samuel (00:50:51):
Right. "You messed up, Rosie. It's back to the drawing board."

Yohann (00:50:58):
So you'd look at -

Yohann (00:50:59):
To come up with the critical pathway, what you do is to look at each of those outcome characteristics, like the char on both sides, and to think about what causes this characteristic to come about? The saltiness-

Samuel (00:51:15):
Right. And then figuring out when in the timeline that that particular change should happen too.

Yohann (00:51:21):
Right. Right. This amount of pepper, what causes that? This amount of salt, what causes that? Does it need to be marinated or not?

Samuel (00:51:29):
Yeah. And "when" causes that.

Yohann (00:51:32):
Yeah. And when causes that. So what you're doing is you're looking at the outcome characteristics thinking about what causes those characteristics to be, and then structuring those causes within a flow between point A and point B.

Samuel (00:51:56):
Yeah. Do you remember, this was back when people were like, "Can you believe the internet?" But there was a guy years and years and years ago who traded a paper clip on Craigslist for a house. Did you hear this story?

Yohann (00:52:12):
No, I have not.

Samuel (00:52:14):
So you know what Craigslist is, right?

Yohann (00:52:16):
Yes.

Samuel (00:52:17):
All right. So he trades... He became a media sensation because he used Craigslist primarily to trade a paper clip up to something slightly more valuable than a paper clip. And he's like, "I'm going to try to keep doing this until I get a house." And then so he traded the paper clip to somebody for a pen. And then he traded the pen to somebody for... This is speeding things up, but like tickets to the Super Bowl. And then he traded tickets to the Super Bowl for one year rent in somebody's apartment. And then he traded one year rent in somebody's apartment for getting the speaking gig in a big budget Hollywood movie. And then he got to trade that blah, blah, blah, blah, blah. He trades all this up and eventually he gets to trade something that's roughly the equivalent value of a house for a house and he succeeds in doing this.

Samuel (00:53:09):
But he had to take each individual upgrade along the way. He couldn't just go straight from paperclip to house. Or again, I used the example Minecraft in the past. But when you're crafting something in Minecraft, you start with the raw ingredients. Like, I don't know, like wool and leaves, I guess, or things... My son's going to be so embarrassed -

Yohann (00:53:38):
I wish I played Minecraft so I could help you out.

Samuel (00:53:43):
But you start with these raw ingredients and then you put them into different combinations to create different, more complicated objects. And then you can take those... Like, you can take a piece of wood and then you can turn that into a plank of wood that you turn into an ax by adding a blade to it, or a rock to it or whatever. And so you take these primitive materials and you upcycle them into more complex things. And then you can take different combinations of the more complex things and you can upcycle those into even more or complex things.

Samuel (00:54:17):
And that's what we're talking about, when you have like a nice, salty, peppery crust of a steak, what were the, almost on a chemical level, processes that took place to get there? And how do you arrange reality in the proper choreography of actions to arrive of at that result as well? It no more complicated than like following a baking recipe, but there's definitely an element of temporality there where you don't just throw everything into a bowl and then put it into an oven for an hour. There's a sequence of events that has to take place for you to wind up with a birthday cake or croissants or whatever it is that you're baking. And the order in which you adapt the ingredients is as important or more than the ingredients themselves.

Yohann (00:55:10):
You know how complex all of this stuff is sounding as we talk about it, it's reminding me about the difference between "catching a ball" and the "physics of catching a ball".

Samuel (00:55:24):
I have no idea what you mean. Please continue.

Yohann (00:55:28):
I will explain. You don't need to know anything about mass or gravity in order to catch a ball. And we're constantly making paths for ourselves as designers and users of stuff to get to outcomes that we care about. We create paths for ourselves and organize reality on the go all time. But we are talking about the theory of making that happen for someone else, and that's like the physics of catching a ball. You're dealing with differential curves and meters per second and velocity per minute or whatever. And the theory of it is just so different from something that comes so naturally to a toddler, even, which is, catching a ball.

Yohann (00:56:19):
The depth of complexity at which we're talking about this stuff reminds me of that. When you're trying to teach, when you're trying to lay out a procedure for a robot to catch a ball, something that's so intuitive to you becomes such a complex problem to solve.

Samuel (00:56:38):
Right. And in order for the products that we create to have experiences that feel intuitive, we need to be thinking through that process so that it resonates on that level.

Yohann (00:56:49):
Right, right. So that it has the intuitive that would come naturally to a process that they would've created for themselves.

Samuel (00:57:02):
Exactly. We try to be augmented second nature, I guess, in a way.

Yohann (00:57:10):
I love that example that came up on a client call. You talked about your son playing a video game. Do you remember this? Can I tell the story?

Samuel (00:57:22):
Sure.

Yohann (00:57:25):
So when Samuel's son was really young, he saw Samuel playing a game and was really curious about it. And Samuel was like, "Here, why don't you come and try this game out for yourself?" And so he did. And as he was going through the game, he said, "This game is making me so smart," or, "I'm so smart in this game." I forget the exact words. What were his exact words?

Samuel (00:57:51):
It was, "I'm a fast learner a lot in this game." That was... I remember being like, "This is the goal of UX."

Yohann (00:58:03):
I love that. It's such a great story. And it's essentially what we're trying to create for people and why we're getting so complex about, what are simple things that we do every day?

Samuel (00:58:17):
And one nuance in the story that you just mentioned is that it made my son feel like he was the fast learner, that it was an accomplishment that he was making, because that's why you play games, for this vicarious thrill or this feeling of accomplishment, or you can psychoanalyze that until the cows come home, but you do it for some sort of positive feeling. And he was able to achieve that for himself, quote unquote, in a way that brought him a lot of joy. And in a similar way, we want to be obsessing about these timelines that the users are on, not so that we can rigidly force them through a railroad kind of experience where they... Where that's like the Clippy experience where it's like, "Hey, it looks like you're about to write a letter. Do you want me to help you how to figure out how to format the reply address," or whatever?

Samuel (00:59:16):
Not hijacking the experience and trying to force people to go through something step by step, but deeply, deeply understanding the actual order and sequence of what needs to change and when so that you provide the user with the appropriate tools and expertise for them to feel like they're making progress, not so that they are complying with one out of 10 gamified steps that you have inserted into the experience, whether it even claims to be relevant to what the user's trying to you or not. You're looking to give them the materials to support their own autonomy and self-actualization; you're not trying to impose that on them.

Yohann (01:00:04):
Well put.

Samuel (01:00:06):
Well, thank you very much, Yohann. With that, I think that we are probably at about time. Is there anything else that you feel like we should definitely cover here?

Yohann (01:00:15):
No.

Samuel (01:00:16):
Okay.