What Is Product-Led Growth and Why Is It Critical for API-First Companies?
An overview of product-led growth (PLG) and why API companies need it to appeal to developer customers.
Join the DZone community and get the full member experience.Join For Free
There’s a common misconception that product-led growth means a business doesn’t focus on sales. That’s not the case. It’s just that product-led growth layers in sales later in the customer journey. This can be a hugely effective approach, particularly when it’s combined with deep data insights to drive that growth.
For API-first companies, this product-led approach is a cornerstone of success. We’ll dive into the detail of why it’s so critical below, but first, let’s start with the basics…
What Is Product-Led Growth?
Product-led growth is precisely what the name implies — it is where acquisition, activation, expansion, and retention is led primarily by the product. Customers either use a free version of the product or pay a nominal amount to use it, with sales coming into the equation only after the customer has had the opportunity to see the product’s value firsthand.
With the product-led model, it is the product itself that is driving sales. By using the product, supported by the company’s customer support team and, at the relevant time, its sales team, the customer moves almost seamlessly through the four stages of product adoption: activation, expansion, retention, and adoption.
A Different Approach to Sales
Using the product-led growth model doesn’t mean assuming the product sells itself and having zero sales staff. It just means that sales teams are focused on what people are actually doing with the product, rather than sitting there analyzing target industries and creating ideal customer personas. Their goal is to grow the accounts of existing customers, rather than to sell to cold prospects.
By layering sales in at a later stage of the customer journey, the nature of the task fundamentally changes. There is less effort required to pitch the product, as customers are already familiar with it and the value it can provide, so the effort of pushing something new is removed. Instead, sales work becomes more about creating more value for the organization. This could be getting additional teams to use the product, increasing its usage, or finding additional use cases so that customers move up to a higher value plan.
There is a strong link between sales staff and customer success teams when it comes to product-led growth. Customer success staff are dedicated to ensuring that customers get the best out of the product — that they understand its value, how to utilize it fully, and how it can be of maximum benefit to their business. While the focus is on ensuring customers get value, rather than making a sale, that showcasing of the product’s potential can result in deeper integration and growing usage. The product becomes increasingly critical to the customer’s success.
Why Is Product-Led Growth So Important to API-First Companies?
Product-led growth isn’t suitable for every business. If you’re selling solar panels, for example, the upfront costs and installation process preclude using a product-led growth approach. However, for API-first companies, where the cost and effort of enabling a customer to try the product are minimal, the product-led growth model can be particularly effective.
One reason for this is that they are selling their products in a sector where buying has become much more decentralized. Individual developers will be looking for solutions that suit their particular use case and that they can trial for minimal cost. Those same developers are often skeptical of sales and marketing teams, so the hands-on nature of using a product before making any major commitment to it works on multiple levels.
Selling to technical teams as a whole can be hard. They have a constant stream of higher priority tasks to juggle and you’re battling the "not invented here syndrome" when trying to introduce something new — along with the fact that many developers are naturally inclined to wonder if they can build it themselves when you try and sell them a new product!
Product-led growth cuts out this uphill battle and replaces it with engineers discovering the product in their own way and at their own pace. Provided the integration is easy, by taking a product-led approach, API-first companies are empowering individual developers to make decisions around the API solutions that work for them. And once the developers are on board, conversations with the C-suite execs become that much easier.
Selling to Developers
Providing a developer with a quick and cost-effective way to trial an API means they can experiment with it and prove the concept. A product that’s affordable on a trial plan means popping something on a manager’s credit card, rather than going through an onerous procurement and legal review process. API-first companies that get their pricing and swift integration right can hugely reduce the friction involved in getting their product through the door.
This isn’t about bypassing procurement altogether; far from it. It’s about providing developers with an easy opportunity to get to know the product — to experience it firsthand and see what a good fit for the business it is. Give them click-through terms of service, fast integration, and a price that they can pop on a manager’s credit card, and you’ve laid the foundations for a small proof-of-concept trial that has the potential to deliver a sudden skyrocketing of volume further down the line — with all the associated procurement activities undertaken and legal hoops jumped through at that later stage, naturally.
Getting Billing Right
This style of product-led growth requires some thought around your billing model. This is where usage-based billing comes into its own. A developer can pay a token amount to get started with the product and trial it in their test account while they complete their proof of concept. After that, when the developer takes the product into production, the usage-based billing model needs to scale alongside the customer’s growing usage.
APIs are a natural fit for this pay-as-you-go style of billing, as there are various ways that their use can be tracked. Just be sure that you’re using the right metrics! Broadly speaking, value metrics can be focused around:
- Transaction volume: Number of API calls, messages sent
- Revenue/cost share: Percentage of revenue, transaction fee
- Data volume: Gigabytes sent, minutes made
- Users: Monthly active unique users
- Resources: Compute units, active hours
These examples hint at the huge variety that can be built into usage-based billing. They also highlight the complexity of getting billing right.
Take the example of an email automation API that allows customers to create email templates and send emails to leads. Usage-based pricing centered on the number of templates could see the customer store 1,000 templates and send zero emails. The customer would get zero value from the product while receiving a huge bill, making them a very high-risk customer. Bills based on the number of emails sent or different contacts reached out to, however, would be closely linked with the customer getting true value from the product — and thus more likely to continue using it. This is why implementing the right value metric(s) is so important.
Using data to drive your sales is key here. The support from your customer success team needs to merge seamlessly into conversations with sales at just the right point in the customer’s growing usage. For that, API-first companies need data.
With tracking in place for account health and usage growth, sales teams can open discussions with customers at just the right moment to ensure that the customer gets more value out of their product. They can create a plan that factors in both current usage and future growth plans. That's why it's best to have an API analytics solution that tracks usage data and flags key customer milestones.
But tracking usage data isn’t just about finding the right sales moment. It’s also about ensuring that the customer doesn’t get hit with an enormous surprise bill following an increase in usage — and then cancel due to the unexpected jump in cost. Instead, a well-timed call from a salesperson to discuss a more appropriate plan can ensure the customer feels they’re still getting value for money, even if their bill goes up.
How to Engage Developers with Your Product
API-first companies that are looking to their products to lead their growth don’t have to sit back and wait for developers to discover them. They will need to proactively market the product to ensure that developers hear about it and see enough potential in it to try it out.
This means a whole heap of investment into developer experience needs to go into encouraging initial engagement with the product and into making it easy for developers to carry out that first proof of concept. That can be achieved through a mix of tutorials, demos, technical documentation, blog posts, webinars and more. Content of this nature becomes an integral part of the sales funnel, because it supports developers to trial the product in the first place.
Ease of use becomes a top priority with this product-led model. From sign-up guides to integration walkthroughs, onboarding needs to be super easy, as every stumbling block reduces the potential for the product’s success. At the same time, the onboarding and trialing process needs to be as self-service as possible; otherwise, it’s not easily or rapidly scalable.
Again, the pricing and packaging model is important here. A self-service trial can be used by a wide spectrum of companies, so billing options need to be built around a huge variety of needs. At the core of each of those models, though, needs to be a low price to activate customers initially and support them to engage with the product. After that, once they realize how valuable the product is to their business, it’s time for API-first companies to let their sales teams work their magic.
Published at DZone with permission of Derric Gilling. See the original article here.
Opinions expressed by DZone contributors are their own.