We know the Product-Led Growth darlings Figma, Calendly, Slack, and Typeform. They are highly viral. They are easy to use and require no integration. However, what to do when you have a developer-focused product, such as an SDK? Will product-led growth work? I recently talked to a few industry friends about it, and I was surprised by their skepticism.?
During the last decade, I had a chance to lead Product, or consult with seven companies that market SDKs to developers. PLG can work in this context. However, you must adapt your product and go to market motion from the standard PLG playbook. Here are five key lessons I took from this experience:
- Make it easy for developers to discover your product. Before you jump into SEO optimization and search engine marketing, talk to your target customers to understand how they search for and discover new technologies. Stack Overflow and a strong Github presence are a must. Engineering thought-leadership blogs are another good channel. Ensuring your SDKs can be found through package managers is also critical.
- Help developers reach an Aha moment before integration. A few years ago, I worked with a company where a typical SDK integration required two to four weeks of development work. They refused to include proof of concept in the deals because they lost on a few occasions due to the complexity of integration. The product had a very high NPS from developers, but the initial integration needed to be improved. We made improvements to simplify the integration. We made APIs verbose and added checks for the compiler to ensure developers get all the guidance without needing to open documentation. It helped, but more was needed to enable PLG. Now, I see an increasing number of companies offering APIs and no code integrations via Zapier to help developers experience an Aha moment without needing costly integrations. These APIs are loss leaders. In and of itself, they do not generate enough revenue to justify their development and maintenance. However, they enable developers to reach Aha without wasting time integrating a complex SDK. That drives conversions for products that offer a free trial or freemium models.
- Freemium triumphs free trial. Free trials are built for products that are easy to use and help you get to the Aha moment quickly, but there are limited opportunities to expand in the future. Developer products are often different. The timeline from a proof of concept to a decision can take months. Smart developers will integrate the external solution in a smaller app or in a limited way to avoid technical risks and to ensure they can properly test the integration and observe the impact on the system. Once confidence is in place, the product will spread to other apps or be widely adopted by the broader engineering team. SDKs tend to have gross retention around 95 - 98% because developers do not want to go through the process of removing and reintegrating for small value gains. Freemium built around a usage metric, or a value metric is optimal. It allows developers to integrate and test the product in a limited capacity for free. As the product gets widely adopted by the engineering organization, the usage will grow, and the account will continue to expand.
- Devs want to talk to devs. It seems obvious, yet virtually all developer products I signed up for offered me only the opportunity to talk to sales. When I have technical questions, I get a sales pitch back. Recently, I worked with a company where developers provided all of the support during the trial and afterward. It’s a small developer-driven company. Initially, they couldn’t afford to add more AEs and build a CS function. Over time, they realized they were winning against their competition because developers wanted to talk to developers. Developers championed them to their bosses, and they influenced the outcome.
- - ilities are critical. There are over 80 -ilities, such as availability, auditability, configurability, learnability, modularity, scalability, or security. Developers evaluate technical products through the lens of -ilities. They want to know how integrating the product will affect the current performance of their system. Your developer communication should avoid developer jargon and focus on addressing the concerns around the key -ilities relevant to the product. Developers do not want to hear that your product is enterprise-grade. Instead, they want to know that the API guarantees 99.99% availability and has a latency of under 100ms.
I am curious what is your take on this? Do you agree? Are there any other adaptations that you would recommend?
Product and Growth Leader for B2B scaleups || I focus on the operational details of growth through sustainable product and GTM strategies
2 年I think reticence with developer-focused PLG is sometimes traced back to a belief that PLG demands this to be all or nothing. That _all_ of the sales experience and the “sell” must come from a completely self-serve, “hands-free” freemium experience. Sometimes this requires some education internally, to help all those in the revenue org to understand how each thread comes together and appropriately supports the developer’s lifecycle from trial, to believer, to internal advocate, to champion.
General Partner at Horizon
2 年Great post! Do you think open source business models naturally account for the 5 lessons?
Reimagining customer experience with AI
2 年The SDK is quite the barrier to Overcome when non-Eng are lining up for the outcomes a freemium service provides.
Technical Product Management Senior Leader, AI Consultant | Amazon | Blizzard | AppFolio
2 年PLG always works since it’s centered around creating value for the user. Does not matter who the user is. All users have problems that need fixing with innovative solutions that meet business needs. Certainly the devil is in the details of how to execute that product-led operation, though. Good read.
Founder, The Product-Led Geek | Dev Tool Growth Advisor | Proven growth systems for efficient scaling
2 年Thanks for tagging me Leah Tharin ! Mike Pilawski nice summary! I'll add that: - SEO can prove highly effective for discoverability of dev products. A core growth loop we implemented at Snyk was building a sidecar product that augmented package manager data with security scores, community (repo health) scores etc to provide holistic package data and be a top destination for developers searching for packages. - The commentary on aha before integration is interesting but perhaps most relevant to SDKs with high integration costs. Many categories of developer products have lower barriers to entry. - Agree with free plans being typically preferable to trials with dev tools, but would note that the combined solution of reverse trial is often better than either independently. Also, strongly believe it's never enough to get to an aha moment; getting a dev or team to habit moment is necessary.