Over on the Accidental Product Manager blog, Dr. Jim Anderson writes that cost-based pricing of a product is a bad idea, and that value-based pricing is the way to go.
Cost-based pricing and value-based pricing are two different ways a product manager can decide on the price of a product.
A cost-based price is the cost of producing a unit of the product plus a certain margin. For one example of applying cost-based pricing, see Adam Bullied's blog entry on the pricing new products.
A value-based price reflects the value of the product to the customer. The way I suggest pricing a product based on value is to use negative pricing.
Dr. Anderson points out that price and volume have mutual feedback effects:
The goal that both approaches have in common is to maximize profit. Maximizing profit means finding the ideal balance of margin and volume.
.png)
With cost-based pricing, your product manager tries to find the right margin but can also take the impact on volume into account. The hazard is that all the variables are dependent, and maintaining positive margin may result in such small volume that the product isn't profitable.
With value-based pricing, your product manager uses knowledge of the competition and the urgency of the problems being solved to determine the price of the product. A product that addresses urgent problems that the competition doesn't address merits a high price. The hazard is that the value-based price of the product may not cover the costs.
It's fairly straightforward to conclude that there has to be some convergence of the two approaches. Whether it's you, your product manager, or another person in your company, someone has to project the costs and compare them to the value of the product to the customer. This analysis is part of determining whether the product is worth developing in the first place.
Either way, pricing is often an iterative process. Initial research into the market and your projected costs will almost certainly be incomplete or off target. By "testing" prices in the market, your product manager will gain further insight into what the product's true value is to the customer.
Cost-based pricing and value-based pricing are two different ways a product manager can decide on the price of a product.
A cost-based price is the cost of producing a unit of the product plus a certain margin. For one example of applying cost-based pricing, see Adam Bullied's blog entry on the pricing new products.
A value-based price reflects the value of the product to the customer. The way I suggest pricing a product based on value is to use negative pricing.
Dr. Anderson points out that price and volume have mutual feedback effects:
Since your unit cost is changing with volume, your price will determine how much you sell. This will then impact volume which then impacts unit cost.As a result:
So what’s wrong with cost plus pricing? Simple - cost plus pricing will cause you to over-price your product when there is a weak market and will cause you to under-price your product when there is a strong market.Let me try to reconcile some of the conflict between the two approaches.
The goal that both approaches have in common is to maximize profit. Maximizing profit means finding the ideal balance of margin and volume.
With cost-based pricing, your product manager tries to find the right margin but can also take the impact on volume into account. The hazard is that all the variables are dependent, and maintaining positive margin may result in such small volume that the product isn't profitable.With value-based pricing, your product manager uses knowledge of the competition and the urgency of the problems being solved to determine the price of the product. A product that addresses urgent problems that the competition doesn't address merits a high price. The hazard is that the value-based price of the product may not cover the costs.
It's fairly straightforward to conclude that there has to be some convergence of the two approaches. Whether it's you, your product manager, or another person in your company, someone has to project the costs and compare them to the value of the product to the customer. This analysis is part of determining whether the product is worth developing in the first place.
Either way, pricing is often an iterative process. Initial research into the market and your projected costs will almost certainly be incomplete or off target. By "testing" prices in the market, your product manager will gain further insight into what the product's true value is to the customer.
Comments
Well, only because the science is so simple - you usually want to price to make money. Unless you are specifically running a loss leader.
I think we both agree the "art" side to pricing really involves feeling things out, seeing where they go, assessing each deal in and of itself, and watching where things go.
You always have to be paying attention to the market and your customers, otherwise you will lose - not just on pricing, but delivering an entire package. Of course, pricing is a critical part of that package.
But like anything else, it involves constant and ongoing attention - and the opinion on folks that are not just the product manager, but also Sales Managers, Marketers, and the Executive team.
You put something on the line that you *feel* is right and see where it goes. It's like releasing a big new feature that you are pretty confident users will want; but you don't know 100% until it's out there and they are using it.
You won't know if customers will pay the price you are asking for until your Sales team starts asking for the orders.
A more interesting question (for software) is what the unit of pricing should be. You should tie this to how your target customers get value from your product, so you might price "per download" or "per seat per month" or "per GB of indexed mail" or "per resume that matches your narrow hiring criteria."
See a couple of my old columns on this: http://www.enthiosys.com/insights-tools/goldilocks-pricing/ and http://www.enthiosys.com/insights-tools/disruptive-pricing-units/
You're right that the pricing unit is another interesting topic. Some of the same considerations apply to that topic. Cost still matters, but so does customer value.
Tying the unit of price to the unit of value to the customer is intuitive and works in many cases but doesn't always yield a sufficiently understandable pricing structure.
What it means, examples, and why it's critical.
I feel a blog post coming on :-)
The cost of vodka is what? 5 cents? It's potato moonshine. Yet people spend how much for it?
If people value the product less than it costs to build, then you have a business problem, not a pricing problem. Remember, units 2 thru n of software are free to manufacture.
I'm reading this in the context of a pricing exercise I'm leading now. Good summary of value vs. cost basis. Our team is definitely in the "art" stage with this current product, though we have a good direction lined with cost and competitor pricing data to work with.
I'm interested in your thoughts about pricing for SaaS products, where costs include additional server boxes, server software, bandwidth and storage costs that are part of providing that service (product). In my own experience, these don't add up to a make-or-break percentage, however it does mean that units 2 thru n are not "free."
Anything else to think about when it comes to service pricing?