This post continues from part 1 where I observed that our macro obsession with efficiency does not automatically translate into the purchase of efficiency-boosting IT products.  Product managers may have good intentions, but there’s more to delivering overall efficiency than optimizing a singular IT process or function.  This concluding post will look at the costs our customers must balance against the benefits we claim.

How much does it cost?

“How much does it cost?” is largely under the product manager’s control.  Many vendors have historically tried to nickel-and-dime customers with excessive options and licenses.  My experience has been to simplify pricing with three or fewer options for a broad portfolio and just one or two options for a new product to remove licensing as a barrier to adoption.  The pricing decision gets easier when you’re not fixated on collecting every possible dollar from every customer.  When I introduced a new software product a few years ago, we optimized for sales velocity and priced one license for all product capabilities.  We subsequently added a lower cost option, but resisted the temptation to offer a la carte options.

Even when the product manager believes that cost transparency has been achieved, indirect acquisition costs come into play.  Other purchases may be required to deliver all of the required capability – rust-proofing anyone?  Some of these may be asset acquisition and some may be professional services or consulting.  The IT industry is littered with products requiring extensive consulting and customization to make them operational and deliver on the vendor’s promises.  I constantly hear customer feedback to make a product work properly out of the box.  Not long ago I called engineering and product managers together to set our priority around ease of deployment and overall usability rather than adding more features.  Product managers can drive their team’s thinking around the out-of-box experience (or, “I signed up for the service, now what?”) before assuming product usage begins once the product is fully configured.

How easily can I implement it?

This brings us to the third factor: ease of implementation.  It’s clear that consulting and customization services will add to implementation cost.  Are these one-time or ongoing costs?  Does the customer need to re-engage services whenever the vendor releases an update?  Customers may find it difficult to fully assess implementation complexity depending on the type of product in question.  Standard interfaces, wizards that step users through multi-step configurations, and sensible defaults are just a few ways to make easy things easy.  One of my product teams created a priority for automation software to include out-of-box wizards and workflows, enabling customers to be self-sufficient in product deployment.

Ease of Implementation goes beyond money.  The time required to deploy the product and get promised value can have a large impact on whether the product is viable.  IT organizations have busy times of the year and narrow change windows during which they deploy new products.  Subject matter experts are typically busy without slack time to indulge in extra projects.  The product is competing with other projects for each change window.  Higher priority projects to fix problems (aspirin anyone?) or roll out new business offerings can easily wear down motivation to “do the right thing” by increasing efficiency.

It’s no surprise that customers don’t immediately deploy new products that promise greater efficiencies.  Asking people to step through a detailed evaluation and navigate their myriad dependencies inevitably takes the shine off the desire to be more efficient.  I’ve watched customers in briefings get excited about a new way to improve data center efficiency, followed by the more sober assessment of the time and effort to follow through on the vision.

So who cares about efficiency?  Most IT professionals.

Should we continue building efficient products?  Yes!

There is a difference between caring about something and channeling that caring into action. If product managers believe that efficiency is important, we can build products that minimize barriers to adoption and effectively lead users through clear steps to be successful…and efficient.

Adherence to the concept of efficiency is almost a religious conviction in our society.  Who wants to be inefficient?  Perhaps worse, who wants to be perceived as inefficient?  Business pundits laud economic efficiency, as they call out countries and businesses that should serve as role models for us all.  Throughout my career building IT management software my colleagues explained how our products saved money.  But how much do IT professionals really care about efficiency and act on it in their daily operations?  Is efficiency merely an intangible aspiration more than a daily reality?

The engineer in me wants to believe in efficiency and that users will utilize novel technologies that improve their organizations’ efficiency.  Who wants to waste time or money, after all?  The product manager in me wants to believe that productivity arguments and proof points will compel customers to purchase and implement products that boost efficiency.  Yet, it’s sometimes unclear how much of a priority this is in the data center infrastructure industry, with one report that 30% of servers are not even used.

A venture capitalist once asked if my product amounted to an aspirin or a vitamin.  The implication was that people tend to buy things that resolve pain, but are less likely to pay for longer term health.  (We were talking data centers, not personal care products where – I hope – health gets more credit.)  It’s a fair question because everyone has limited time and budget.  We’re more likely to prioritize today’s pain over tomorrow’s promise of improvement.  We may agree that efficiency is a good thing, but to what extent will we put our money behind positive aspirations?  United States consumers spent $376B on electricity in 2013, while electric utility efficiency budgets were about $7B that same year – a small fraction of the overall electricity market.

I’ve seen this battle for mindshare and priorities throughout my product management career.  My experience in data center automation software was a classic example of “invest now to gain future efficiency.”  We had many customers, yet others chose not to make that leap and continued with costly, time-consuming operations.  The degree to which efficiency wins the day depends on three factors.  How much will I save?  How much does it cost?  How easily can I implement it?

Knowing how much the customer will save and how much the product costs may at first appear objective and quantifiable, but they’re usually anything but clear.  Modern data centers and the applications running within them are mind-blowingly complex.  Efficiency pitches typically go like this: “Replace these pieces (or processes) in your data center with my product.  It will perform the same function while saving capital cost, power, operational overhead, and/or time.”

How much will I save?

These are lofty claims, but how to quantify?  Capital cost and commodities such as power are the most straightforward.  A customer can look at the cost to upgrade existing assets and compare with purchasing the new product.  Power can be measured as well.  There may be a small leap of faith that the replacement is sized appropriately for the task and that additional equipment or licenses will not be required to replace the existing asset.

Operational overhead and time savings are more murky.  Assuming ease of implementation is addressed (stay tuned), will my product require learning a new user interface?  Much has been written on how product managers can heavily influence their product’s user experience and ease-of-use.  Will the customer require ongoing integration with existing systems such as security, monitoring, or accounting?  These costs are real, contributing to multi-billion-dollar integration products and services that are growing rapidly.

This still doesn’t completely answer “how much will I save?”  While I can ask for the customer’s hourly labor rate and multiply by some number of hours saved, many employees are salaried and not compensated for additional time worked beyond a certain baseline.  Maybe employees are working through lunch, staying late, or checking in on the weekend.  Putting aside issues of pay and fairness, all hours are not accounted for equally and the purported time savings may not show up fully in the customer’s bottom line.  A common approach quantifies cost savings for existing customers and uses their data, with permission, as examples for others.

It costs…what?

In part 2 of this post, I’ll explore the costs and complexities that detract from efficiency claims and increase the customer’s burden to buy into the goodness we promise.  Send me your stories and feedback on how you’ve approached efficiency in designing and selling IT products.