Picking Markets & Creating Movements (for OSS Based Businesses)
This post reviews prior art on picking a market, doing market research, developing users (and an opinion) and starting a movement around your OSS Based Business.
In the last post, we took a look at how CrossFit is a great example for building an open source based business. This post will come back to software and take a look at some of the variables around picking markets for open source products.
If you enjoy this content, please subscribe!
Picking your Market
Picking the market is the most consequential decision you’ll make as a founder. As a side note, you don’t have to build a billion dollar business, you can build a small one. A discussion for another time.
Big Markets Always Win
Here are some choice quotes:
“Our view has always, preferably, been: give us a technical problem, give us a big market when that technical problem is solved so we can sell lots and lots and lots of stuff.
-Don Valentine, Sequoia founder (Source)
A technical problem in a big market is a great foundation for a strong company.
“If you address a market that really wants your product — if the dogs are eating the dog food — then you can screw up almost everything in the company and you will succeed.”
- Andy Rachleff, Benchmark Capital founder (Source)
While I am in no place to debate Don Valentine or Andy Rachleff there are some interesting nuances that others call out.
Sometimes you have to develop a market
Martin Casado (in another post) points out that things aren’t always so simple - especially in markets that are going to develop (instead of those that already exist):
One of the biggest myths founders have is that people will immediately see the value of the product they built, whether in understanding what it is or in paying for it. This is especially true in “pre-chasm” markets, where you might have a few early adopters who totally get it — but there’s also a deep chasm between them and later, more mainstream users.
-Martin Casado, a16z GP (Source)
Having seen several companies operate in early markets, this rings true. Pre-chasm markets have so many false summits - where the early adopters get it but follow-on companies simply haven’t learned the pain. As Martin continues later in the post, “pre-chasm companies have to create a pull-based market,” something that pulls users to the product - not just pushing product on the users.
Now while these quotes are pulled from blog posts not specifically on open source products or companies, the same principles hold. You’ve got to focus on a big market and challenges that have your users begging for a solution.
Let’s jump into some ways that companies have chosen markets!
Market Research: Identifying the problems with existing solutions in the market
Market research is the foundation of “choosing a market”. As a founder or project creator, you must understand the trends, the challenges, and the issues in the marketplace. It’s not sufficient to choose a market and go. Here are some examples of founders that do that.
Solving Problems You’ve Seen Before
Many founders are already in the “markets” that they build open source projects in.
CockroachDB is a great example, the founders knew the problem space from their time at Google. After that, they went to different companies (e.g., Square) and realized the value of having that infrastructure. Then they built a copy of that infrastructure in the open. Subsequently, they founded a company around the project.
Confluent is another great example of solving problems you’ve seen before. Confluent’s founders were the original creators of Kafka. They knew the problem domain and built a solution within LinkedIn to solve that problem and subsequently open sourced it.
Just like with CockroachDB, the founders knew the problem space, realized the value of having that infrastructure, built that in the open, and founded the company based on that technology.
“LinkedIn was an incredibly data-rich service, with lots of applications, databases, and analytics layers that helped it operate. The big problem we faced was how all these could connect into one holistic service in a way that really let us build interesting products and harness the data we had”
Jay Kreps, Founder + CEO at Confluent (source)
That said, you don’t have to be spinning out massive pieces of infrastructure from the likes of Google and LinkedIn. You can also focus on solving your own problems and see what gaps come out of that.
Solving your own problem
In the early cloud era, there were real gaps in the development experience. MongoDB was originally founded to be an online service for developing and scaling web applications.
It was late 2007, and the idea was to create an online service for developing, hosting, and automatically scaling web applications. (Source)
However, MongoDB, the database, started because the founders could not find an open source database platform to build their cloud service (in 2007). (Source)
"We felt like a lot of existing databases didn't really have the 'cloud computing' principles you want them to have: elasticity, scalability, and ... easy administration, but also ease of use for developers and operators," Merriman says. "[MySQL] doesn't have all those properties."
The cloud service was never finished. But the database was open sourced as MongoDB.
In pursuit of solving a larger problem, the team stumbled upon an open source business.
Doing Great Research on User Problems
An alternative to being at the right place at the right time or solving your own problem is doing great user research. An excellent example of this is Dagster.
Dagster helps developers ship data pipelines faster. The founder, Nick Schrock, did not originally work in the data infrastructure domain. However, he did great research, user interviews, and learned about the gaps and problems in the marketplace.
He goes to show that you don’t have to be living and breathing the ecosystem (as a creator) before starting a project in the space. Great research and iteration can be a strong basis for an awesome product and company.
The User Development Process
Once you have your problem statement in hand and proper market context, you will have to develop your users. This is all about finding product market fit (for your open source project).
In the words of Steve Blank, “start with a hypothesis, test it, prove it, move on or further iterate on the hypothesis”. This is framed as a “minimum viable product”.
In addition, since you understand the problem you seek to solve in the marketplace, you must understand and be able to articulate the value you aim to provide users. Focus on validating or invalidating that. Steve Blank has great material around using developing customers or users to do so.
All of the aforementioned projects did an excellent job developing users, understanding their pain points, and focusing on solving them - especially at the beginning. No one else can do this for you (as the founder).
Once you’ve built momentum around user development, you’ll have a product that others are seeing is valuable and speaks to a broader market problem (hopefully 😉). In order to get adoption for your project, you’re going to have to do more than helping users succeed. The next step is all about taking a stand, going against the grain, and creating a movement that others want to join. To build a successful open source company, you’ve got to create a community of folks that are passionate about joining you.
Creating a Movement
Successful open source projects and companies know the criticality of their communities. Community building and cultivation is not optional. You must cultivate a tribe. You must tell stories, craft narrative, and demonstrate that you understand the community that you seek to serve.
Seth Godin’s framing makes the most sense to me. It’s all about tribes. As Seth Godin in Tribes states:
A tribe is a group of people connected to one another, connected to a leader, and connected to an idea. For millions of years, human beings have been part of one tribe or another. A group needs only two things to be a tribe: a shared interest and a way to communicate.
Open source projects provide both of those things - a shared interest and a way to facilitate communication. Successful open source project leaders cultivate the shared interest and build systems to help communication. But simply having these is insufficient.
Tribes need leadership. Sometimes one person leads, sometimes more. People want connection and growth and something new. They want change.
Being an open source project leader does not simply mean reviewing pull requests. It means taking a stand. Having a perspective. Building a movement, in the words of Seth Godin, is all about being a heretic.
Heretics are the new leaders. The ones who challenge the status quo, who get out in front of their tribes, who create movements. The marketplace now rewards (and embraces) the heretics. It’s clearly more fun to make the rules than to follow them, and for the first time, it’s also profitable, powerful, and productive to do just that.
A Heretical Example
The launch blog post for Dagster is a great example of building a movement. While I can’t say it’s as heretical as MongoDB’s original lack of ACID transactions, Dagster definitely takes a stand on how things should be done.
Conclusion
In this post, we reviewed what it means to pick a market in open source. We reviewed some material on the subject, reviewed some examples and what it means to create a movement.
In the next post, we’ll review some good markets for open source based businesses.