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

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio