On the Hierarchy of Product Needs
Or, Semi-Philosophical Musings on How to Prioritize Product Development
21 January 2016
Abraham Maslow was an American psychologist best known for developing the theory of hierarchy of needs, often referred to simply as Maslow’s Hierarchy of Needs. The theory suggests that human needs form a prepotent hierarchy: needs that are lower in the hierarchy usually need to be satisfied to some extent before a human will pursue needs that are higher up in the hierarchy. As the man himself wrote:
Human needs arrange themselves in hierarchies of pre-potency. That is to say, the appearance of one need usually rests on the prior satisfaction of another, more pre-potent need. Man is a perpetually wanting animal. Also no need or drive can be treated as if it were isolated or discrete; every drive is related to the state of satisfaction or dissatisfaction of other drives.
The hierarchy is often presented as a pyramid, though apparently none of Maslow’s own work depicted it in visual format. From the bottom up the needs in his theory are physiological needs, safety, love and belonging, esteem, and, on the top of the pyramid, self-actualization needs:
Someone who is hungry will not usually seek self-actualization by writing poetry. Someone living in a war zone will not usually seek to be recognized in a given field of expertise. In those circumstances, people will usually be more occupied by finding something to eat (a physiological need) and staying unharmed (a safety need) than fulfilling needs higher up in the hierarchy.
Notice the emphasis on usually: without it, we wouldn’t have starving artists, selfless acts of compassion from someone living in poverty, or people dying playing computer games in Taiwanese gaming cafes (neglecting physiological needs while pursuing belonging, esteem, and, perhaps, self-actualization.)
From Maslow to products
I’d like to draw an analogy from Maslow’s theory to product design and use his work to suggest a hierarchy of product needs. (For brevity, I’ll use the word product to refer to services as well.) People have used this same analogy before from various perspectives; my emphasis is on how the concept of the hierarchy of product needs can be used to help make decisions that may lead to better products.
Here the product needs are functionality, usability, and pleasure:
Others have divided this hierarchy into more than three layers by adding, for instance, meaningfulness on the top; while I’m tempted to do this myself too for the added granularity, this is just a model and as such sufficient for the purposes of this text. Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.
For a product to have any value, it first needs to have some functionality: a tap needs to be able to let water out, a hammer needs to be able to drive nails into wood, and a Twitter app needs to be able to tweet. The functionality layer doesn’t state anything on how easy or difficult this functionality is to interact with.
To add value to the functionality layer, the product should be somewhat usable: the tap has a handle to control the flow and temperature of the water, the hammer has one end that’s good for the grip and other that’s good for the hitting, and the tweets fly out from the Twitter app. When a product is usable, it probably doesn’t cause major frustrations to its users, but this alone doesn’t mean that the product is a joy to use.
On top of functionality and usability is the pleasure layer. Pleasure is what we seek when consuming entertaining products, such as movies and games, but can also be achieved in products of more mundane nature. Pleasure is the platform on which people can build a positive emotional connection with a product and can make them become loyal customers or even fans of the product. Of the three layers, pleasure is by far the hardest to achieve. It’s beyond the scope of this text to detail our current understanding of what makes a product pleasurable, but a good primer on the topic is the four pleasures framework with its concepts of physio‑, socio‑, psycho‑ and ideo‑pleasures.
It’s worth noting that, in terms of the pyramid model, some products are naturally more bottom-heavy and others more top-heavy, and that’s all fine. However, even in the most technical of products, it is difficult to imagine a situation where you wouldn’t also have a chance to address the higher needs: somewhere down the line there’s probably a human being with all her needs and wants waiting to be fulfilled.
Money, time, and other boring constraints
As product development endeavours are practically always bound by budget and time constraints, we are forced to make decisions on how to prioritize resources between building these layers.
With the deadline looming and a shrinking amount of money left in the budget, should we crank up yet one more feature or, alternatively, focus on the pleasure-providing aspects of the product and end up with a smaller set of functionality? Should we add one more blade to the Swiss army knife, or focus on what it feels like to carve out wooden figures with the knife or how the knife will add to a person’s self-construction?
All too often in these situations the tendency is to resort to a document or a bullet point list specifying what the shipped version of the product is supposed to do, which, in the context of the hierarchy, equals the things that the functionality layer should include. This document is called the specification, or the spec.
From the point of view of building great products, the problem with the spec is that it is pretty easy to list functionalities and tick them off one by one when they become ready, but incredibly difficult to write a list of pleasures and tick them off when they are, somehow, achieved. The higher up in the hierarchy we move, the fuzzier things get and the more difficult it becomes to measure them unambiguously (which, by the way, comes across as analogous to Maslow’s Hierarchy).
If product development is prioritized by just simply ticking off as many items in the the spec as time and money allow, we'll end up with products where the functionality layer is seemingly strong, but all the sacrifices will have come out of the two top layers:
Prioritizing product development this way leads to products that are half-baked in terms of the higher needs: the product won’t provide much pleasure for its users to go on raving about and to become fans of.
However, there is a different way of prioritizing what to do with the time and money that is left in the budget, one that may lead to more successful products:
Though the product is stripped off of some of the functionality that was initially listed in the spec, the pleasure that it provides to its users may well compensate for this. People don’t choose products by reading over the spec, but rather choose and stay loyal to products that they can create emotional connections with.
Don’t worry if your product doesn’t do everything that it could have done. But if your product isn’t able to build an emotional connection with people and, at least on some level, make them feel pleasure, be scared to death: a product that can do just that is probably just around the corner.