Business & Technology Nexus

Dave Stephens on technology and business trends

Archive for December 2006

Exploring Enterprise Software Pricing Models

with 4 comments

I’ve posted quite a few times on SaaS before. Some posts have been positive, while others have been more challenging.

But there’s one truth I think we can all agree on – that the pricing model of SaaS is fundamentally different and very challenging for traditional vendors to match.

Software license pricing is a very interesting area – as the business models themselves end up acting as a strong motivating force for very different styles of software development. But before we get into the psychology of pricing, let’s walk through the 3 basic approaches:

1. Bits-in-a-box Version-specific Perpetual License

Consumer software is sold this way, almost exclusively. Companies build a product, like Textmate 1.5 or Microsoft Word 2004 for the Mac, and sell you the right to use that software till the end of time. More and more, companies will use the internet to provide you minor updates for free, but these updates have more to do with controlling the firm’s support costs than anything else.

When a new version comes out you might receive a discounted price for an “upgrade” to the new version. But you may just cruise along on the old version if that proves good enough for your use. It’s up to the company to entice you to upgrade, presumably by building an impressive set of capabilities you determine you just can’t live without.

Support for consumer software products has been, for the most part, assumed. In the first place, if you are selling a product to hundreds of thousands of people for $20, you better not offer something that leads to them all wanting to call you to figure out some thorny technical problem. So, over time, people have gotten use to buying without the expectation of implicit support. And “bundled support” with the perpetual license, has become more and more paltry.

2. Introducing the Annual Support Contract

Software vendors have yet to offer the same quality and reliability in business software as they do for consumer software. And employees of the company buying the software, quick to protect their interests and standing, require significantly more assurances around a software buying decision. Enter the annual support contract. With it, software companies offer an array of telephone and web-based support, sometimes even including on-site presence.

At Oracle, this contract included a curious clause – as long as a customer stayed current on their support contract, both minor and major revisions of the software would be available “free of charge.”

In this way the customer pays for the current version via their perpetual license purchase, then for ongoing development with a portion of their annual support payment.

I assert that the Oracle model, while very fair to current customers, reduces the incentive to upsell its current customers on new versions of the software, and thereby decreases pressure to make more than incremental progress. Instead, it places an emphasis on new customer acquisition & on competent support thereafter.

3. Subscription – you know, like the Wall Street Journal

SaaS has been called “revolutionary” because it removes the burden of systems management from customers – instead relying on centralized, assumedly more expert resources to manage maintenance and updates efficiently. And we’re all used to SaaS – we use it via Google Maps, via Yahoo! Mail, and other B2C web services.

But in the enterprise space, SaaS tends to come along with something just as radical – the “end of the perpetual license.”

I’ve gotten in trouble in the past at describing SaaS as a “software rental service” – but the analogy holds here. But instead of thinking of software as “like a house” (which tends to appreciate over time), think of it instead as “like a car” (which tends to depreciate over time). So why not rent?

Knowing your software vendor’s preferred licensing model can give you insight into their likely future behavior. In the enterprise, there’s a definite shift away from a high up-front fee for an enterprise license fee, especially for big businesses concerned with the high degree of shelfware (software bought but rarely used i.e. sitting on the shelf).

The last point here, predictably, is that while SaaS made it popular, subscription licensing can work for on-premise software too. And for many businesses, subscriptions may just be a better way to go.


Written by Dave Stephens

12/13/06 2:32 PM at 2:32 pm

Posted in IT, Procurement

Matt Asay – Advice for Open Source Startups

leave a comment »

I thought Matt wrote a pretty informative piece on Alfresco’s experience with demand generation a la open source firms. Check it out here.

The Coupa experience is too new to form any conclusions on what lead gen programs work best. We’ve had interest from prospective partners and prospects from all over – so part of the secret sauce is definitely deciding “what not to do.”

The key add I would offer, as a companion to Matt’s sage advice, is to not get carried away on the winds of promising oh-so-close-you-can-taste-it prospects – and take your eye off the ball on the #1 reason any software company succeeds – the product! My guess is that all paths on demand gen lead to success if the product is useful and solves a problem a business person is interested in..

Written by Dave Stephens

12/8/06 10:15 PM at 10:15 pm

Posted in Opinion

Use “Use Cases” to Evaluate Procurement Software

leave a comment »

Making procurement click at most companies involves handling the req to check process as easily as possible. That’s why @ Coupa we’ve spent so much time with our initial releases trying to get the usability “right”. But beyond drag-n-drop, streamlining, and consumerizing the application, procurement flows must recognize the nuances of “what” an individual is trying to buy.

A 1-time engineer-to-order part is a lot different than a PDA. And a complex services buy is another thing entirely. So you can learn a lot in your eProcurement software evaluation by shrugging off the abstractions and going with your actual use cases to see how the software “fits” your business.

[One thing you learn, as a software vendor, is how the whole idea of verticalizing Procurement software is a fallacy. The use cases dictate software functionality, and those use cases can and do cross industry verticals in unexpected ways. Said another way, once you’ve handled Simple Fixed Price Services, you’ve handled it, regardless of whether it will be used in Public Sector or Aerospace. Now on the margins you can find exceptions where truly vertical functionality creeps in. And certainly Direct Materials Procurement should be treated as a special and important case. But at the core much of Procurement is a horizontal application category. ]

So my recommendation is to not get caught up in an exhaustive feature-function list in your next evaluation – instead stick to flows that keep the context of what you are trying to achieve. Build up your use cases on what you’ve bought in the past — and if that’s not available take your best guess. Buy a lot of complex services with SOW’s you want to track through payment? Ask your prospective vendor how their software can handle that flow.

Sticking to category use cases gives your vendor the ability to meet your requirements without being straight-jacketed. And using them can make sure you hit the targets you are signing up for with the project.

Good luck!

Written by Dave Stephens

12/4/06 9:33 PM at 9:33 pm

Posted in Opinion, Procurement