Wants and Needs

When a client asks for a capability or feature – is it a want or a need? How do we prioritize them?

Maslow’s Hierarchy

Abraham Maslow proposed in 1943 that humans are psychologically driven to meet a set of needs, or achieve a set of goals that range from “basic” needs to “higher” needs. His theory is that people focus on the most basic needs, until they are achieved, then advance to the next level of needs, defining a hierarchy of needs. We have a saying at home – “If that’s the most important thing you have to worry about today, things must be going pretty well!”

Maslow’s hierarchy defines needs in the following set of increasingly “higher” categories:

1. Physiological / biological needs
2. Safety
3. Love / belonging
4. Status / esteem
5. Actualization

The logic is straightforward – until a person addresses his hunger, he doesn’t care about job security. Until he has job-security, he doesn’t care about recognition for his efforts. Each base need must be met before someone prioritizes the next level in the hierarchy.

In other words, until we have enough potatoes, we don’t care if we have enough mr. potato heads.

Customer Requirements

Many customers exhibit a similar behavior. When thinking about software purchases, or feature prioritization, they may have a hierarchy that looks like the following:

1. Meets the needs of our business
2. Fulfills the wants of our business
3. Enables us to improve the way we do business

If the software doesn’t do what it must do, then we don’t care if does extra stuff. Only when the software helps me deal with today (both needs and wants) do I care about how it helps me reinvent for tomorrow. The tactical takes precedence over the strategic.

Balancing Act

We have to perform a balancing act – climbing as high up the hierarchy, without going too high.

Climbing the Hierarchy

Determining how to address this hierarchy with our products / solutions can be tough.

1. We have to address all of the needs, or our product will be eliminated from consideration.
2. We have to address at least some of the wants or our product won’t be differentiated in the market.
3. When we can innovate and help our customers innovate, we have a great opportunity.

The trick is to remember that we have to address the basic needs in the hierarchy first. Our software must address the needs – that is the price of admission. By addressing the wants of our clients, we can differentiate ourselves. All viable (by definition) competitors must be addressing the needs already. And only when we have satisfied wants and needs can we ask our customers to become introspective and consider reinvention of their business in a way that redefines wants and needs, in order to achieve a discontinuous improvement.

Here’s a soundbite version of the same hierarchy:

1. Required
2. Desired
3. Inspired

Going Too High

When we try and do too much, we can alienate our potential customer and lose the deal. Or worse, we can close the deal and lose the users. Featuritis is the all-to-common condition of having too many features in our software, trying to tackle all of the wants and needs. The extra features make it too hard to learn how to use our software, alienating users. Without adoption, we won’t achieve the value promised by our software.

Anecdote

A situation that happened today, when defining a future business process:

1. We defined the steps involved in modifying some business objects.
2. We agreed that this was required to support a previously scoped business process.
3. The business owners asked for the ability to see the results of the modifications.

The first step was validated in the second step as one of our needs. The third step looks like a want. The “ability to see” was a manual “let me just make sure that it worked” step. When we asked the question “Which business process requires you to see the results of the modification?” the answer was “None.” It turns out that a manual inspection only provides confidence to the user that things are working as they should.

Potato? Or potato head?

Our vote is potato head, as their is no ROI gained or lost by including or excluding this feature. Emotionally, that was hard for our business owner to accept (and no, we didn’t use the potato head analogy). Ultimately, we will include this feature, but only with the awareness that it is lower in priority than required features.

The implementation of the feature happens to be essentially free, and the goodwill and initial user adoption benefits are enough to make the value measurable, however transient it is. Therefore, our “in the real world” decision was to include it. In the theoretical world, we would have excluded it.
Conclusion

Customers care first about things that are required, and then about things that are desired. Only after addressing those two can we propose solutions that are inspired. Thanks Maslow!