The OSS market has two ends of a continuum – one end consisting of what I refer to as “the self-service customer” (ie highly repeatable) and the other being “the requirement of one customer,” (ie highly customised). Naturally there are contracts that fall on the continuum between these two extremes too.
The self-service end of the market has proven to be a successful niche for some vendors, the ones who have made their products highly user-friendly. They’ve also made them highly repeatable, albeit still customisable. They tend to provide free trials and / or very low-cost starting points. I’d like to explore this with you in more detail today.
One of the challenges for the highly customised OSS offerings is the lengthy sales cycle and corresponding cost of sales that go hand-in-glove. The entry-level offer strategy is designed to circumvent long sales cycles by giving the customer a “rapid outcomes with almost no risk” use of the solution. This is the complete inverse of customised OSS solutions isn’t it? They tend to take a long time to deliver outcomes and there is huge risk in selecting a vendor, which leads to the long sales cycle in the first place.
The entry-level package is basically (no pun intended) the simplest, bare-bones version of the offering (eg a containerised version). Being bare-bones, it requires a minimum viable product, lean thinking approach – to make everything from download to install to configure to operation highly simple, streamlined and repeatable. It requires an 80/20 mindset on many levels, such as which interface types (eg SNMP) and which networks (eg IP) will be used by almost every customer so that almost anyone can easily get some of their data into the system (eg alarms, discovery, etc) to be able to play with.
This entry-level thinking is anathema to most OSS vendors (except the self-service players of course), because there is a perception that they make their money and differentiate their products through their ability to cope with almost any unique customer’s requirements. The entry-level approach is also deemed risky because customers may perceive that this minimalist product is incapable of performing some of their important, unique use cases. This is where really clever design is required – to show the customer that there is an upgrade path to service their need and/or for the product to have functionality that takes the customer’s feedback and allows the vendor’s team to quickly show how that requirement could be met with current or custom functionality.
This approach doesn’t help where the customer issues highly customised request for proposals (RFP) and / or demonstrations, but generally these RFP processes follow lengthy prior dialogue with vendors / integrators.
For many in the industry, this is a very contrarian view, so I’d love to hear your take on the scenarios where it might or might not work.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email