A reliable set of design principles is invaluable when developing systems. Few principles are so pervasive in system design as the pareto principle. The pareto principle dictates that a subset of a system's features provides a disproportionally large fraction of the system's value. You can apply this principle to systems in general, but I will be writing about it in the context of product development.
Why is this Useful?
This principle serves as a decision making guide. Time, energy, and other resources are limited. When developing a system, you must allocate limited resources among a set of features. The pareto principle informs you where resources can be most effectively applied: you should devote the majority of your resources to the set of features which provide the most value. To go against this principle is to ineffectively allocate resources. The value a person-hour can create is not constant and a person-hour should be allocated to the feature of a system which results in the greatest increase of overall system value.
Applying the Pareto Principle
A clear sense of purpose is necessary to do this effectively. A clear purpose will allow you to order the features of the system in terms of value. The pareto principle does not tell you how to value features. The gold standard for measuring feature value is user feedback. Communicating and empathizing with your users will result in the most accurate measurement of feature value. When no user feedback is available (e.g. developing an MVP) a clear sense of purpose and good design intuition is an adequate substitute. Given an ordering of feature value you will find that roughly 20% of the highest value features account for 80% of the overall value of the system.
This process can be applied iteratively, both to the remaining set of features and the subsystem of an individual feature. Each individual feature is its own subsystem and the pareto principle can help you decide what features of that subsystem require the most resources. The pareto principle can also be applied to the remaining features. The remaining 80% of features will generally also follow the same pattern.
The evaluation of features is a process that you should constantly applied. Requirements change, the purpose of the system can change, the goals of the people developing a system may change. This constant flux means the value of any given feature of the system is always changing.
An Example
The pareto principle applies directly to developing a product. In the initial stage, you should have a clear sense of the needs of your users. This will serve as the guideline for determining the value of each feature.
Dangers
- thinking you only have to go 20% of the way
- underestimating the other 80% of resources
- shifting goals/constraints
- psychologically: