Building a Commercial Open Source Company
In our time investing and supporting open-source companies, we’ve learned several lessons about project & community growth, balancing roadmap and priorities, go-to-market strategy, considering various deployment models, and more.
In the spirit of open source, we wanted to share these learnings, organized into a series of posts that we’ll be publishing every week — enjoy!
- Part 1: Building blocks to a commercial open source offering
- Part 2: Focus your commercial and OSS roadmaps on developer adoption
- Part 3: Sequence your distribution & GTM strategy in layers
- Part 4: Your deployment model is your business model
PART 3: Sequence your distribution & GTM strategy in layers
1. Vibrant communities make for the best lead generation:
The open-source popularity of a project can become a significant factor in driving far more efficiency and virality in your go-to-market motion. The user is already a “customer” before they even pay for it. As the initial adoption of the project comes from developers organically downloading and using the software, you can often bypass both the marketing pitch and the proof-of-concept stage of the sales cycle.
2. Start bottoms up, developers first: Focus on product-led growth by building love and conviction at the individual developer level. Make it easy to sign up, deploy, and show value. Leverage developer referrals, community engagement, content marketing, and build the product-led growth mentality into each function of your company. Nailing the developer experience can lead to growth curves that look much more like consumer businesses than enterprise, and lead to much larger deals later on.
3. Nail bottoms up before enterprise selling: You can focus on product-led growth (bottoms up) or account-based marketing (top-down), but not both at the same time. Start with product-led growth to build an experience that developers love. Once you’ve reached some critical mass with a flywheel of developer acquisition, begin to introduce account-based marketing, starting with the expansion of existing customers to learn the enterprise sales motion before going after new accounts.
4. Developer first doesn’t mean developer-only: While nailing the developer-first experience is key to driving strong customer growth, it’s often not sufficient when trying to scale the project into larger-scale deployments. Transforming from a proof of concept to multiple large scale deployments across the customer’s organization requires a different set of decision-makers and requirements (i.e. security, policies, control, SLAs). Be sure to understand how the needs of the organization may differ from the needs of the developer when planning how to expand deal sizes and go after larger customers.
5. Build your sales funnel based on project commitment: Customers will come in three coarse flavors: (1) already deployed OSS project internally (2) starting to deploy OSS project internally, (3) decided to adopt OSS project. Design the sales motion tailored to the customer journey in order to focus on solving the right problems and challenges.
6. Target the ‘right’ developer: It’s critical to know who you are solving for and what you are solving for them. Going after the wrong developer persona can make a critical difference in whether the developer community understands and embraces your solutions, or not. Is this a solution for DevOps or data engineering? Technical business users or Data Scientists? An example data infrastructure project could be seen as (a) making it easier for DevOps to manage, (b) shifting the power from DevOps to engineering, c) helping data engineering leverage better code patterns, and (d) making it more secure for SecOps to manage data access. Obviously, all (4) have very different problems, with different values associated to them, but are all value props of the same solution. Focusing on the right persona, with the most painful problem, where you can continually layer value over time, is critical to building wider community love and commercial adoption.
7. Sell impact, not solutions: Help understand the total cost of ownership (TCO) of your solution vs an existing, closed, or in-house system — this matters and is rarely done well by the customer when making buy/build decisions. Understanding the value and ROI your service delivers, both hard and soft, allows you to sell on impact to the business, and not on a technical solution. Are you saving developer headcount? Increasing developer productivity? Reducing infrastructure costs? Cost-take out of a more expensive or legacy system? Being clear on the cost savings and velocity benefits of your solution drives up customer contract values.
Building Commercial Open Source Software: Part 3 — Distribution & GTM was originally published on Medium.