Audience: software CEO’s, product leaders, engineers & investors.
Much has been written about Product Led Growth (PLG) in recent years and in the last 12 months in particular. It’s in the zeitgeist. Most of what’s been written is focused on startup founders, rather than product leaders in established software companies. It’s also mostly short-form and surface deep. I won’t regurgitate information that’s amply covered in other posts/publications, but in this discussion I’ll cover in some depth elements of PLG that are often overlooked by the punditry.
The main concept under discussion in this article is the use of PLG in established software companies that haven’t built themselves up around PLG from the beginning (you know… the majority of B2B software companies).
Popularized by consumer SaaS companies like Evernote and Dropbox, with roots that go back to the shareware movement of the 80’s and 90’s, PLG is ever-more relevant in B2B SaaS. Why? Because it substantially lowers CAC and does great things to your LTV/CAC ratio. If you’re not already tracking your discrete CAC ratio and LTV/CAC, stop reading now and go and read about those concepts. Someone in your finance team probably is, but as a product leader these should be first-class metrics in your world, particularly if you’re going to embrace PLG, as PLG moves part of the P&L responsibility onto your team. Ben Murray, “The SaaS CFO” has some terrific content on both topics.
There are a few different models for thinking about PLG, here are some of the most frequently encountered:
Freemium: this is the quintessential PLG play. The basic idea is to deliver a free-forever, but in-some-way limited, version of your product that provides a straight-line upgrade path to a paid tier. Think 5 GB of free storage on Dropbox, syncing 2 devices on Evernote, or hitting the free message cap on Slack;
Free trial: the venerable free trial is the grandfather of modern-day PLG (and itself is the descendant of shareware). It’s tried and true, and considered by many to be dated, but works in lots of scenarios.
Feature-limited: this is similar to, but slightly different from the freemium offering. In the freemium offering, the user usually gets the full product experience but are limited by quantity on some vector (# of GB, # of devices, etc). In a feature-limited model however, your users get some functionality on a free-forever basis, without access to some other set of features or modules that are locked behind a paywall.
Orthogonal offering: I haven’t found a better term for this idea elsewhere, so I’m coining this term. The basic concept here is to 1) identify a “technology dabbler” who has the ability and propensity to bring your technology into your target organization; 2) identify some pain point they have (big or small); 3) build a free tool that solves that pain; 4) achieve brand awareness and love by doing so; 5) have a high-octane pool of leads to sell your core offering to (through either self-serve or sales-assisted tactics).
Each of these PLG approaches have pros/cons. Given that in this article I’m attempting to address the adoption of PLG for an existing business, I’ll focus on that angle.
If this article is TLDR, then here’s a summary:
For those who want to go a bit deeper, here’s some perspective on these approaches:
1. Freemium
Freemium is pretty well understood at this point. You have a product that is free for most users and use cases, that triggers a user to convert to paid when a certain threshold is hit.
1.1 Freemium Pros:
Fast time to value: because your users are getting the full product experience, they (hopefully) can extract value from your offering almost immediately. If there isn’t fast time-to-value, freemium may not be a great fit for what you’re selling, or you might be executing it poorly.
Gets them hooked: because they’re using the full tool, your users are more likely to embed it in their daily workflows, which puts the hook deeper in their metaphorical mouth for the inevitable upsell. Slack was a great example of this: they gave the full tool away for free, and only popped a paywall once a user’s message volume exceeded a threshold. Their users were already “addicted” to the tool before they prompted them to pay.
Aligns payment with value: when done properly, the incentives of the user and the company are aligned. i.e. users are only asked to pay once they’re truly getting value from the offering as evidenced by them bumping up against the paywall (think, using lots of storage on Dropbox, or reading more than X articles here on Medium). If users are already getting lots of value from your offering, they’re much less likely to react poorly to hitting your paywall.
1.2. Freemium Cons:
Its expensive to run: When you think about delivering a freemium offering, you’ve got to account for all of the costs of running it (this is especially important in calculating a fully burdened CAC figure as part of your LTV/CAC analysis). The costs of running a freemium offering vary based on your application type, but are nearly always going to include cloud compute, storage, and networking fees if you’re a SaaS company (if you’re building on-prem software only, see the building costs below). In most SaaS companies, this is going to be about 15–25% of the revenue you’d derive from a paying customer (if it’s not, make sure your pricing model has been well thought through and that your non-standard gross margin has a good justification).
It’s expensive to build: a less obvious cost of the freemium model is the engineering cost associated with building it. Obviously the gross R&D costs for the freemium effort will be well known, but what of the true net costs? What per cent of your prod/eng budget is being used to build freemium features that are only used by your non-paying users? You need to account for this in your CAC analysis. If your freemium offering has 20 features, and only 2 of them are correlated with users converting to a paid tier, then 90% of your engineering budget isn’t driving revenue. This point also highlights the type of data you need to gather from within your product: usage information by feature and conversion information by customer type. If you aren’t tracking those things, then you can’t properly size your freemium R&D costs and you need to look into product instrumentation. This might not matter in a start-up when you’re throwing your ideas against a wall to see what sticks, but in a business where you’re accountable for your R&D spend (particularly on a new initiative like PLG) it matters.
Its very hard to retrofit: I haven’t read anyone else talking about this, but if you’re an established software business (cloud or on-prem) this is a core consideration: you can’t easily take an established paid-for product and make it freemium. Why not? Firstly, because you’ll probably cannibalize your revenue streams, and that’s usually a non-starter. Secondly, because the user experience will probably be crummy. Taking a product that wasn’t built with a freemium model in mind and converting it to freemium usually results in a kludey experience for the user. Crummy user experience == low conversions == failed PLG experiment.
Success can be punitive: you’ve launched a freemium offering, it’s gone viral, and a million people are using it. Great right? Not so fast. What are your COGs on this? You need to account for these and load them into your CAC calculations for your main business, which means you’ve just increased your CAC and dragged down core product sales efficiency metrics. If you don’t get your paywall triggers just right this is going to be painful. I don’t know what Dropbox’s COGs bill looked like early on when they had millions of free users using lots of storage and limited premium paid-for offerings, but it can’t have been pretty. If you’re a startup with oodles of VC cash and no concern for profitability like they were, then that’s awesome. For product managers in established software companies though, that’s not usually going to be the case.
So who is freemium best for? Green-field startups usually. It’s pretty hard for an established software company to adopt freemium effectively. That’s where the orthogonal offering comes in (see below).
2. Free Trials
Everyone knows what a free trial is, and it’s a useful PLG strategy, particularly as an entry point. But its got lots of downsides and is a lazy approach to PLG.
2.1. Free Trial Pros:
Its well understood: pretty much every user on the web understands, and expects, the free trial. Although interestingly, there is an emerging trend away from this (see Outreach.io for example as an example of a white-hot company that doesn’t do trials).
Easy to implement: you can take pretty much any product and add a free trial offering to it. But just because you can, doesn’t mean you should (see below).
2.2 Free Trial Cons:
Not tied to value: in a free trial, you pop the paywall at the expiration of some period of time. It’s pretty arbitrary, and isn’t (necessarily) aligned with the user extracting value from your offering.
Timing is hard: Just like it’s almost impossible to time the stock market, it’s pretty hard to time your trial expiry optimally. Lots of A/B testing is what’s called for, but most companies don’t have the infrastructure to effectively and repeatedly test trial offerings. So product managers pick an arbitrary time period (usually 30 days) and hope for the best. Rarely is 30 days the time of peak appreciation for your offering. So this strategy really boils down to hoping your user gets hooked on your product and that after 30 days you’ve become an (indispensable) part of their routine. Incidentally, if you’re not already doing A/B testing on your product, Optimizely and VWO are great tools (if like most of us your product is web-based… if its desktop software there aren’t many off-the-shelf options).
They’re obnoxious: I don’t think anyone has fond memories of popups from their AV vendor of choice reminding them to convert to paid toward the end of their trial, nor of the ceaseless drumbeat of email spam or sales calls that arrives as the deadline approaches. This means that you’re at risk of souring your users on your brand right at the very time you’re hoping for a moment of peak attraction. It’s misaligned. The alternative is to not popup or email or call, and that will inevitably mean fewer conversions and a less successful PLG strategy. Not a win.
Products often aren’t trial-suitable: if a software product hasn’t been built with a free trial in mind, then it is probably not suitable for a free trial. Why? Because in the real world products have all sorts of rough edges, and under-developed features. Free trials put all that in the user’s hands, without guide-rails, and lets them discover all the good and the bad stuff about your product.
You’re on the clock: given that you’re asking the user to pay after a given amount of time, you’re on the clock right from when the user opts for your trial. This is an acute consideration if your product has some setup complexity that has a time cost or an effort cost. If it takes the user 7 days to set your product up, that can really kill the momentum of a trial. As an aside, if your product has a delayed time-to-value, you should really look at that and determine if it’s a requirement of your offering (e.g. an ERP), or poor execution on your part.
As a follow-on to that last point, it’s worth highlighting that products which require lots of integration, like ERP or a disaster recovery product, don’t lend themselves well to free trials. Explore providing a sandbox environment to your prospects instead.
Why use a free trial then? Well, if you’re an established company and you can’t afford to adopt a freemium play (because the implicit or explicit costs enumerated above are too high) the free trial can be a legitimate option. Just know that its sub-optimal as you’re going into it.
It’s also pretty easy to implement. Take your entire offering, build in a time bomb at the 7 day or 30 day marker, and throw it out into the wild. Just don’t expect great things from it in terms of user-driven conversions. But do think about it as generating a decently qualified MQL that can be fed into the sales machine.
3. Feature Limited Offering The feature limited offering is pretty common in enterprise software. You let the user see and even interact with advanced functionality from a free tier or low cost tier, but you prevent them from using said functionality without upgrading to that module. This might be combined with the free trial tactic in that the user could have access to the advanced feature for 7 or 30 days before it gets walled off again.
3.1 Feature Limited Pros:
Aligned with value: like the straight-line freemium offerings described above, the feature limited PLG strategy aligns value with payment.
Encourages product exploration: because you’ve ideally allowed the user to see the advanced features, and potentially even tinker with them, they’ve got some concept of the value that’s sitting behind the paywall and are more likely to buy.
3.2 Feature Limited Cons:
It requires exploration: the exploration concept is a two-edged sword. In many cases users won’t find the advanced features on their own and your conversions will stink.
Doesn’t deliver value: In the most common form of this tactic, the advanced features simply aren’t available to the user. Think about Salesforce’s advanced functionality as an example. It’s cordoned off and not even visible to the low-tier user. Without the user getting value from those features, they’re not super likely to buy them.
You’re holding back awesomeness: Definitionally, with the feature limited approach, you’re not giving the user the full power of your platform. To me, this is the killer of the feature limited approach: your users don’t actually get to experience the best you have to offer. Why adopt a strategy where you’re not putting your best foot forward? So when should you use the feature limited approach? When you’ve got a sticky customer and a big or relevant brand (in the customer’s mind) and there’s already trust that you deliver solid product. In general though, this isn’t a smart approach to PLG and is just a disguised sales-driven approach. If you’re going to adopt a feature limited offering, then at least pair it with the free trial concept to ameliorate some of its weaknesses.
4. Orthogonal Offering
This is my favorite PLG tactic for established software companies. Given that I’m introducing that term, led me describe the approach.
The essence of this tactic is to:
Identify an influential “technology dabbler”: Find someone in your target organization who 1) has the ability to buy your core product; or 2) influences the person who can buy your core product; and 3) has the ability and the propensity to bring technology into their organization. I call this person the “technology dabbler”. They’re typically early adopters who like to play with new tools (rather than inherently seeing new tools as a hassle like many folks do). This person is often going to be a younger team member than the person who buys your main offering. If the CFO buys your ERP platform, then you might here be targeting the young finance staffer who’s got pain around their current FP&A tools (which is probably Excel!)
Study: analyze and empathize with this user. Dig into the challenges they face on a day-to-day basis. Do 10 interviews, being two apiece with 5 folks, 30 days apart so you’ve got time to think between sessions. You’re not looking for challenges related to what you sell necessarily. You’re just looking for problems they face regularly. Ideally the problem(s) you uncover are 1) frequently encountered; 2) annoying to the human in question; and 3) not solved by commonly-available tools. You’re looking for the inverse tooth-brush test here: not a product they use every day, but a problem they encounter every day, or frequently.
Build a tool for them: this is the easy part. Build a tool that scratches the itch identified in the previous steps. In an ideal world, the tool you build will give you insight into how close to your ideal customer profile this organization is for your main offering. The free offering doesn’t have to be in the same problem domain as your core offering, but if its correlated, that’s great. If you’re selling BI on top of ERP’s, having a free tool that tells you about a user’s ERP and its complexity would be cool.
4.1 Orthogonal Offering Pros
Easy to build: because you’re building something new and fresh it’s (relatively) easy to build compared to the other freemium approaches. You can use the latest and greatest technology. You can start from a clean slate in terms of design and not be encumbered by your existing product’s mental model or technology stack. You don’t need to worry about breaking anything.
Small surface area: you’re attacking a small and discrete problem in this approach. You’re not boiling the ocean. This makes it much easier for your PM’s and engineering to wrap their arms around it and nail the solution.
Low risk to the user: you’re not asking the user to invest much time (as you’re implicitly doing with a free trial — “hey, try this, it’ll take 30 days for you to love it”), nor are you asking them to put a credit card on file or really risk much at all. If your free tool isn’t useful, they’ll discard it, no harm no foul.
Creates brand love: if your free tool does solve their problem, you’re going to go a long way toward creating love for your brand inside your target organization.
Leads to virality: Your core offering may not be viral at all inherently (think the ERP example referenced above). But your free tool can be extremely viral, either just because of word-of-mouth (think TeamViewer) or because its got virality built into it. Virality is a pretty core concept in the PLG world, and you can build it into your orthogonal offering in a few ways: 1) build in some basic collaboration features ala Trello; 2) build in some beautiful analytics or reporting that users will be prone to share within their org (or even publicly like Canva users do with their Canva-made creative assets); 3) reward users for spreading your tool to others by giving them extra credits for your paid offering (like AirTable).
Should be cheap to operate: because you’re building a discrete tool with a small problem surface area, you can and should architect it so that it’s got low ongoing operating costs. With this approach you don’t need to be afraid of success the way you can be with freemium offerings. You’re probably not going to rack up millions of users sucking down substantial COGs like say… Dropbox’s 5 GB freemium offering.
Easy to experiment: Because you’re not mucking with your core offering, and you’re (probably) not having to use existing code or infrastructure, you can be nimble and move quickly and try different things. You can even build multiple tools and have a suite of free offerings you provide. Quest Software did this very well with TOAD (although that was an open source product that was pretty complex that they acquired… so not a perfect example). The fact that it’s easy to experiment is a major benefit to the established software company. It’s the opposite of a long-term re-architect approach where you place a large bet on moving to freemium, and tons of engineering work in pursuit of a strategy that might just not be applicable to your domain, customer or vertical.
At my previous company (www.infrascale.com), our take on the orthogonal offering was a storage analyzer/estimator. We used free trials, experimented with freemium, and also used the feature limited tactic. They were all “OK”. My favorite approach was the orthogonal product. We were selling cloud-based disaster recovery software which usually required the CIO or equivalent to sign-off on as a purchase. But we figured out that the storage admin (either in-house or at a service provider), who was an influencer in the decision for the org to buy our core product, had a pain point around answering the seemingly simple question of “how much data do we have?”. So we built a tool that rapidly discovered data on a host and made it easy for the user to share the analysis whilst also feeding that data up to the mothership. This did a few things: 1) created brand awareness/love; 2) gave us insight into how much storage a given org had, which was strongly correlated to how much disaster recovery they needed to buy; and 3) led the user to share reports on storage usage, which virally spread our brand around within the target org. The result was a pool of extremely qualified leads, with good intel on the storage environment of the organization, that resulted in high conversion rates. And the estimator cost peanuts to build and had no ongoing operating costs. Win/win/win. We moved away from using it in favor of the feature-limited and trial tactics, but that was a mistake in retrospect.
By the way, you don’t have to build it yourself. Think about what Atlassian has done with Trello. Trello didn’t do a good job of monetizing itself when it was a stand-alone freemium offering. But within Atlassian, it’s a great source of leads. It’s a free tool that 1) appeals to Agile-minded folks; 2) is frictionless to adopt; 3) is fully-featured and doesn’t hide value; 4) has built-in collaboration features and inherent virality. Net result? A pool of super qualified leads for Atlassian to sell their more hardcore Agile software products to like JIRA.
4.2 Orthogonal Offering Cons
Not many: If approached as described above, there really aren’t many cons to the orthogonal offering.
Financial risk: There is always the risk that you’ll miss the mark with the tool, and whatever you sink into it in terms of R&D is wasted. But this risk applies to all of the PLG tactics described herein.
Brand risk: Similarly, there’s a risk of hurting your brand if you build something that is crummy, but that’s true of all product development. Diluting your brand is a more likely risk, and this can be mitigated by choosing your “dabbler” appropriately, and in choosing the right problem to solve for them.
On balance, the orthogonal offering is an easy-to-adopt PLG tactic that 1) can be implemented quickly and cost-effectively; 2) without much brand or financial risk; 3) in a way that enables experimentation (which is key to PLG success); and 4) with decent chances of success for an established software company that can’t easily adopt the straight-freemium model.
Thanks for reading, and please post comments and thoughts below. Would love to hear from you.
Cheers, Ken
About me: I’m a software engineer by training and a software leader by profession. I’ve led two SaaS companies as CEO. I’m passionate about product & believe product management is the highest leverage activity a CEO can participate in. I’m planning to be here on Medium writing mostly long-form posts on topics I’ve got experience in, mainly #SaaS, #Product, #Startups, #Offshoring. This was my first post, thanks for reading!