How smart vendors sell to the CTO


Commentary: For vendors who aim to change the world, sometimes it pays to change their sales approach.

data.jpg

Image: iStock/ty cgi stock

Yes, your product is great. No, it’s not going to solve a CTO’s every problem. In fact, it’s likely to create problems if you don’t find ways to make your shiny new solution work within the confines of a whole lotta legacy tech the CTO (or CIO) already must contend with. In a series of conversations with CTOs and CIOs over many years, it’s perhaps this request (“help me integrate new things with the old”) I’ve heard most often.

From these conversations, I’ve gleaned a cardinal rule: sell the future, but also how that future connects to the enterprise past.

Doing the math on IT purchasing

Before I spent any time actually working in enterprise software, it seemed clear that the way to solve all enterprise problems was simply to buy whatever I was selling. I suspect a quick Google search of past blog posts would confirm this, but I don’t want to get depressed by my youthful indiscretions. After years of “real talk” with IT executives at a wide array of companies large and small, I’m a little wiser. 

Also, I’m a bit better at math.

For example, I may have left AWS, but I’m just as bullish about the cloud opportunity. Still, it was while I was there that I did the math on IT spending and realized that even though the cloud providers were earning billions in revenue, the overall IT market is worth trillions. So, yes, cloud is a big deal, but it’s going to take time

SEE: The most important cloud advances of the decade (free PDF) (TechRepublic) 

Why? Because however much CXOs might want cloud, they’re still spending heavily on mainframes. (IBM’s mainframe business keeps growing.) The bigger the company, the more it is constrained by what it already owns. Ask around, and for companies with revenues of more than $1 billion, as much as 80% to 90% of their IT budgets go toward servicing existing IT (software and hardware). Comparatively little goes into innovation. The more forward-thinking the IT executive, the more they’re trying to shift the balance toward innovation and away from legacy maintenance, but it’s a tough slog.

This is why you’re not being helpful if you propose a miracle cure, and that cure is your product.

Help me help you

While “rip and replace” does happen in enterprise IT, it’s not the norm. It’s far more common for new IT alternatives to find their way into an enterprise through new application development. Again, few companies are in a position to scrap significant swaths of their infrastructure unless legacy IT is actively harming the business in some way. It’s harder to justify the cost (and risk) of a big change without some proof that it will pay. The easiest way to get that “proof” is through small-scale experiments that can demonstrate value for the company within a quarter or so. 

Yes, there will always be an early adopter crowd to which you can sell magical solutions to fix everything. But that’s going to be a relatively small sale, compared with the overall IT budget. (Remember the cloud math above?) The real money is in meeting enterprises where they are and helping them move to where they want to be. That help will often involve not just software but also services. 

SEE: 2022 IT Budget Research Report: COVID-19 prompts organizations to tighten budgets (TechRepublic Premium)

Oh, and people. A recent Linux Foundation survey found that enterprises are anxious to find talent sufficient to help them embrace open source technologies like Kubernetes. Ideally, they’d find that talent internally. As Gartner analyst Svetlana Sicular said years ago, “Learning Hadoop is easier than learning the company’s business,” so helping those employees bring the expertise they have, while adding to it, is a win for enterprises. 

So yes, you should be pitching the brighter future your technology can bring. But if you want to be successful, it pays to tailor that new technology to the old IT investments enterprises will have already made.

Disclosure: I work for MongoDB, but the views expressed herein are mine.

Also see



Source link