Subscribe
Share
Share
Embed
Today's guest has strong opinions on the way a company should measure their performance – in short, by being the best at helping customers not building software. In this episode I'm joined by Samuel Hulick, creator of UserOnboard to talk about his approach to designing and measuring onboarding experiences that drive successful outcomes.
Happy Customers is about why making customer successful - and ultimately happy customers is more important than ever before.
Over the course of this series we’re going to explore what people inside some of the world's top companies are really doing everyday to go beyond the metrics and numbers on the balance sheet, collaborate across their entire organization, and truly invest in making their customers successful.
Samuel Hulick (00:00):
One thing to underline and bold, in my opinion, is that you do want to be the best at helping people. You don't want to be the best at creating quality software.
Stuart Balcombe (00:13):
Hello, and welcome to Happy Customers. The show where we're exploring what people inside some of the world's top companies are really doing every day to go beyond the metrics and numbers on the balance sheet, collaborate across their entire organization and truly invest in making their customers successful. In this episode of onboarding operations, we're talking to Samuel Hulick to unpack his lessons learned after more than a decade of helping companies understand and improve the paths their customers take to value. I'm Stuart Balcombe, and I'm excited you are here. Don't forget to subscribe and leave us a review wherever you get your podcasts. Okay, let's get into the conversation.
Samuel Hulick (00:57):
What I'm working on these days are twofold things. You might be some familiar with an entity called User Onboard, where especially in the past, I would produce tear downs that would explore different popular web apps onboarding experiences. And I'm also working on something bigger, in my mind, called Value Paths, which is taking a lot of the learnings that I have attained from lasering in on the user onboarding part of the overall user experience over the last 10 years or so. And recognizing that it serves a much bigger function for your business than just having a welcome tour that people can click through and then start using the product like an earnest. That really it's a question of, how do you identify what success looks like for your different customers? And how do you craft an environment that helps your customers arrive at the value that they're seeking and that they're coming to you for?
Samuel Hulick (01:59):
Which is really what onboarding should be, but most people think of onboarding as the tool tip tour that they click through 20 times before they get to the product. And so trying to move a little bit away from that and more toward, what is the actual value that's being generated when people engage with software? And how can we tune and design software to be as in alignment with that as possible?
Stuart Balcombe (02:20):
Yeah. And it's interesting the value paths piece and the journey that you've been on from self-serve onboarding, tear down to discovering the outcomes that the folks are actually trying to get to. At what point did you find there was a disconnect between what folks were doing? Or on how people were measuring the impact of how their onboarding was performing versus their customers actually being successful?
Samuel Hulick (02:49):
Yeah, that's a good question. So from an onboarding pigeon hole standpoint, the shortsightedness that I often see people bring to an onboarding practice or an onboarding effort, I guess would be better to say, would be to assume that making people go through your onboarding steps is the equivalent to setting them up for success. That if you can just make them click next and look at all of the different cool features that your product has, that they will just magically remember what it is that they're supposed to be doing when those features or capabilities actually become relevant to the processes that they're undertaking. And so I recognized upfront that, A, onboarding was usually designed, especially when I started, but unfortunately continues to be the case. Onboarding is often maybe even usually designed after the product is designed.
Samuel Hulick (03:48):
Rather than saying, what we want to do is to get people from signing up to a point of success for them. And we are going to craft our product experience around helping facilitate that transformation in their lives. Instead, people hyper index on creating a tool, a software tool, and then try to figure out how to educate people about the tool through the process of signing up for it. Which in my opinion is kind of a fool's errand. So for me, it's close, but instead of trying to teach people about the tool that you made, ultimately the tool should be teaching people about how to make progress in the form that they're going to the tool to achieve.
Stuart Balcombe (04:30):
How do you define onboarding? And I guess probably more interesting to me is, where do you see the guardrails around onboarding? Where does onboarding start and end to you?
Samuel Hulick (04:44):
I don't see any hard edges around where onboarding starts or when it stops. I do think that it's important to have a metaphorical finish line in mind of understanding what it is that the user is hoping to achieve with the product. What kind of difference they are looking to make in their life via the product. But as far as setting an arbitrary endpoint, where now we can say that somebody is "fully onboarded," to me, does not make a lot of sense. And I suspect a common theme in our conversation will be toggling between looking at things through a product centric view versus looking at things through an event centric view. Or saying, how can we help this process unfold in somebody's life, rather than how can we impose our products processes into their life?
Stuart Balcombe (05:35):
I think it is definitely an interesting question to explore. And you sort of hinted at this a little bit with, folks build the software tool first and then try to figure out how do we get people to successfully use that tool. And I guess it begs the question, how do you define successful usage of a tool? How do you think about that, in terms of measuring the success of... you used onboarding effort earlier. How do you think about measuring the success of the onboarding effort that you are engaging in?
Samuel Hulick (06:11):
So from an onboarding perspective, I could start just by rattling off a few things that I wouldn't focus on. A lot of times people will look at the success for an onboarding project as being that more features were activated or looked at. Or that somebody made it through your own onboarding steps as if that was an inherently valuable thing necessarily, which usually unfortunately is not the case. For me, what I look at for success is that ultimately as a software company, your revenue is almost definitely generated through some form of ongoing engagement. Where an account is created and then the account persists in engaging with the software or your offering over and over and over again. Usually, like if we're talking SAS, that would be a subscribed customer. But even if you're like Twitter or whatever, even if your revenue is not coming directly through a subscription, you still want to sustain the engagement and the relationship that you have with somebody who pops up on your radar.
Samuel Hulick (07:21):
And to me, when you look at creating a big pile of low churn, long subscriber relationships, what you're really looking to do is to identify when somebody engages with your offering, what kind of situation are they in right now, that's driving them to come to your offering? And what kind of situation are they hoping that you're offering can help them arrive at? And tuning as much of your experience around facilitating that transformation successfully, as often as possible when people come to your product. And unfortunately, you don't really see that represented in a lot of product experiences. A, on the one hand, a lot of companies out there are, to use a spicy word, shamefully comfortable with 1%, 2%, 10% conversion rates. So if you were operating a restaurant and you had 100 people come to your restaurant that day, and 90 of them left without having been better off for doing that, it's going to be hard to operate a restaurant.
Samuel Hulick (08:29):
Your margins are not going to be great. Your marketing efforts are not going to go as far, so on and so forth. And in a similar way, even if the 10 people who come to your restaurant have a positive experience, you want them to continue having a positive experience when they come back. And again, you want to understand what it is that's driving them to come to your offering. And facilitate as seamlessly as possible, a way for them to arrive at the outcome that they're seeking every single time. And products to my mind are developed in an industrial manufacturing mindset where we create the product. And then we have marketing advertise the product. And we have sales, sell the product. And we have engineering work on the product, and PMs work on the product. And customer support, support the product. Where the product itself, it's not like we're selling material goods where you have to design a lawnmower and then mass manufacture it and ship it out everywhere.
Samuel Hulick (09:31):
Instead, we can have the lawnmower "come to the customer." We can have the lawnmower adapt to whether they're trying to... really stretching this metaphor here. But if you're trying to mow on hills, versus if you're trying to mow a cool design into your yard, or whatever if the lawnmower can't "know" what the user's trying to do. But in software, we don't have those limitations of the material constraints of our offering. And unfortunately, I don't think that software designers are really recognizing that. And I don't think that they're really digging into and leveraging that as much as they could be.
Stuart Balcombe (10:10):
So from a designing software perspective, how do you go about on day one? You either don't have a product yet, or you have a version of your product today. How do you go about identifying the most common outcome that your customers are seeking, and then will begin that process of adaptation to better facilitate that outcome?
Samuel Hulick (10:34):
I think it's really different depending on whether you already have customers or not. So if you're in one scenario where you're just trying to think of like a cool startup idea, and you're going out and trying to identify an outcome or a cluster of outcomes that you think that you could create an offering to facilitate, that's one whole process. But if you are already a customer support role member on a customer support team at a preexisting organization, it's pretty likely that you already have a product in place. And so my recommendations and approach would be pretty different even though it'd be using the same tactics. So would you prefer to hone in on the preexisting product scenario or the non-existing product one?
Stuart Balcombe (11:17):
Yeah. Let's hone in on the preexisting product. I think that's the one that it's probably the most common. And it's also the one that my assumption is it has the most challenges in organizational change and addressing things that maybe don't exist, constraints that maybe don't exist in a pre-product scenario.
Samuel Hulick (11:38):
So if you already have a product and you already have customers, then the real question that I like to try to figure out is what are the most common outcomes that people are seeking, especially when they are creating their account for the first time. If you just think about how unlikely it is that somebody even finds out about your offering. They have to have that particular problem and decide that their way of solving it is insufficient for some reason. And then they need to go out and find other ways of solving that problem. And then hopefully, your way of it pops up on their radar. And then, they want to do some research to make sure that this is legitimate and that they can have reasonable expectations coming into what you're doing. And that it's actually going to work out and not be a big waste of time.
Samuel Hulick (12:25):
And then after all of that, they finally decide to sign up. And then you're losing 90%, 99% at times, of the people who go through all of that, just to get to the point of signing up for your software. So that's an emotionally rich moment. And I like to really dive into that. Especially because when you're looking at it from a numbers standpoint, that you're losing the most amount of people early in the process. And so the more that you can be in tune with what people are looking for early in that process, the more likely it is that you can stop the hemorrhaging of major, major churn taking place within the first few months of becoming a customer. So looking for patterns in what people are seeking when they come to your product is one big part of it. And then another big part of it is looking at those different patterns and evaluating which ones have an empirical demonstrable relationship with better customer performance in terms of revenue.
Samuel Hulick (13:26):
So, for example, I always use the example of an invoice sending company. If people are coming to send an invoice, they might be doing that for different reasons. Maybe they're coming because they just got their first big potential client, and they don't want to send out their janky looking word document invoice, and they want to appear to be bigger than they are. Maybe that's one common reason. Or another common reason might be that the person who managed the invoices at the company just up and quit one day. And they just have a folder full of zipped up documents that nobody can access. And they don't know who's due for an invoice or when, or whatever. And they need somebody to come in and just manage that whole chaos kind of situation. Those would be different patterns of value that people would be seeking from our hypothetical invoice sending software.
Samuel Hulick (14:19):
And if we can, A, identify what those patterns are, and, B, look at the performance of the customers who are seeking those kind of things, especially when those points of value are resolved. So for example, if we can tell when somebody's coming, because they want to try to land a new big client, versus when they're just trying to do damage control on their existing chaos. And we can help them arrive at the outcomes that they're looking for. We can also tell how well those different customers perform as customers. We can see for example, oh, the people who come because they are trying to manage the chaos of somebody who just left. The LTV of those customers is twice the LTV of the customers who come because they want their first big client. So even if we see a lot of people who want to win their first big client, maybe that's not the juiciest ROI outcome for us to design around and really aggressively pursue creating a supportive environment for.
Stuart Balcombe (15:19):
That all makes a lot of sense. So I guess two questions. One, tactically, how do you go through that identification process, if you haven't started? Is that like a one-to-one email? Is that a survey? Is that conversations? How do you actually do that? And we can definitely split these, but two is what do you do with the people who are not in the most optimal segment?
Samuel Hulick (15:41):
Great questions. So, number one, as far as how do you go about actually doing the measurement on a tactical level? Where I personally would start, would probably be talking to customer support of all things. They are the ones who, for better or for worse, personally, I think for worse, they're often the ones who are the only team that's in continuous communication with the customer base. And I have personally found that if you're looking for a reality check around what is it that people are really coming to us for and what is their own personal definition of what success looks like? Customer support tends to have their finger on that more than I would say going and talking to a product manager or talking to someone on the rev ops team, or something along those lines. As important as their feedback is, and their contributions are, if we're talking about just really getting our fingers on the pulse of what users are looking for when they come to us, support is probably the number one place that I would go.
Samuel Hulick (16:47):
And once you do have some ideas around, all right, again, maybe we conduct a little bit of user research, we do some interviews, we talk to customer support. And for our hypothetical invoice sending company, we realize that these two main outcomes are the two main things that people are pursuing. The number one recommendation I would make at that point would be to ask people why they're signing up. What is that you're hoping we can help you do, in so many words, as part of the activation process? Which accomplishes a number of different things all at once. For one, it lets you segment based off of what people's intentions are. If you ultimately say, "Really, we've done this research, we've talked to our executives, we've thought about the kind of value that we want to provide. And it really comes down to these three or four different things."
Samuel Hulick (17:40):
Then you can make those available as a question, in even like a multiple select question, as part of the activation and account creation process. Basically saying, are you here more for landing your first big client or more for getting the chaos of an abandoned folder full of zip files managed? Or where do you ultimately land? A, that not only will let you segment those people and see what their performance as customers looks like moving forward, but, B, it also lets you personalize the experience that those people have. So if somebody comes in and says, I'm looking for outcome A, and somebody else comes in and says, I'm looking for outcome B. You don't have to show them the same exact one size fits all user experience of your "singular monolithic product." You can create workflows that facilitate your product. And also probably leverage a lot of other competencies and skills that your organization has acquired in the form of knowledge bases and training videos, and all of the internal expertise that your organization has.
Samuel Hulick (18:51):
You can reconfigure that on the fly to help somebody get to a specific point of value that, ideally it's something where they're like, "How did you know this is what I wanted?" That's when you're really doing it at a high level is, if you can say, "Oh, well, if you're saying that you have qualities X, Y, and Z, that probably means you're looking for this. Is that correct?" And if they say yes, then you know, all right, now we can coordinate all of our different resources that we have in a timeline that will help them get to that point B that they just told us that they're seeking. Does that make sense?
Stuart Balcombe (19:26):
Absolutely. So is what you just described, and I guess the end result of what you just described, is that what you would call the value path? And if not, how would you define that?
Samuel Hulick (19:38):
Yeah. If we're filling in a lot of blanks in terms of the end result of what I was just talking about, then yeah. But the basic idea being that when people come to you, they are in some sort of state that, I don't want to say that they're agitated or irritated or frustrated. But they're in some sort of state that they are not satisfied with. And they are pursuing a different state in their life. And that they're hoping that whatever they do in your product can act as a step stone to that desired state that they have. And the more that our products can be in tune with, A, their current state and, B, their desired state, it becomes much more likely. It almost feels like cheating. You're just doing paint by numbers kind of a thing. Where it's like, oh, well, if you're here and you're trying to get there, then do this, this, this, and this, and you'll be able to get there.
Samuel Hulick (20:31):
And fortunately, we've paved that road and augmented it with all kinds of resources and expertise that we've been able to marshal over the years. And have basically just set you up for success as much as we possibly can. And if that's the case, then you are basically competing against nobody. Because right now, the dominant paradigm in software is that you make a product and you imbue it with "value" by giving it more features or shipping dark mode or whatever is that you're doing to improve the perceived value of your product. But software people are significantly under leveraging their ability to actually help people arrive at those outcomes. So much of product marketing in the world of software is trying to sell different, sexy features and capabilities of the product. But then as soon as somebody signs up to take on those features and capabilities, there's like nothing there to actually help them utilize those in a way that leads to success as they see it. And to me, that's just having it totally backwards.
Stuart Balcombe (21:43):
I love this topic. I want to dive into a couple of things you said there. So one is the, as you discover the paths and the outcomes that people or the outcomes that people want to get to, and you can start to lay out these sort of personalized, for lack of a better term, paths to get there. That along the way, you are including things that, as a company, you've built up your expertise, you've built up these resources that go along with helping that customer step stone their way to that outcome. How do you think about the ability of software alone to help people get to an outcome? Which is obviously the dream, right? Like go build software, you'll never have to talk to a customer. You'll build this thing once and they will come and then they will use it, and everybody gets rich. How false is that as a paradigm compared to including these other things, like human interaction, knowledge base content, just having a path that is laid out?
Samuel Hulick (22:42):
I don't disagree with the dream too much. I personally share that dream. And that certainly is the promise of scalable technology and automation that you can create something "once" and then be able to re-leverage it over and over again at scale. I'm definitely for that concept. To be totally honest, I think that the predominant way of approaching software shoots oneself in the foot, by trying to do that. And to be a little bit clearer in what I mean here, what I'm saying is if ultimately the users are coming to your offering in pursuit of their own definition of value, which we can call state B, whatever that is for them. Then what you ultimately really want to be doing is identifying a process that you can help people through that is preferable to the other processes out there.
Samuel Hulick (23:40):
So there might be another company that offers people help in achieving their given state B. But maybe it costs a lot more or it's slower or it comes with these other concerns. Or maybe a person could be achieving state B by their own means with pencil and paper or using email or spreadsheets, or all kinds of different ways of doing it. But as we were just mentioning a second ago, ideally you should be way more familiar with the ins and outs of how that state B can be attained than the user, because they're coming to you for help with it for one thing. And for another thing, it's probably their first time encountering this issue. Whereas for you, you're just living in this process all the time. You're like in Groundhog Day, when Bill Murray can walk under the tree and catch the cat as it falls and knows how to play piano. And he's just lived through that day, like thousands of times.
Samuel Hulick (24:43):
That's how you are about whatever value your product offers or can help people achieve. And so you should know the ins and outs of that territory so much better than your users to begin with. And so if we're talking about creating a process, I would not start with making my best guess as to what kind of software tool would facilitate that process. And then, and designing it and coding it and launching it and marketing it. And hoping that ultimately it creates value for people. Instead, I would go straight to the value creation and marshal whatever resources I have available. Human energy, knowledge, base resources, all kinds of different things, all the non-software things we're talking about. I would include of the tools in the toolbox to just create a functioning, reliable process where we know we can go out and get people who are in state A, and we know where to find them, and we know how to speak their language, and we know how to build trust with them and so on and so forth.
Samuel Hulick (25:40):
And we have a really reliable process of getting people who are in state A, into state B. And you do, then it's a question of how do we automate these parts out? How do we scale this out better? How do we take a process that's already working and leverage technology to scale it and automate it and be able to kick our feet up and drink a mimosa on the beach or whatever the... have a laptop in the sand or whatever the idea of success there would be. So that's my general viewpoint on it. Did that touch on your question or?
Stuart Balcombe (26:14):
Yeah, absolutely. And I think that you sort of restated a really important point. I think that's sort of certainly coming through in this conversation, I think is often overlooked. Or people sort of talk about it and it's the thing that's at the forefront. But it really highlights it's the importance of segmentation and segmentation as early in the journey as possible, right? Because if you are going to be the best at the... You often think about this when you're building new software. Everybody has limited resources. Everybody has limited time. What is the thing that you can be the best at? And if that thing that you are the best at doesn't line up with the thing that your customers want you to be the best at, you immediately have a mismatch, right? It just becomes much, much harder to be the best at many different things or many different processes, which obviously vary. The more customer types, the more complex the problem. There's sort of growing complexity on the process side too.
Samuel Hulick (27:15):
Absolutely. One thing to underline and bold in my opinion, is that you do want to be the best at helping people. You don't want to be the best at creating quality software. And so often in my career, I've seen people really just put on the horse blinders and try to think of how do we make our software higher quality? How do we bake in more value into our product? And I think that's just really barking up the wrong tree. That really, value is determined by the beneficiary. It's not something that you can force into somebody's life. It is something that is co-created in the life of the beneficiary. They're always a part of it. And especially in software where so much of the engagement is self serve. What you're really doing, even though we call it self serve, it's still collaborative.
Samuel Hulick (28:09):
As product designers, you're collaborating with people in the future who you're never going to meet. But you're still producing your side of the collaboration in the form of pooling together all the resources and software tools and so on and so forth that will help set at that person up for achieving success as they see it. But you can't tell them what success is. Or if you ship dark mode and somebody doesn't use dark mode, that doesn't make your product more valuable to them. Or it doesn't make your product more valuable in an objective sense. It only becomes more valuable when the person who's benefiting from it realizes, Hey, I'm better off because of this. And really, that is not the same as following best software design practices and having rounded corners on your rectangles, or whatever sort of product design aesthetics or hype is out there in a given moment.
Stuart Balcombe (29:03):
That totally makes sense. And I want to go back to some you mentioned earlier, which I think, at least in my experience, is often the objection to this. What you just described is building software where the measure of success is a software sort of company centric, known measure of success, right? Like we are going to build good quality software or the best software as defined by the roundness of our corners and the number of our features. Right? Whereas, what we're talking about here is defining success by the beneficiaries measure of success. But how do you do that? And you used revenue earlier as the thing that you look at as, is this cohort or is this segment successful? Is that what you would always point to is, if you're going to measure the impact of the success of your value path, the success of your efforts to get customers to the outcomes that they want. Would you always measure it in revenue, or do you have some other measure that they're actually getting there?
Samuel Hulick (30:03):
We could talk for like an hour on that one alone. I'll try to give you the short version. The state of affairs right now, I would say, is that people are creating value paths without realizing it. They're creating an offering that serves a bundle of outcomes. But those outcomes tend to not really get a lot of explicit design attention or explicit revenue attention. And so if you walk into a company and say, "Okay, well, we can all agree that your users are subscribing and being customers because your offering helps them be more successful at pursuing the outcomes that they're pursuing. So what are the outcomes that are driving most of our revenue?"
Samuel Hulick (30:50):
You're probably going to be met with a lot of blank stares. Or like, "Well, they love how user friendly our product is." Or things like that, which, again, are just generic product characteristics rather than a really intimate familiarity with what it is that people are seeking when they are coming to you for help. What is the help that they're looking for? And which kinds of help most strongly correlate with positive customer behaviors?
Samuel Hulick (31:17):
So to get more numbers driven, if we go back to the invoice example and we identify two different outcomes. One is getting your first big customer, the other is managing chaos. And we ask people upfront. We wouldn't just say, which of these two is most important to you? But in some subtle sort of way, we're able to detect whether they're more looking for that outcome or a different outcome. We can then say, of the people who's said that they were seeking this particular outcome, let's look at a couple different numbers.
Samuel Hulick (31:47):
One is how many of those people arrived at that outcome? And if you don't have the instrumentation in place to be able to tell whether somebody arrived at one of the most meaningful outcomes that your offering provides, that's an issue just onto itself to begin with.
Samuel Hulick (32:02):
But let's imagine that you can tell. And you can see the success rate of this many people signed up saying that they were coming for this outcome and this smaller number actually made it to arrive at that outcome. Then that is a percentage that you can try to improve over time. You can think of that like a batting average, or like your free throw percentage or something like that. Where instead of a hundred people signing up to land their first big customer, and only two of them actually landing that customer. Could we bring that up to four? Could we bring it up to 16? Could we bring it up to 20? How can we bring those ratios up so that it's more likely that people attain those outcomes?
Samuel Hulick (32:41):
And then the other big question is, of the people who are on that path to attaining that outcome, who we are able to segment, because we're asking that question up front, what do their customer behaviors look like? What is the likelihood, let's say that we have a two week free trial. How many of the people who are here to land their first big customer convert to paid versus the people who are here to manage chaos? Or how many of those people stick around two months later, or three months later? And see, is there a giant drop off in terms of just the revenue that's produced by these different segments? And if so, can we focus on the juiciest ones and try to bring our batting average for that up as much as possible. And at that point, you have your hands on a lever that's much more causally related to what's actually happening than looking at your product and trying to think of how to imbue it with a higher degree of quality as you perceive it.
Stuart Balcombe (33:39):
Yeah. That totally makes sense. And it's a very tangible thing to try and improve. I love all these relative metrics of success, right? Let's figure out what the baseline is, figure out where we are today, and then relative to that, how do we make improvement? How can we experiment to get to a better outcome or a better result against that baseline?
Stuart Balcombe (34:02):
One thing that you mentioned, which I always think is funny is, hypothetically, in a perfect world, everybody would know or have the instrumentation to know how their customers are. Are their customers reaching the outcomes that they set out to achieve? What is the mechanism that you would recommend? If a company doesn't have that instrumentation today, what is the instrumentation that you would recommend to actually identify whether or not customers are achieving their outcomes?
Samuel Hulick (34:26):
Well, one thing that I love about software is that it always comes with receipts of behavior. That anything that you put out there, you can see how it was interacted with, for how long, by how many people, at what sort of repetition, all kinds of different things. Because there's a paper trail or a digital paper trail of everything that your users do within your offering, if you choose to track it. And so the question to me would be, are you actually facilitating the arrival at that outcome? Are you actually getting people to state B? And if so, then just start tracking it. Or is it something where you know that your product plays some sort of role in getting people to state B, but then once they've taken the resources or capabilities that your offering provides, that they then go leverage it elsewhere to actually arrive at state B?
Samuel Hulick (35:23):
And in that case, it becomes much more difficult to track. Then, the usual tools would be like a post engagement survey or something like, "Hey, did you actually wind up saving money or landing that customer or whatever it is that you were looking to do?"
Samuel Hulick (35:38):
But instead of just relying on passive customer sentiment kind of things, or looking at like NPS to determine whether people are overall happier or not. What I would recommend doing is to think about, how can you create something that is digital in nature, and therefore has those behavioral risk seats baked in that helps people actually arrive at state B? Or maybe they come to you in state A, and they take your expertise and go somewhere else to leverage it. But when they do, there's a little extra thing that helps them seal the deal. And then at that point, you will have the ability to know that person actually made it there. Because they're leveraging something useful in the moment of arriving at that outcome that you provide. And therefore, you do get that data.
Stuart Balcombe (36:23):
Yeah. That totally makes sense. And I think that's really good sound advice. Figure out which of those modes or which of those places the outcome is occurring and then act accordingly to intentionally track, are people actually getting there or not?
Stuart Balcombe (36:38):
Thank you so much for taking the time to do this. I'm sure we'll have to come back and do a part two, or probably end up part three or four as well in the future. But yeah, thank you so much for taking the time.
Samuel Hulick (36:47):
Yeah, absolutely. Just my biggest recommendation is to identify the outcomes that drive your revenue and to help those outcomes take place more often. That's really the name of the game.
Stuart Balcombe (37:02):
Thanks so much to Samuel for sharing so many insights in this conversation. Here are my top three takeaways from this episode.
Stuart Balcombe (37:09):
Number one, be the best at helping customers, not building software. Becoming the best at helping customers effectively complete a process that gives them the outcome that they desire will always be more valuable than inanimate software. Number two, understanding customer outcomes starts with a conversation. Existing customers who are talking to support and success likely are already giving you the clues you need to zero in on the outcomes they're trying to reach. And number three, driving high net revenue retention is a function of alignment. To produce low churn, long living and expanding customer relationships, what you're really looking to do is to identify when somebody engages with your offering, what kind of situation are they in right now? What's driving them to your offering? And what kind of situation are they hoping that your offering can help them arrive at? And then tuning your experience around facilitating that transformation.
Stuart Balcombe (38:07):
If you enjoyed this episode, I'd love to hear from you. Drop me a note, stuart@arrows.to. Or reach out to Samuel @SamuelHulick on Twitter. And let us know what you think. Thanks so much for listening.