2004-08-18 19:26:20
Product Pricing Primer
Summary: Eric provides a collection of issues to consider when making decisions about the price of software products.
Every small ISV wrestles with the question of how to set pricing for its software products. I've been asked many times to write an article on this topic, and I have finally decided to do so. Before we begin, I would like to offer a disclaimer:
Product pricing is hard. There is no magic formula that will determine the best price for your product. I can't provide any easy answers, but I can give you some things to think about as you make your pricing decisions. In the end, you will just have to make a decision using your own judgment. There will be times you will wonder if you made the right decision. You may never know for sure.
Stating the Problem
Let us first say that our goal is to find the price at which profit is maximized. If we say that a price is "too high" or "too low," we are saying that our profit could have been greater if we had set the price either lower or higher.
Obviously, revenue is the simple multiplication of quantity by price:
Revenue = Quantity * Price
Where "Quantity" is the total number of units we sell, and "Price" is the amount we charged for each unit. The only variable we can control is the price. But the price we choose will influence the quantity sold.
In a simplified view of the world, we would draw a graph with price on the x axis and revenue on the y axis. The curve would look like a parabola.
The price we want is the value of x at the point at which the curve peaks. However, in real life, pricing is far more complicated than this.
It All Starts with Positioning
Pricing and positioning are inseparable. Don't bother trying to figure out your price point until you first figure out what position your product will have in the market.
Ask yourself these four questions:
- Who are your competitors? If you honestly think you don't have any, then your product is going to be either a huge success or a huge failure.
- How is your product different from your competitors? You should have a very short answer to this question, and you should be able to deliver it quickly. One important caveat: If you think your primary differentiator is price, think again. Differentiation is absolutely critical, but using low prices as your primary differentiator is a well-worn path to failure. More on this later.
- How do you want to be known in your market? You need to be able to describe what position you want to have in terms of the way you want your target market to perceive you.
- What are the prices of your competitors' products? Your prospective customers will compare your price against those of your competitors, so you might as well start doing it now.
Keeping all these things in mind, you should be able to figure out an approximate price range to use as a starting point. In rough terms, what price range is consistent with the perception you want people to have of your product?
As a hypothetical example, let us suppose that you want to develop a new database development tool based on the Firebird open source database. Responding to the four questions above:
- Your product will compete directly with Microsoft Access.
- You've decided your primary differentiation point is the strength of the Firebird engine. Firebird has the ease of deployment of Jet but is far more powerful.
- You want your product to be known as the best way to build serious desktop database applications.
- At the time of this writing, it appears that the price of Microsoft Access is $229.
So what is the right price range?
This question is the point where most small ISVs will wimp out. "We don't have the Microsoft name." "Our product is less mature." "We feel inferior, so obviously our price has to be lower than theirs."
Bzzzt! Wrong answer. The right answer is: "A lot more than $229."
Your differentiation is clear. Your strategy is to convince the world that in one specific way, your product is better than Access. Your price has to be consistent with that message. Nobody will believe you if you set your price at $199. By doing so, you are sending a mixed message.
Send the world the clear message that you believe your product is around four times better than Access. Set your price at $899. Find creative ways to say, "You get what you pay for."
By the way, please don't send me e-mail and tell me what a lousy product idea this is. Trust me, I know. I'm simply trying to use this example to illustrate the point that pricing and positioning are inseparable. Don't miss that point by focusing on all the obvious holes in this very hypothetical example.
Think About Your Expenses
In more traditional industries, a classic approach to the pricing problem is called "cost plus." Basically, "cost plus" means that you determine your product price by taking all your costs and adding the amount of profit you want.
We don't really want to price things this way. The software industry is maturing, but our markets are a long way from the day when they behave like actual commodities. Our pricing should not be primarily based on our expenses. We want to charge the maximum amount that our customers are willing to pay.
However, that doesn't mean we should completely ignore our expenses when we make our pricing decisions. Whatever price we choose, we do have to convince ourselves that we can in fact make a profit. We need to identify all our costs, being careful not to overlook any of them that might be hiding. The total of all of those expenses will help us define the floor--the minimum price we can consider.
There are several different kinds of costs that we need to remember:
Development expenses
Compare your small ISV to a traditional business like a bicycle shop. Most of the bike shop's expenses are monthly items that are quite predictable. The guy who owns the bike shop isn't actually designing and manufacturing the bikes. He buys the bikes, marks up the prices, and sells them.
Your life is different. In your small ISV, you are not merely the retailer, but also the designer and manufacturer. You have to invest a whole bunch of time and money in development before you can get your first dollar of revenue. Regardless of how you paid for that development effort, it must be considered and somehow included in the price of your product.
The bike is no different, actually. Be it a bicycle or a blogging tool, the price of every product must reflect the cost of its design and development. The bike shop guy knows exactly what this price is—it is the amount he paid for the bike. In your case, you might want to keep track of your developers' time so you can get a rough idea of the value of the effort you have expended.
Cost of goods
The price paid for the bike is called "cost of goods." The difference between cost of goods and the product price is usually called "markup." In traditional businesses, the amount of markup varies widely. Clothing at the mall may be sold at 100% markup. A clothing business may buy a shirt for $15 and sell it for $30. The markup on a gallon of milk--or a small sedan--is much lower.
In a small ISV, the concept of markup is essentially irrelevant. The actual "cost of goods" on each sale is very low, perhaps even zero if customers are merely downloading your product. Nonetheless, if you do have physical materials like a printed manual or a CD-ROM, be sure to keep those costs in mind when you determine your pricing.
Tech support
This cost is sometimes difficult to quantify. Customers need help. They get themselves into strange messes and expect you to get them out. You have to be ready to provide assistance to your customers. There are two common ways of dealing with this:
- Hire tech support people who help customers full-time.
- Have your developers use a slice of their time to help customers.
There are costs associated with each of these two approaches. Here at SourceGear we use a combination of both.
Costs of selling
How are you going to sell your product?
- If you have a Sales Guy, you have to pay his (or her) expenses and commission. This can be an enormous amount of money.
- If you use resellers, they will expect a discount of at least 20 percent.
- If you pay someone to host a Web storefront, that person will take a percentage.
- If you want your product on the shelf at a major retailer, the retailer might take 50%.
- If you host your own storefront, you'll have to pay the costs of hosting.
- If you accept credit cards, the merchant account fees will be around 3 percent.
- If you accept checks, some percentage of them will bounce.
- If you accept corporate purchase orders, some percentage of them will not be paid.
Regardless of how you do it, the act of selling costs money. You have to include these costs somewhere in the price of your product.
Overhead (a.k.a. "everything else")
All of the costs in your business have to get paid somehow, including rent, utilities, insurance, taxes and your T-1 line. When you calculate your costs, don't overlook anything. Make sure your understanding of your company's expenses is complete.
How Much Is Your Product Worth to the Customer?
One of the most important issues in your pricing decision is the matter of how much value your product generates for your customer. This value is the justification for the price of your product. As much as possible, it is important to understand your customer's perspective on this.
Some products generate value that is much easier to quantify than others. Let us suppose for a moment that you invented a molecular transporter that can instantly "beam" an individual to any place in the world. How much value would this generate for the business traveler?
Although this example is obviously rooted in fantasy, it is quite simple to quantify. I really need to visit the Microsoft campus tomorrow. It's not hard to figure out approximately how much I would pay to be instantly transported to Redmond.
- I just checked airfares and I see that a roundtrip ticket to SeaTac is going to cost me $2,388 (USD).
- The flight will take approximately seven hours each way, including a layover at O'Hare. Let's assume I value my time at $50 an hour. That's another $700.
- Instantaneous transport will spare me a hotel stay. That's another $200 or so.
Bottom line, my break-even point is around $3,300. Let us now suppose that your transporter only costs $100 per jump, including depreciation on the machine. You could charge me $300 roundtrip and still make money.
However, I am happy to pay you ten times that amount and I am still saving money over my other option. You should charge me as much as I will pay, even if the profit is obscene. Eventually, market forces will erode your profit margin. Enjoy it while it lasts.
Put yourself in the shoes of your customer. Understand his world in as much detail as you can. Figure out how much your product is worth to them.
High-Volume-Low-Price or High-Price-Low-Volume
With apologies for grossly oversimplifying, I assert that you are facing an important strategic decision that offers you two alternatives:
- Do you want to sell your product to a few customers, each of whom will pay you a very high price?
- Or would you rather sell your product to many customers, each of whom will pay you a lower price?
This matter is highly tied to the questions about your positioning. It is important to realize that you have these two alternatives. In fact, there are probably a number of other opportunities available between these two extremes.
Conventional wisdom says that if all else is equal, if you can get the same revenue with fewer customers, you should do so. There is a certain cost associated with having every customer. Having fewer customers reduces those costs and simplifies things.
However, I have to confess that I'm not fond of this bit of conventional wisdom. I simply don't like the implication that customers are something to be avoided. We sell SourceGear Vault for $199. We could have priced it ten times higher and focused our marketing message only at those customers who really needed Vault's specific set of features and benefits. I honestly don't know if our revenues would be higher or lower than they are now.
However, I personally prefer the high-volume-low-price approach. In high school I played Harold Hill in The Music Man. I've been a bit of ham ever since. I like a big room.
Having a large customer base has some advantages that offset those per-customer costs. A larger customer base will generate more buzz and more word-of-mouth marketing. A larger customer base has more gravity.
The high-volume-low-price approach fits very well with the "Responsive Sales" approach I presented in Closing the Gap. Part 2. In contrast, if you choose a high-price-low-volume approach, you are far more likely to need a sales guy.
Is Your Price Too Low?
Low prices can cause all kinds of problems. Most people are naturally afraid of setting a high price point, worrying that the customer simply won't buy the product if it is too expensive. To balance that fear, here are two reasons you might want to be afraid of setting a price point that is too low.
Price alone is a lousy differentiator
Referring back to the issue of positioning, it is hard to overstate the importance of being different. Your product doesn't need to be better in every way--it needs to be better in just one way.
But as I mention above, you don't want lower price to be your primary differentiator. It's okay to be competitive on price, but you need something else to say as well. If your only message is about price, a certain portion of your market will perceive your product to be "cheap" or "low quality." If you want to be aggressive on price, fine, but focus your message on something else.
Even worse, if price is your only message, what happens if your competitors lower their price to match? Now you have nothing at all to say.
Software development is risky
This is a risky business. The industry-wide pace of change is insane. The trends come and go at a ridiculous pace. The competitors are big and smart.
Running a small ISV requires you to take risks, and it is inevitable that you will get burned at least once in a while. One of the reasons that gross margins in software are so high is to offset all these unpleasant surprises. When you get too aggressive on price, you are cutting into those margins, and you may be reducing your ability to cope with the next unpleasant surprise. The customer might pay more.
In the macro view, a product will always sell fewer units at a higher price than it would at a lower price. However, in the micro view, there are exceptions.
Over the last seven years, SourceGear has sold approximately 60,000 licenses of SourceOffSite. Our current price is $239. What if our price had been 1 cent higher? Would any of those buyers have made a different decision over a mere penny per license? I rather doubt it. We have almost certainly given up $600 in revenue by setting our price too low.
Obviously I don't lose too much sleep over this glaring mistake in our pricing. And yet, I can't help but wonder: Isn't it intriguing that I could increase the price even a little without affecting demand? How far does this horizontal segment of the curve extend? Exactly how high could I raise the price without affecting quantity? What if the price of SourceOffSite had been just $5 higher? That's only a two percent increase, but it would have made a difference of $300,000 in revenue.
I'm asking questions that cannot be answered. I nonetheless recommend you ask yourself the same questions about your own product pricing. It can't hurt you to at least think it over. If customers will pay n, why won't they pay n+1?
Know Where the Lines Are
Depending on your situation, there may be certain numbers to which your price will be compared. Think of these numbers like lines painted on the floor. If you cross the lines, there are consequences you must accept.
Add-ons
If your product is an add-on for another product, the price of the base product will be a barrier for your own price. The market will usually expect your product to be significantly less expensive than the base product.
For example, suppose you are selling plug-ins for Adobe Photoshop. It is only natural that customers will raise an eyebrow if your plug-in costs more than Photoshop itself. That doesn't mean you absolutely cannot cross this line, but you're going to need a darn good reason.
Policies
In corporate environments, your customer has spending limits. At each rung of the corporate ladder, the organization has policies that specify how much that person is allowed to spend without getting higher approval. It's worth trying to make sure that your price point is within the amount that your customer is allowed to spend.
Exactly who is making the purchasing decision for your product? Find out how much she is allowed to spend, and price your product slightly less.
Price Is Not Just a Number
Up to this point, we have been assuming that price is simply one constant number. It doesn't have to be.
Perfect pricing
In an ideal world, the price would be different for every customer. The "perfect" pricing scheme would charge every customer a different amount, extracting from each one the maximum amount they are willing to pay.
- The IT guy at Podunk Lutheran College has no money: Gratis.
- The IT guy at a medium-sized real estate agency has some money: $500.
- The IT guy at a Fortune 100 company has tons of money: $50,000.
Your pricing is more than just a number. A complete pricing policy contains lots of details that you have to consider.
- How will you handle volume discounts?
- From what companies will you accept a purchase order?
- What about academic pricing?
- How much will you charge for annual maintenance and support?
- What is your policy on refunds?
- How much will you charge for shipping?
You can never make your pricing "perfect," but you can do much better than simply setting one constant price for all situations. By carefully tuning all these details, you can find ways to charge more money from the people who are willing to pay more.
Tiers
The most common way to approach perfect pricing is to have a product with multiple tiers. Each tier has a feature set and price point that is carefully chosen. For example:
- The lowest tier might be your "Standard Edition," supporting a very basic feature set at a very low price.
- The middle tier might be your "Professional Edition," designed for the largest segment of your market.
- The top tier might be your "Enterprise Edition," including every feature and priced much higher.
Examples of this strategy are obvious, but Microsoft Visual Studio is the first one that comes to my mind.
Three tiers is a good number to have:
- Your middle tier is your main product. Most people buy this one.
- The lower tier gets your product into the hands of those who could not otherwise afford it.
- The top tier allows you to charge top dollar to the folks who are willing to pay for the comfort of knowing they didn't miss out on a feature.
The wise use of multiple tiers can offer a very rough way of approximating "perfect pricing."
Beware of complexity
Your desire to approximate perfect pricing should be held in the proper tension with a value for simplicity.
The ultimate example of the quest for perfect pricing is the system of fares in commercial air travel. The airlines are willing to sacrifice simplicity in a never-ending quest to ensure that each passenger pays the maximum amount they are willing to pay. For example, last-minute travelers pay more, on the assumption that they are business travelers and are therefore willing to be gouged.
The airlines have built enormous computer systems that are constantly running simulations and models to determine the ideal prices for every flight. Based on the result of all these computer simulations, the airline industry makes thousands of fare changes each and every day.
The result is a system that no consumer can possibly understand. All this complexity has opened the door for a number of small airlines to carve out a nice market niche by presenting a pricing system that isn't so scary.
Complaints About Price
After seven years of running a small ISV, I have come to the following conclusion: No matter how low we set the price, someone will complain.
- If I lowered the price, I would merely attract the attention of someone for whom it is not low enough.
- If I gave the product away, someone would complain that I am making them buy more disk space to install it.
- If I paid each user a hundred bucks to use my product and sent Salma Hayek in a bikini to personally install it for them, someone would complain that they prefer blondes.
That's life. Most of SourceGear's customers are really nice people, but it is inevitable that someone will have the perspective that your price is too high.
In fact, if nobody is complaining about your price, then it is probably too low. The trick is to tune your pricing until the volume of the whining is just right.
When we first introduced SourceOffSite, the price was $119. At that level, a number of enterprise customers told us they couldn't believe we were charging such a low price. Virtually nobody was complaining that it was too high. So we raised the price until the level of complaining seemed about right.
Loss Leaders
The basic idea of a "loss leader" is to price a product very low in an effort to gain the attention of a large number of people to whom you plan to sell something else. Many traditional businesses do this all the time. Your grocery store sells milk at a loss, placing it in the very back of the store so you have to walk by a bunch of higher-profit items in order to buy it.
The loss leader concept is very tempting for software because we don't have any cost of goods. Unlike milk, we can take our price all the way to zero if we want.
Some ISVs use no-cost products or open source strategies quite effectively. For example, SleepyCat is a very successful small ISV that developed its own software. At SleepyCat, they use an open source strategy. Their product is wildly popular.
However, it's easy to forget just how expensive it is to build software. The ideal loss leader is something that is quite cheap. Although the cost of goods on software can be zero, software development is really expensive. If you are building a piece of software for the specific purpose of giving it away, you are accumulating a lot of costs that need to be repaid in some other way.
What I'm saying here is that SleepyCat is unusual. Most open source companies are companies that did not have to pay the cost of development. Red Hat did not write Linux. Covalent did not write Apache.
Even worse, loss leaders in software don't capture users as effectively as you might think. If you actually want to give away milk at no charge, you can probably capture most of the market. Software isn't like that. OpenOffice.org and Linux involve no license fees, but lots of people still use Microsoft Office and Windows.
Giving away software is not as straightforward as it looks. Tread carefully.
Temporary Pricing
Resist the temptation to run short-term special sales.
Here again, we see this tactic frequently in traditional retail. The grocery store is selling milk for $1.79 a gallon, but only through Sunday. The car dealer promises us a bigger rebate if we buy before the end of the month. The furniture store is running a different sale every week of the year.
In the short term, temporary pricing usually works. It will temporarily increase your sales. This can be handy for situations where you need a relatively quick inflow of cash.
However, these special sales often have a negative effect in the long term. People who miss the sale may wait for the next one. Customers gradually become trained never to buy at regular prices.
Know the Law
Here in the United States (and probably elsewhere as well) the law has a few things to say about pricing. If you are Microsoft or Wal-Mart, these laws affect every decision you make and every conversation you have. Small ISVs are a lot less likely to be affected by these laws, but it can't hurt you to know something about them.
Once again, all I can do on this topic is mention it and suggest that you consult other sources. I am not an attorney, so I am not allowed to say anything that could be construed as legal advice. Google on the words price fixing. Ask your attorney for more information.
Summary
Well, here we are at the end of the column. You've read the whole thing, and just like I threatened at the beginning, you don't have any simple answers.
I've given you a whole bunch of guidelines and issues to consider as you face your pricing decision. I've said some things here which conflict with other things I've said here. Which issues are you supposed to consider?
You should consider all of these issues, and probably a few more that are specific to your situation. Look at the decision from every possible angle. Anything you read on the subject of pricing is merely an aid to your own judgment, not a substitute for it.
Eric Sink is the non-legendary founder of SourceGear, a developer tools ISV located in Illinois. Eric recently visited a 12-Step program for people who can't stop using alliteration in the title of their columns. They kicked him out for refusing to admit that he has a problem. Eric's weblog is at https://ericsink.com/.
This article originally appeared on the MSDN website.