How you want your Open Source Based SaaS Business to work
How to think about the business developing over time, the phases you will experience, and what to expect in each phase.
Plans are worthless, but planning is everything - Dwight D. Eisenhower
As you’re looking to build an open source business, you’ll want to have guideposts for what you and your team are building towards.
Often times founders will want to figure it out as they go along. You will have to do this. You will need to learn on the fly. However, you also need to have a plan or approach, something you can actually deviate from, in order to iterate effectively.
Steve Blank wrote about this over 10 years ago. A scalable startup (and open source project) needs to hit some key milestones before it can transition to a company or business.
The way I like to characterize how an open source startup should develop is broken down into four phases of maturity:
Market definition and problem statement
Your open source solution
Monetization and building the business
Expanding & growing your business
These phases can overlap but it’s helpful from a mental model to think about doing them linearly.
In this post, we’ll be reviewing each of them and talking about goals and objectives in each.
Phase 1: Market Definition & Problem Statement
Whether you are evaluating good and bad markets or picking a specific market, the first phase is always picking the market. This is true regardless of whether your business is based around open source or not.
The target is to build a business (unless you just want to build an open source project). This means that you’re going to have to solve pain that people will pay you for. In order to solve that problem, you’ve got to understand the problem better than your users or prospects understand it themselves. Focus is critical.
For the purposes of this post, I’m going to use a market ‘hierarchy’ to help describe the different phases and customer types.
SMBs - these are small, fast moving companies that are either starting out or operating at a limited scale. They can move quickly but that’s not always good - they can disappear just as quickly.
Digital Natives - Digital natives are brands that are “born in the cloud” and know how to use cloud systems effectively. They’ve already got viable businesses and target fast growth. They move quickly but often have more need for diverse capabilities and stricter security requirements than SMBs.
Enterprises - These are traditional companies with large business models that are relatively stable. They are laggards in terms of digital solution adoption and often need handholding to succeed.
You can think about this as layers in an onion, as depicted in the following diagram.
Critically, you want to solve a problem in a large market and one with more than just SMBs. You can stay at the SMB level if you’re hoping to build a smaller business, but if you want to go big, you’ve got to serve the enterprise segment.
It’s hard to build a $100M business selling only to SMBs - you need to move to the enterprise.
Your Goal in this phase: Focus on understanding the key problem you hope to solve for your users. The job to be done.
You must find critical pain in their process in order to ensure adoption as well as a viable business. This is less “fun” than simply building something, but you’ll learn a lot faster by talking to others in the market than simply building something and hoping that it works out.
Phase 2: Your Open Source Solution
While phase 1 is never really “done” after some research and investigations, you should have a crisp understanding of the problem you want to solve with your solution and the experience you want to deliver.
You’ve got to start with the customer experience and work backwards to the technology, you can’t start with the technology where you’re going to try and sell it.
-Steve Jobs
The biggest failure mode that I’ve seen is starting with technology instead of starting with the customer problem and the experience you want to deliver. This is so tempting in open source. But you must focus on the problem. I’ve yet to find it so succinctly described as in the following video of Steve Jobs:
This post won’t elaborate on product design, just make sure to work iteratively.
Once you’ve hit an MVP, you’ll have a market structure similar to that below. You are solving problems for a small(-ish) set of users and see adoption from an early adopter cohort that is relatively well serviced by your product or solution.
This is a beachhead into the marketplace that allows you to get a foothold with some users, solve their problem, and commence the customer (OSS customer, in this case) development iteration process.
It’s possible but unlikely that the first product or service you develop will be exactly what potential customers were already hoping for. That’s why failure is the fuel that moves new projects forward. Failure is a way of discovering one more thing that customers didn’t want, and perhaps, learning a bit about what they might want. By iterating without tears or fears, organizations are able to discover things about their future customers.
-Seth Godin
The lean startup has great material on the topic as well but essentially you’re using these initial users to help formulate and shape your product going forward.
Phase 3: Monetization
Now, assuming you’ve got a reasonably well adopted open source solution (skipping a lot of pain here), let’s talk about the monetization phase.
The monetization phase is all about providing your user more value by working with you than using the open source alone. Typically what you should observe is that open source users should adopt the open source project, struggle to run it in production (something requiring expertise), and they come to you for answers.
You, as an open source business creator, can have roughly three answers and three business types (previous covered in the an overview of open source:
'“Pay me and I’ll run it for you” — Services based - you sell time to your customers to teach them to use the software
“Buy this and it should be easier / better / faster” — Managed distributions - you sell a distribution or some packaged up version of your product, along with some services
“Subscribe to this service” — Managed product - you sell a managed service of your product (e.g., a SaaS offering) and sell usage of that system.
These are not necessarily independent and in general you should lean to #3, as that provides the best “business structure” in the long term.
The complicated thing about monetization is now you have to compete against your own project. You’ve got to compete against yourself in order to justify why customers should pay for your solution as opposed to using the open source.
This causes a lot of friction (both potential and actual) but is unfortunately necessary as an open source business creator. Also, this will be a continuous process over time - what innovation you have now will change over time. Let’s talk about what it takes to expand.
Phase 4: Expansion
Once you’ve got a basic business running and an open source project people are adopting, it’s time to start optimizing. There are a couple of ways of doing this that we’ll explore below.
(1) Reducing Friction
A great first step is reduce friction in your product. Hiring PMs can help optimize for target workflows. This helps users see value faster and helps you close more deals.
If friction is greatly reduced, you should see higher close rates versus the open source as it is now seamless to move to your product.
You might end up reducing friction in the open source (to compete better against the market) or you might end up reducing friction for your product (to compete better against your open source solution or the market).
(2) Adding Products or Features to Close Gaps To Adjacent Markets
Another option is to add products to your portfolio or features to your existing products in order to enter or capture more of the broader market. This means that you can capture a “bigger slice of the pie” because more customers can use your solution because you solve a broader set of problems.
Introducing new product lines should not be your first instinct, but hiring PMs to scope and add new features to help close more customers is a great idea.
(3) To the Enterprise (e.g., removing security blockers)
Another option is to add security features or solve compliance problems in order to enter a more secure / discerning customer. Typically this means going to enterprises or more secure digital native companies.
This is rarely what you want to do at the outset. In general, it’s best to make sure you’re truly solving the problem for SMBs or digital natives before you start adding compliance or security features because those capabilities won’t improve your product they’ll just prevent other teams (that are not your direct user) from blocking the purchase of your product. You may need to do this to get to your target market but then you’ll want to question the value of open source at all.
This is a critical distinction. If you’re having trouble selling to small SMBs and people are not kicking and screaming for your product, you do not have product market fit. Adding security features (unless they are required upfront by your users) typically won’t help that.
You should be adding security features either (a) as table stakes for basic adoption of your product or (b) to expand into the enterprise.
Conclusion
Building open source businesses is hard. You’ve got a couple of discrete phases and plenty of challenges in between. In later posts, I will describe in more detail how various folks have approached this problem.