Skip to main content

Value-Based versus Cost-Based Pricing

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:
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

Adam said…
Roger, I really like your notes and approach. Pricing is definitely more on the "art" side as opposed to the "science" side.

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.
Unknown said…
Since many products are built on software, there's no natural per-unit product cost. Software is mostly fixed cost to make and variable revenue to sell. So value-based models are IMHO the only ones that make sense for software solutions.

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/
Roger L. Cauvin said…
Rich, software is definitely a different animal than physical products with physical manufacturing and shipping costs. However, you still can't ignore costs when evaluating whether the product is worth developing in the first place. There still has to be a reconciliation of cost and value.

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.
Adam said…
I think first to understand how to tie pricing to value, one must understand value itself.

What it means, examples, and why it's critical.

I feel a blog post coming on :-)
Unknown said…
Adam - here are some thoughts from LinkedIn: Answers to get you started. http://is.gd/gtNF
Unknown said…
Value is all. Nobody cares what your product costs you to build; they only care about the value to them.

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.
John Peltier said…
Roger,

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?
Roger L. Cauvin said…
John, the only thing I would add to your observations about the on-going costs of SaaS products is to apply negative pricing. What are the on-going costs to the customer of not using your service? What is the total cost of ownership for the customer of not using service?
Unknown said…
This comment has been removed by the author.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Use Case as a Black Box

Consider the following use case: Purchase Items Actor: Purchaser Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40. Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased. The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items. What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement . Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint: Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the