« All Episodes

Season 1, Episode 1:

"What is Value Paths, and why should I care?"


Apple Google Spotify Overcast RSS

Episode Summary

In this episode, we talk about how to generate the key outcomes for both your users and your software business.

Your users are on a path of pursuing value, and they're recruiting your product into it. Your business is pursuing value too, so we help you align both processes like chocolate and peanut butter.

📚  References

🔤  Transcript

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

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

Samuel (00:29):
And today our episode's theme is What is Value Paths and Why Should I Care? And if you happen to have caught the last episode, we started by talking about how the podcast was originally branded under the auspices of self-serve revenue and how we've been working on a growth framework that internally we've been calling Value Paths. And we thought that if we could couch it in a context of self-serve revenue it would help as a way to translate our thoughts to within a context that made more sense for people. But what we found was that self-serve revenue wasn't an inherently super meaningful term for many, many people and so we decided let's just call it by what we call it and so we're just calling it Value Paths and we're moving forward with that as the context instead.

Yohann (01:18):
And we begin with what Value Paths is.

Value Paths vs "Traditional Product Design"

Samuel (01:22):
Right, what is Value Paths itself? Value Paths is a growth framework that you and I have been working on for the last few years where there is an emphasis placed much more on user outcomes, rather than the design emphasis being placed on product features and characteristics. Is that a fair high-level summary?

Yohann (01:48):
Yes, fully agreed. Can I follow up with a question?

Samuel (01:52):
I love questions, of course.

Yohann (01:54):
Aren't product features on products already accounting for user outcomes at the moment. How are they thinking about outcomes differently right now?

Samuel (02:07):
How are they in the sense of traditional product management and traditional UX looking at the software and software user fit issue differently than we are, is that the question?

Yohann (02:21):
Yes. Yes, that's the question.

Samuel (02:23):
The contrast that I would draw here would be that in traditional user experience design it is always... To be totally blunt I think a lot of times, empty gestures toward the value that users can get out of a product or the outcomes that a user could derive from product usage, but are not really serious about actually delivering those particular outcomes. Where in traditional methods have things like personas and user journeys where the user's goals and the value that they're getting out of a product is all kind of murky and hand-wavy, where maybe different personas have different goals, but are you really actually tracking in your product - How many people who are seeking that particular outcome are actually getting there and are you tracking whether that outcome has any kind of correlation with people being better customers, either having a higher LTV or lower churn percentage or things along those lines, kind of the same concept there.

Samuel (03:33):
But generally speaking, are you understanding the causal motivations within the person's psychology or the context of their situation that's driving them to use your product and what those outcomes that they're seeking your help with attaining are so that you can align your product experience around the attainment of them as reliably as possible, rather than aligning your product experience around being a product.

Yohann (04:08):
Right. And approaching it in this way means making some fundamental changes for how you see your product to begin with.

Samuel (04:20):
I imagine so. I think that a lot of times people when they think of, you could say some sort of Hallmark card platitudes, delivering value to our customers is our number one goal or our company's growth is driven by delivering user value. Which, if you said that in a conference talk I don't think anybody's going to stand up and call you a liar, it sounds like a pretty plausible thing. But at the same time if you look at how we approach product from a research standpoint, how we approach product from a design standpoint, how we approach product from an analytics standpoint, those are really not diving into a rigorous study of which outcomes are actually taking place and which are being desired most frequently and which of those outcomes correlate most closely with revenue, et cetera.

Samuel (05:23):
I think that instead we like to focus on the "thing that we're making" which for a software company they might think of their offering as being a mobile app, or a website, or a SaaS offering, or something along those lines. But what you're saying, I think, way back when you were talking, apologies for this rant, but what I think that where you're getting at was that you're looking at the offering that you provide to your customers in a fundamentally different way, if you think that your offering and your value is access to your product, versus if you think of your offering and your value as a reliable means for attaining the results that you're seeking. It's a very, very different paradigm.

Yohann (06:14):
Right. What you're building is a way, what you're building is a path, and the product is just one of the many things on that path between... One of the examples you use all the time is making pancakes. Getting from no pancakes to having pancakes is a path that requires a whole bunch of different objects, skills, actual physical places, and to, if you're in the business of making pancake mix to think even for one second that with pancake mix you're able to get people from having no pancakes to having pancakes. That's just wrong.

Samuel (07:11):
The idea being that in our software metaphor - here the users or the customers of the pancake mix don't get value from the pancake mix inherently. The characteristics of the pancake mix that make it valuable are only assessed within the context of how well it turns into pancakes in the end, if that's what you're using the pancake mix for, which would be an operating assumption, I would think for a pancake mix company. The idea being that the pancake mix company's expertise doesn't need to be in creating the world's best pancake mix or the platonic ideal of all of the characteristics that make the best pancake mix. What they really want to do is make a process of arriving at pancakes as straightforward as possible and provide the user with the expertise and resources that they need to be able to pull that sequence of changes off.

Samuel (08:09):
You got to take the pancake mix and then mix it with water, and then it becomes batter, and then you got to stir the batter around. And then you got to pour the batter onto a hot griddle but which you had to heat previously, which usually means turning on the stove. There's just a million different things. You've got to flip the pancake, all these different things that you got to do to get to just turning pancake mix into pancakes. And in the software world, I think that we get overly caught up on wanting to make the finest best pancake mix and really neglect the pancakes that are resulting from that pancake mix instead. Fair?

Yohann (08:47):
Right. Yep, that's fair. And for you folks sitting at home...

Samuel (08:54):
Or wherever are. You could be on the commute, you could be biking, we are not prescribing that you have to only listen to this at home. But home or wherever.

Yohann (09:02):
Yeah. Home or wherever you are. If you have been thinking about customer outcomes and customer value and these are familiar terms to you, you have to ask yourself the question of what that actually means, to what depth does that thinking go and recognizing the process is a huge part of this. So to what extent do your company systems, to what extent do your business systems recognize the context and situations that users are bringing to your product, and the contexts and situations that help them recruit the product into making outcomes that they care about, happen?

Samuel (09:59):
Yeah. You want to sync up your product states with the user states and you want to recognize what kind of situation they're in and be able to anticipate what kind of situation they're trying to recruit your expertise into helping them attain and align your experience around helping them do that, in the same way that you would look at your conversion funnel and say, "Well, we're getting this many signups that turn into this many trials, that convert into this many new customers, and we retain them for X long or whatever."

Samuel (10:30):
You can think of it in the same way but think of it from the user's perspective, where if you're the pancake mix company, how many people are we losing at the step where you make the batter? How many people are we losing at the step where you pour the batter onto the griddle? How many people are we losing at the step where you flip the pancake? So on and so forth. And you want to see that all the way through so that you can diagnose the "conversion funnel" of the user's pursued outcome that is driving the relevance of this entire engagement.

Yohann (11:00):
And it can have outsized impact on business value too, that's the point of this. The point of this is not to think of user value in a vacuum, it's to tie user value and business value together. For example, if you, as Samuel said, by tracking these different steps that from the user's perspective they're going through to actually get pancakes. If you discover, for example, that a majority of the people who pick up your pancake mix don't have spatulas at home, if you sold your pancake mix with a spatula, there'd be a huge number of people now equipped to actually get the results that they recruited you into their lives for.

Samuel (11:49):
I'm going to steal that example, that's a really good one. Did you just come up with that off the top of your head?

Yohann (11:57):
Off the top of my head.

Samuel (11:59):
Damn good. Nice one, Yohann. Okay, so totally agreed. I think the spatula example is a really good one because you're basically saying, "We are now selling to... We're expanding our market beyond people who already own spatulas." Anybody who doesn't have a spatula already, maybe they're camping, maybe whatever, if you want to expand your market and you're saying, "Okay, we are only letting you into our club through the front door, with the velvet rope or whatever, you've got to have a spatula in order to be our customer or." Or you can make some subtle product changes, maybe part of the cardboard box is perforated and it pops out, and that would be a really terrible spatula, but something like that maybe, who knows?

Yohann (12:46):
Right, right, right.

How Value Paths takes JTBD-type thinking even further

Samuel (12:47):
But another crucial component to this, because I imagine that people listening wherever they may be are thinking this sounds like Jobs to Be Done. There's been a little bit of snake oil in that realm, do we really need another named framework? What's the new idea here, really? And I would say that the contrast... We've already contrasted Value Paths from traditional UX and traditional product management. And the way that I would contrast it from Jobs to Be Done, if people are familiar with that, we should probably talk about Jobs to Be Done in-depth at some point but I don't think that time is now. If you already are familiar with Jobs to Be Done, I would say that the distinction is that Jobs assumes that there's a product and that you are trying to find the compelling contexts in which that product is hired into different Jobs.

Samuel (13:45):
And a lot of times when I see Jobs To Be Done put into practice, there might be some research but it's very consumption-oriented and it's really focused on the point at which people decide to become customers and not so much focused on how do you troubleshoot the entire process of actually fulfilling the job. Which is kind of ironic to me, but that's really where Value Paths focuses in saying, "Since we have digital software, we can track how far people are making..." If you're making pancake mix you don't know how many people you're losing at the flip the pancake stage, but if you are offering a digital product, you know exactly where your cohorts are falling off the most and churning out the most from one step to another to another.

Samuel (14:28):
All of that is just information that's just sitting there, so to not even be looking at it, which I would say the vast majority of companies currently are not, it doesn't make a lot of sense. Especially, if these powerful methods are only really being leveraged by gigantic corporations like Facebook or whatever to try to screw you out of all of your attention and sense of empathy for people or whatever. No offense to Facebook. Well, I guess a little offense to Facebook, but not to... I don't know. I shouldn't have said that, but anyway. Roughly correct?

Yohann (15:02):
Yeah, roughly correct. And there's just one small thing I would add. Jobs To Be Done, the way I've experienced it says, "There are things that you can control and there are things that you can't control, but keeping the reason that people are coming to you in mind will help you execute the things that you can control better." And one of the things that you can control is the product. If you think about the reason people are using the product, you can build a better product.

Yohann (15:34):
But what Value Paths is bringing to the table is that there's really no distinction between the things you can control and the things you can't, there's just the process. And the more you understand the causal lines between the process, the more you can design for the process rather than just making a better product. Adding a spatula to the pancake box doesn't change the quality of the pancake mix, it just adapts to the process a little bit better.

Samuel (16:10):
It makes it fit into the timeline more seamlessly.

Yohann (16:14):
Right, exactly. Exactly.

Samuel (16:16):
And I think that's a good way of summarizing it, whether we're talking about Jobs To Be Done or traditional product design approaches, or things along those lines, that really what Value Paths focuses on more than anything else is distinguishing from designing within terms of space like how wide, what's the aspect ratio of the rectangles, and are we using this sort of grid layout or these final wire frames, or what does the main navigation look like?

Samuel (16:46):
All of the spatial 2D or 3D characteristics of the product really de-emphasizes those and really emphasizes the time side of things. We're not as concerned about the spatial elements, we're more concerned about what is the sequence of actions that needs to take place in order for the user's original intents to be fulfilled and how valuable are those different intents and how reliably are we delivering on those intents, rather than how can we use this as inspiration to come up with a better composition of rectangles or whatever that maybe. Fair?

Yohann (17:25):
Right. Fair. And how granular can your support get? Because at the moment if you have three steps between, again, going back to the pancake example, if you're seeing the process between not having pancakes to having pancakes is three steps, going to the store, one step, picking up pancake mix, second step, actually making the pancakes, third step, you wouldn't be wrong, but you wouldn't be right either because there are so many invisible steps between each of those that you're not accounting for.

Samuel (18:03):
Hidden spatulas.

Yohann (18:06):
Hidden spatulas, yeah. The more granular you can get with your support, the better you're actually equipping the users as they go through this process of making pancakes.

Samuel (18:21):
Right. And I guess that's where we would also take issue with traditional user journeys, where it's a poster of the top six things that the company wants the user to do. And a lot of times that format is criticized for being overly simplistic and company-centric or wishful thinking, I guess. Instead of using that as inspiration to go make better compositions of rectangles, use that as the framework to dive deeper into all the nooks and crannies of what is really involved in pulling that process off.

Yohann (18:58):
Right. Because every time you think it's a 2-step process it's actually a 10-step process and there are 8 steps that you're not seeing right now that have to be performed.

Samuel (19:07):
And if you leave it up to the user, bad idea. Anytime that you're like, "Up to the user," they will figure this part out, that's what you want to avoid. You want to be filling in those gaps with support. All right, I got to put a close to this conversation because we have not even gotten to our main points yet, so I anticipate this will be a long episode either way, but in interest of listener service let us move on to our exchanging of the prominent concepts.

Yohann (19:35):

Samuel (19:37):
And thus far two episodes in, you have been the first concept offerer both times. Would you like to kick us off again?

Revenue isn't a team metric, but should be

Yohann (19:45):
Yes. You should care about Value Paths if there's a disconnect in your company between user value and business value. One thing we've noticed, and this has just been confirmed a number of times, as I've talked to a large percentage of you as a part of the growth research we were doing recently, is that business value is like a C-level consideration and user value like the granular, 'what should the screen look like for users to actually get value' is a practitioner, individual contributor kind of consideration. And there's a huge disconnect between the metrics that teams and individual contributors focus on and metrics that the C-suite or the board focuses on. So...

Samuel (20:45):
And also that maybe some shaky logic as far as the causality between the two as well.

Yohann (20:51):
You're right.

Samuel (20:53):
For example, if you had an invoice-sending app and you knew that user value came in the form of people successfully sending invoices, those invoices getting paid, understanding of the different reasons why people are trying to get paid or the different conditions in which they're trying to get paid more quickly or whatever, those would all be Value Paths-centric considerations. But what we see in the wild is they're not thinking about it in terms of how can we get more users to this very specific outcome that we understand inside and out and more like, how do we just keep mashing users into our product via engagement hacks, and how can we bring up our Day 20 retention even if there is no demonstrable correlation between Day 20 retention and revenue other than the fact that obviously the people who stick around longer are more likely to become customers.

Yohann (21:48):
Right. That logic not withstanding,

Samuel (22:13):
Completely agreed.

Yohann (22:17):
That's one big reason to care about Value Paths. Should we talk about how Value Paths solves this problem?

Samuel (22:23):

Yohann (22:25):
Okay. One of the big reasons I've heard for revenue to not trickle down to the team level is it's kind of a lagging indicator.

Samuel (22:37):
Revenue is?

Yohann (22:39):
Revenue is. You don't know whether your product efforts have resulted in more revenue until much later, until users have had a chance to experience those product changes and then you can track those, and then you can track the impact of those product changes on revenue, sometimes even months down the line. And what we mean when we say that Value Paths is a method for doing, and whether you're tracking outcomes and how you're aligning business outcomes and user outcomes, is that Value Paths turns revenue from a lagging indicator into revenue as a leading indicator.

Samuel (23:21):
Completely agreed, Yohann. I am glad that we started off with that point. I think that's a good one to kick things off with.

Yohann (23:28):
Okay. Over to you, Samuel.

Samuel (23:32):
My top reason, or one of my top reasons for caring about Value Paths is because, I am not saying this to be scandalous, and I am not saying this to just be dismissive toward the work that has been put in to build the foundation of how we approach design in general, but to be completely honest as a user experience designer with over a decade of user experience, I guess, I think it's a waste of time, to be honest. I think that thinking of your company's offering as a product is a really limiting paradigm to begin with as we've already covered. And I think that user experience similar to the aspect of Jobs To Be Done that you were talking about just a moment ago regarding how the product is assumed and assumed to be not something fully under the company's control or not the most flexible lever to be pulled. I guess you could say.

Samuel (24:46):
Where I think that Value Paths really questions that and says ultimately, the relevance and value of the product is only relevant within the context of the outcome that the user is trying to pursue in a given session or with their relationship with the product overall. And that if you assume that the product is the value, you're always wrong because the value is not determined, value is not something that you can stuff into a thing. And now we've made it five times more valuable.

Samuel (25:28):
You can't make a product more valuable because value is determined by the beneficiary, not by the provider of the resources. It's in the person's mind how they evaluate how valuable the experience is. I started a mailing list with Mailchimp and it grew and I was really happy with how it worked, or I started a mailing list with Mailchimp and it didn't grow and it was a waste of my time. Those people may be experiencing the exact same product but arriving at very different experiences and really it's that we're in the business of.

Samuel (26:07):
To use a quick example, my son, I was excited as a father to teach my son how to ride a bike. And when I was a kid we would use training wheels where you screw these additional wheels onto your bike so that you don't have to figure out the balancing part, you can just figure out the pedalling and steering part. And then when you're done with those, off come the training wheels and then you learn the balancing part and that usually involves falling down a bunch of times, getting scraped elbows and putting ice on it and things like that, and I was anticipating that being the case as with my son.

Samuel (26:51):
And instead he had a balance bike, instead of getting training wheels, which is a totally different configuration where instead of it being a bike with additional wheels added to it, it's a bike with the pedals removed. And so instead of focusing on teaching the kid how to pedal and steer and then learn how to balance, the child learns how to balance and steer and then learns how to pedal. And it was the funniest thing because as soon as we put him on a real bike that had pedals, I was ready to be following after him and helping clean the gravel out of his cuts and stuff, and he just took off, he just started peddling away. And it was the easiest thing for him to add that one additional component to his overall physical recipe of being able to ride a bike, and there were no scrapes or anything needed.

Samuel (27:45):
And so I say all of this to draw this back to the idea of traditional UX, traditional product management. If you're working at a training wheel company and you do user experience research and you realize that people should be learning how to balance before they learn how to pedal, how do you incorporate that into the features of the training wheels? You don't because the training wheels insist that there is a different process to making pancakes in the form of learning how to ride a bike. And it's paying attention to the order of the steps and being present with the right resources at the right time. That's most important rather than trying to make one really, really, really ultra good resource for every possible use case.

Yohann (28:31):
Right. Your offering is, in a sense, your construction of the path.

Samuel (28:41):
Yes, right.

Samuel (28:43):
But you're not trying to make a really good path, you're trying to more reliably generate outcomes. The value of the path is only valuable in so far as it generates the outcome.

Yohann (28:56):
Right, right, that makes a lot of sense. And that was a really great example of how-

Samuel (29:03):
Thank you so much-

Yohann (29:05):
... Learning to ride a bike doesn't necessarily have to be this process of cuts and bruises and falling down. Just by making a small switch up in the timeline, it results in better outcomes faster.

Samuel (29:24):
Right. And so, again, it's not a spacial concern, it's a temporal concern. You're coordinating the timeline, not coordinating the arrangement of any given asset.

Yohann (29:38):

Samuel (29:41):
Number three?

Yohann (29:42):
Number three. Okay, one big reason on my list to care about Value Paths is if you're even a little bit uncomfortable with correlation, it seems like correlation is the best we can do in SaaS at the moment. Because user behavior is not something we can control, the best we can do is nudge users to take the behavior that we want, this is the traditional thinking, by the way, the best way-

Samuel (30:13):
Yeah, I was about to say, this is evil-mustache-Yohann talking right now.

Yohann (30:19):
The traditional way of thinking is, we can't control what users do but we can nudge them in this way and that, and the more we nudge them in a particular direction the more they do the things that we want them to do. And we know that certain things are correlated with revenue, so if we nudge them towards those things then we will get more revenue at the end of the day. Is that a fair nutshell version of the traditional thinking of correlation and nudges at the moment?

Samuel (30:50):
Yeah. I mean, I think that the paradigm that people are working within is that they think that their value proposition is selling different levels of access to their product, where, pancake mix is not valuable unless if it results in pancakes and software is especially not valuable... You could at least take the pancake mix and take it back to the store with your receipt and get a refund or go sell it on the street to some other idiot who's going to take the terrible pancake mix off your hands. But if you have a software account what are you doing? What's the street value of that? You're not going to sell that on Craigslist. So what you have is valued at nothing until outside of what you get out of the software.

Samuel (31:36):
And ultimately if your software company realizes that it's in the business of helping users get outcomes and not in the business of offering "high quality software" or access to high quality software, the sooner it is in tune with the real driving impulses that are actually generating the behaviors that result in ''customerhood'' and subscription payments and the things that come with that.

Yohann (32:06):
Right. If that resonates at all and you're uncomfortable with the picture of correlations that you're drawing between engagement and revenue, then Value Paths is for you because it is very focused on causal lines and doing away with this whole picture of correlation. Because it's true, that user behavior is something you can't control, but it's also true that users have arrived at product because they're seeking a particular outcome. And if you can really design for that outcome, this is going to sound strange, but you can control user behavior because you understand what's driving users to begin with, if that makes some sense.

Samuel (33:01):
That makes a lot of sense. And I would say from a paradigm standpoint, another big difference is that the interest or the goal is never to control the user's behavior or to coerce the user into doing what you want. The goal is to create an offering that is so good at helping them get what they want, that it's a no brainer for them to generate the value that you're looking for them to reciprocate. You want to make it a really good deal for them.

Samuel (33:32):
A lot of times, companies will come to us and say, "We want to generate habits. We want to get our users hooked," so to speak. And I think that if you are not paying attention to the basic performance of your value delivery mechanism and if you're not working from a really clear idea of what kind of outcomes are driving your users to become users and to become customers, especially, the last thing you want to be doing is getting people addicted to some product that you haven't even really tuned yet. The whole idea is to identify where you're losing people along the way so that you can scale your offering even better. And if you are trying instead to get people addicted to a product that's not useful to them, I think that that's just going to be a significantly worse strategy.

Yohann (34:28):
Great. If I can bring in a thought experiment here.

Samuel (34:34):
No thought experiments, please.

Yohann (34:38):
Imagine you're a lawyer and you're trying to figure out who's responsible for this woman named Coleen's death.

Samuel (34:52):
This is weirdly specific.

Yohann (34:55):
Really. Just imagine two situations. One, Coleen had a friend, Ben, and Ben poisoned Coleen's gin. That's a clear cut case. You'd be able to draw a clear causal line there. You know Ben's responsible for Coleen's death. Imagine another situation though, imagine Ben poisons Coleen's gin, but she notices it and she heads out to the store to buy herself a new bottle of gin and on her way back from the store, she gets hit by a car. Is Ben still responsible for Coleen's death?

Samuel (35:37):
What's your take?

Yohann (35:39):
My take is that... Okay, the point here isn't to have an answer. The point here isn't to have an answer, but what the thought experiment encourages is thinking about the difference between direct and indirect causes. In one case Ben was a direct cause of Coleen's death, in the other case he poisoned Coleen's gin and that set off a chain of events that resulted in Coleen's death. But would you actually throw the handcuffs around him? It's difficult to draw that conclusion. It's difficult to convict Ben based on the circumstances of Coleen getting hit by a car. I feel like revenue works a lot in the same way, in the sense that-

Samuel (36:33):
Let me make sure I'm following you, just to be sure, though. What you're saying is in that murder scenario A, there's more of a direct cause effect parallel than in murder scenario B?

Yohann (36:49):
Yes, yes.

Samuel (36:51):
And so, I guess, would you say that you would see Ben as a contributing factor either way but just less of a contributing factor or equal of a contributing factor to just a bigger, more complex unfolding of events?

Yohann (37:11):
Yes. In one case it's the difference between Coleen's death was caused by Ben and Ben killed Coleen. In one case you can clearly say Ben killed Colleen. In the other case the best you can say is Ben contributed to Coleen's death because she was hit by a car. And how this ties back to software is that we want to be figuring out what makes revenue, we want to be figuring out what revenue is a direct result of.

Samuel (37:51):
How do we get the poison in there nice and good.

Yohann (37:53):
Yeah. I used a dark example here and that led us down a strange path.

Samuel (38:01):
I think that evil mustache had an effect on you.

Yohann (38:04):
But my point stands. When you think about engagement, you're thinking about an indirect cause, you're hoping that more engagement will set off a chain of events that at some point will result in revenue, but what you want to be doing instead is figuring out what makes revenue happen.

Samuel (38:25):
Yeah. As we say, focus less on how much money you're making and focus more on how you're making money.

Yohann (38:32):

Samuel (38:36):
All right. Well, that is a convenient segue to point number four, if you yield the floor.

Yohann (38:41):
I yield the floor.

Net churn doesn't tell you WHEN users churn

Samuel (38:43):
All right. Convenient segue being that another reason to care about Value Paths is that your early churn, the amount of people that you lose early in your relationship with them or early in their account-having status is way worse than you probably think it is. A lot of people who have not taken a deep dive into their retention metrics might look at a high level VC sort of metric like net churn which just says from one time period to another, let's say one month to another, of the people who you already had, how many of those people did you lose. Either in terms of head count, like the number of users or in terms of revenue in the form of how much subscription money just walked out the door. Right?

Yohann (39:41):

Samuel (39:42):
And generally this net churn number is usually supposed to be hopefully somewhere in the 2 to 3% range. If you're down to 5%, that's not a great outlook or you would want to run your business differently based off of that. If you can get to 1% or 0 or the fabled fantasy lands of net negative churn where your user base is actually growing over time, that's the ideal. But either way, people churn at very different times in their relationship with you. If you're looking at net churn for the month of August, how many people did we have in August who we kept into September, and you're including your entire user base from people who just walked in the door five minutes ago to people who have been customers of yours for nine years, the likelihood of them turning are very, very different.

Samuel (40:43):
And generally speaking, the net churn number masks that complexity and it just gives you the overall performance of how big of a pile of users you have at any given moment, rather than giving you insight into the critical early stages, where you are just haemorrhaging the most amount of people. And it's true at several different levels of scale. If you look at monthly revenue, for example, if you have a subscription plan and you have people who are paying monthly versus yearly or whatever, if you look at how many people you keep from month one to month two, it's a bigger drop-off from month 1 to month 2, than month 2 to month 3. And then it's an even smaller drop-off from month 3 to month 4, and then it's even smaller from month before to month 5.

Samuel (41:34):
And then eventually, hopefully it either planes out or turns into what's called a smile chart where you have net negative turn and you're actually growing those users after you lost a bunch of them upfront. But even if you zoom in further and you say, "Okay, well just going from signup to paying the first month, where are we losing the most amount of people?" Usually, it's in whatever the early steps are. So if you have a series of steps where you have people confirm their email address and enter their credit card and invite three colleagues or whatever the sequence of things that you have people, and fill out a sales survey that somebody stuck into the onboarding experience three years ago and people forgot to pull out, whatever all that stuff is, you're losing people at every step.

Samuel (42:18):
And as a general rule of thumb, you're losing way more people in the early steps than you are in the later steps. And so to try to patch the holes in just haemorrhaging out the people that you're probably not even super aware of if you're paying attention to your entire user base, whereas you would be painfully aware of it and hopefully inspired to do something about it if you were paying attention to it on a cohort by cohort level, looking at it from each individual early step to the next.

Yohann (42:51):
That is a great point.

Samuel (42:53):
Yohann, back over to you.

Yohann (42:55):
We have actually covered everything that I wanted to say. There are a few more on my list but I think there was some overlap between our points and we've naturally covered them.

Samuel (43:06):
Or save them for the lightning round, more granular stuff.

Yohann (43:10):
Right. Anything on your list?

Your users deserve more thoughtful paths

Samuel (43:14):
I do. I have one more big point to make. Why should you care about Value Paths? One reason would be that your users deserve better, I don't say that to insult or offend. I know everyone's trying their hardest and I genuinely appreciate that, but at the same time I think that the foundations on which we are making product decisions are a little bit more 'emperor has no clothes' than we're really willing to be real about it. I think that not only does that lead to us wasting our time professionally, making higher quality, improving the user experience of training wheels rather than just pivoting into making balanced bikes for example.

Samuel (44:13):
I think in a similar way, our users are really getting screwed here too, or it's a waste of their time as well. Because if you think of it again from the perspective that every time someone uses something, they are seeking a particular situation or outcome, then it would make sense that our apps should try to care at all about guessing what that specific outcome is, so that the app can align its experience around helping the user get there. If the user is pursuing that outcome, there's no reason why you would want to give them the same one-size-fits-all experience that everybody else gets.

Samuel (44:57):
On a tactical level we're almost talking about personalizing by intent and customizing experiences and having different segments segmenting your user experience in a way. But it's not just a question of getting users to the outcomes through your own conversion funnel and making sure that they generate value for your business, which is a completely fair concern, but also taking genuine interest in upholding your end of the value proposition. If you're promising that people will get to work from a laptop on the beach with a coconut in their hand with an umbrella inside it or whatever, are you actually creating an end-to-end process that gets people?

Samuel (45:45):
Are you delivering the coconut? Are you putting the umbrella in it, or what is it that you actually do and how good are you at actually producing the outcomes that you are good for and how does a user sus that out? And how does the user tell whether a company is wasting their time or whether they're not? And one example that I really like to give is there's an app called Caviar, which is sort of a UberEats kind of a restaurant delivery service app. And -

Yohann (46:22):
Is it fancy? Is that why they call it Caviar?

Samuel (46:24):
No, maybe it was a little fancier, I don't know. That was just the name of it. But I remember using Caviar several years ago and there was a... When I say feature I'm using the term very loosely, there was a quality of the product, a feature of the product, where when you open the app for the first time it shows you the different restaurants that you can choose from and then you can go into the menus and place your order and so on and so forth. But then if you open up the app again, later, while your order has been placed, it doesn't show you a list of restaurants. It shows you the status of your order by default. There's a new default screen that it shows you when your account is currently in an order transaction.

Samuel (47:17):
Does this make sense? Like the-

Yohann (47:18):
Yeah, makes a lot of sense.

Samuel (47:18):
... Pizza tracker kind of a thing?

Yohann (47:20):
Yeah, yeah.

Samuel (47:22):
Okay, then contrast that very simple example, just having any vague idea of what do we know about the user and what is the most relevant stuff we can put in front of them, based off of our best guess of what they care about. I'm holding them up as a good example of that. Now we contrast that with an experience that I had with Airbnb, where I booked a registration and I downloaded the app for the first time on a new phone and I knew to pull up the instructions to the cabin before I drove out there in case I didn't have cell phone service and wasn't able to get in and didn't get the security code or whatever.

Samuel (48:04):
So I go to pull up Airbnb's app for the very first time on this new phone and it knows I sign in as me, I do the social sign-in via Google or whatever. It's loading up my account for the first time, and does it show me anything that's related to the listing that I am about to go check in to, it knows that I am on the day of check-in. It knows that I have an active listing. It knows that I am some physical distance related to the residence that I'm trying to check into. If I open up the app and it knows that I'm within 10 feet of the street address and it's the day of check-in and it's the time of check-in, why would you be showing me restaurants? You should be showing me the pizza tracker.

Samuel (48:55):
But instead in Airbnb's case, when I pull it up it's like, "Have you ever thought about becoming a host?" And it's just like all of this stuff that's totally irrelevant to what I'm trying to do. And it feels like Airbnb is making no effort and even just meeting me halfway and getting the help that I need in order to generate the value that their offering is supposed to be providing me with.

Yohann (49:20):
Right. And in this case it's not even an awareness of outcomes because they are aware of their outcomes. In this situation it's just a little more acknowledgement of the process that you're in at the moment.

Samuel (49:36):
Exactly. It's a question, again, like we've talked about of sequencing things and time and understanding what's most relevant to the user at different stages or when their account is in different states and designing for those states rather than designing a single state or solid state product that is a one-size-fits-all experience for all the users who come to it regardless of what they're trying to do in general or in a given session.

Yohann (50:09):
Right. Because if you make a really good product and you sell access to it, then only the users who are competent find value, only the users who are okay with figuring things out on their own find value. And all the users that aren't drop-off, get left by the wayside without support, through a process that maybe they're trying to figure out for the first time themselves.

Samuel (50:37):
Yeah. Conversion Rate Experts is an organization that I greatly admire. They're based out of the UK and do conversion rate optimization. And their metaphor is to think of your conversion steps as an obstacle course, and at every step in that obstacle course you're going to see different amounts of people getting tripped up on stuff. But the steps that you provide are not... It's not like if you turn your onboarding experience from five steps into eight steps then you've added three steps of value, you've probably subtracted value by making it more complicated. From that standpoint I definitely agree.

Yohann (51:25):
You need to be equipping all your users with things that they need to go through their process to value, to go through the stages of their process to value, rather than just giving the competent ones access to this beautiful tool that you've built.

Samuel (51:47):
Right. It's almost like if you imagine the user as a surgeon. Well, you ever see movies where there's a high, tense surgery and the surgeon's like, "scalpel." And they hold out their hand and then the assistant puts the scalpel in their hand and then they're like, "gauze," and the assistant puts gauze in their hand? The products that we create should have a sense of when the surgeon wants the scalpel and when the surgeon wants the gauze and to give the scalpel when the scalpel is needed and the gauze when the gauze is needed and to not just continue offering a buffet of options and keep adding more and more "functionality and features", when really, you just need help with the thing that you're trying to do that the app really should be able to know.

Samuel (52:40):
And when we talk about guessing what the user's desired outcome is, we call that internally desired triangulation, which is, I guess, cute. I mean, your app should give a shit about what its users are trying to do and it should try ultimately to be helpful in supplementing their experience of pursuing that outcome to the highest possible degree. But I mean, even just casually having any idea of why you might be pulling up their app at a given moment like in Airbnb's case I think would not be a bad place to start.

Yohann (53:20):
Kathy Sierra summed this up so beautifully when she said, "You're not trying make better cameras, you're trying to make better photographers."

Samuel (53:29):
Bingo. Shout out, Kathy, the OG.

Yohann (53:33):
Yeah. And if more people, as a user, if more people were invested in my becoming a better photographer, that kind of support would be invaluable.

Samuel (53:46):
Yeah, no brainer. You have competition of zero people, nobody's in the space of actually studying the outcomes that people are seeking and designing around even vague patterns, there really. I mean, I guess vague patterns, but if you want to approach it with any semblance of the scientific method or just rigor of curiosity, you quickly realize that it's significantly more complicated than it seems on the outer end, and that when we're designing products, what we're really doing - we're looking at compositions of rectangles and saying, "Oh, I don't know. Maybe the lorem ipsum should be under the image instead of above," or whatever.

Samuel (54:34):
But what we're doing, the reasons that we come up with the suggestions about the 2D space arrangement of the screen state, what we're doing is we're cranking through tons and tons of simulations in our head of, oh, what if somebody who was trying to do this came into this screen, or what if somebody who was trying to do this came to this screen? And we're just flipping through those like a Rolodex whether we're aware of it or not, as we're assessing the fit of the arrangement of screen components. But to talk only in terms of screen components and only make vague gestures toward what the users really want is just like inventing a game of telephone for no reason.

Samuel (55:18):
There's no reason to not be focused on reliably delivering the outcomes that drive people to be profitable customers for you and really considering the product that you have in place right now to be something that should not be a sacred cow and should be able to be adapted to any slice of the timeline to be the best fit Caviar don't-show-restaurants kind of ideas.

Yohann (55:52):
Right, right. Fully agree. I just want to remind everyone listening that we're just scratching the surface of all of these concepts here and kind of introducing the idea. And over the next few episodes we're going to dive into a lot more detail because this isn't just theory for us, this is something we live and breathe in our work at UserOnboard. And our projects are all executed a Value Paths kind of way, so we have a lot more to share, and if any of this sounds vague it's just temporary.

Samuel (56:30):
Hopefully, I guess. Or, I mean, if anything is vague and we don't have a good answer for it then we would love to become aware of that as well. So, any ways that you want to poke and prod or critique this perspective, by all means have at it, you cannot hurt our feelings. I guess, I always say that but I should really just speak for myself. Can criticism hurt your feelings, Yohann? Should I just limit it to me?

Yohann (56:56):
No, no, no. Include me in this, Samuel. Because-

Samuel (57:00):
I mean, technically speaking you could really hurt my feelings but we're putting on the veneer of bravery to help put people at ease to provide comments that they genuinely are not going to really ruffle our feathers. We love feedback, please dig in. And if you were crazy enough to listen to this whole thing, thank you very much for caring and keep fighting the good fight.

Yohann (57:24):
And we will talk to you soon.