In the last year, I’ve seen RFP responses worth an accumulated total of well over $1B for network services, systems and such. In almost every case, the carrier buyers have indicated that they’re seeking innovative solutions. That’s the outward-facing commentary at least. But the real, inward-facing story is that they’re just seeking cost-reductions in most cases.
In one example, I knew of a telco that issued an RFP seeking a new AI-based solution. They invited around 20 vendors to bid (at significant cost and time to buyers and sellers alike). From it, I know they received at least one really innovative tech solution that really shook up their thinking. But they were committed to staying the course with their real intended outcome – getting their incumbents to reduce costs by at least 20%. Changing vendors to the innovative bidder would’ve just added unwanted time, costs and risks to their program of work. It was never actually about innovation or doing things differently.
Sadly, I suspect this is quite common, especially for telco / ops outsourcing procurement events (and OSS/BSS solutions too). Almost all network services bidders are seen as replaceable and essentially identical “arms and legs” – a commodity. If a buyer compares the offers and effectively thinks that all are pretty much the same then they’ll just buy the cheaper one. This drives the marketplace ever-lower until margins are hovering around breakeven or just enough to keep the lights of the business on. There’s a knock-on effect though. Reducing profitability for the sellers means there’s not enough in the budget to hire great people, provide exceptional experience, invest in R&D or innovation – or basically anything resembling growth or improvement – that goes for buyer and seller alike!!
Now, I might hear you saying, “tut-tut, those awful carriers.”
Maybe, but let’s think more about where that mindset originates from. Unfortunately, most people see operations as a cost-centre, not a business unit that helps to drive growth or profitability. When you have a cost-centre, the aim is generally to reduce its costs. Therefore, everyone involved (buyer and seller alike) is delivering into a declining industry, which are nearly impossible to thrive in. Sadly, for the most part, the OSS industry is submitting to that line of thinking. The cost-centre perception is our fault because we haven’t changed it!
However, it doesn’t have to be this way. It’s on all of us to change the perception from cost-centre to what OSS really are – the linchpin of the entire telco business model.
As described in this earlier article, “Telecommunications has reached its burning exchange moment,” OSS are arguably the biggest single technical influence on telco business models:
There are two simple shifts required to make the cost-centre pivot in thinking. I’ve turned both into frameworks that I use to quickly determine whether there’s a likelihood of growth emanating from what you’re working on (ie your product development backlog / pipeline).
We need to think about not just adding value to Operations (the O in OSS of course), but to a broader stakeholder group. To take it a step further, we also need to think about adding value to the stakeholders’ customers because our stakeholders will only pay a premium if they perceive and/or see proof of value being created for themselves.
What’s the value we can create? There are many, many ways, but the biggest is probably closely aligned to telco’s biggest pain – if telcos don’t increase profitability, their entire business is at risk (nearly 50% of European telco CEOs don’t expect their business to exist in a decade).
So, you might be wondering how any of this relates to the headline of this article – “Let us review your OSS product development backlog and I’ll predict if there’s growth in your future.”
As described in this article, “Do you know what the most widely used OSS/BSS application is?” I use the following long-tail diagram to contrast where product development roadmaps are being focused (ie adding new features at the far-right of the blue arrow) versus where they should be focused (ie improving the effectiveness inside the red-shaded box).
The x-axis is a list of functions/services being offered, whilst the y-axis represents value.
The red-boxed functions at the left of this long-tail chart show the high-volume / high-value functionality offered by OSS products. This is where the needle is really moved when trying to improve the efficiency of network operations. This is where business cases tend to succeed or fail.
The bars on the right side (in the blue arrow) are the functionalities that have little impact, but are great at differentiating one product (I have 1,001 features) from another (you only have 1,000 features), which possibly works in an RFP situation (unfortunately). Profit growth is unlikely to come from the blue arrow (20%). Profit growth could come from the red shading (80%)… if you create a differentiated and persuasive messaging around it.
But that’s not the full answer. In the chart above, both the 80 and 20 tend to focus on providing functionality used by Operations. It’s the O in OSS afterall. The 80 and 20 are selling into a declining market (ie cost-cutting that’s being sought in all cost-centres).
To truly grow, to remove buyers and sellers alike from this race to the bottom, we need to think to the left of the 80/20 chart as shown via the green arrow in the chart below. We need to expand on current thinking and deliver functions / value that extends beyond Operations, beyond cost-centre thinking. We need to think beyond the boundaries of current product functionalities that have often existed as the status-quo for years (eg to think not of alarm lists, but tools that help improve network resilience – eliminating the cause of the symptoms, not just providing the medicine). We need functionality that delivers value to carrier sales teams, to marketing teams, to executive teams, to finance. We need to improve customer experiences (CX) and speed of delivery. We need to create functionality that offers compelling value to our clients’ customers. That’s when we’re going to really move the needle
But it’s not just a case of changing the operations-centric mindset and increasing the perception of value.
We also need to drastically reduce time-to-value (TTV) and the many forms of friction that slow us down. Friction introduces delays in TTV and also introduces corresponding costs, risks and effort / sacrifice for clients.
Let me provide a non-OSS example of the TTV / friction concept. Why do people pay tens of thousands of dollars (eg $24,000) for liposuction rather than a hundred dollars a month to join a gym (eg 12 x $1,000 = $1,200)? The result is more or less the same but the perceived “value” of liposuction (for some people) is 20x that of the gym. Liposuction clients are willing to pay 20x to get the outcome (ie weight reduction) faster and with minimal effort.
Perhaps even more importantly, friction and delays reduce the perceived likelihood of delivery (which happens to be a big fear-factor for OSS buyers BTW). If you’re taking a year or two to deliver the first signs of value on an OSS transformation (ie the big-bang delivery approach that many vendors seem to prefer), then you’re putting the project at risk. Even if you’re tracking exactly to schedule (or you’re even ahead), if you’re not delivering obvious business value to stakeholders and interested onlookers, then the project can be perceived as lacking momentum and associated fears arise from this. To revisit the liposuction analogy – If you’re not losing weight after two months visiting the gym, then it’s easy to imply that it’s not working and stop working hard for the necessary 12+ months, whereas liposuction delivers near immediate results.
Let’s look at a few forms of OSS friction and consider whether your backlog has any evidence of friction-removal in it (as referred to in our article, “The one person, two day, OSS challenge“):
Where do you sit on each of the OSS Friction Continuums below?
In summary, if there’s no evidence of green-arrow functionality or friction-removal in your backlog, or if it only contains blue-arrow functionality, then I’d predict that growth is unlikely to be delivered by your future roadmap.
If you’d like us to review your roadmap / backlog and provide a fresh set of ideas, we’d be delighted to help. As evidence of faster TTV to you, we’ll even offer to plan your upsell pitch to your clients and help you book orders for your upcoming valuable new products / functionality. We can only take on one backlog review a month and one backlog uplift a quarter, so drop us a note today if you’d like to discuss further.
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
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.
