Table of Contents
- Sections
- (00:29) What Is Self-Serve SaaS?
- (04:19) A Digital-Native Sales Model
- (09:34) How Customers Want To Buy
- (11:46) The Unit Economics of Self-Serve
- (14:16) Scaling Self-Serve vs. Scaling Sales
- (29:01) An Alternative to Sales-led Or Viral Growth
- References
- Hunting Mice Vs. Hunting Whales
- David Skok's Cash Flow Trough
- Transcript
Do not index
Do not index
Self-Serve customers produce the most scale-friendly cash flow in the SaaS game. But what does it take to scale revenue with self-serve? And how does it compare to scaling with a sales team instead?
Sections
(00:29) What Is Self-Serve SaaS?
(04:19) A Digital-Native Sales Model
(09:34) How Customers Want To Buy
(11:46) The Unit Economics of Self-Serve
(14:16) Scaling Self-Serve vs. Scaling Sales
(29:01) An Alternative to Sales-led Or Viral Growth
References
Hunting Mice Vs. Hunting Whales
To visualize the scale of the different kinds of customers that a SaaS company can go after, Christoph Janz put together a helpful chart in 2014:
The original post: http://christophjanz.blogspot.com/2014/10/five-ways-to-build-100-million-business.html
In the context of the episode, however, we use the chart to talk about how companies tend to go upmarket (towards the Elephants) to unlock revenue growth. Fly- and Mouse-segments aren't seen as legitimate revenue growth levers despite being the most scalable.
David Skok's Cash Flow Trough
If you need a sales team to sell your software, you have to plan for a cash flow trough that looks like this:
From David Skok: https://www.forentrepreneurs.com/saas-economics-1/
In a self-serve context, however, this cash flow trough looks very different because 1) you don't have sales salaries to account for and 2) enterprise value to put together.
Transcript
Transcript
Samuel (00:00:24):Hi, I'm Samuel from UserOnboard.
Yohann (00:00:26):And I'm Yohann also from UserOnboard.
Samuel (00:00:29):And today our episode is all about our three pillars for healthy growth. And we will get to the three pillars in painstaking detail later in the show, but to kick things off we wanted to start by defining what healthy growth means to us. And to me personally, healthy growth is growth without the hacks, that you're not trying to come up with engagement hacks for just mashing more people into your product over and over again, or certainly not trying to get people addicted or creating habit loops around products that aren't actually delivering on their end of the value proposition or things along those lines. Anything that subverts the user's best interest for the sake of driving engagement, I would generally call unhealthy growth, in part because it's unhealthy for the users, and also because I also truly believe that it's unhealthy for the business. If you're wanting to take a long-term and sustainable approach to your own growth. Would you add anything to that Yohann?
Yohann (00:01:46):The only thing I would add is this perspective of means and ends. If you're thinking of growth as an end that you achieve no matter the cost or no matter the means, I think that's an unhealthy way to approach it. The means matter, the how matters, and you want to achieve growth in a way that is not just sustainable, but also accounts for how it comes about.
Samuel (00:02:16):Can you share a little bit more on that?
Yohann (00:02:18):I can give you an example there. Say you want to lose weight. If that's your goal, and that's the end, and you're saying, "I'm going to achieve this end no matter the cost. I'm just going to stop myself or just eat under the number of calories that I need per day in order to achieve this," it's not very healthy and it's not very sustainable. You want to think about the end in terms of sustainable means that don't deplete...That don't reduce you down to nothing. In software terms, reduce you down to nothing would correlate to reduce your product down to hacks that engage users but don't help them make progress.
Samuel (00:03:07):We're not operating casinos or slot machines.
Yohann (00:03:13):Right. You don't want small term wins, you want the long-term wins. You don't want this to just work for the next month, you want to extend that growth out to a longer period of time. And even if that means making a few sacrifices in the short term, that's okay because you know that you're building something more sustainable.
Samuel (00:03:37):Yeah. And that's not just like hippy dippy kumbaya, it wouldn't it be great if apps were better for users kind of a philosophy. That's very much a business perspective as well because a lot of times you're looking at the what's called CAC Payback Period, CAC an acronym for cost of acquiring a customer, how long it takes for your users to pay 100 bucks a month or whatever your subscription revenue or otherwise user generated revenue would be. It's going to take a while for them to pay off how much it costs to get them as a new revenue generating user. So you don't want to just be trying to trick people to come back on day two because you've noticed that people who come back the day after they first log in, tend to correlate with better conversion rates. Yeah, superficially that's true. But you've got to be thinking about how do I deliver value over a long term and become part of long-term processes in their life so that my product continues to be relevant to them. Because if not, they're not going to use it, they're not going to get value from it and they're going to turn.
Yohann (00:04:49):Right. And the systems you have in place to measure how that's happening —this might be a slight tangent— but when you have systems of measurement where you're tracking monthly targets and you're saying, "I need to meet my target this month," you're willing to do things to sacrifice next month's target in order to make this month's target look good. And that's the kind of thing where we're leaning against. You want to think about this in terms of trends and have every month trending in an upward direction, irrespective of the spikes from month to month around the trendline.
Samuel (00:05:30):And when you say trends, you don't mean trends in the industry or trends in your market. You mean the way that the effectiveness of your offering is trending, the reliability with which it produces value for your business and for the users.
Yohann (00:05:50):Yes. In graphical terms, you want the trend line to be moving up and towards the right. That's the kind of trend I'm talking about.
Samuel (00:05:58):Yeah, exactly. So, perhaps that's a convenient segue to outlining what, in our opinion, are three pillars for approaching growth more in the fashion that we do recommend, and less in the fashion that we just walk through. And those three pillars are what we currently call "Path Design," another pillar is called "Performance Valuation", and another is called "Super-Outcomes". And we will go over each of those in detail, but they all work together in a high level degree as well. So we wanted to cover each of those at a very high level first, then we'll do a deep dive on each of them. So Path Design is a concept that we view as being underrepresented in the product design literature. It's a difference of paradigm where you might be thinking of creating a valuable product that you have designed well, that you can then provide access to to users and make money off of it. Or you can be thinking about why your users are finding that product to be relevant and thinking about the process that they're bringing that product into and engaging it in and designing for the whole path, the whole process that makes that product relevant to begin with.
Samuel (00:07:33):So from that perspective, that's what we call Path Design. And from a Path Design standpoint, we ask questions like where are users trying to get to and what are all the steps that they need to go through in order to get there? And how much support is your product or offering providing to them step over step to be able to actually make it through kind of the obstacle course of what we referred to in the last episode, making pancakes or whatever kind of process that they happen to be engaged in at that time. So a lot of those kinds of considerations would take place under Path Design.
Samuel (00:08:16):Performance Valuation on the other hand is a different beast. Yohann, do you want to start this one off?
Yohann (00:08:23):Sure. Once you have designed the path, or once you have a path that you're analyzing, you want to measure how many people are making it from one stage to the next. And you can get really granular with how you do this. And we will dig into this granularity further into this episode, but at the moment, one big concept that I want to mention is that apart from just measuring how many people make it from each step to the next, you also want to assign a value to that whole process. And in the last episode when we talked about how to turn revenue into a leading metric, this is essentially what we're talking about. If you can assign a certain dollar value to people making it through the path, and you know the number of people that are actually making it through that part in average, and where they're dropping off along that path, then you can make very accurate guesses about how the path is performing. And how you expect the path to perform forward in time.
Yohann (00:09:37):So at a high level, we're not just talking about measuring performance, but we're talking about valuing that performance at a certain dollar value, and that helps you make changes to the path and measure the revenue impact of those changes as well.
Samuel (00:09:56):I love the description. I have nothing to add to it. I'm locked in.
Yohann (00:10:00):Okay. And that leaves Super-Outcomes. Samuel, all yours.
Samuel (00:10:04):Super-outcomes is the term that we use for when you can get users to a particular valuable outcome or milestone that they're seeking. So back before when we were talking about CAC payback and having users stick around long enough to actually pay off the amount of money it cost to acquire them (and then hopefully stick around significantly longer so that they can produce revenue for you in their subscription or whatever their usage is). In that same way, you have to be focusing not on the outcomes or user behavior that takes place within your product... It's not going to give you those kind of bigger contexts in which your product becomes relevant. And when we talk about designing an entire path around a particular outcome, you really want to be specific about which outcomes you select because it does take a lot of effort and rigor to design an entire path and to evaluate its performance and to tune it and iterate and improve over time and have it trending upward as we were discussing before.
Samuel (00:11:19):So you want to be really selective in which outcomes you're designing for. And to start with, they're not outcomes that take place within your product, they are outcomes that take place exterior to your product that bring your product into someone's life. So there are a number of other considerations that make it either more or less reasonable of something to invest your time toward. And we will dive into those in richer detail when we cover it in the deep dive. But between the three, Path Design, which is all about designing across an entire process instead of designing a single state product, Performance Valuation, which is all about being able to measure the impact that your changes to the product or to your offering or to the path, are having on key outcomes for both the users and for your revenue. And then we also have the concept of Super-Outcomes, which is getting really specific about what those outcomes for the users are that really drive the most revenue, have the healthiest LTV, pay CAC back faster, etc. So all three of them work together and we are going to dedicate the rest of this episode to talking about each of them in more detail. Unless you have anything else to add to the overview, that is, Yohann.
Yohann (00:12:49):I would like to say one more thing about how they work together and that thing is the deeper you get in each of these, the better you can do the others. One thing we see is that people think about these things as separate. Path Design is usually constrained to in-app flows and it's usually a design problem. So marketing, who's thinking about super-outcomes that they should put on the homepage like value proposition, how do we get people to care about our product kind of stuff, they're not thinking about the path, they're not thinking about how that marketing material tees people up for product use later on.
Samuel (00:13:33):Well, and generally speaking, the product people are not thinking of how do we take the baton of what marketing inspired people to do and actually fulfil the rest of our end of the value proposition and confirm that people are actually getting what we're advertising.
Yohann (00:13:51):Right. And on a metric level, each team is so focused on their own metrics that the more you zoom out, the more aggregate the metrics get. So if you zoom out and look at a CTO, for example, the kind of metrics he's tracking are all aggregates of the impact of different teams. So we see each of these pillars treated — 1) superficially and 2) in isolation. And what we're trying to do is not just bring them together, but point out how achieving a certain depth within each of them can help the other two pillars perform better. The better and more specific you can get with a superior outcome, the better you will be able to design a path later on. The better you analyze a drop-off between steps in the path, the more specific you will be able to make your Super-Outcome. Things like that. To use a terrible word here, there's a lot of synergy between these three pillars.
Samuel (00:15:04):That was the word. I was like, "Samuel, don't use synergy. Samuel, don't use synergy." Alright. I agree. So with that in mind, let us boldly proceed into diving deep into each of these three pillars. First one up Path Design. Yohann, would you care to tee this one up?
Yohann (00:15:26):With pleasure. So when you're thinking about a path...think about your geometry class and your introduction to geometry. Drawing lines and making triangles and so on was thinking about points. In the same way, when thinking about paths here, we're going to think about points — starting points and resulting points — because a path is just a connector between two points. And even the term "starting" and "resulting" is contextual because what's a starting point in one particular context is a resulting point in another. The signup page, for example, is a resulting point in a marketing meeting, but it's a starting point in a product meeting. That's the kind of thing I'm talking about. Anything to add here, Samuel, before I keep going?
Samuel (00:16:25):I think that you put that quite well. I would agree that the idea, it's called Path Design, but really the point is to make it more likely that people generate the desired outcome, which is the end state of the path. So the point, let's say, I mean, to use an ultra basic example, let's use the user interface of a light switch as an example. If I become a user of a light switch, it's either because I probably want to make the room darker or because I want to make the room brighter. And depending on which direction I flip the switch, I will be changing the status of my situation. So if I am sitting here and I'm ready to go to bed and I go to flip the switch because I'm going to bed, then contextually speaking, the resulting state that I'm seeking is to have a darker room so I can go to sleep. Is that a fair example?
Yohann (00:17:31):Yes. I think that's a great example. Yeah. So you're working with resulting points and these resulting points are outcomes. And when you're designing the path, you're kind of working backwards from these outcomes to figure out how you can make those outcomes happen more reliably. But that being said, you're also working forwards because your starting point is defined by conditions that users have at the moment. And you have to meet them where they are. So you're working-
Samuel (00:18:12):Strongly agreed.
Yohann (00:18:13):You're working forwards from where users are at the moment and backwards from where you want them to be.
Samuel (00:18:19):Yep. The two main things that really stand out to me in what you just said is that you always want to have a general idea of what the user's state is so that your system can guess what their desired state is, and then organize it's experience around forming a path that guides the user to that desired state, rather than just saying, "Hi, I'm a product. And if you learn how to use me, then you can hopefully get there."
Yohann (00:18:53):That's a great segue actually, because it leads me to the next thing I wanted to say, which is that you already have paths. If you have a product, you have paths that your users are working within at the moment to achieve the resulting states that are meaningful to them. But, if you're not thinking about the resulting states themselves, and you're thinking about ... Okay, let me take a step back. If your resulting point is something that isn't in product action or behavior, and if you're optimizing the path to make that product behavior happen more, it's good that you're doing that, but by not focusing on the resulting situation that the user is pursuing, you're kind of forcing the user to do all the work by themselves after they make this product behavior happen.
Yohann (00:19:55):So say you want this button ... sorry, this template, that's a better example. You want this template to be used more. This template is useful because it is helpful in a particular situation like a team meeting for example. You're making a template that is helpful in a team meeting. You want users to interact with the template more so you design a path to make that happen. Users then, once they do make that happen, once they do interact with the template, have to do the work of making that template actually helpful in the situation of a team meeting. And you would be much better off if you thought about the team meeting as a resulting point to design to, rather than the interaction of the template. Does that make sense?
Samuel (00:20:52):What do we want the effect of the template to be on the team meeting? And then just say, let's not even think of it as a template, let's just think of how to get team meetings to be good and the way that we're trying to get them to be good. So if we think about how we can actually produce an outcome for somebody if we have an understanding of what their current state is, the real question then becomes, how do you create the path in between? And what we like to do before thinking about it in terms of screens or interfaces or design patterns, we like to take a step back and look at it as a process instead that has a number of steps. So our background is in user onboarding. If you really look at your user onboarding flow under a microscope, there are a number of different steps that you are asking the user to do, often. Maybe it's to create an account, maybe it's to invite other colleagues, maybe it's to confirm their email address, maybe it's to let you know what the size of their company is and what the industry they're in, or all kinds of different things. And all of those screens that are included in that flow have to be acted out in reality by the user.
Samuel (00:22:24):And if you think of those as a series of actions, especially within the context of generating the outcome that you're looking for, if you have an invoice sending software company and somebody's coming to you so that they can start sending invoices to their clients, and so that they can start getting paid, and you're starting out asking them what kind of industry they're in, or how many people work at their company, or having them go confirm their email address, these are not steps that you would say, "Oh, of course, if you're trying to have somebody get an invoice paid more reliably, you got to start off by having them tell you what their industry is." Because frankly speaking, it's probably not really that relevant to the user in that step. And a lot of times when we look at user onboarding flows, that's like a question that a sales intern put into the flow three years ago, and they're not even there anymore and nobody thought to take it out.
Samuel (00:23:28):So being really, really specific about what are the actions that take place to produce the required smaller changes that result in the desired, bigger change. And our nerdy term for those smaller changes are compounding sub-outcomes where you have the idea of the end outcome, the resulting outcome in mind. And you have to think about given the user's current state, how do you create a sequence of smaller outcomes that compound together almost like crafting in Minecraft, if you're familiar with that, or if you've seen your kids play it or whatever. How do you pull together the right resources at the right time and in the right configuration so that you can produce something that's bigger than any of those individual changes on their own.
Yohann (00:24:31):There's so much to unpack in what you just said, but I think focusing on the term compounding sub-outcomes kind of encapsulates what we're trying to say here. First, we're trying to say that changes are made of changes. So when you're thinking about one of the changes in the path to successful onboarding being users creating a password for themselves, that change is made of smaller changes. First having to click on the form field and then having to find the first letter of the password on the keyboard, and then the second and so on. It's every change is made of a smaller change.
Yohann (00:25:17):So when you start thinking of outcomes as made of sub-outcomes and those sub-outcomes made of even smaller sub-outcomes, you're thinking along the right track of what needs to change. But on the other hand, the compounding side of things is that if you're organizing this path to contain changes, that don't progress the user towards the resulting state, then those changes are just dead weight in this path. They don't make the resulting point happen any easier or any faster. They're there for maybe your benefit, but not for the path's benefit. So they actually detract from the outcome happening more reliably.
Samuel (00:26:16):Correct. Or there could even be things that are well-intentioned but just not relevant to a given user at a given moment, or all kinds of different things along those lines. So the reason that we focus on the compounding part of the compounding sub-outcomes is that you want to focus on what absolutely has to change between right now and the place that I would like to be. So if I want to see my son in junior league hockey, I've got to go buy him skates because he doesn't have skates right now. I've got to go buy him the equipment. I've got to go find a junior hockey league.
Samuel (00:26:56):There are a million different things that I've got to do along the way that I know have to change. And if I was creating software to create the end result of this random example that I just made, I would identify what are the changes that have to absolutely have to take place and in which order, or when in the timeline and think about how I can position the resources that I offer as my software company to boost, provide progress boosts at every point of change. Not thinking about it in terms of like, how can we stuff as many cool ideas and different activities into this process as possible. But how can I just measure the absolute, what I personally call "critical pathway". The most limited, bare bones representation of what has to happen between two points in time and use that as a starting place. Because I think that that leads you to focusing on ideas and having design inspiration that's a lot more likely to actually be of utility to the users rather than, "Yeah, it was like a cool feature idea, but nobody actually cared about it."
Yohann (00:28:19):It was a trap I fell into all the time when we started working together, where you'd be like, "We need to design this thing that gets people X." And I'd be like, "Oh, X needs to happen. They need to do this cool thing and they need to do this activity and they need to work with this worksheet." But I wasn't thinking about it in terms of what actually needs to happen in order for X to happen as well.
Samuel (00:28:44):Yeah. And I think one other aspect of it too is the timing aspect of it, having a real theory of change, theory of how do we actually get people from a common state that they usually arrive in to the desired state that our marketing implies is possible with our products. How do we actually think that that happens and how do we go about breaking that process down and evaluating the resources that we put out through that lens? And there are a number of different design considerations at a UI level that become really apparent when you start looking at your product less as a product and more as sequences of steps in a process. And I could get into that too, but I feel like that's a whole other episode. But the general idea being evaluating the steps themselves and do they even make sense? And can you help create content that resonates with the users on where they currently are and help them advance to where they're trying to get to, and we can just leave it at that. But that's the general gist of Path Design to me.
Yohann (00:30:09):Right. That makes sense. I think that's a good place to leave it without getting more granular, but there is more granularity to get to.
Samuel (00:30:19):So with our due respects paid to Path Design, we now segue over to pillar number two, which we call Performance Valuation. And the main theme here, as you may recall from the intro is that we should be able to track the impact that our design changes have on user behavior and especially user behavior that strongly correlates with the users getting what they want and/or the business getting what it wants.
Samuel (00:30:59):So the idea here being that if you think, "Hey, maybe we should add a tool tip tour to our onboarding sequence, maybe that will result in better things happening." And you just add it, you're not going to know whether that had a positive effect or not, or maybe no effect. Maybe it's bringing the conversions down for all you know. So generally speaking, what we recommend is to start with revenue and not only measure the first time people produce revenue, which is oftentimes going from signup to producing revenue for the first time is often called your conversion rate, that we think it's crucially important, but we also think it's equally important to measure how many people go on to pay a second time, if we're talking like in a subscription model. How many people stick around for a third payment, a fourth month, fifth month, or six months, etc.
Samuel (00:32:01):So that you can actually track how many people are actually making it to a point where your cost of acquiring a customer, your CAC that you're trying to pay back when that actually takes place from a cashflow standpoint. There's no reason not to be tracking these kinds of things. And if you're tracking that, it's the same principles of Path Design, where you're starting with a starting point of signing up and an ending point of let's say revenue one, just for sake of example. If you use cohorts, you can tell whether the percentage of the signups that you're getting in one given week is going up or down as you continue week over week over week.
Written by
