<< All Episodes

Season 1, Episode 7:

The Company Timeline vs. The User Timeline


Apple Google Spotify Overcast RSS

Episode Summary

A long-held belief in software is that designers need to balance the company's needs with the users' needs.

In this episode, we reexamine that two-headed monster from a different perspective: thinking in terms of timelines.

Your user flows will always be affected by company-timeline considerations, but diving further into your USER's timeline is an easy way to find insights for healthy conversion and retention.

📚  References

🔤  Transcript

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

Yohann (00:19):
And I'm Yohann, also from UserOnboard. And today, our topic of discussion is something we've brought up in past episodes, but are using this one to actually go into more granular, nitty-gritty detail. The topic of today's episode is the company timeline versus the user timeline.

Yohann (00:42):
From a Value Path's point-of-view, when we talk about putting the customer first, what we're talking about is paying more attention to the timeline that they're on. And I will explain both those terms, the company's timeline and the user's timeline. I will explain what those terms mean in more detail in just a few minutes.

Yohann (01:06):
But before we get there, what I would like to do is talk about what it means to actually put customers first. In our industry, there's a whole grab bag of mindsets and ideas of what it means to actually put the customer first. You know whether that's incorporating more customer feedback into your designs, or seeing your software as co-created with the customer. There's a whole spectrum between those two ideas of what it means to put the customer first.

Yohann (01:48):
But if there was one idea that represented the whole mix, and one that we stood behind value paths, it would be this. It would be really understand the user timeline, and put it first. So, let's get into definitions before we go any further. Samuel, how do you see the company timeline versus the user timeline?

What is the company's timeline? How does it differ from the user's timeline?

Samuel (02:16):
I think that the company timeline is often mistaken as just being 'the' timeline, where anytime you're working in an organization that's looking to grow, looking to succeed, looking to make an impact on the world, so on and so forth. There's an inherent narrative that emerges about how much progress that company or organization is making toward its goals and how successfully it's growing and how successfully it's operating on its basic mission. And so, you might think of the narrative timeline of your company as being something that started with a couple of people with a scrappy idea.

Samuel (02:59):
And then, they went out and got funding or got into Y Combinator, and then raised more rounds and grew even bigger, and so on and so forth, all the way up to IPO-ing. And there are so many decisions that need to be made during that time from an executive standpoint, especially regarding hiring plans, which markets to go after, which distribution channels to figure out, what different features to release at different times so that you can stay at a level of parity with your competitors, so on and so forth. And all of these are what we generally would call company timeline considerations. Is that a fair overview, Yohann?

Yohann (03:36):

Samuel (03:36):
So, what are we advocating for instead? What's the other side of the equation?

Yohann (03:41):
The other side of the equation is acknowledging that users don't know, are not aware of, and frankly, don't care about the business's timeline, about the business's narrative. If I could illustrate with a story.

Samuel (03:58):
Please do.

Yohann (03:59):
And this is not related to SaaS at all, but I think it really sets up the concept nicely. Recently, around the Thanksgiving holidays, I was staying in a hotel, and I was there on holiday. So, I was having a very relaxed morning, woke up late, didn't have too much on the agenda except relaxing and maybe going to the pool later and doing a bit of sightseeing in the place that I was staying.

Samuel (04:31):
That's a nice agenda. Yeah. That's my kind of of agenda.

Yohann (04:34):
Thank you. Can you imagine holidays that are packed with activities? I've never understood those kinds of vacations.

Samuel (04:41):
You will get me going on a long rant if we go down that direction. So, let's just say we agree.

Yohann (04:48):
Let's nip that in the bud. So, anyway, it's about 9:00 in the morning. I am getting ready for a very chill day. And then, I hear the doorbell go off two, three times in a row, just very aggressive doorbell ringing. And I'm wondering who this is, and what could possibly require so much aggression this early in the morning on a holiday of all things. So, I go to the door and I open it up.

Yohann (05:21):
And it's this woman and she's super dressed up. She's got jewelry hanging from every possible place that's possible to hang something. And she's wearing very fancy clothes. And she looks at me in surprise. And she is here at the hotel for a wedding. She thought my room was her friend's room. And she's very flustered because she's late for something. She quickly apologizes and leaves.

Yohann (05:52):
I'm not supposed to be thinking about software on my holiday. But my first thought was, this is a great example of how this woman and I are in the same hotel at 9:00 a.m. on a particular day, and we're on completely different timelines. My timeline for the rest of the day versus hers for the rest of the day. And even how that changes our experience of this particular moment are completely different, two different narratives.

Yohann (06:30):
So, to think of the business's narrative as the only narrative is a mistake, because you are missing out on what brings the user to your software at this particular time, and how urgent their needs are, what their priorities are, what their frame of mind is, all of those things are different because they're on a different narrative than the businesses.

Samuel (07:03):
And it's interesting to think also that yourself, and the woman who you encountered both probably used multiple apps throughout that given day. But I bet that you use maybe different apps, maybe the same, but I bet you use them for very different reasons that were contextually nested within the overarching timeline of the days that you were having in general. Would that be fair as well?

Yohann (07:32):
Right. Yeah, totally fair to say. Even if we were using the same app, even if both of us used Uber that morning, the considerations would have been completely different. The urgency with which we were making the booking would have been considerably different.

Samuel (07:49):
I appreciate the way that you outline that. But one thing that I'm imagining is, let's say that I work at Uber, and I'm listening to this podcast. And I think, oh, yeah, that's a good point. You could be using Uber on a restful holiday vacation kinda day. You could be using it on a more urgent day. You could be using it to go to a wedding or go to a funeral or go out to the movies or all kinds of different reasons that you might be using the product.

Samuel (08:20):
How do you make sense of which ones to pay attention to and which ones you're over-indexing on? Or, how do you prevent it from just being a chaotic blur of different possible use cases? And the answer to that question, in my mind, is to pay attention to the specific outcomes that people are pursuing, that cause them to find your product to be relevant. And especially whichever outcomes that people are pursuing, that strongly correlate with them being long-term subscribers.

How to understand and positively impact the user timeline

Samuel (08:54):
If you're in the SaaS game, and you're looking for, to make a big pile of low turn subscribers, I would be looking at what are the things that people commonly need among the group of people who are our best subscribers? And especially how can we detect when they're on that kind of path early in the process, so we can align our resources around helping them get to that point as effectively as possible. Do you have any thoughts on that Yohann?

Yohann (09:25):
The only thing I'd add is that it's the outcome that is moving users along their timeline. That's why it's so important. The outcome is the accelerator. Is that a fair word? It's the thing-

Samuel (09:45):
It's like the fuel, the accelerant almost. It's the energy that drives the engagement in my opinion.

Yohann (09:54):
Exactly. Yeah. Yeah. It's the energy that drives that engagement. So, without an understanding of the outcome, you can't tap into the force that is moving the user along the timeline. And without understanding which of those outcomes are the most lucrative for your business, you can't structure things so that the user moving along their timeline moves your business along its timeline.

Samuel (10:27):
I think that's very well put. And so, to put a clarifying point here, when we're talking about the business's timeline versus the user's timeline, what we're ultimately saying is that there are reasons other than being a customer that drive your customers to find your offering relevant. And that the clearer you can get on those common reasons that people are seeking your product to help them with, and align your product around helping those most common ones, or at least the ones that you can demonstrate most reliably correlate with good customer behaviors, then that really helps you understand what it is that you need to do.

Samuel (11:11):
So, to use an example that's not Uber, we have our pretend company Invoicr, where we could position it as the best way to create and send invoices, for example, but we would know by the nature of the situation at hand that people wouldn't be engaging with Invoicr because they love sending invoices so much. The outcome that would be most commonly desired would be getting those invoices paid, I would imagine.

Yohann (11:39):
And this is in the same territory of another question that you might be thinking at this point, which is, why not just pay attention to the outcome? If it's the outcome that drives the engagement, that big out of app beneficial outcome, why not just focus on understanding that? Why think about the timeline at all?

Samuel (11:58):
So, if we think along the user timeline, what does it take to go from, you have a potential client, who you need to be able to create an invoice and deliver to, and then that client needs to be able to see that it has been sent to them, and to review the invoice. And then, they need to approve the invoice. And then, the approved invoice needs to have pay initiated, then that money needs to be transferred from one account to another, so on and so forth.

Samuel (12:29):
There are all kinds of different steps along the way, like how we talked about making a peanut butter and jelly sandwich is a lot more complicated when you start looking at all the steps in between steps in between steps, et cetera. And so, if you're making decisions around what's our hiring plan, and which features are our competitors releasing soon, then you're not thinking in terms of how do we help people go through all the different hoops it takes to actually get that invoice paid, because we know that that's what they're there to do, rather than maybe we should add dark mode because everybody else is rolling out dark mode or whatever.

Samuel (13:06):
So, in the case of Invoicr, you have something where you can be thinking about what the user's desired outcomes are, and what sort of chain of events needs to take place in order for them to get there. And in the case of Invoicr, maybe we would say it would be a default assumption that people who were coming to our offering would be getting their invoices paid and that, therefore we should try to raise our batting average or success rate of getting people to invoices to go from sign up to having an actual invoice paid.

Samuel (13:43):
I bet that if you look at the data, again, along the customer timeline or the user timeline, not along the business's timeline, and measure what the likelihood of somebody going from signup to paying customer is, and you look at the difference between the signups who have gotten an invoice paid during the free trial or whatever, versus the signups who haven't gotten an invoice paid, I would predict a much higher likelihood of conversion among the people who had achieved some sort of value-based milestone that actually matters to them. So, far so good?

Yohann (14:20):

Samuel (14:21):
Okay. So, the other consideration here can be that there are patterns that drive people in their lives external to your offering to come to your offering, to generate some valuable outcome. So, in the Invoicr's case, we might do some user research and ask people, why are you trying to get invoices paid to begin with? Why are you coming to us for help with that to begin with?

Samuel (14:49):
And let's just say hypothetically speaking, we talked to a bunch of different people and two different clear categories emerge. One category is people who are saying, "I am a small company, this is the first time that I've been able to take on what I hope to be as a really big project. And I don't want to look like a rinky-dink operation with my Word template, I want to send them a professional-looking invoice from a professional source."

Samuel (15:16):
That could be one. So, basically, we can categorize that as wanting to land at a bigger job than usual, so to speak. And then, alternatively, maybe we're doing some research, and we find that a bunch of different people's stories all fall under the category of we were working along, everything was fine. And then, the person who handles our invoicing quit and moved to Cancun. And all of the documents that they had are in this locked zipped folder. And we are just starting off with Dropbox and chaos. And we just need to have a new system in place. Maybe you find that as a common theme as well.

Samuel (15:58):
So, in both cases, you can be thinking about which valuable outcomes are meaningful milestones in that customer's timeline of pursuing this bigger picture out of app type outcomes as well. You could create a lifecycle email sequence, all about how to get your first big customer. Or, you could create a lifecycle email sequence, all about how to come up with an invoice management system on the fly after the person just quit and moved to Cancun.

Samuel (16:34):
And so, along those lines, you can find different patterns that cause your offering to be relevant. And instead of chasing every single one down, like somebody who woke up late on a day that was supposed to be vacation, but it turned out that it was raining. So, instead, they changed. You don't have to get super hyper-specific, but having a general understanding of the high-level patterns that drives your users to find your offering to be relevant, and then trying to understand where they are in a pursuit of that particular outcome, and how to align your resources around helping them get the rest of the way is, from a Value Paths perspective, pretty much the name of the game.

Yohann (17:18):
Right. And finding that point of specificity is the real challenge. Because if you get high level enough, Uber is just about getting from one place to another. If you get too specific, it's taking an Uber from this specific hotel to that one for a wedding. So, finding that right mix of practical and thematic is part of the challenge. But that's something we've covered as well.

The consequences of ignoring the user timeline

Yohann (17:48):
And what I want to talk about now Samuel is as a point of contrast if these kinds of decisions aren't informed by the user timeline, so let's just say we were working with a company that doesn't recognize that there's a difference between the business's narrative and the user's narrative. That they're on two different timelines and they believe that the business's timeline is all there is. What does the path look like in that situation? Just as a point of contrast to the kind of situation we outlined just now with Invoicr.

Samuel (18:31):
I think that even in the case of a company dominant timeline being the main thing that is being focused on, it's interesting that there are still customer or user timeline aspects of the overall strategy. It's almost like even on an intuitive level, there needs to be some sort of acknowledgment that, oh, yeah, the customers have to progress through a process in order to be able to arrive at their intended outcome in order to generate revenue for us, and so on and so forth. And so, what you will find are things like Pirate Metrics, Dave McClure's AARRR, which stands for Acquisition, Activation, Revenue, Retention and Referral. Is that right?

Yohann (19:19):
And referral, yes.

Samuel (19:19):
I nailed it. Nailed on the first try. But anyway, so AARRR, and then they're called Pirate Metrics, because it's our but what you're looking at when you are using an AARRR lens, is that you are imposing your own preferred order of events, which is that the user is acquired, and then the user activates, and then the user produces revenue, and then the user is retained, so on and so forth. These are all things that are good for the users to do for your company. But that's not how they see it at all.

Samuel (20:00):
Nobody would ever say, "Oh, hey, how are things going with your Substack newsletter?" And you'd be like, "Pretty good. I'm in the retention phase thinking about even turning things into referral." You just don't think about your relationship with an offering that way. As a customer, you're thinking, how am I going to grow my Substack audience and try to make big bucks off of it or whatever your particular goal might be?

Yohann (20:23):
Another problem that I have with the business's interpretation of the user's timeline is that it's always a model of the user's timeline and not the timeline itself. So, if you are creating a user journey map, for example, you think that you are mapping out the user's timeline. But what you're doing, in fact, is creating a model of the user's timeline. And the model could be very different from what's actually happening in reality.

Yohann (21:02):
The map is not the territory, and you should really be paying attention to the terrain rather than the map. Along these lines, one common story that comes up a lot is... common concept that comes up a lot is the concept of the coastline paradox. In a nutshell, the paradox is that depending on the unit that you use to measure the coastline, the coastline can actually be very different lengths. For example, the coastline of Great Britain, if you're measuring the coastline of Great Britain, with 100-kilometer units, for a coastline-

Samuel (21:48):
For US dummies, what's that in miles?

Yohann (21:51):
That's 62 miles.

Samuel (21:53):
All right, so if you're using a ruler that is 62 miles long, and you're trying to measure the coastline of Great Britain.

Yohann (22:03):
It nets out to 2,800 kilometers, which is 1,739 miles.

Samuel (22:12):
So, we've got the answer.

Yohann (22:15):
Yes, but if you're using a ruler, that's 50 kilometers instead of 100 kilometers, so-

Samuel (22:25):

Yohann (22:25):
Yeah, half, so 31 miles. If you're using a ruler that's 31 miles long, then the coastline of Britain is 3,400 kilometers, which is 2,112 miles.

Samuel (22:44):
How could it be two different coastlines?

Yohann (22:48):
Right, how can it be two different coastlines? Because the ruler changes the length of the coastline, because there are some things you can't measure with 100-kilometer ruler that you can measure with a 50-kilometer ruler.

Samuel (23:07):
Little nooks and crannies inside the coast.

Yohann (23:12):
Right, right, right. And it's the same thing with an abstraction of the user timeline. So, if you're sitting in a room in the company, and trying to come up with the user timeline, and this usually takes the form of something like a user journey map, what you're doing is creating an abstraction that might not actually fit the terrain, or that might fit terrain-

Samuel (23:40):
A wish list of things that you hope people will do.

Yohann (23:43):
... a wish list. But what's actually happening, I don't mean for this to sound sarcastic, but what's actually happening is the best indicator of what's actually happening.

Samuel (23:56):
I think that it's a question of who gets to say what the user's journey or flow is. That I think that we're both of the perspective that the user's flow is not something that you can draw up in a board room and decide people will go through and expect it to be very effective. It's not something that you can... what was the metaphor used with the dictionary? Ideally, we want to take a descriptive approach, not a prescriptive approach, right?

Yohann (24:32):
Right, right, right.

Samuel (24:32):
And so, when we're saying representing what's happening in reality, we're saying go straight to the source and see what kind of patterns you can pick up by observing the natures and behaviors and ambitions of people who are actually using your offering, rather than going into an ivory tower and determining what will be decreed to the people down below.

Yohann (25:00):
So, tying this back to the Pirate Metrics that we were talking about just a second ago, the Pirate Metrics are an abstraction in the same way that they are the business's interpretation of the user's timeline. And if you were to measure things along the user's timeline, it would actually unlock a lot more growth opportunities than just optimizing for activation and retention, and referral down the line. There's a lot to cover here. And maybe we should save that for a future episode, maybe performance valuation part two.

Samuel (25:36):
Oh, yes. It's very mysterious. Basically, the gist here being that we hold it self-evident that user motivation is the energy that drives any given engagement. And that you need to have successful engagements with your offering in order to be able to charge for it, especially in a subscription sort of business model. And if you're measuring user engagement in terms of pirate metrics, or virality, or things that are good for the business, but are not necessarily good for the user, then you are misidentifying the actuality of someone's given timeline.

Samuel (26:20):
So, if you're taking a user's timeline, and you're chopping it up into AARRR chunks, for one thing, that's not going to represent the way that things work anyway. People don't only start referring other people to products after they have already paid for them and been retained by them, whatever that might even mean. But beyond that, it's not at all how the user sees it, or how they resonate with their own sense of momentum, and ambition in pursuing the goals that are driving them to use that product to begin with.

Samuel (26:52):
So, you know that that's a crappy model for what the motivational patterns are, that drive people to engage with your offering to begin with. And yet, those are the metrics that you're probably tracking or paying attention to in some form, or fashion, especially when we look at the way that a lot of people measure net MRR or net ARR, or generic net churn rate or things along those lines. You don't want to be thinking in Pirate Metrics, when you're operating the growth levers of your business. You want to be a lot more considerate and strategic than that.

Samuel (27:28):
One other thing, while I'm ranting, I would like to add is that the less that you impose upon the user's timeline, the better. What you really want to be doing is acting as an accelerant to help propel them through their timeline and the steps that they need to go through, like creating the invoice, sending the invoice, having the billed party see it, have the billed party decide to pay the invoice, be able to go through with the transaction, so on and so forth. You want to be ushering them through all of these steps, rather than imposing friction, especially arbitrarily along the way.

Samuel (28:08):
And yet, a lot of times, we see that the required steps if Invoicr was just some other generic company out in the wild, maybe one of the required steps from going between sign up to having an invoice paid is to fill out some dippy required form that makes you say how many employees work at your company, and what kind of industry you're in, so that some salesperson from three years ago was going to be able to better decide which leads to follow up with. So, thinking about how much of your own process you impose into the user's process needs to be surgically selective.

Samuel (28:46):
And ultimately, what you want to be doing is having your own process merge with the user's process as much as possible. And so, if we're thinking in terms of when you have a dance partner, one dance partner leads, the other follows. You want your offering and the experience of using your offering to follow the lead of the users' dance, rather than to be imposing its own dance onto the user, with perhaps the one exception of when you know how to lead the dance to where the user is trying to go better than the user does.

Samuel (29:23):
But in that case, you still don't want to be leading the dance per se. You don't want to be imposing your own design decisions on them. You want to be presenting the users with resources to let them autonomously choose with volition, which path forward they want to do and how and when, and so on and so forth.

How to prioritize business interests within the user timeline

Yohann (29:43):
It's related to a question that we got recently from a listener. To paraphrase the listener, when you do have to ask a question that is business-centric, when do you do it? So, if you have to surgically choose where to insert this question or how to merge this question with considerations that are important to the user anyway, how do you do it?

Samuel (30:14):
I think that the short answer is whenever it's to the maximum benefit of the user. And if it isn't designed to benefit the user in any way, then is the question really when to add friction that's empty calories for the user, but that the company needs to know? Or is it more, how do you position a survey so that it isn't empty calories for the user? Do you have a sense? Or we could talk about both sides of it I guess, too.

Yohann (30:45):
Yeah, yeah, that's what I was thinking we could do. Yeah.

Samuel (30:48):
So, in past episodes, we've talked about the wrapping the something in a meatball strategy, where instead of trying to force a dog to swallow a pill that it doesn't want, you just put the pill in the meatball, and the dog eats it right up. And so, if there are things that need to be done, and that also benefit the user, make sure to include the context of why it's good for the user to proceed in the way that you're setting up the activity itself. That's one part of it.

Samuel (31:18):
But then the other part of it is, if you have activities that you need users to engage in that have no benefit to the user, then ultimately, you want to be, A, as selective as you possibly can with these, and not just have something where it's like, "Well, I don't know. I joined the company three years ago, and they asked people what company size they were when they were signing up then. So, it's just still there now." Question all of those and make them stand on trial for their life, and have it be a compelling reason would be one thing.

Samuel (31:49):
Another consideration would be to think about how you can delay those as much as possible. Because when you're looking at the amount of people that you have who are going through any kind of user flow, but in this case, we'll say the number of people who go from signing up for Invoicr or to having an invoice paid, we're going to find that we lose the most people earlier in the process rather than later in the process.

Samuel (32:14):
And so, if you have some sort of arcane requirement that somebody has to download three PDFs and have a notary public watch them, sign them, and then scan them or whatever, if you can choose to make that the last step that somebody needs to take, you're going to have all of the people who are going to say, "No, I'm not going forward with that." Or, maybe want to go forward with it, but are incapable of doing so.

Samuel (32:45):
All of those people will have made it further into the process, and have hopefully, not only had their motivation amplified by whatever experience they've had with your process thus far. But hopefully, they're even more capable, or have even better resources to be able to take on those harder benefit-less, friction points that you might need to require.

Yohann (33:12):
And they might also be more generous at that point in time, which is why delaying is such a good strategy because you have some time to build trust and deliver value. And once you have delivered value, users are much more likely to be generous and say, "Okay, I will take the time to give you an app store review, which has nothing to do with my timeline but I know benefits you, or answer this particular survey, or give you feedback. Those kinds of asks are much better received once you've delivered value first.

Samuel (33:48):
Or coupled with value. If you are able to say, hey, congratulations, you came here because you wanted to do blank and blank just happened, so nice job. While we're at it, do you want to buy an annual plan at a discount, or something like that? You can think of or conduct a survey or whatever it is that you want people to do. You can use that as a follow-on to harness the motivation of whatever good news you're sharing as well.

Yohann (34:19):
Completely agreed. And one small point to make about when we were talking about wrapping something in a meatball, wrapping something in a meatball covers communicating why that particular thing is to the user's benefit. But what we should also include and what we should also talk about while we're at it is demonstrating that it actually is to their benefit. So, if it is to their benefit to answer a few questions early and you tell them, answer these questions because then we can make X, Y, Z happen for you actually make those things happen, because then you're showing that you can actually deliver on the benefit that you've told them you can deliver.

Samuel (35:08):
You're giving the user a quick feedback loop with which to gain confidence in what you offer.

Yohann (35:15):
Right, that was much better put.

Samuel (35:17):
Oh, it wasn't a competition. I was recapping. We're both standing on the shoulders of giants, Yohann. But anyway, so that is definitely one aspect of it. All right, so that covers one of the mailbag questions. But for this episode, we are dealing with a bounty of questions. We have two different ones to talk about.

A real world example of prioritizing the user timeline: Buzzsprout

Samuel (35:40):
The other one, in this case, being what I would generally summarize as could we provide more real-world examples of the different concepts and topics and metaphors that we're putting out there. And fortunately, I can provide a real-world example of a company that did a very good job of paying attention to the user's timeline rather than their own. So, we can deliver on this one. And in this case, it's a little bit meta. But when we were creating this podcast, we had to sign up for podcast hosting services.

Samuel (36:19):
And so, I did some research and found some different options available and heard good things about Buzzsprout. And decided to ultimately pull the trigger with them, or at least see how far I could go with them to try to get to the point of success that I was desiring, which was to have a podcast out and available and downloadable, and so on, and so forth. And so, I think that if you're looking for what I would consider quality workflow design, look at the way that Buzzsprout organizes its resources and highlights different things at different times.

Samuel (36:57):
So, just to go from basically scratch to having a podcast that people are listening to requires a number of steps. You've got to come up with a podcast idea. You've got to come up with an episode topic. You need to record an episode. You need to upload the audio file of that recording into a podcast hosting software, unless if you're rolling your own or something. And then, you need to make other podcast distribution networks aware that your podcast exists.

Samuel (37:36):
So, get it listed on Spotify, get it listed on Apple Music, get it listed on Google podcasts, et cetera. And so, every step of the process that you go through, in order to get your podcast out and listen to, there is some sort of corresponding screen or resource within Buzzsprout that gently guides you along from one hurdle that you have to overcome to another, rather than with a contrasting sort of perspective that we would hold up as maybe traditional product design would be to say, our product hosts podcast audio.

Samuel (38:15):
And we want to be the best at hosting podcast audio files, and focusing on creating the highest quality podcast file hosting interface that you possibly can, rather than saying, well, what is the reason that people are wanting to host these files, and organizing all the resources, interface design, attention, UX, et cetera, around getting people incrementally from one point to the next to the next, and ultimately arriving at a point where they do have a podcast that's being listened to.

Samuel (38:51):
And on top of that, they also know that you care about weather, you don't want just one person to listen to your podcast. You want to be growing your audience. And until in Buzzsprout case, they do something that I think is completely delightful. And I am very stingy with that word considering it's overused in user experience design, but they send you email updates whenever when you get your first 50 listens. And then, when you get your first 100 listens, you get another email saying "Hey, congratulations, you just got your podcast got 100 listens, 200 listens, wow."

Samuel (39:27):
And so, they're sharing in the success of the journey that they are facilitating you being the star of and you being successful in rather than creating an environment that is something of an obstacle course that people have to go through even just to be able to get any sort of reward for their time and effort that they're putting into it much less to get a reward for whatever kind of money you're hoping they will pay you. Fair?

Yohann (39:56):
Yeah, I think that was a great example.

Samuel (39:59):
All right. So, thank you for submitting feedback. We love to hear it. We would love to hear any questions that are critical of what we're saying, that are asking for more clarity around what we're saying, we welcome the good, the bad, the weird and otherwise. And all of that can be sent to podcast at UserOnboard dot com.

Yohann (40:23):
Thank you so much for listening as always. It's a pleasure to be able to share these concepts with you especially as we're thinking through them ourselves. Stay tuned and we will talk to you again soon.