Pricing and the metrics that matter

31 07 2009

Previously, we engaged the topic of the metrics you might choose as the basis of your pricing and how the evolution of technology will disrupt your well-laid plans.  This is especially true in software and hardware, but can also be found in other areas such as telecommunication or Internet services.

Businesses tend to manage new technology or legislation very closely.  Executive positions and departments rise up around a new technology and then get re-focused as that technology is commoditized.  Think about what “IT” means today vs. 20 years ago.  It might have been called IS, MIS, or “Information Systems” back then.  The role of IT used to pertain to mainframes, networking etc. but has grown to encompass cell phones, voice over IP services, laptop support, managed software deployments, cybersecurity etc.

The government can create new positions involuntarily within a business as well.  There are now “Chief Compliance Officers” (i.e. “guy in charge of going to jail”).  But, as these roles become more habitual and the variability or costs become reduced, these roles in an organization can shift or dissolve.

Licensing metrics: Rules Patterns

This is a set of observations I’ve collected over the years in studying and theorizing about what metrics to use for software pricing and licensing.  The only thing that can help deal with technological or market evolution is have a plan around changing your licensing scheme.  When you have those discussions, keeping these things in mind may help.  Here we go:

  • There are no “natural metrics” in software

Unlike soft drinks, bread, and airline seats, quantizing software is an inherently arbitrary process.  Someone must draw boxes around functionality, modules, or introduce artificial limitations in order to create pricing breakpoints.  There is no real reason you’d restrict your application from running on all available CPU’s or limit its network throughput.

One could argue that a user is a “natural metric” but when you deal with families at home, the notion of a user on a shared computer goes out the window.

  • Your metrics are immutable

The previous post about metrics made this case already… technology will evolve in a way that has an unpredictable effect on your pricing and metrics.  The only defense is to plan for things to change and understand the work involved to transition customers to a new set of metrics.  Even if it’s just that the features change or you add a new package to an existing offering, someone will have to decide how to roll that out to users (especially if it’s a package they used to pay for).

When you have the conversation about dividing up your software, you will likely get embroiled in the quest for the perfect metric.  You can visualize it.  It’s out there, just beyond your grasp… if you could only write it down! 

Stop it.  Reality will always intervene.  Metrics are a compromise.

But, there will be one guy who looks at all the negotiations, whiteboard drawings, forecast spreadsheets, and furrowed brows and concludes “it has to be simpler than this!  What if we…”  This brings everyone a new hopeBut all this has happened before, and all this will happen again. 

This cycle could go on for years.  Literally.  Yes, you can get simpler, which leads to the next observation…

  • The choice of licensing metric is the balance between contract complexity and money left “on the table”

If pricing is the act of striking a balance between the perceived potential value to the customer and their pocketbook, metrics are the balance between your product’s market potential and resulting contract complexity. 

You can, indeed, use a simpler licensing metric.  The potential revenue sacrifice could be significant, but the objective may justify it.  If you are trying to sink the competition and you have a war chest handy, making a very simple licensing and pricing scheme can tip the scales in your favor.  You have to “make it up in volume” – and that’s actually not dependent on your product, but how well-suited your business is to accepting lower revenues, remaining profitable (factors include reputation, business efficiency, market dynamics, product quality, etc.) and of course, what happens to your competition.

If you want to extract every dollar from each negotiation, you need a highly variable, narrowcasted set of metrics that are tailored to each customer.  And an army of contract lawyers.  That’s very hard to upgrade later on.

  • The epic struggle will be between engineering and sales

Your engineers are proud of their baby.  They want everyone to enjoy and use it.  Customer adoption of their baby equates to validation of their talent – their ego boost.

Sales (and the business) see how much it costs to create that baby and how valuable it is to customers.  Sales will suggest ways to capture the low, middle, and high end of the market by asking for lots of “tuning parameters” to fit edge cases and extract the maximum amount of money for each deal.  Engineering will see this as a lot of (unnecessary) work that prevents them from doing the next fun thing, and a disservice to users because they can’t tap into the product’s full potential. 

Have fun with that.

  • You cannot recoup your engineering costs directly through software licenses

I hear this discussion a lot.  “It cost us 100 mythical man years to make this piece of software.”  It’s the same argument pharmaceutical companies make about drug development and patent extensions. 

Get over it.  Yes, R&D is expensive.  But software is basically free to distribute.  CD’s cost nothing, downloads cost nothing, copying it around a network to each PC costs some IT time.  Trying to recoup the costs of development in your licensing will sink you.  This truly is a long range argument where you have to look into your crystal ball to see how valuable your product is to your customers, how it plays in the market, and how your business must grow to support its adoption and future development. 

Customers don’t care how much it cost to make.  Customers care about the potential value your product brings them and the opportunity cost associated with it.


Of course there are many more of these observations.  I invite you to add your own in the comments.  I’d love to discuss the empirical discoveries you’ve made about pricing and licensing!



2 responses

31 07 2009

I’ve always thought the investment model of the oil industry was a useful metaphor for the software industry (or vice versa). It costs millions to drill a well on land, tens or hundreds of millions to drill offshore. Sometimes there is no payout or limited payout. Sometimes payout is dramatically higher than the investment.

The cost of operating the well is a small fraction of the revenue you receive from the oil produced. Hence the short term price can be highly variable and bears little relationship to the cost of drilling the well. Only when prices are very high or very low for a long time does the feedback loop finally increase or decrease the basic supply and work to bring prices back to the norm.

26 08 2009
Pricing topics round up « Spackle

[…] Review: Pricing, metrics and evolution to get some ideas of how things might change for you.  Once you have some perspective, you have to create Pricing and the metrics that matter. […]

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: