The 5 Questions That Will Make or Break VC Backing for Your OSS Company

So you’ve snagged a meeting with a venture capitalist or other potential investor. It’s your big moment to share about that open-source software company you’re itching to launch — but most importantly it’s an early opportunity to get feedback.?

To help you prepare, here are five essential questions that would make or break an investor’s decision to invest in your open-source software company.

1) What’s the problem you’re targeting?

Every good business solves a problem. Your problem should be a concise, clear description of the challenge or opportunity that your solution can address.?

When crafting your problem statement, ask:

• What is the specific problem or challenge that requires your solution?
• How does this problem hamper your ideal customer’s work?
• Is there a quantifiable cost imposed by this problem??

Exploring these questions early on helps you establish a comprehensive view of what’s going on. After all, this problem statement will become the guiding force behind your future company.?

2) What is your value proposition? What evidence do you have that users support your product?

By this point, we should have a good picture of the challenges potential customers face. The next step, then, is to describe how you’re going to solve their problem or, in business-speak, your value proposition.

Here are some topics to consider as you craft your value prop:

• Define what makes your solution unique. Have you developed a new approach? or a technological breakthrough?
• Describe how a customer’s life is better after using your software. Before and afters aren’t just for consumer companies.?
• Quantify the impact. How would a customer measure the impact of your product on the individual and on the organization, and how significant is the change?
• Know your place. Is this a nice-to-have or a must-have solution?

Remember, every product has competition: either direct (a product with similar functionality) or indirect (tackling the problem in a different way). You’ll need to articulate how your product is superior to all alternatives and crisply define a compelling reason to buy. Saying you have no competitors is a big faux pas — even if there is not a perfectly competitive company, indicating who could be competition shows pragmatism.??

Finally, you need to be realistic about potential barriers to buying your product. Key factors can include:

• Any changes in process or work steps that might need to be made to accommodate your product
• Are you targeting new budget

When we evaluate companies as possible investments, we’re after the same thing you are – enthusiasm for your project. But we need to know how deep and broad that enthusiasm is, and how long it may last.??

So, prepare to share how you’ve? measured the adoption and usage of your open-source software. GitHub stars, contributors, forks, pull requests (PR), and Discord/Slack posts — they're all breadcrumbs we follow. Sure, they don't tell us if folks are ready to throw money at you, but they hint at what users find valuable (and whether there might be enough enthusiasts to constitute a viable market).

If a handful of people contribute PRs, that’s nice. If a couple hundred do, then you might have something with legs.

3) Who is your target customer?

Let's dig deeper into your ideal customers. Who are these future fans you want to target with your software? Be prepared to share some of these characteristics while answering this all-important question:?

• What job title(s) do they have and what are their responsibilities?
• What kind of companies do they work for?
• Are there any industries or markets that make them more suitable customers?
• What does success look like for them??

4) Does your product fit into a category that people already understand?

New solutions are often a double-edged sword: innovation is valued yet change often creates uncertainty. The more radical a solution, the more difficult it may be for the market to understand and accept it. Customers often look for a “bucket” in which to place you and your product. You need to place yourself either in an established category — consider Gartner categories if applicable — or define a new market segment.

Side note: creating a new market segment may sound exhilarating and highly differentiated, but it is a lot of work. We’re talking years of market education using time and resources that most startups don’t have. It may also complicate your sales process if customers need to create new budget line items or purchase a solution. It can even hamper your ability to raise money; some investors will want to know the size and growth rate potential of this new market segment. Just level setting with you.

5) How will you monetize your product and who’s going to pay for it?

Getting people to try open-source software isn’t super hard — it’s free after all. But if you want to build a viable company based on that software, you’re going to have to charge for it. Your challenge now becomes how much you charge, and how the paid product differs from the free version.

It’s not essential to have a pricing model at the outset. But you should at least have a vision for monetization in the future and a rough idea of how you will? motivate users to keep paying for your product over time.

And for goodness’ sake, name your paid product something that sets it apart from the open-source version. That will help both you and your customers clearly distinguish between the versions.?

For example, the developers of open-source project Dapr eventually formed their own company based on the software: Diagrid, the name they use for the enhanced services they provide on top of Dapr.?

And consider how open-source project business models can change over time as demonstrated by HashiCorp’s recent migration to a Business Source License… following the open source footsteps of Elasticsearch, MongoDB, etc. Is this the natural progression for all future open-source projects?

To be clear, the developer who tries your open-source software and loves it is the start of the journey, not the end point. The key question to answer is: who has the budget to pay for your product?

As I discussed in Part 1 of this series, it’s a very different proposition when users of open-source software need their manager to sign off on a 5-, 6- or 7-figure purchase order to adopt a product. Pricing justification for your product must change along the way. Instead of stressing the features and ease of use that make it attractive to developers, you will need to present a cost-benefit analysis (perhaps including an ROI calculation) to convince the manager to sign a PO. It’s incumbent on the vendor to help their users build internal justification for the purchase — your customer’s boss, their boss's boss and perhaps CFO need to be enlightened.?

So there you have it, folks! If you come to a VC itching to start an OSS company, these are the questions we’ll ask. If you're not ready with solid answers, then you have work to do. I'll cover how to ace these questions in my final blog. Stay tuned!