A Parable on Stage 4 Product Proliferation

Once upon a time, long, long ago, TypicalEnterpriseSoftwareCompany had a simple little price list. It could be described in a paragraph. Buy our server and pay $XX,XXX per machine. Buy our companion client-side tool and pay $YYY per instance. Simple.

And then came the inevitable. Prospective Customer A started complaining: "TypicalEnterpriseSoftwareCompany, we like your product. But it is too full-featured for us. We don't want to pay for functionality we won't use.  We want to pay less."

Instead of recognizing this as a price negotiation tactic, what do you think the leaders of TypicalEnterpriseSoftwareCompany decided to do? Did they attempt "value pricing" to bring the price more in line with the benefits Customer A were to receive? Did they offer a one-time discount so the price would fit the project's budget?  Did they try any other creative ways to make the product more affordable to the customer without requiring modification to the product?

No. Of course not. Because those options are too simple. And too cheap. You see,TypicalEnterpriseSoftwareCompany always likes to do things expensive way. The way that is most likely to confuse the heck out of customers and the sales people and pretty much everyone.  The way that is most likely to increase the cost of BOTH sales AND product development by tenfold.

So what did they do?  The leaders of TypicalEnterpriseSoftwareCompany decided that a NEW product should be created, a variation on the original.  This NEW product would have less functionality than the original at a lower price.

And it worked. The deal closed.

And then the very next customer, Customer B, said: You know what, we like your stuff, TypicalEnterpriseSoftwareCompany. But the original product is too much for us, and product variation A doesn't do enough.  We need something in between and we don't want to pay for functionality we don't use.

And so the company leaders met again, and they commanded that Yet Another Product be created. Product B would have less functionality than the original and more than Product Variant A, and offered at a price in between the two.

Customer B liked. And Customer B bought.

And you can see where this is going, right?

N years later, TypicalEnterpriseSoftwareCompany now has product variations A through ZZZ.  All are slight variations of each other.  Each has a moniker meant to distinguish it from the rest, but instead these names confuse the heck out of everyone: "Lite", "Starter", "Ultimate", "Standard", "Enterprise", "Developer", "Advanced", "Professional", "Professional Plus", "Basic", "Premier", "Express", "Personal", "On-Demand", "Workgroup", "Home", "Business", "Desktop", "Premium",  "Basic N", "Unlimited", "Datacenter", "Foundation", "Framework",  "Mobile", "Community"...  The list goes on and on. Naturally, there is no consistency in the naming. That would be too easy.  Plus it is unclear what most of  these terms  mean, anyway.  Especially when the "Unlimited" and "Ultimate" variants aren't as powerful as the "Enterprise" or "Pro Plus" or whatever. And how are the Lite and Basic and Express and Starter editions different?

Not only that, each of these "new products" can be licensed in a myriad of ways: per instance, per customer site, per server, per processor, per concurrent user, per named user...  It is difficult to think of a licensing method that TypicalEnterpriseSoftwareCompany does not support.

Results?

The price list is now enormous, pushing 200 pages or so. No one can understand it. Especially not sales reps.  They join DysfunctoSoft and then quit/get fired within a year. And then it's time to train a new sales rep. It takes them MONTHS to finally internalize this nutso product line architecture.  Without their guidance, customers can't understand what to buy or how much it costs. Forget a consumer sale, a self-service sale, or one driven by website research.

Product Development is getting crushed underneath the weight of all these product variations. Although they all largely use the same code base, there are significant differences that have impact throughout the behavior of the products.

And because the names are hard coded into the products, manuals and marketing collateral, despite a concerted effort NOT to hard code them, it is now impossible to change the names to more sensible alternatives.

The QA effort required to test all these products on all the support platforms has gone through the roof.  It seems that for any new release 60% of the effort goes into making the licensing more intricate and trying to automate this crazy product variation structure via license keys or elaborate build systems.

What else?  Support costs have skyrocketed.  As have documentation and training costs. Marketing costs too. I am sure the effects do not stop there. Oh what joy it must be to handle the accounting for such a needlessly massive product line. Or the financial forecasting. The auditors probably have a grand old time billing DysfunctoSoft after sifting through its cornucopia of transactions attributable to each product and licensing option combination.

I truly, honestly believes that TypicalEnterpriseSoftwareCompany's latest troubles are primarily due to the explosion of products that are not truly differentiated.  It's treading water, trying to keep its head above the continually crushing waves of a massive code base.  There is no time to actually create value for your customers when you can barely maintain what you already have.

TypicalEnterpriseSoftwareCompany is hardly alone. Even companies like Proctor & Gamble are lured to madness by the siren of product proliferation and endless line extensions, paying dearly in the end for their lack of discipline.  Every software company I've ever worked with has suffered the same illness.

But most of those companies were still in their early years, suffering from Stage 1 or Stage 2 Product Proliferation. Alas, TypicalEnterpriseSoftwareCompany has an older product line, and is now suffering Stage 4 Product Proliferation: malignant, inoperable and infecting all organs in the body.