Standing in the Field
Notes from SJS Application Server Field Engineering
Standing in the Field
Notes from SJS Application Server Field Engineering
Well it's almost a month later, and I still haven't finished my article on software economics. I've been busy, as always, but I've also had some recent changes in my job that have been distracting me. More on those job changes tomorrow.
But since I don't think I'll be able to finish my article in the foreseeable future I wanted to post what I have so far. As a reminder, this article was to be a response and follow up to Bryan Catrill's recent post.
As Bryan Catrill pointed out one of the interesting aspects of software economics is the fact that the gross margin of software is effectively 100%. (Although I'll debate this somewhat in part two.) This has all kinds of interesting consequences, many of which Bryan points out in his original article.
One of Bryan's points is that an existing software customer is relatively price inelastic. In other words, once they are locked into a vendor, they will generally continue to buy regardless of changes in software price. The exception being if the software cost exceeds a the cost of migration: what Bryan terms the FYO point.
In contrast, however, customers that are not locked into a vendor can be quite elastic in response to price. There may be 100 companies willing to spend $10,000 a CPU for your software, 400 more willing to spend $2,000 for your software, 6000 willing to pay $100, and 100,000 more willing to use it if it were free. So software vendors have the choice of either charging everyone $10,000 per CPU (in which case you end up with a niche high end product and only one million in revenue), $2,000 a CPU (you end up with more customers, but the same about of revenue), $100 (less revenue, but lots of customers.), or even offer the product for free and make revenue offering consulting and support to the large group of customers.
One result of these circumstances is "tiered pricing". The Sun Java System Application Server is a classic example of this. Sun's application server comes in three different "editions": Platform, Standard, and Enterprise. Enterprise edition is the complete product and has a list price of $10,000 per CPU. Standard Edition is the same product, with a couple of features disabled and it lists for $2,000 per CPU. Platform Edition has a few more features disabled and is free. Theoretically this is the best of all possible worlds: customers get a price commensurate with their needs. The vendor maximizes their revenue by tapping both low-end and high-end markets. But this is a hard balancing act. The hardest question being, what features are needed only by high-end customers? You don't want your low end product to be crippled so much that no one will use it. But you also want the extra features of the high end product to be compelling enough to win over the high end customers.
Tiered pricing isn't unique to the software industry, of course, But the effective 100% gross margin of software means that the tiered pricing tends to be very extreme. Apple sells iBooks in three tiers ranging from $1,099 to $1,499. Honda sells Accords in tiers from $15,900 to $23,300. But a price range of $0 to $10,000 has a much different impact, especially when printing a CD costs to the same amount to Sun regardless of which edition it ships to a customer.
Further complicating this issue is that the cost of sales and customer expectations will also change as you change the price point. If you have a $10,000/CPU product, your customers will expect hands-on attention from a sales force, long evaluation periods, analyst coverage, and 7x24 support. If you charge $100/CPU, customers will expect a lot less: they will buy over the web. They will have lower expectations of support and services. Evaluation periods will be short. This is only natural: companies are are trying to avoid getting locked into the situation that Bryan describes. A $100 investment is a lot easier to abandon than a $10,000 investment. But the net result to vendors is that pricing not only affects the revenue you make from a product, but also how your product is perceived and purchased.
There was a discussion on the Joel on Software forums about this. Joel writes about the fact that customers will sometimes avoid less expensive products because they are perceived as "cheap". He also talks about certain price thresholds. Under $500 and your product can be bought by a low level manager on a corporate credit card for departmental use. But,
[A]s soon as your price gets up in the $3000 level, the amount of approval it needs is so absurd that you are not going to sell products without a salesperson making a few visits. Hiring the salesperson, sending them out to make presentations, hotels, airfare -- now it costs $50,000 to get the sale done just in sales closing costs. That's why you see a lot of software products at $100,000 and a lot under $3000, but anywhere in-between and it's impossible to make sales.
This really resonates with me because Sun Java Web Server has a list price of $1,495/CPU and Sun Java Application Server Standard Edition has a list price of $2,000 per CPU. Which makes a lot of deal sizes in that five figure range that Joel warns about, and I've seen the challenges that price range brings. It's hard for Sun to justify putting me on a plane to do a demo for a potential $10,000 deal. But on the other hand, volume wins. So Sun wants these midrange products to be successful. It's a difficult balancing act but, as always, Sun tends to err on the side of customer satisfaction.
The net result of this is that software pricing is arguably more complex than any other industry. The 100% gross margin on software means that the relationship between price and quality is tentative at best. There have been free products (including open source) that have been very high quality. And many very expensive products are what Joel Spolsky calls "consultingware": software that ends up being nothing more than a framework to be used by consultants. And, at the risk of sounding like I am patronizing my boss's boss's boss's boss's boss's boss, the net result of all of this economics lesson is that volume wins. Although a large percentage of the software market is in sales to the Fortune 100, it's really the small to mid size companies that make or break a software product. Because the small to medium market is where the cost of sales is the lowest. And because the small to medium market is were the volume is. Since the cost of printing CD's is effectively zero, every additional customer goes directly to the bottom line as profit.
More on this later this week when I post my second part discussing the real costs of software.
(2004-10-05 19:54:12.0) Permalink Comments [4]Well it's almost a month later, and I still haven't finished my article on software economics. I've been busy, as always, but I've also had some recent changes in my job that have been distracting me. More on those job changes tomorrow.
But since I don't think I'll be able to finish my article in the foreseeable future I wanted to post a summary of what I had been thinking.
As a reminder, this article was to be a response and follow up to Bryan Catrill's recent post.
As Bryan Catrill pointed out one of the interesting aspects of software economics is the fact that the gross margin of software is effectively 100%. (Although I'll debate this somewhat in part two.) This has all kinds of interesting consequences, many of which Bryan points out in his original article.
One of Bryan's points is that an existing software customer is relatively price inelastic. In other words, once they are locked into a vendor, they will generally continue to buy regardless of changes in software price. The exception being if the software cost exceeds a the cost of migration: what Bryan terms the FYO point.
In contrast, however, customers that are not locked into a vendor quite be quite elastic in response to price. There may be 100 companies willing to spend $10,000 a CPU for your software, 400 more willing to spend $2,000 for your software, 6000 willing to pay $100, and 100,000 more willing to use it if it were free. So software vendors have the choice of either charging everyone $10,000 per CPU (in which case you end up with a niche high end product and only one million in revenue), $2,000 a CPU (you end up with more customer, but the same about of revenue), $100 (less revenue, lots of customers.), or even offer the product for free and try to make revenue offering consulting and support to the large group of customers.
Further complicating this issue is that the cost of sales and customer expectations will also change as you change the price point. If you have a $10,000/CPU product, your customers will expect hands-on attention from a sales force, long evaluation periods, analyst coverage, and 7x24 support. If you charge $100/CPU, customers will expect a lot less: they will buy over the web. They will have lower expectations of support and services. Evaluation periods will be short. This is only natural: companies are are trying to avoid getting locked into the situation that Bryan describes. A $100 investment is a lot easier to abandon than a $10,000 investment. But the net result to vendors is that pricing not only affects the revenue you make from a product, but also how your product is perceived and purchased.
There was a discussion on the Joel on Software forums about this. Joel writes about the fact that customers will sometimes avoid less expensive products because they are perceived as "cheap". He also talks about certain price thresholds. Under $500 and your product can be bought by a low level manager on a corporate credit card for departmental use. He also says,
[A]s soon as your price gets up in the $3000 level, the amount of approval it needs is so absurd that you are not going to sell products without a salesperson making a few visits. Hiring the salesperson, sending them out to make presentations, hotels, airfare -- now it costs $50,000 to get the sale done just in sales closing costs. That's why you see a lot of software products at $100,000 and a lot under $3000, but anywhere in-between and it's impossible to make sales.
This really resonates with me because Sun Java Web Server has a list price of $1,495/CPU and Sun Java Application Server Standard Edition has a list price of $2,000 per CPU. Which makes a lot of deal sizes in that five figure range that Joel warns about, and I've seen the challenges that price range brings. It's hard for Sun to justify putting me on a plane to do a demo for a potential $10,000 deal. But on the other hand, volume wins. So Sun wants these midrange products to be successful. It's a difficult balancing act but, as always, Sun tends to err on the side of customer satisfaction.
(2004-10-05 06:51:39.0) Permalink| « October 2004 » | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 7 | 8 | 9 | ||
10 | 11 | 12 | 13 | 14 | 15 | 16 |
19 | 22 | 23 | ||||
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 | ||||||
| Today | ||||||
