Pricing is a fact of life. One of the things I have encountered more than once is how to price new products.
More often than not, it freezes people. I have narrowed the reasons why down to:
- Afraid to leave money on the table
- Afraid to de-value the product
- Afraid to set a negative precedent with other clients
- Not knowing what to do
The way most folks deal with this is to hum and haw over the “perfect price” and usually end up getting it way wrong. Complexity after complexity gets layered on to entice the client to sign on – when in reality, when pricing something to market for the first time, you should be less concerned about tiered discounts and price breaks.
You have to tell the prospect something. And surprise, there is a very easy way to do this:
New price = cost * x-factor
I generally start at 10x and drop the x-factor down from there until I arrive at something that feels right.
You need to understand and estimate the cost to provision of the product, and then multiply that to what you feel is reasonable (plus a little bit more). There is a pricing strategy called “skimming,” which is what you have to do to find the right spot to be in.
But, usually (not all the time based on the scenario) you want your sale to make the company a profit. So, when multiply by the x-factor, make sure it leaves your Sales team enough padding to discount if they feel it’s needed to close, but won’t cut your margins down to be razor thin and you end-up pinching pennies internally to get the product to the client.
You may find that the response to the new price is negative. Folks in your pipeline may tell you it’s way too high; and that’s OK – remember, you want to skim initially. It’s way easier to drop a price than to raise one. To put it another way, you don’t want to go to market with a horrible pricing strategy and realize you have had 10,000 people buy your widget but your cash flow positions are still awful.
That would be bad.
Maybe you have a pipeline of 500 prospects – 10% of them buy at your skim / first pricing attempt. 30% (provided of course they are in your target market you have identified an opportunity in) tell you they would buy, but the price is far too high. So, start pricing down until you hit the sweet spot. If you run in to a situation where you have to price down so far you end-up losing cash on a transaction, you can either:
- Acknowledge you have a loss leader and re-assess accordingly
- Re-assess your cost structure and re-price
But don’t get overwhelmed. It really is this simple: price = cost * x-factor. Start with that and then you can get into heroic-like / super complex pricing schemes and variables later. If you can’t find a price this simple way, you certainly won’t be able to find a price in a more complex way.
{ 18 comments… read them below or add one }
Good practical advice, but I have serious concerns with cost-plus pricing. Pricing should be grounded on value delivered first, then constrained by economics like price elasticity and competitive pricing forces. Cost should only be considered when deciding whether the project is worthwhile for the company to spend resources to develop, produce, and sell the project. Cost-plus pricing is a terrible way to start out. On the other hand, if you don't think you have any cost advantages then it will give you an idea about the attractiveness to competition if you price very high (profitability can drive competitive response). I think that people often resort to cost-plus pricing because they either can't model the value delivered, or they consider opportunity costs and ask the question – at what price would this be attractive to me to allocate my resources to this? This is more of any internal-focused apporach than a market-focused question and it leads to irrational pricing behavior.
I do, however like the idea of pricing very high for a new product and making allowances for discounting and price adjustments later on. A skimming strategy not only ensures that you can “play the game” but it also signals high value for the product and anchors the perception as a premium product. Ultimately the price that you can charge is according to what the market will bear and so pricing very high and working your way down can be a good way to find the best market price through gaming. You have to be prepared to actively manage pricing and deliver a clear pricing strategy to the sales organization. Otherwise you will lose opportunities because you are pricing yourself out of the game.
Your rule of 10x your cost is probably the maximum that you could go without offending potential customers. If they are able to estimate your cost, then if you go higher than this they will probably do a make vs. buy analysis and just tell you to go away because they'll build it on their own.
So, again good practical advice.
Thanks for the great feedback, Mike. You are right on of course -
there is much more to consider when formulating price, as you point
out.
That's all great stuff.
My whole thing is just trying to help get over that initial hump. When
you are experimenting in the market to see if there is an actual
opportunity you sometimes don't have the luxury of going out and
really identifying value being delivered.
To me, that's something that comes over time. Chances are, you are
going to want to iterate on price while you iterate on the very first
versions of the product, work with the very first clients, and
actually identify what's out there. The opportunity you think was
there initially may not exist, so why not keep everything as simple as
possible?
Just my line of thinking. But again, you are correct. All PMs should
consider the exact things you mention – my experience just tells me
those come a bit later than the first, second, or third clients
acquired.
I agree with your message here. The challenge in pricing, which I think is part of your x-factor, is understanding the potential market (i.e. how many click/licenses/seats/etc. you can sell). So I would see something like this… price = (cost + margin) / x-factor where x-factor is really your potential market. Of course, delivery models (perpetual vs. monthly vs. etc.) will affect how you slice the price from there. I completely agree with your start high and reduce until the right spot is found. Very Agile. Get it in the market, test, review, update, repeat.
Pricing can be a fun day buried in Excel. Yes, fun day.
Stewart
I like where Mike is going with this… using cost to justify the development and using value to justify the price. However, have you not already determined the price to justify the cost of the development (ROI).
I get what you are saying Mike. Pricing is complex and is ultimately a function of what the market will pay. But, I'm noticing a recurring theme in product thought these days. The idea of “just get it out there” is gaining voice.
As product managers and experts, our general mentality is to build the best product we can and deliver a well thought out, well implemented experience to the marketplace. The problem is that product lifecycles (particularly in tech) are shortening so rapidly that if we jump through all the hoops to develop the perfect strategy before launch, then we are increasingly faced with risk of missing the opportunity altogether.
Good market research is expensive. Pricing conjoints can take months to develop, execute and analyze. Going with your “gut” and delivering earlier stage products with experimental pricing may often be a more successful strategy, allowing for relatively cheap market research by measuring what customers actually do versus what they say they'll do.
Clearly there is no one-size fits all solution to pricing strategy. The best approach surely lies somewhere between cost plus (or cost times) and a more value-driven approach. But one thing about the value driven approach is that it always starts with assumptions.
If the product manager is in tune with his customer, then testing those assumptions on real customers would bring greater value than testing against a model.
Exactly!
Here is a scenario. Imagine sitting in a meeting with senior management (either with or without your VCs). You are running a $200k per month burn to keep the business going and are under pressure to build some revenue with your product and you have some prospects in your pipeline that want your product.
The question ultimately comes to you: what's the price?
Whenever I get that question, my immediate response back is, “well, what's the cost?” Typically, start-ups will throw out irrational figures because they sound good / high / heroic.
Question: “What's the price?”
Answer: “$20k”
Instead of:
Question: “What's the price?”
Response: “What's the cost?”
Response: “$25k”
Answer: “25 * 3x = $75k”
Start with that because it guarantees you profit. If you don't start out with profit in mind (even when running a loss leader – then you need a model to get you to profit), you are sunk right away. All of the other things are important, yes — but in the scenario I first described you don't want to be the guy in the room saying, “well folks – I know we have deals we could make, and we are burning $200k per month – but I really think we should take an extra couple of weeks to do x, y, and z.”
Trust me on this one – you will be asked to leave the room and then the rest of the folks will say, “cost * x-factor and then discount down to get the deal.”
Thanks for the article – I like the simple and pragmatic way of approaching pricing. I'm an associate PM and have never had to formulate pricing before so some of this was over my head, but the rest was definitely useful. Question for you though – how do you determine cost for a product (especially an SaaS product)?
Calculating cost is pretty straightforward – but you need to keep a constant eye on details. For a SaaS service, you may want to look at cost of running the servers as # 1 (bandwidth, hardware costs, electricity, etc…).
Man power is next – what's the level of effort required to actually get the instance up and running and keep it running? How much support will be needed? 1 hour per month? 10 hours? etc….
Really, you have to make a list of all of the things that go into brining the SaaS product to life for that client. I've also seen dev costs factored in as well. For example, you spend 1,000 hours of dev time per month on the product and all of your clients will be using that functionality / bug fixes / etc – you may want to identify some average cost associated with that and bake it in to the recurring charge.
Doing people / effort estimates for cost is hard and can get complicated. In the past, I've estimated FTEs (full time equivalents) out at 100,000 per year per person. This roughly breaks out to $50 per hour of an internal charge to the company for them to be working on things.
So, for dev time (for example) – say you spend 1,000 hours total per month on product development. That comes out to $50k per month internal cost to produce those results.
But – you have to really keep an eye on those details.
I'm really enjoying the discussion on this topic, and it has created some sparks in my mind about some pricing problems that I have faced recently – most are totally unrelated to value vs. cost-plus pricnig but it made me think about them anyway.
I think that Adam's post offers really good, partical advice. I just hate to start out with cost-plus before anything else. Even if you start out with value-based pricing on just a gut-feel qualitative level, it helps you to focus on the value that you're delivering and to get away from the internal focus that we always have on features and costs. You need this value message to sell anyway. If you sell based on features instead of the problem that your product is trying to solve then this can help set your price at cost-plus too.
Sometimes you just have to make a decision and execute now. Cost-plus works here, for sure. Especially if you don't have any information on the value delivered or the time to get it. This is far from ideal, but sometimes acceptable and often the most practical approach.
Cheers.
Thanks! Does this mean you'd then divide your cost estimates by your anticipated market penetration (# of customers) and multiply byu the x factor to arrive at your price?
Mike's comment is spot on. Value and impact on the customer's way of life first. Comparison to competitive solutions, and cost factors later. Cost plus pricing leaves doesn't account for volume.. so if you sell fewer, you spread a total cost over fewer 'units.' If you sell more, then your margins are great because your cost per unit is lower. This can be a never-ending debate, especially if cost-plus advocates have proof of great gross margins.
OK, let me put this stake in the ground. I totally agree with Steven and
Mike. Completely, whole-heartedly, 100%. Value-based pricing is the way to
go.
Except in the case when you are testing market opportunity. My whole thing
is, if you are putting a price out there as a way to dip your toe in the
water, why not use something quick and dirty to get a feel for it while you
are working on figuring out the value side of the equation?
I'm not advocating the use of cost-plus pricing for tangible goods / units.
That can get hairy, especially when there is the entire value-chain
involved. I'm mainly referring to my experience in software and services. If
I can get gross margins of 20%+ on a few initial deals while I'm proving
market opp, identifying requirements, etc… that's pretty good.
Of course, the cost-plus pricing model would be augmented as more value is
uncovered / competition analyzed / etc…
That's an interesting approach – I'd give it a shot and see how it plays out. But if you think about 10x being the absolute max in cost-plus pricing, work your way down from there:
Price = (derived cost) * 10x
So if you determine your cost to be $1,000 your price would be $10,000. That's a little high, so I would start dropping from there until you arrive at something more inline with the value (see guys – I'm not adverse to it!
For example, some technology that costs you $1,000 to produce probably isn't worth $10,000 to the client in all fairness. And I would bet competitors are selling it for much less.
So maybe try 5x cost, 3x cost, etc… until you arrive at something you feel comfortable with. Keep in mind you want to go out a little high so you have room to execute a skim strategy, as well as your Sales manager has some room to discount.
Remember, in this scenario you are talking about getting your feet wet and vetting a new market opportunity – not making long-term strategic pricing decisions.
Adam, I agree that, realistically, getting a price out there and testing it in the market is the way to go. It's very often an iterative process. And I think it's safe to say that the price needs to be one that has positive margin.
But I think it's overstating the case to contend that you don't have “the luxury of going out and really identifying value being delivered.” The bread and butter of product management is to understand problems in the market and their urgency to customers. You can perform some of this bread and butter activity before you develop the product.
If you understand problems in the market and their urgency, you will get some idea of what these problems currently “cost” the customer without your product. Your product is worth no more than this cost, and should be priced accordingly. I have written about this method of pricing before; I call it negative pricing.
If value-based pricing doesn't cover your costs, then you shouldn't develop the product. I just wrote a blog entry that reconciles value-based and cost-based pricing by essentially pointing out that the two approaches have to converge for a viable product.
Of course I agree. I may have overstated a slight bit to make the point.
You should always have a sense of the value you are delivering – whether it's written down or not on a piece of paper. And I do – even when I've taken the cost-plus approach.
I'm using that “x-factor” as I call it in the post to determine the plus portion of cost-plus. It's not some arbitrary number to give us profit (if it was, then I would always use something to gaurantee we make money, like 4x or 5x, and that would be silly) – it's based on what I feel we are delivering to the client themselves and what they are getting out of it.
If your products are software (and even hardware usually has software buried deep inside), then the concept of “cost” isn't very useful. Your engineering team spends $2M to create a software product, but it costs “nothing” to sell incremental copies. Cost-plus burns to the ground. Software demands value-based pricing. See my many ramblings about this (http://www.enthiosys.com/insights-tools/disrupt... e.g.) but I try this overall three-step approach:
- what is this software/solution worth to our target customers? Can they save $100k/year on reduced shipping costs, or sell 10% more widgets with our improved prospecting tool? HOW and WHY do they save or make money?
- what is their natural unit for work, which should be our natural unit of pricing? In other words, we can price our software by the seat, or by the download, or by the M&A transaction, or per hired applicant in a resume screening process. We want to choose units that make sense to our target audience.
- then (and only then), what's the price? Imagine that we can capture 5-10% of the customer's value. What packaging options let us have small/med/large versions? http://www.enthiosys.com/insights-tools/goldilo...
- finally, can we make money at this? Applying some market sizing and sales forecasts, let's make sure we can cover our costs and give ourselves healthy annual bonuses. Or move on to the next bright idea.
Unlike digging up iron ore and smelting it, there's no natural price point for software. You signal value by your pricing, so it should be value-based not cost-based.
Joel has a very good post on establishing pricing at http://www.joelonsoftware.com/articles/Camelsan...
Joel has a very good post on establishing pricing at http://www.joelonsoftware.com/articles/Camelsan...
{ 1 trackback }