Product

Product-market fit

Building a company around an open source project with good traction indicates that it has good potential for PMF, but does not guarantee it. Product market fit (PMF) is when the product meets the needs and wants of its target market, and people are willing to pay for it. It's achieved when the product has a substantial market and can generate significant revenue.

To achieve product market fit, a startup should be able to identify its target market and demonstrate a deep understanding of its needs and preferences. The product needs to meet the target market's needs and solve their problems.

PMF signals:

  1. Increase in OSS contributors/contributions

  2. An increase in ARR growth speed

  3. Sales are a more predictable process and less costly in terms of time and resources required

  4. The sales team closes deals without the founder's involvement

Once the product is developed, test it with your target market to get feedback and make necessary improvements. Continuous testing and iteration are crucial to achieving and maintaining product-market fit. It is important to note that finding product market fit is not a one-time task but a continuous process. A product may achieve product market fit initially, but it can lose it over time if it fails to keep up with changing market trends and customer needs.

Commercial MVP

A minimum viable product is the simplest version of a product that can be sold. The goal of an MVP is to collect customer feedback with minimal effort and avoid building products that customers don't want.

It is important to start talking to customers early on and throughout the lifetime of a company. They will help provide insight into the problem that the company is solving, which should inform product development. Don’t make the mistake of building in isolation.

Customers buy solutions to problems, not features. By identifying and prioritizing the needs of your heaviest usersarrow-up-right, you can develop products that address your customers' most pressing problems. Understanding these problems deeply requires iterative development to refine how you meet customer needs.

Deciding first features

Don't reinvent the wheel to get started creating enterprise features.

EnterpriseReady.ioarrow-up-right is a great resource that identifies which enterprise features to build first by providing a research-backed roadmap of the 12 most valuable enterprise features, based on studies of successful SaaS companies. Founders can use the self-assessment tool to benchmark their product, receive specific implementation guidance with real-world examples, and prioritize development efforts that will drive enterprise adoption and revenue.

To improve the existing product, product features should be weighted based on their source in listening to customer feedback and informed by customer discovery, and not necessarily on the frequency of requests.

  1. Ideas for features and functionality can come from users, but the result of what the product will do is defined by the product team. 90% of the product scope will come from the product team.

  2. Prioritize feature requests based on effort vs value. Focus on high-value low low-effort changes.

  3. Working closely with large customers tends to yield the best new features. Large customers have knowledge, expertise, and ask for things that other customers want.

The heaviest users will give the best feedback. They understand the limitations of the software and will be more likely to have submitted pull requests for modifications and issues. Visibility into that feedback through contributions by heavy users is an advantage of open core products.

Potential customers never buy because of product featuresarrow-up-right. Overvaluing the requirements of a potential customer can be a high effort and deprioritize more meaningful improvements. Someone who has never used your product can’t really know how to make it better. Sales requests are important, but they will not make up a significant amount of feature development. Product and sales should have a list of the 5-10 most important requests that they revisit every quarter.

Premium/Enterprise releases

A premium or enterprise release for an open core company will usually be a version of that software that includes a software as a service (SaaS) option (which is hosted) in addition to source available and open source versions.

On-premises offerings with releases should be evaluated on a case-by-case basis for companies and are generally more useful for infrastructure projects. Certifications and data locality can represent a challenge for implementing on-premises offerings, along with the possibility of functionality degradation. Replicatedarrow-up-right helps software vendors with the delivery of on-premises solutions.

Professional support & services

In the early stage of a startup’s product development phase, your R&D efforts may look like professional support and services. Utilizing professional services engagements for R&D efforts should focus on building features that have the potential to be relevant to other customers.

Avoid second-system syndrome

Second system syndrome refers to the tendency to overcomplicate and over-engineer a new version of a product or system. This syndrome occurs when the creators of the second system try to address all the perceived flaws and shortcomings of the first system, resulting in a bloated and ineffective solution.

  1. Focus on the core functionality: Identify the most critical features and prioritize them over secondary or nice-to-have functionalities. Keep the system lean and focused on delivering value to users.

  2. Iterate and gather feedback: Instead of aiming for a perfect and fully-featured system from the start, adopt an iterative approach. Release early versions of the system, gather feedback from users, and make incremental improvements based on their needs and preferences.

  3. Stay aligned with user needs: Continuously engage with users to understand their requirements and ensure that the system remains aligned with their needs. Avoid adding features or functionalities that are not directly relevant or valuable to the target users, and avoid building in isolation.

Last updated

Was this helpful?