It seems like most products out there either claim to be product-led or strive to become ones.
Product-led proved to be an effective model for growing audiences at scale without the need to engage a robust (and expensive) salesforce. It’s also hard to imagine a different approach for B2C products where directly interacting with and onboarding every customer is infeasible.
However, there’s no single silver-bullet recipe for building a product that works well with a product-led company model.
In this article, I’ll introduce you to six unique approaches to establishing product-led models and explain which model might be the best depending on your situation.
In simple terms, a product-led growth model is a type of business model where the product itself drives all core business activities.
To put it in perspective, the opposite of a product-led company is a sales-led company.
In a sales-led company, your salesforce reaches qualified customers, encourages them to try out the product, works on closing the deal, and ensures that clients expand to higher-paid tiers and don’t churn.
In product-led models, you focus on building a product that can achieve those things without the need for direct interaction with customers.
In order to do this, you need to:
There are six primary product-led models that allow your potential customers to experience your value proposition without the need to engage sales or other human interaction:
Let’s explore each of them.
An opt-in free trial is a time-bound trial during which users can access the full benefits of the products.
In this model, you don’t ask users for payment information upfront. You first deliver the value and then ask them to opt-in to purchase the product by giving you their credit card info.
By doing so, you create a frictionless experience that motivates a wide group of users to sign up for the trial, maximizing your reach and increasing the chances of winning new paying customers.
An opt-out free trial works similarly to an opt-in free trial with one key difference — potential buyers must give their credit card information upfront, and if they want to resign, they need to opt out of the subscription.
Although it might seem like a cosmetic difference, it significantly impacts the whole model.
Requiring users to put their payment information upfront and then to remember to cancel if they don’t like it greatly increases friction and reduces the number of new trials.
There are two reasons why it might be a good thing.
First, if your cost-to-serve free trial is expensive, this extra friction automatically filters users and encourages only truly interested users to start the trial, often positively influencing your acquisition costs.
Secondly, it helps you limit free trial exploits. Without requiring credit card details upfront, it’s easy for people to span numerous new accounts just to get the benefits for free without paying. Collecting credit cards upfront and limiting the trial eligibility to only one trial per given payment limits this fraudulent behavior.
As the name suggests, a usage-based free trial allows users to explore the product to a specific usage threshold before requiring them to pay.
Examples of usage-based limits can include:
It’s an especially useful model if it takes a variable amount of time for your users to experience the product’s value or if it requires a long set-up time.
Let’s take push notification SDKs as an example.
Using a new SDK requires developers to integrate it within the product. Depending on their capacity and development process, it might take days or months.
Also, depending on the number of customers they have and pushes they send, one company can realize the value within a week, while another might need a month or so of usage to see the difference in their business metrics.
A too short time-bound trial wouldn’t allow companies that need more time to experience value to truly grasp the product’s benefits. In contrast, a too long time-bound trial would be expensive to maintain for heavy customers who use the product extensively on day one.
In cases like that, usage-based free trial strikes a good balance.
The freemium model gives users a limited value for free, while requiring them to upgrade to experience the product’s full value.
The model is perfect if you simultaneously meet two conditions.
The first condition is that your product solves distinct beginner and advanced problems.
Beginner problems are widespread problems a larger audience has, while advanced problems are the new problems that appear when people solve beginner problems.
Let’s take Buffer, a social-media scheduling platform, as an example.
The fundamental problem people have is the ability to schedule their content upfront. Buffer solves this problem for free in their freemium offering.
Once users become regular content schedulers, new problems appear. They’d like to level up their game by:
These are advanced problems that Buffer can help you solve, but it requires a paid subscription to do so.
In short, Buffer first hooks you to the platform by helping you solve your beginner problems, and once you are ready to handle more advanced problems, they have your back, but only after you put your money on the table.
The second condition is the ability to cheaply serve free offerings at a scale.
If you lose money on each freemium account in your product, you’ll quickly go bankrupt.
Freemium works only if:
If your product focuses on solving only advanced user problems, and for some reason offering trials doesn’t make sense (e.g. very high cost-to-serve or a one-time usage), you might consider adding a new acquisition-focused product to your portfolio.
For example, a few years back, HubSpot wanted to attract more users to their core offering with product-led strategies, but the cost to serve each customer was too high to offer their value for free.
So they decided to launch a new product, Sidekick (today known as HubSpot Sales).
The idea was to solve a more widespread, beginner problem at scale with the new product, and then, once users get hooked to it, try to convert them to their core offerings that solve more advanced problems for a higher price point.
The underlying idea works similarly to a freemium model: solve beginner problems for free and then charge users for solving their advanced problems. However, sometimes the problems are so distinct that solving both within a single product would be confusing and counter-productive.
The last resort product-led model is to offer a sandbox experience.
In this model, you allow users to explore the full suite of product capabilities in a closed environment with fake data.
Let’s take various product analytics platforms as an example.
A sandbox experience allows users to set up dashboards, analytics, and triggers based on the fake data to get a gist of what they could achieve if they implemented the solution in their product.
The main issue with this approach is that users don’t get an actual value from using the sandbox. A closed environment doesn’t allow them to solve their actual pain points, so there’s no opportunity for a powerful aha moment.
However, it might be the only option for products that have a really long time-to-value (e.g., require months of implementation and usage before getting full benefits).
Choosing the best model for your use case is a context-dependent and complex activity.
To simplify it, I created a decision tree that might help you make the right decision:
In short:
Remember that this decision tree is just a high-level guide to help you with decision-making. Your product most likely has unique quirks and attributes that you should also consider when evaluating which product-led model to pursue.
There are six main ways a product can attract, convert, retain, and upgrade customers without human intervention:
Each offers a unique way for potential customers to explore the product’s value on their own.
While there’s no silver-bullet approach to choosing the perfect model, the decision tree included in this article should be a great starting point for evaluating which models might be optimal in your specific context.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Your product backlog should be a vehicle to drive value but it often becomes a distraction to what really matters.
Brad Power, Senior Director Digital Product & User Experience at Kendra Scott, shares factors to consider in build, buy, or ally decision.
Product managers aren’t perfect and mistakes will happen. However, every issue offers a learning opportunity.
Vamsee Chamakura talks about how his engineering background helps him act as a bridge between different groups in the organization.
Learn more →
One Reply to "6 types of product-led models"
Seems odd to imply that a sales led company wouldn’t do the exact same things a product led one would.