When Value Proposition Isn’t Enough
Sometimes an enterprise needs more than just a huge value proposition to embrace no-code... sometimes they need a plan.
I was gratified recently when, while meeting with a senior sales executive covering a large enterprise whose VP of Applications had expressed hesitation, the senior sales executive remarked privately that “the enterprise will save a huge amount of time and money, what else is there to understand?” The reason why that gratified me is because that very thought had consumed and confounded me for many years. If I can save an organization tremendous time and cost all while making them more agile and giving their IT team a greater degree of control and compliance…what else was there to understand?
Well, the simple answer is that for most product sales, where sales representatives are primarily focused, there may not be much else to understand. However, for custom software tooling sales, after many rejections, I realized there must be something more needed. But what?
In thinking back, I’m reminded of a time over a decade ago when I had been trying to sell into a large enterprise. I had courted the CIO for a long period of time, there was a clear project, and I could easily save their organization a lot of money on the project. To be more specific, I could replace and maintain their cluster of MS Access applications in a way that would have reduced their annual costs by 80% and freed their people to work on other projects. I had built a personal relationship with the CIO. I thought to myself “there is no way we can’t win, the decision is obvious”. And it was. But then one Saturday morning, I got the call. My CIO friend called me on a Saturday with a lot of hesitation in his voice, and he told me “I woke up this morning, and I looked at my wife, and I told her ‘I simply can’t take on yet one more thing’.” Really? I was stunned. You are going to save over $200,000 per year, and you can’t take that on?
As it turned out, the value proposition alone wasn’t enough. In this case, a bloated application infrastructure consisting of dozens of other tools and capabilities was weighing their application development teams down severely. In fact, it’s been said various aspects of technical debt (such as that) can count for 3 out of every 4 dollars an IT organization spends. Suddenly, $200k/year didn’t seem like such a big number given that their shop had hundreds of developers.
What are the types of factors that can offset a value proposition as strong as no-code and CitizenDeveloper offers? Off the top of my head, here are five such factors I’ve encountered that have blocked sales. Note that I’ve listed these out in a progressive order…the objections further down are frequently harder to surface; I’ve seen first-hand how the earlier objections #1 and #2 will be given, but where the actual objection was #3, #4 or #5. Use your best salesmanship and ask the right questions to surface and address the real objections. Once you know the real objections, you can apply a selling strategy.
#1: No Time.
This is the most common objection I’ve heard and is definitely a case of “you can’t afford to do this?…actually, you can’t afford not to”. In this scenario, the application and feature requests are truly backed up…sometimes for years. The organization is suffering. They are having emergency meetings on a weekly basis. There is no way they can evaluate a new technology stack and start an organizational change process towards that new tech stack.
But that new tech stack is actually the solution to their problems. It will help them free their specialists to work on other things, and to grind through their backlog. They would be heroes in their organization. But it’s risky. While their world is falling apart, taking risks is scary. These folks need what you are offering, you just need to help them find a way to embrace it slowly and painlessly.
#2: We Need Fewer Tools, not More.
This is another one of those frustrating “you can’t afford to do this?…actually, you can’t afford not to” objections. In this objection, they have tool sprawl within their organization. Every tool backs one or more applications, and therefore needs to be supported. That means that people have to be hired who know each and every tool, and these specialists are harder to hire and come with a premium cost. Every application request then must be evaluated across a variety of possible tools. Just evaluating which tool to use for a given request can consume too many cycles. Competency has to be maintained across so many disciplines that it can get out of hand quickly. Here again, technical debt could be consuming 75% of the IT budget.
In this case, CitizenDeveloper is absolutely the answer…it allows the customer to collapse many of those tools into a single, easily managed tool. The strategy here is certainly to focus on reducing the tool count. Identify which tools lack the right supporting team members, or which are consuming too many team members, or which simply aren’t delivering, and provide a strategy to take those tools out of the mix. Eliminating headaches is a big buy-strategy in the enterprise, and here you have a lot of opportunities to eliminate headaches.
But remember, these past two objections are what is presented on the surface. Read on to see objections that go deeper and aren’t always as simple to handle.
#3: We are a <insert tool stack here> shop.
In this scenario, the central IT shop has put tremendous resources into standardizing around a single (or a few) technology stacks. They own the tooling. They have hired specialists. Their processes anticipate all the challenges that stack brings. When they are faced with new feature requests, they know where to go to find solutions, code snippets, libraries, to get questions answered, to get support. Frequently, despite all the problems of code, what they have is working just enough to make everyone very scared of change. Afterall, no one has gotten fired using the current stack.
The solution here is to talk about a center of innovation…a “skunkworks”. Every gold star IT organization should both be using standardized tooling, but should also be evaluating innovative tool options, and you as the salesperson should help them to understand this. Analyst firms like Gartner have done significant work around advising enterprises to set aside a small amount of budget for innovation.
#4: I Would be Contradicting Statements I’ve made to the Board.
In this variation of #3, it isn’t so much that the executive believes in the sufficient use of the chosen tech stack, it’s more that they are personally invested in the promotion of that stack within the organization. At some point, they pushed for the stack, and signed their name to it. They are in effect responsible for its success. That is not a good person to be asking to change tech stacks! I remember encountering this scenario with a VP of Application Development at a Fortune 500 company, who had also become a personal friend at that point (our kids played sports together, and we sat on a board together). With genuine interest, he and his staff sat through demos of our technology, and he acknowledged the potential of it all. Then he simply said “but we are a Microsoft shop”. And that was that. It was not a #3 argument, it was because he was in a multi-year process of standardizing their organization around Microsoft, and this was just a different direction. In other words, he was personally invested in their current direction.
How do you address this issue? I’d love to hear your thoughts.
#5: A Threat to the Kingdom
I’ve heard several variations on this objection. At one Fortune 1000 company I was told by the CIO “my IT directors won’t support this”. At this company, the IT directors he referred to each sat over their specific tech stack…their own kingdom. Of course, they weren’t going to support adding a new one!
The solution here is to focus on value messaging, and to talk to an audience who wants to hear it. It’s not that these organizations are successful at application development…it’s that they are entrenched in their ways. You must find a way around those kingdoms, because trying to go through them is very difficult.
Conclusion
Should these five issues be blocking the sale? No, they should not, because in each case no-code and CitizenDeveloper will actually be better for the organization. It’s up to us as high-end enterprise sales team members to spot these issues and get ahead of them. Let’s not let the customer be their own worst enemy.
