Thoughts on Product-User Fit for Open Source Businesses
Some thoughts and reflections on user prioritization in early stage product-market fit finding open source based businesses.
Introduction
Recently, I’ve been working with some companies working through product-market fit for open source based business. I’ve also seen some of this first hand. It’s a non-trivial challenge. As I’ve talked about in how you want your open source company to work, you’re going to have to climb a lot of hills to get to a successful open source based business.
This post will discuss product-user fit, and that being a starting point for product-market fit according to the folks at a16z (the source of the product-user fit article/concept). This post will focus on what product-user fit can look like for an open source project since the a16z article doesn’t speak to open source directly but products generally.
I’ll share some thoughts about user fit and discuss some different perspectives towards product-user fit and product-market fit when it comes to open source based businesses.
Defining product-user fit
The authors from a16z define product-user fit:
The honest version of “we’ve got product-market fit on a small cohort of very early power users” is “we’ve got product-user fit.”
That means that you can give these power users superpowers and they see the value in your product (or open source project) - but that you can’t do that repeatedly or broadly. It’s a limited subset of users.
Let’s take a look at what that can mean for open source.
Getting to product-user fit and some open source specific challenges
To get successful product-user fit, you need to build a machine that takes in uneducated (but conceptually ideal users) and turns them into successful users. Product-user fit is the first stage in that journey - making a small subset of power users successful.
Now with open source based businesses, this might happen in several ways, roughly in order of expected timing / prioritization:
Your open source project makes a small set of power users successful
Your open source project makes a large numbers of users successful
Your company can take a small set of open source users and convert them into paying customers
Your company can take non-existing open source users and convert them into pay customers
If you can reach step 4, you’ve got product-market fit but step 1 is product-user fit (as defined by the article). Some specific challenges for open source are steps 2 and 3, which basically don’t exist for traditional companies.1
Step 2, we’ll define as open source project-community fit.
Step 3, we’ll define as early product-market fit.
Where things can get complicated
For open source, it’s possible (even likely) that your ideal users won’t actually be the ones to deploy the software. In open source, you may even have to add another step (or substep) to the product-market fit sequence above. The reason being, that for maximum value capture, you need people to be able to run the software in production. Let’s explore this in more detail with an example.
Your open source project makes a small set of power users successful
Intermediate Step: Your open source project makes administrative or operations users successful - users that actually deploy and manage your system
Your open source project makes large numbers of users successful
Your company can take a small set of open source users and convert them into paying customers
Your company can take non-existing open source users and convert them into pay customers
Step 1 might mean that you can focus strictly on power users but to take it to the next level, you may have to achieve step 1a and enable folks that can run and operate the systems on behalf of your key users. Step 2 might require administrative and management users (e.g., step 1a success) to be able to succeed consistently in order for you to build a bridge to the broader market of users.
An example: Apache Kafka
Let’s walk through Kafka through the above steps and how they accomplished each of these particular steps.2
End User: Developers (Step 1)
Now the user interface for Apache Kafka is relatively straightforward. It’s an interface that will mimic many pub-sub style systems. Users can learn that quite easily, the challenge is in the operations.
It might be easy to end it here, but I would assert that it’s likely that the user focus was more precise than this. I’d wager it was something much more specific than that something like “real time application developers at digital and enterprise companies that run and operate data infrastructure for 100+ end user developers or entire companies.” The focus is critical, as I’ll touch on later.
Administrative User: DevOps (Step 1a)
Intermediate Step: Your open source project makes administrative users successful - users that actually deploy and manage your system
Even in the early days, the Kafka creators prioritized significant documentation to operations. They prioritized this documentation because they understood that operations users are critical to the adoption of Kafka. They knew that if people couldn’t trust the operations of Kafka, they were going to be a significant impediment to growth and other folks using it.3
Helping these operations folks helped move Apache Kafka from just power user success to step 2 - reaching the broader market.
What Confluent and the Kafka creators did particularly well was understand that there’s a tension when it comes to operations. Operating infrastructure isn’t a huge value add for most businesses - it’s typically not tied to the core business proposition of a company. Let’s say it take 3 people to operate a Kafka cluster reliably, for production, that’s going to be $500,000 to $1,000,000 in salary, benefits, etc. (especially for someone with that expertise). That’s several people dedicated to not helping the business, just managing infrastructure. Confluent, the company leveraged this to help build their business because they could much more easily bill for services and build their business around managing Kafka clusters. The rest is history.
A basic manual for Product-User Fit
Now that we reviewed a simple example, let’s sketch out a simple
Define a user spectrum
Driving focus means defining the edges. You’ve got to understand who you don’t want to cater to and who you don’t want to support immediately (or prioritize work to help). The “Kafka spectrum” is developers but there’s likely more specification that went into it for company size, type of developer, use case and so on.
Drive product focus on an end user
Use that spectrum of users to focus on a particular user, these users should be the focus for you to make initially successful. This should be your focus for product-user fit.
Understand who those end users are going to depend on
You’ll want to make that set of power users successful (somewhat obviously), but in doing so, you want to understand the broader market and where the less capable broader market needs help in order to be successful. These could be administrators, they could be IT teams, they could be DevOps folks, the context will depend on your specific market and product. This should also understanding the potential buyer (and where budget sits) for your particular tool.
In this understanding, the goal is to target the levers of capability - what are the key capabilities that will (a) allow these users to do their job to help you get to a larger user base than you otherwise could and (b) that won’t erode (and even might inform) potential differentiation that you can build into your product.
Confluent did a great job charging the administrative users for the Apache Kafka developers expertise (via consulting) and then seeking to automate them with a managed cloud service (Confluent Cloud).
Some failure modes
I thought it might be helpful to document some failure modes that might come up on this journey. These shouldn’t be too surprising, but things can be more simply said than done.
No user prioritization
Should be obvious, but if you aren’t prioritizing, you’re going to be in trouble. This doesn’t mean that you don’t have vision for the larger or broader market, or how your tool can apply to a number of different problems, but you’ve got to prioritize some (typically power users) first.
Prioritize the wrong user
It may be that prioritizing the wrong user means that you can’t monetize effectively or reach a broad set of users since most people don’t have the problem. This is extremely context dependent and some of this just can’t be known ahead of time - the entrepreneur’s challenge.
Scaling too quickly
Ego is a killer. If you step on the gas because you want to get to the growth phase before you’re actually ready, you’re going to make mistakes.
Skipping what to focus on during the product-user fit stage and prematurely racing to spark the market adoption can actually decelerate your path to product-market fit.
Be easy on yourself, resist the urge to scale and skip steps. Focus on the step that you are at and do it to high quality.
Resist feedback
There are things that you must take feedback on and things that you might not want to. For instance, data challenging your assumptions might be pushed aside but data that tells you how to effectively reach the market and your end users is absolutely critical. Resist feedback at your own peril.
If you don’t listen to the early power users closely enough, you may never discover the insights that get you to a world-class product….
In almost every case, a key driver of bottom-up adoption is to listen to early power users closely in order to discover the insights that get you to a world-class product.
Not a business problem or no business value
You might solve a problem but if it’s not something relevant to a business or something that you can quantify or understand, you’re going to be in trouble.
In the enterprise, undeniable evidence of product-market fit shows up when an early cohort of evangelical customers are ready to pay more, new prospects are banging down the door to get access, and market demand far exceeds your ability to satisfy it.
Conclusion
The slog towards product-market fit doesn’t ever stop, until you get to it. You can even be building for the right users, seeing success, but as the authors of the product-user fit post mention…
Skipping what to focus on during the product-user fit stage and prematurely racing to spark the market adoption can actually decelerate your path to product-market fit.
Focus on your users, make them successful, then be ready to grow and make things happen!
Now, from my perspective, an open source project can never have product-market fit because you aren’t selling anything, you’re just providing value for free. Several a16z folks disagree and define product-market fit as something that an open source project can achieve (read: on open source commercialization) . However, I think this is probably just a debate of semantics, not substance.
Note, I may have some of the details wrong as I’m not intimately familiar with Kafka, but I’m quite sure that I’ve got the flow right. Feel free to drop a comment and let me know if you think I’ve got it wrong.
As I mentioned above, I haven’t done interviews with folks in the early days. This is conjecture, but the example and thinking are sound.