The Pareto Principle: Maximizing Your Investment Dollars

It is difficult to avoid hearing about the “80-20 rule” in the modern professional environment. It has gained traction in many circles as a way to boost productivity and prioritize one’s work.

However, the phenomenon is much deeper and more powerful than this. Formally known as the Pareto Principle, it can be distilled down to the following concept:

80% of all results come from 20% of the inputs.

We will examine the implications that this unofficial law has for SMBs involved in software and how it is the key to maximizing their investments.

From Pea Plants to Software Bugs?

One of the remarkable aspects of the Pareto Principle is how it postulates that paying attention to a small detail can yield appreciable results. It is then appropriate that the principle originated, according to legend, through the observation of pea plants.

As Forbes recounts, the 19th century economist and philosopher Vilfredo Pareto supposedly noticed that 20% of his pea plants created 80% of his healthy pea pods. He then went on to investigate if there were such imbalances in many of the world’s important processes and found the 80-20 distribution everywhere; e.g. in Italy’s landownership rates and in the relative productivity of companies. It is hard to believe that there is a link between pea plants and software features, but the principle certainly holds true in this realm.

A Ubiquitous Phenomenon

Was Pareto’s discovery just an odd fluke? Not likely, as the phenomenon has reappeared in many empirically verifiable forms for many decades. The applications range across economics, industrial reliability, management, marketing, and even personal development. As the article linked earlier notes:

  • 20% of the sales reps generate 80% of total sales.
  • 20% of customers account for 80% of total profits.
  • 20% of the most reported software bugs cause 80% of software crashes.
  • 20% of patients account for 80% of healthcare spending (and 5% of patients account for a full 50% of all expenditures!)

Pay particular attention to the second and third items on this list. This is our jumping off point for how the Pareto Principle interrelates software features, software maintenance, and customer satisfaction.

Stopping Feature Bloat

This post from UserVoice details how the history of product manufacturing has been a history of feature bloat. It also provides evidence that while feature-richness may be a selling point for some customers, a useless accumulation of features contributes to customer churn.

Fortunately, with software products we do not have to accept feature bloat. It is possible to add and subtract software features within a relatively short timeline. It is even possible to re-enable a feature if there is a large outcry at its removal.

The Pareto Principle for SMB Software Investment

In software we can leverage the Pareto Principle to keep a lean feature set. For SMBs this is not merely a clever tool to help boost business, it is really non-negotiable. It is a key to maximizing your investments since resources will be stretched way too thin if you maintain features that are not meaningful for your customers or for your bottom line.

As this HubSpot post relates, we will be driven to add new features due to competitor pressure, a pushy client, or simply because we have a good feeling the feature will be a success. However, we often look at only the ramp-up cost of the new feature and not its long-term consequences:

  1. Increase in setup time: Your product, from an operational standpoint, gets increased overhead which could be in the form of configuration or required training.
  1. Support costs: The feature may generate an influx of support calls. Keep in mind that customer support is an expense that involves payroll, supervision, training, office space, telecom expenses, etc.
  1. Infrastructure costs: A feature may involve costly changes in infrastructure that you do not anticipate. For example, your feature may grow in usage quickly and rely on data from relatively costly RDBMS access. You will then have to consider a redesign with MongoDB or a more appropriate technology in order to maintain the feature.
  1. Increased maintenance costs: Every feature adds a larger base from which bugs can emerge. This is particularly true with a high-volume feature. Your customers acting en masse may be able to break the product in a way that your developers or QA had not foreseen. Certain bugs can only emerge in corner cases that can only be seen in a production environment. It should also be noted that more code leads to a larger “attack surface” that malicious parties target, increasing the cost of security.
  1. The Cost of Complexity: No matter how well-designed our solutions are, adding new features leads to complexity. Difficulty of development and troubleshooting always increases with the size of a code base and the number of moving parts that comprise a system.

Given all these factors, it becomes the SMB’s task to find out which features make the product “sticky.” There is a core set of functionality – 20% – within any system that drives 80% of success. You should perform a relentless analysis and paring to keep functionality lean.

No doubt, 20% of your outstanding bugs will cause 80% of your problems. You need to identify if any of these bugs are critical to your revenue-generating features. If not, then we can perform the most effective bug fix possible – remove the feature.

One important practice for eliminating bugs in software development is that of unit testing code. An organization might try to target a percentage of code coverage in an effort to achieve a certain measure of quality of their software product while another might question the value of writing unit tests, especially when funding or resources are scarce. In either case, it is always best to concentrate unit testing investments to the 20% of your software that 80% of your customers use most.

20% of your customers drive 80% of your sales. Though we talk about the risk of new features, you must obviously have a product that evolves. The proper way to grow your product is to identify your fruitful 20% of customers and listen to their needs.

With only 20% of features really contributing to your bottom line, look to kill the remainder off. This can be done cold-turkey in extreme cases or through gradual weaning. One of the benefits of being relentless about dropping features is that if you discontinue the wrong one, your top 20% of customers will have an outcry. This will give you further insight into your customers and which features matter most.

About Matt Vegas

Leave a Reply