Did Open Source Set the Stage for Product-led Growth?

The era of “try before you buy” for enterprise software is here to stay. Instead of long, painful procurement cycles, solving an end user’s annoyances is the way to go. Long before “product-led growth” (PLG) became the buzzword, open-source software communities used the power of the collective to solve developers’ problems. While open source is unique to developers, PLG provides a hands-on experience to developers and everyone else.

In the open source world, what started as a fringe movement accelerated to a powerful business model. Now, developers can inspect how technology works in their own environment – and even change it themselves – before buying anything.

With scale or specific enterprise demands (e.g. security, compliance, etc.), these developer “builders” became the buyers for commercial open-source software. Instead of CIOs or CTOs serving as the gatekeepers for IT purchases, developers became “the new kingmakers” and primary decision-makers for their own toolsets. That was a massive shift away from settling for stagnant enterprise software and vendor lock-in.

In the end, open source forced a shift in the market toward products that users could test themselves. Let’s take a look at how this shift took off, and the lessons SaaS companies can learn from commercial open-source ventures.

Open source and the changing software buying cycle

Early commercial open-source ventures like Red Hat were a model for the first generation of open-source companies. In time, many companies found that providing support and professional services around open-source software wasn’t the only way to build a profitable open-source business, and went with an “open core” business model that delivered additional proprietary functionality, typically focused on “enterprise” use cases. For example, firms like MongoDB have even stated that community versions of their software served as a freemium (i.e. PLG) strategy for their paid product, helping to drive adoption.

Both commercial and free open-source companies challenged proprietary software vendors to think differently about developer engagement and developers as primary evaluators/buyers. As investor and open source veteran Peter Levine outlines in this article, “Your open source community is a developer-driven top-of-funnel activity.”

This mentality expanded beyond developers to business buyers, who increasingly are digital natives. These buyers tend to want to make their own product selections and avoid long procurement cycles. In fact, Gartner predicts that 80% of interactions between companies and buyers will occur in digital channels.

As a result, many SaaS companies have become more liberal in their approach to product testing, freemium, and pricing strategies. Some, like Atlassian, famously had no salesforce for years, relying on product stickiness and user data to drive demand, retention and expansion. Today’s PLG companies (e.g. Twilio, Calendly, Stripe, Figma, etc.) have followed these early examples. They’ve grown organically based on the merits of their product and the problems it solves for end users who try it firsthand.

Key takeaways from open source to PLG

As someone who has led go-to-market and product strategies for both open-source and proprietary software companies, there are some common threads from open-source that apply to PLG.

First, create a sandbox that’s feature-deep enough to let developers build something in their own environment, even if it’s basic. Developers are often the ones solving problems for the organization (either their own, or on behalf of business users).

Or as Jeff Lawson, the CEO of Twilio put it, “Business people need to think of developers as creative problem solvers (not just people who will grind out code). And when you think of developers that way, you don’t need to share solutions with them, instead, you need to share problems with them. What are the biggest customer or business problems that you’re trying to solve? Make your technical teams a part of answering those problems. When you do that you get a whole new level of output, quality, and speed.”

It’s critical that developers can tell whether or not your product will meet their needs within a relatively short window of time. Otherwise, they’ll find an alternative solution that will. Set up your user activation process incorrectly, and they may never come back.

Second, use guided, orchestrated proofs of concept (PoCs) to inform how prospective buyers engage with your organization. Prospects may chafe at the perceived constraints you put in place but will get to experience the best your product has to offer FAST, without getting distracted or lost in areas that may not matter to their decision and future use of the product.

This early assisted self-discovery of your product can be far more powerful at revealing unique differentiators than a traditional, 300-line RFP. Endless, exhaustive questionnaires lose all stakeholders in the minutiae and never offer meaningful insights about how your technology can solve a problem. Instead, a guided PoC provides real-world information on how to expand and deepen the value of your product with a prospect, which can help your sales team have more informed conversations.

And finally, think about the way open-source communities work. Even if your product isn’t open source, be vigilant in gathering feedback from everywhere possible to improve your product. Open-source communities are the best examples of listening to your users, adopting change requests, or improving features.

Whether you are an open source purist or a commercial open source enthusiast, it’s hard to deny open source’s impact on the software buying cycle. To keep up with changing user demands, enterprise SaaS companies need to adopt some flavor of PLG to prove the value of their products in a short period of time. From there, closing larger deals becomes a consultative process based on real-world information – rather than an exhaustive, confusing RFP with more questions than answers.