I can’t remember how many times at Smart Bear I tried to sell Code Collaborator with the argument that it “saves you money.” And customers demanded it — some even required that we produce an ROI spreadsheet. And we did.
The argument makes sense (though it’s wrong). Code Collaborator is tool which helps software developers review each other’s work, just like an editor of a book. It cuts the time of a code review in half — maybe better — because it eliminates busywork.
So the economics are obvious: If two developers would each normally spend an average of 30 minutes on a code review, once a day, that’s 20 hours of total time in a business-month. At a fully-loaded developer cost of $150/hr, that’s $3,000/mo. Code Collaborator cuts the time in half, which means you save $1,500 every month.
Code Collaborator costs $499/developer — one time — so you make your money back inside the first month! After that it’s gravy… all the way to the bank.
You can’t afford not to buy it, right?
But this argument never worked, not once, even though the reasoning is sound and customers requested it. The reason is that the “savings” isn’t commensurate with how budgets actually function.
In a perfect world, if the software development organization “produced more quality code” with fewer important bugs, that’s undeniably valuable. But it’s also essentially impossible to measure, and is never in fact measured. So the “savings” are invisible, even if real.
On top of that, budgets are siloed; the “Salaries” budget is separate from the “Tools” budget. Never once in my seven years selling software at Smart Bear, whether 10 seats or 2500 seats did a company make a decision in which a supposed savings in the “Salaries” budget resulted in a boost to the “Tools” budget.
This isn’t just true with engineering productivity. If a company spends $30k on marketing, and your tool “saves” them $15k, are they now spending $15k on marketing? No, they’re still spending $30k, but theoretically with much more output, i.e. higher efficiency. But the marketing budget is still $30k.
But that’s OK isn’t it? Suppose you want $2k/mo for your tool that’s creating that efficiency. This is logical because you’re “saving them $15k,” so surely they’d be happy spending $28k on marketing and $2k on your tool and keep the budget constant.
But that’s still not how it works, because unfortunately people have a natural aversion to spending big bucks on software. The trouble is that software isn’t tangible.
For example, there’s tons of AdWords-Optimization or SEO companies who charge $2k/mo for doing exactly the service I just described, and tons of companies happy to pay. Inevitably they’re paying for a service — human beings doing this work, often with “white-glove” monthly meetings replete with reports and recommendations.
What about companies selling those same things as tools? SEOMoz doesn’t charge $2k/mo — it’s more than an order of magnitude less. Remove the “service with a smile” and you drastically destroy what people are willing to spend for largely the same outcome.
These two examples are two faces of the same thing — that “saving money” or “saving time” is usually an artifact of the value, rather than the way to price.
In the case of Code Collaborator, the customer buys because they genuinely believe this makes for a more productive team, even though they cannot in fact quantify ROI. Spreadsheets are meaningless — they have to be sold on the concept, and the team has to feel it too.
In the case of the Marketing Tools, the customer buys based on the comfort of white-glove service in achieving that cost-savings, not on the cost-savings itself, as is evidenced by tools which do the same thing, causing the same cost-savings, and yet command 1/10th the apparent value.
As the startup founder, what do you do about all this?
First, create so much value (efficiency, time-savings, cost-savings, happiness, whatever) that there’s no need to “compute” it. Make the so-called pay-back period less than a month. Change someone’s workflow so drastically for the better that they can’t live without it whether it’s saving money or not. Improve your customers’ marketing campaigns so obviously and drastically that they don’t need a spreadsheet to understand its value.
Second, price according to willingness and ability to pay rather than as a direct function of so-called “value.” The software development department has a budget for tools and different companies have different ways of arguing internally for expanding that budget — you have to match those constraints regardless of “value delivered.” The marketing department might be willing to pay for services but not for tools.
In any case, rarely is a simple “cost savings” equation the way you’re going to win sales or set price-points.