Blog

Customizations suck

A few months ago I wrote an article for Light Reading called, Why do telco software companies have such lame valuation multiples? I made a few key points:

  • Telco software companies are typically valued at 2 – 3x revenue;
  • They are valued that way because they typically have a large professional services component of revenue; and
  • In order to increase telco software company valuations, they’re going to have to switch to PRODUCT revenue and away from PROFESSIONAL SERVICES revenue.

Yeah, I said it. Ditch your professional services revenue. But if I were talking to a room full of telco software CEOs, I bet most of them would say, “I can’t, it’s our industry, and we HAVE to let customers customize the product. They demand it.”

That may be true: customers do demand changes to be made, and to be made as quickly as possible. But I’m going to argue that it’s bad for BOTH SIDES, and especially for CUSTOMERS, and everyone needs to just stop it.

And so, a bit of background … telco software companies’ professional services revenue comes from three primary areas of activities: delivering implementations, delivering change requests, and upgrading customers. For implementations and upgrade services, as long as telco software companies continue to install their software on premise (and that includes installing in a #fakecloud private cloud), telco software companies will have these types of revenue, making this revenue difficult to kill.

But let’s talk about the other big component – and it’s really, really big in telco – which is change request or “CR” revenue. This is the revenue from customers asking vendors to change their version of the installed software. It might be to add a feature just for them. Or to change the workflow to follow their process exactly as they have it set up. Regardless of the reason, 99% of the time it requires software developers to understand the modification, code it up, test it, and put it into production. And this is where we run into trouble.

See, if Elon Musk can build a re-landable rocket, chances are whatever change request a customer can think of, a developer can code. I mean, it’s software. You can pretty much make it do anything, given time and resources. But here’s the thing. Just because you CAN modify software to do something, doesn’t mean you SHOULD modify the software. And this is where I have a very strong point of view.

Let me tell you about the dirty little secret of customizations that vendors don’t tell you. Every time a customer makes the decision to customize a product installation, they are digging their own grave. It’s a fantastic way to trap a customer forever – and better yet, they asked for it! (No wonder Amdocs gives away its software for free and charges for PS.) You’re trapped because you can’t move to anything else without a massive effort, and because you paid handsomely for it, you want to take it with you on every upgrade from here on out.

But here’s another great reason not to do customizations: they just make the installation you have worse. The product is slower. More expensive to operate. You risk falling behind on the roadmap because you can’t upgrade as frequently. It’s harder to test. More vulnerable to bugs and issues. Not to mention now the vendor is maintaining this special code for you. Is it in version control? Or did some skunkworks side team deliver it for you, undocumented where only one guy named Bob knows where it is in your millions of lines of software code?

Maybe telcos like being so slow. They’re famous for it, after all. Maybe they like to spend money for the heck of it? Customizations will put you at least two years behind the market. It will take six months to launch a variation on your offerings, two months to implement a new offering, or 24 months to accommodate the next technology wave in your marketplace (um, can you say public cloud?). With each customization you make it exponentially more expensive to maintain. It’s a complete mess.

Just to drive this point home, time for a true story. I once had a customer that had installed more than 100 different customizations into its installed version of my product. Over 10 years, more and more crud had been added to the product like Spackle or Polyfilla patching a hole. If the product’s speed was 1x, the weight of all the customizations was loading it up “like a sidecar” (as Jon Fagan from CSG recently said on episode 13 of the Telco in 20 podcast) and dragging it down so it was 5x slower than it would have been had the product been left alone. FIVE TIMES! In charging, where speed matters, that’s a death sentence. My message to the customer: start stripping it out and get your installation back to where it was meant to be: blazing fast.

So my message to telco execs:

  • STOP CUSTOMIZING.
  • Select vendors that provide flexible frameworks, so that non-technical people can use business logic to implement ideas in minutes, not months.
  • Stay as close as possible to the product roadmap and reduce the upgrade complexity so you can receive new innovative features as quickly as your vendor can deliver them.
  • Stay lean and mean – this will create operational speed you’ve never seen in telco.

Fortunately, there’s something coming to telco that’s going to fix all of this. There’s a revolution afoot in the form of the public cloud and SaaS applications. Multi-tenant systems that are centrally managed and provided as a service are just around the corner. There are new software providers coming that are going to drive all of these inefficiencies and costs out of the telecom industry and replace them with a speed of delivery heretofore unheard of. BUT you’re going to have to give up your crazy customizations. Question is: will you be able to do it?

Recent Posts

  1. 5 things you gotta do at MWC24
  2. 4 ways to spot #fakeAI
  3. The perfect BSS
  4. Telcos, don’t give away your strategic advantage!
  5. Do you need an AI strategy?

Telco in 20 Podcast - Tune in

Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

More from TelcoDR