Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles The Hierarchy of Needs

The Hierarchy of Needs

As a product owner I want to prioritize the features in my backlog in order to realize the most valuable features first.

But what is valuable for my customers and users? Some time ago it was much easier to decide which features should be built into the next release - the business people told us. In those days software was mainly created for use in business or science. Nowadays software has become an integrated part of everyday life for just about everybody. The question what is most valuable could be answered much easier if customers and users are part of a well-known business context. But what may be valuable to customers whom I do not even know in an unstructured and completely individualized market?

Value is more than usefulness. Value is related to quality and emotion. A high quality product is more valuable than a low quality product. There are several quality models out there, for instance the CISQ quality model which is based on reliability, efficiency, security and maintainability. But because these quality models don’t include emotional aspects they can not completely explain why that one app is cool and hip while the other similar one is not. We need an enhanced quality model to understand what makes software valuable for its users. Something is valuable for me if it satisfies my personal needs. This seems obvious, but is it helpful?

Can this give me some guidance in finding the most valuable features in my backlog? What do I know about the personal needs of my customers when I don’t even know them?

Psychology may help here. In the mid-20th-century Abraham Maslow developed his hierarchy of needs - a theory of human motivation. The hierarchy of needs may be projected onto a hierarchy of quality aspects of software. In doing so one may come to a holistic model of software quality purposed to satisfy the personal needs of an unknown customer.

Picture 1: Maslow’s hierarchy of needs projected on software quality aspects

In Maslow’s hierarchy of needs the physiological needs are the basic needs. Examples are the need for sleep and food. In the context of software quality the basic needs are availability and operability on the customers device. This basic needs are called “Mandatories”, “Baseline Features” or “Must-be Quality” in the Kano model 1. (See below for more information about other methods of backlog prioritization.) If the software is functionally adequate and has a good performance the customer already perceives a general feeling of given quality.

The next higher level of needs is safety. The hierarchy of this model doesn’t mean that a lower level of needs must be perfectly satisfied before more and higher needs will arise. Often it will be sufficient if lower needs have been minimally satisfied to give rise to new needs on a higher level. On the other hand one cannot satisfy single needs unlimitedly. If you are well rested and sated a plus on sleep and food are not the needs that will motivate you most.

Related to software quality this means for one thing that robustness, safety and understandability will become relevant only if the software is runnable on the customer’s device and performs the tasks it is intended for. Further it means that an increase in functionality may not result in a higher quality experience on the customer’s side if his or her functional needs are saturated but higher needs are not. For a potential customer functionality is central. For a customer who uses the software already the functionality is more of a given fact. He or she will often expect other and higher quality attributes instead in a new release.

Besides robustness and safe usage the safety needs include understandability. The feel of ease and understandability shields the user from the fear to make mistakes and fail. Barrier-free accessibility is also a need in this category.

When physiological and safety needs have been satisfied at least to a certain degree social needs will arise. Whether or not the software is popular and recognized within the customer’s social circles may become more important. This may inspire additional features like direct posting to social media, recommendation or rating systems or including a chat-room into a web store where users may discuss pros and cons before buying a certain product. Often the fact that the product is a market leader is more important than functional completeness. Alternative solutions may become a second choice even if they would fit better. The reason for this is partially grounded in safety needs, too. The user may feel safer if she or he can find help with the software in communities or social networks.

But the opposite may be true, either. Some people want to distance themselves from others by not using the market leader product. Even some degree of quality loss will be accepted in order to be different from the crowd. To differentiate your product from the market-leading product you could try to become better in higher need categories even if your product does not include all the features that the market leader offers on lower needs.

What you may notice by this example is the fact that this model is not perfectly hierarchical. On one side basic needs must be fulfilled to a certain degree to call higher needs into play. On the other side those higher needs are often more valuable for the customer which may lead the customer to put back basic needs for the benefit of satisfying some higher needs.

As the next step beyond social needs Maslow sees the needs of the individual summarized by the term “Esteem”. This is the domain of power, autonomy and freedom but also of prestige, acknowledgement and respect. In terms of software quality and value this means to be enabled to do things you could not do without the software or a specific feature, things that enhance your status or broaden your horizon - cool and individually satisfying things. The fifth and last step in this model is reserved for self-actualization (Maslow later refined his model and added the step of transcendence). A software that enables users to go their own way, to realize own ideas or that fosters the users creativity will be recognized as more valuable than a software that focuses narrowly on a given solution space. Connectivity or collaboration features like “Sharing” for mobile apps and cloud services or “Import/Export” for desktop applications may fall into the categories “Esteem” or “Self Actualization” because they often enable the user to create his or her own workflows beyond the limits of a single application on a single device (see example below). 

A classical understanding of software quality is based mainly on physiological and safety needs. In contrast a quality model for today’s software should be based on the complete hierarchy of needs. Because software enters more and more personal and private areas of our life, some new social and individual aspects of software quality come into play besides security and privacy. Availability, robustness and suitable functionality will be simply assumed by consumers. Actually a lack of these basic properties often results in unfriendly posts in App stores or social networks.

This trend is apparent not only in the consumer market. The fact that we all are software consumers all the time also shapes our expectations on business software. That software must be usable without an intensive and lengthy study of a user manual is nowadays taken for granted and is essential for success or failure of any software product.

So how may this be useful for prioritization? In their book “How Google Tests Software” 2 James Whittacker suggested a test planning and risk-assessment technique called ACC for Attribute, Component, Capability. The idea is to span a matrix of quality attributes promised for the product on one axis and the components of that product on the other axis. In the cells of that matrix you fill in capabilities of the components that mitigate the risk of that component not to meet the promised attribute. For instance, if marketing promises that users of the product can find searched items quickly, this may result in a capability for the search engine to return results within a given short time span. This idea inspired me to use a similar approach for prioritization of features by the amount of satisfying Maslow’s categories of human needs. I call this the NFC method. NFC stands for Need, Feature, Capability, where the Maslow need categories on one axis and the features to prioritize on the other axis, span the matrix and the cells of that matrix, depicting the way the feature will serve the need. Features that satisfy higher needs will be given higher priorities over features that only satisfy lower needs – always assuming that more basic needs are already at least partially satisfied by the product.

Let me give an example. Let’s say you have a mobile app which enables users to fax documents. The app has its own basic editor and as a product owner you have to decide whether to include more advanced features in the editor, build in a function that enables users to delete faxes from the outbox before sending or allow receiving documents to send from other apps via their “Share” function. This leads to the matrix displayed in table 1.


Need Category

Editor enhancement

Delete from outbox

Receive documents








Enable faxing of any document that can be shared, enhance status






Ease of formatting, safeness thru undo function

Error friendly “undo” sending



Functional completeness of the editor



Table 1: How will the features serve the user’s needs?

Table 1 shows that receiving documents for sending from other apps will serve the highest needs by enabling users to do things which they could not do without this function. This possibility may also enhance a user’s status (I can do something that you can’t). Both capabilities serve the Esteem category of human needs. As a result of the feature capabilities shown in table 1 you as a product owner may give the “Receive documents” feature highest priority followed by “Editor enhancements” as second and “Delete from outbox” as the third most valuable feature. The reason why “Editor enhancements” is more valuable than “Delete from outbox” although they both serve the Safety needs is because “Editor enhancements” additionally serves the Physiological needs where “Delete from outbox” only serves the Safety needs. Your job as a product owner when prioritizing the features in your backlog is to think about how the features in your backlog will serve your user’s needs, according to the Maslow hierarchy. Always give highest priority to the feature that serves the highest needs for which all lower needs are already sufficiently satisfied.

There are some other techniques for backlog prioritization, many of them are business value or risk based. For learning more about other methods of backlog prioritization you may want to check out a talk by Mike Cohn on that topic from the Agile 2008 conference 5. A lean startup approach to prioritization is validated learning 4. In this technique, features are chosen based on the highest market risk. Highest market risk features are built in the product first, released to the market and the learnings are used to select the next feature.

One of the best known methods for backlog prioritization is doing an analysis based on the Kano Model 1. The Kano Model can successfully be used when categorizing quality attributes (delighters/exciters, satisfiers, dissatisfiers, mandatories, etc.) derived from customer interviews (Voice of the customer 3). It focusses on analyzing user satisfaction, not on predicting what may be valuable to customers in general.

My thoughts and the resulting NFC method are a theoretical approach to feature prioritization and prediction of user satisfaction. The results should always be complemented by interviews with real users, experiments and testing. But I believe these thoughts and the NFC method can provide a good starting point and guidance when searching for features that may be most valuable for customers and users who you do not even know.

Further readings

1 The Kano Model

2James Whittaker, Jason Arbon, Jeff Carollo: “How Google Tests Software”, 2012 Pearson Education

3 Voice of the customer

4 Validated learning

5 Mike Cohn, Prioritizing Your Product Backlog

About the Author

Manfred Rätzmann is Head of Department Quality Assurance at E-Post Development GmbH, based in Berlin, Germany. Before his engagement at E-Post Development he worked as a product owner for Hypoport AG, a Berlin based internet company offering financial services. Being a software developer at heart he has focused early on tools and practices for building high quality software and agile software development. He is co-author of the book “Software Testing and Internationalization”. He has written several articles and is a regular speaker at conferences about quality and agile software development.

Rate this Article