FWIW, I don’t think the 3% number you cited is universally applicable, although it could definitely apply in some domains.

You’re right that the cost of acquisition is higher for new customers than old customers, but after about 15 years of working with enterprise software companies and with dozens of enterprise software customers, I will tell you this. My perception is that an inordinately higher level of investment is made on new-customer acquisition than on revenue-generating upgrade sales. Many enterprise licensing arrangements include all minor (and occasionally a fixed number of major) upgrades in the initial sale.

I don’t see license sales and then SaaS as serial stages in the lifecycle of products based on a particular technology. I see them as orthogonal business models that can compete in the same market. Different financial considerations may drive companies in one direction or another, and for a given market segment / product space, may make one model incredibly ineffective at competing with the other. The Kindle sells “forever” use of the cellular modem + network as part of buying the product. Why don’t cell phones get sold the same way?

Also – great point about feature-bloat tendencies in licensed products. The McKinsey analyst found 50% to 80% of the features in licensed products were unused, while SaaS providers were able to measure usage more effectively and tailor their offering accordingly. Note that this is really more about online/offline applications, but there is definitely correlation (but not causality) between on/offline applications and SaaS/licensed products.

In the TCO, the infrastructural multiple increases without regard to release cycles. The infrastructural multiple washes out ROI claims above 3%. Learning builds at the front of a release and falls at the back of the release. Learning cost extend beyond what shows up on the books. Many of the learning and support costs involve the salary contribution of workers who cannot for the moment be productive. That time represents money lost.

Not all companies selling licenses reduce the commissions on upgrades. When they don’t, they are failing to capture their increasing return. This usually results in higher prices.

Selling licenses and then selling SaaS subscriptions are both necessary over the life of the underlying technology. You sell license until you enter Moore’s late mainstream market, enter a recession, face price-based competition or commoditization, or enter a consumer market.

When you transition from product to service, start by moving license and subscription management–the business transaction functions–online first. Then, move some, but not all features online. Eventually, all your features will be online. Further, the UI for licensed software will be geek facing and feature bloated, while the UI for a SaaS application will remove the feature bloat, use intelligent defaults and other knowledge-based capabilities, and will face the non-geek. SaaS provides the power without necessitating the control that geeks don’t want to do without. This divide may have you maintaining your licensed product while serving your SaaS version.

I’ve seen similar dynamics (vendor to business, bypassing IT) as well. I’ve also seen that with packaged software sales (into F500 companies), where the business feels that IT is not agile enough to enable the business to succeed. That introduces some interesting governance problems, and a bunch of “mini IT shops” within pockets of a corporation. Then the pendulum swings the other way, and the company goes back and forth between trying to be agile and trying to reduce ongoing costs.

SaaS presents an interesting opportunity to avoid that problem, although when you customize a SaaS product, you run into the same governance issues. One client I’ve worked with has a massive SaaS vendor, and all of the “customization activity” is managed through a global IT bureaucracy. The client realizes the TCO benefits, maintains some governance, and loses some of the agility that would otherwise be enabled by outsourcing a “best of breed” component of their infrastructure.

You do raise an interesting point about paying for SaaS as a recurring expense versus a capital outlay. I think it depends. I’m too rusty on my tax accounting to know what type of depreciation schedules a company can set up for a long-term SaaS contract, or if they even can. I also wonder if the company would have to track a SaaS vendor relationship as an ongoing liability (like property leases). So at the CFO level, I don’t really know which is better.

Most of the economic buyers I’ve worked with in the enterprise space can make recurring commitments (SaaS) of more significance than packaged-software ‘purchases’ due to the way their budgeting authority is granted. That does make it easier to penetrate an account with a viable solution.

I think you’re spot-on, pragmatically, about being closer to the customers. I don’t know of an enterprise IT team that manages itself as a profit-center instead of as a cost-center. A profit-centric IT group would, in addition to cost-management, would engage tightly with the business to uncover opportunities to improve the business. That IT team would probably be even better to work with (as a SaaS vendor) than working only with the business. Primarily because that IT team would be able to apply a global perspective in how the company can benefit from and integrate with your offering, where an individual business group would be narrow in scope. You could unlock more value for your customers when working with that magical IT team.