"ROI" is the wrong way to sell your product

Inhalt

by Jason Cohen on October 10, 2012

Customers ask for ROI calculations to justify purchasing your software, but it still doesn’t convince them. Here’s what to do instead.

Cartoon d916e7a2

I can’t remember how many times at Smart Bear I tried to sell our main product Code Reviewer with the argument that it “saves you money.” Some customers demanded it in the form of an ROI spreadsheet. So we gave it to them.

The argument makes sense (though it’s wrong). Code Reviewer 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. We even lead with that in our one-pager (because back in 2004, sales calls were in person, and one-page leave-behinds were useful):

Code Reviewer cuts peer review time in half

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 per month. At a fully-loaded developer cost of $150/hr, that costs you $3,000/mo. Code Reviewer cuts the time in half, which means you save $1,500 every month.

Code Reviewer costs $499/developer—one time1—so you make your money back with the first month! After that it’s gravy… all the way to the bank.

1 Ah, the days before SaaS, when all software was “lifetime,” though you’d attempt “maintenance and upgrades” sales in future years at 20% of the original price. Life is better now.

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 these “savings” aren’t how budgets actually work.

In a perfect world, if the software development organization really did produce more, higher-quality code, that’s undeniably valuable. But it’s also essentially impossible to measure, and is in fact not 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 savings in the “Salaries” budget resulted in an increase to the “Tools” budget.

With Code Reviewer, the customer buys because they genuinely believe it makes their team more productive, even though they cannot in quantify ROI. Spreadsheets are worthless—they either believe, or they don’t.

As the startup founder, what do you do about this?

First, create so much value2 that there’s no need to “compute” it. If so-called pay-back period really is less than a month, it’s obvious. 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.

2 more leads, more sales, faster code, efficiency, time-savings, cost-savings, delight, corporate brand, personal image, societal impact

Second, price according to ability and willingness to pay and the structure of your business model, 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. 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 prices.

☞ If you're enjoying this, please subscribe and share this article! ☜

Zusammenfassen
The article discusses the ineffectiveness of using ROI calculations to convince customers to purchase software. The author shares his experience of trying to sell a product by demonstrating cost savings through ROI spreadsheets, but it never worked. He explains that budgeting and decision-making processes in organizations do not align with these savings. Instead, he suggests creating undeniable value that doesn't require computation and pricing the software based on the customer's ability and willingness to pay, rather than its direct value. The author emphasizes the importance of demonstrating significant value and aligning pricing with the customer's budgeting constraints and internal decision-making processes.