Pricing metrics and the customers that suboptimize them

6 08 2009

There are many truths in life.  If it didn’t sound so geeky and pessimistic, I would add to the list “customers will always suboptimize your product based on your metrics.”  It’s not very catchy.

I previously wrote about points to consider when choosing your metrics.  It was by no means exhaustive, but it did have a “salesy focus”.  That’s because your sales people play a vital role in your pricing and licensing scheme both before it is rolled out and when their boots hit the ground (and I saved one harsh reality for the end of this post).

Additionally, I brought up a few “rules” (or at least observations I’ve discovered) about choosing your metrics.  I could have added suboptimization to the list, but I’ve found there are some finer points to consider about this psychological pattern when it comes to your software’s sales, adoption, deployment, and expansion.

Suboptimization emerges iteratively

Throughout the course of the sales engagement, your customer’s understanding of your licensing metrics will mature to a point that they may understand the permutations of your price list better than your own people.  That’s because scrutiny multiplies once real money is in the game.

Because you probably aren’t buying your own software, your understanding may be more abstract than the visceral feeling the customer has when surrendering cash for intangible, arbitrary software licenses.

The buyer is going to bat for your company and product when he or she tries to get funding.  They are putting their reputation and perhaps their career trajectory on the line.  Fears of going from “hero to zero” overnight race through their minds.  Factors like:

  • Who will use it?  Will they adopt it?
  • What will the tangible value be?  How can I prove it?
  • Do I trust this software company and product enough to risk my own reputation?

This is why bigger purchases involve committees so that the blame can be spread around in case of failure.  But as the deal structure solidifies, so does their understanding of your metrics. 

The final deal structure is their leap of faith.

Suboptimization may dictate your software’s deployment architecture

As your buyers identify the local or global minimum amount of your software they will purchase, you may start to see bizarre and incorrect deployment plans emerging.  The customer will discover the loopholes in your pricing algorithm and attempt to exploit them to render the “best value for money”.

What the customer may lack is a feeling for how your product was intended to be used (i.e. “as developed” by your engineers).  Your metrics may prohibit its “intended use”.  Thus, they may not be able to justify purchasing a “correct” deployment up front.

This is the effect of your metrics on your product’s viability.  If your metrics drive bad architectural decisions, you are doing both your product and your customer a disservice.  Some common causes of this I have observed include:

  • Pricing breakpoints based on bundling – customers may buy a cheaper bundle that omits a critical piece of your product because of price.
  • Pricing rules based on architecture – example: running 5 instances of the license on a single CPU is OK, but running 1 copy on 5 CPU’s costs 5x as much.  This usually leads to performance problems.
  • Metrics based on topology – to avoid multiple licensing costs, users may choose to have one large server in a central location serving thousands of users, but their infrastructure is incapable of adequate performance.  This could also be a sales practice – how complex is it to work with the customer’s internal purchasing bureaucracy?
  • Throughput or transaction based metrics – users will treat your software like a long distance telephone plan and minimize the use of your product for fear of overage charges.  They will build custom software around your product to avoid charges.
  • Multiple licenses for a single user – requiring a “client access” license, a CPU license, and a client license is confusing and minimizes deployments.
  • Metrics IT doesn’t understand – if IT is going to manage your product, you had better work with metrics they understand (desktops, CPU’s, etc.).

I know there are more (hint: leave comments!).  These are the ones I’ve directly experienced.  It’s up to you to understand how your metrics work in the real world and find the trade-off between value to the customer and your revenue.

You may not be able to recover from your licensing’s first impression.

Suboptimization will stifle viral growth

If your metrics end up restricting your product’s exposure to a small enclave of rabid, yet invisible users (in the corporate sense), you have failed.

In order for people to deploy, endorse, and adopt your product, you need (positive) exposure.  This is a multi-level problem that’s dependent upon:

  • Your champion’s trust in your product and company
  • Your champion’s status and reputation in their own company
  • The influence of your metrics on your champion’s recommendation

Invisible products provide niche value.  Your product may be the best “wireless transmission frequency and throughput lubricant” in the universe.  But if your pricing metric restricts it to the custodial staff’s two-way radios, that’s where it will stay.

Suboptimization may prevent future upgrades

The corollary is that expansion of your product can’t be justified by a niche value proposition resulting from buyer suboptimization.  Knowing your company’s long term perspective can help you choose initial deployment and expansion-friendly metrics. 

Consider these questions:

  • What’s more important: up front license fees, or a long term annuity?
  • Where is your entry point in the customer organization, and what magnitude of value can your product realistically deliver to the customer (e.g. saving $20,000/yr garners different attention than saving $1,000,000/yr)?
  • Do my metrics make it easy or compelling to expand my product’s deployment?  This also pertains to the changing face of the buyer persona as your product becomes more visible through the customer’s organization.  Metrics that engineers understand may not make sense to the CTO.
  • Are my metrics compatible with other software or hardware (including other products made by your company) that may govern my product’s expansion?
  • Is my product a leader that can make its own metrics, or a follower that shouldn’t buck a familiar trend?

Your mileage may vary of course.

There’s no easy answer to any of this, but it never hurts to run through thought experiments as you lay awake at night wondering how to finalize that pricing strategy.

Finally, remember that your sales people play a critical role in how the customer consumes your pricing.  Some sales people will suboptimize your product for the customer.  Some are great at selling the potential value and getting the customer well-situated for future growth.  It’s the difference between nickel and diming your customer to death and “Prego pricing” (“It’s in there!”). 

You’ll know who does what, but you can’t create metrics that will change their behavior.

That’s when you need to relax and let reality take its course.  There is no perfect metric, but you can consider what hasn’t worked to pick the best structure for the time being.



4 responses

6 08 2009

Great stuff as always – Seems like you should be charging for this kind of advice. What’s your business model here?

6 08 2009

Of course, I would love people to offer me some revenue or sponsorship in exchange for this type of work and knowledge.

There’s a great line in the stage adaptation of Dostoevsky’s “Crime and Punishment” where the young intellectual laments “nobody pays for knowledge.”

I am hoping that the application of this knowledge is valuable to someone. Like graphic design and marketing content generation, most people believe that they can do this sort of thing in their spare time internally.

What I noticed while doing product management, pricing, graphic design, and marketing content generation internally was that there were no resources that would engage me in a material way to help me move forward. No one internally could check the work or offer a counterpoint.

I feel that by creating this body of work, perhaps I can build up a real, dedicated following that either wishes to engage me for some short term help, or wishes to sponsor the creation of these types of posts. I would like to offer a public way to anonymously work through real world examples in stages so it is instructive to everyone.

Pricing is a very hard topic and there are few right answers. But the hardest part is being alone while doing it internally.

7 08 2009
Chris Hopf

Really appreciate your posts Gregg . . . well done. Look forward to your further insight and perspective. Take care.

19 08 2009
Tony Chen

Gregg, this is great stuff – many of the ideas you expressed are exactly what we’ve been pondering recently as well. keep it up!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: