When Licensing Metrics Must Change

5 11 2009

Everyone knows that technology changes quickly.  So it’s surprising (at least to me) that licensing metrics for software are so difficult to change.  Purchasing contracts, license agreements, and license enforcement tend to lag technical milestones.  Sometimes this is a good thing – for instance, everyone waited out the predicted move to 64-bit servers during the development of the Itanium processor.  At other times, licensing metrics are not compatible with IT practices that develop due to technology – you license per-Ethernet port and they buy per-device.

Consumer packaged goods don’t usually have to keep pace with technical changes.  Cars are licensed per unit, not per cylinder, seat, or window.  In many ways software is licensed “per cylinder” which makes it susceptible to fundamental changes.  Think of the impact hybrid technology or turbo chargers would have on a per-cylinder vehicle licensing model during the current green movement.

What to disrupt when you’re disrupted

We’ve pointed out that people and organizations are change averse.  Potentially the only group more averse to the risk associated with change are the lawyers and contracts personnel that have to refine sales agreements into actual recognizable revenue.  Any change to a license metric raises the risk of damaging revenue streams, renegotiating existing contracts with customers, liability exposure, and unintended consequences.

If you’re a public company, your investors and board may vote to prevent metric changes – meaningful or not.  If you’re a private company, you might have the main stakeholders in your office more frequently than is comfortable for you and anyone else within earshot.

So when a fundamental market or technology shift occurs, whether you anticipated it or not, a progression of events occurs.  Each event may have a different sense of urgency associated with it.  I’ve loosely structured these events as follows (they are not a linear progression):

  1. Detection
  2. Assessment and internal product impact
  3. First response (i.e. “we’re investigating it”)
  4. Longevity determination
  5. Business impacts (new business, existing customers, internal training, CRM, development)
  6. Choosing what to disrupt
  7. Use case development and forecasting
  8. Testing with real customers and sales people
  9. Rollout planning
  10. Announcement and implementation

It’s not really a 10 step program.  It could be more or less.  It’s also an iterative and parallel process (unless you’re a Cylon and can forecast everything appropriately on your first assessment).

At the heart of this process is picking what you need to disrupt in your product and licensing program in order to respond appropriately.  Product managers will very likely have a mental list of possible disruptive changes that could be applied in any given situation.  This comes from intimate familiarity with existing licensing metrics and their involvement in the sales cycle.  Customers usually enthusiastically share licensing shortcomings with sales people and product managers.  I’ve never heard a customer say “Gosh, that licensing program you have exactly fits our situation!”

If you have a few product managers, it is important to develop an internal understanding of any disruptive change across all your products.  That means each product manager shares their disruptive ideas and they assess the impact of the relevant scenarios on their products.

There isn’t a need for consensus in this exercise – there is a need for communication, sharing the details, and estimating the impacts. 

Remember: there is no magic licensing metric that will serve all products and all customers equally.  It’s not a democracy – someone must decide what to disrupt and how to do it.

Finer points of metric disruptions

If the product managers, business development, and sales force are engaged, early detection of disruptive forces in technology, the market, or in customer buying patterns should be possible.  The real trick is understanding whether the disruptive change actually applies to your business and whether or not a response is needed.

Examples:

  • Multi-core CPU’s and virtualization – if you license per-CPU or per-machine, you had better have a response before customers start rolling out new hardware.
  • New competitors – if some other company has dipped into your market (accidentally or otherwise), understanding how they are engaging your customers may lead to a disruptive change.
  • Buzzword compliance – long ago it was “open systems”, “year 2000” (Y2k); recently it was “application service providers” (ASPs), “web services”, and “service oriented architecture” (SOA); today it’s “software as a service” (SaaS), “the cloud”, and the “real-time enterprise.”
  • Deployment of something new that removes barriers – wireless sensors, broadband availability, or digital content distribution infrastructure.

Is this potential disruption relevant to your business?  Is this disruption transient, or is it the real thing?  Is this disruption relevant to your customer base?  Can you use this disruption to corner the market?

While change is hard, sometimes your company and products are well situated to take advantage of the opportunity.

Don’t get caught flatfooted.  Develop a response to a disruptive force and share it appropriately.  Your response doesn’t have to be an actual change to products or licensing metrics.

No matter what, if that disruption is big enough to catch the attention of the IT or industry rags, your customers will eventually ask you about it.  Whether they’ll do anything about it is always unclear.  Sometimes these are “buyer persona” items and will never play a real role in your software or their business.  However, if you can’t check that box, you may not make that deal.

If it’s real, introduce it

The phases of this plan must be treated like a New Product Introduction – even if it requires no new features or software releases.  Major items include:

  • Impact on your product – does it need to change?  What are the long-term implications to your current product’s trajectory?
  • Development – what needs to change, and when can it happen?  This is a disruption, so it’s not part of your roadmap.  Even if it’s a terminology change, there may have to be an out-of-cycle release (urgency-dependent of course).
  • Price list – how do you adapt your pricing?  Is it a new pricing column, or does it impact current licensing too?
  • Revenue – if you’ve changed or augmented your price list, you need to forecast the business impact.  Validate in steps: internally in spreadsheets amongst your team against test cases you’ve developed, then involve a few sales people for pipeline impacts and real use cases, then business stakeholders, and finally, if you have a customer advisory council, attempt to validate the changes with them (accuracy may vary).
  • Contracts – will this change create new contracts?  Will customers decide to migrate to this new scheme?  Will it be compulsory?  Are there revenue recognition changes?  What risks are forecasted?
  • Marketing – do you need to announce this change?  What collateral, web site, or other updates are needed?
  • CRM and manufacturing – implement the new changes, create part numbers, and create the required bill of materials (BOM) for both order processing and delivery.
  • Training – whether it’s messaging, talking points, product manuals, or simply familiarizing the sales and business development teams with the new arrow in their quiver, you will get asked a lot of questions.  Hopefully you have prepared for that through your test scenarios and early involvement of some sales people in your revenue impact assessments.
  • Preparation for changes – the law of unintended consequences rules the day.  You may have to retrench quickly after initial roll-out, so have a Plan B ready.

In case of emergency

There are many disaster scenarios that may be unavoidable. 

What if you have no data about revenue impacts?  This can be because of ad-hoc product bundling and order entry that doesn’t itemize revenue on a per-product basis.  Or perhaps it’s an entirely new product where no comparables exist and actual demand is unknown.  This exercise may also uncover significant issues such as weird sales discount practices, problems in your CRM and BOM implementation, and of course outlier pre-existing contracts.

What if you give away the farm accidentally?  Sometimes a licensing or pricing change may be good for new customer acquisition, but may unintentionally damage your ongoing software maintenance program (e.g. price list changes suddenly “give away” another existing product, or clever customers exploit a loophole you couldn’t close). 

It’s important to frame your roll out correctly.  Give yourself and escape hatch in case your pricing must self-destruct.  Some equivocation is acceptable – maybe it’s a limited time discount program, or a pilot program for a single industry or set of customers, or perhaps it’s a “product adoption” promotion.

Sometimes a disruptive change is beneficial beyond your expectations.  An example I walk past every day in New York’s East Village is referred to as “Dollar Pizza”.  You stand in line, hand over a dollar, you get a slice of basic cheese pizza.  A little more than a year ago, this pricing scheme was introduced as a “Grand Opening Special”.  Thanks to the proximity of NYU, the line for Two Brothers’ pizza is out the door from 10AM ‘til the wee hours of the morning.  A constant flow of pizza ingredients go into the shop, and no pizza stays out of the oven longer than 10 minutes (I’ve done repeated non-scientific observation).

The question for hungry, perhaps inebriated students is now: are other pizza slices 200 to 450% better than Two Brothers’? 

Is there a “dollar pizza” strategy you’ve overlooked?

Advertisements

Actions

Information

One response

6 11 2009
Laurent

Thanks for sharing your views and reflexion on pricing.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s




%d bloggers like this: