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.
Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
Earlier in the year, we wrote a series of articles about the chasm that exists between OSS/BSS buyers and sellers (pt1, pt2, pt3, pt4, pt5, pt6). “The chasm” is
Actually, maybe a few related questions. As you’ve seen from recent articles such as this, I’m increasingly interested in the cross-over worlds of comms and
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
4 Responses
Isn’t the number of potential customers the real issue that prevents good segmentation of offers. My “territory” (European Union) counts +/- 100 potential customers for OSS (compare this to its 20 million SMEs).
Hi Roland
Very valid point.
There are so many layers to this discussion aren’t there and each vendor’s situation looks different.
Here’s my over-simplified take on it:
The entry-level build = more repeatability = faster roll-out (plus greater initial momentum) = lower initial cost = accessible to a broader market (deeper into the enterprise market and a larger number of customers).
How does an OSS vendor channel Henry Ford and use the steps above to open up a whole new market?
Of course the enterprise market doesn’t represent all OSS vendors’ ideal customer base but we can all benefit from improved repeatability.
Applying Clayton Christensen’s thinking, I do not believe that OSS firms will go low-end (e.g. enterprise markets), but that enterprise companies/products will eventually take over OSS (like Salesforce is currently demonstrating).
Hi Roland,
Interesting you mention Clayton Christensen (I’m jumping to the conclusion that you’re referring to his Innovator’s Dilemma BTW) as I have an upcoming blog relating to cannibalisation of OSS markets. Interesting that you mention Salesforce too, as I see the proposed small-grid OSS model having some similarities with the Salesforce platform (but differences too of course). I think there’s some parallelism in our lines of thinking Roland, but with a difference too. I see companies like Solarwinds as being OSS firms that are already servicing enterprise markets with largely self-service models, but can I assume that you classify them slightly differently?