Testing Needs and Wants

I often see project teams, as they define the requirements for the project, use the words "want" and "need" to sort essential requirements from nonessential. The needs are the essential requirements, critical to project success, and the wants are non-essential. If we find out that we can't satisfy all of the requirements, we'll jettison some of the wants and focus on the needs.

This simple distinction between wants and needs has the advantage of allowing speedy triage. We gain that speed by trusting the unexamined and risky assumption that needs are more important than wants.

But hold on... The risky assumption that needs are more important than wants? Needs are more important than wants. Aren't they?

Sort of. Most of the time. Often enough to lull us into believing that "needs versus wants" is a good way to sort requirements.

Labeling requirements simply as wants or needs hides at least as much information as it expresses. Each requirement, whether we call it a need or a want, is a value. Like any value, a requirement gains its importance through a rich web of beliefs and values called a Value Hierarchy. When we quickly label requirements as wants or needs, and quickly sort the requirements under the assumption that needs are obviously more important than wants, we leave unexplored the rich web of beliefs and values that motivates the requirements in the first place. If we act on requirements without testing the underlying beliefs and values, we increase our danger of solving the wrong problem, and of wasting precious time, money, and attention.

What leads us to think of needs as more important than wants? To explain that, I'll need to describe how I think about wants and needs.

In their noun forms, the words want and value mean the same thing: a condition that we desire. Wants, then, are organized into Value Hierarchies — each want becomes a want precisely because we believe it leads to some other condition that we desire even more. Each want is a means to an end.

I see needs as special kinds of desired conditions — that is, as special kinds of wants. Like other wants, each need is a means to some more important end. What distinguishes needs from other wants is that a need implies necessity, our belief that the means is necessary if we are to achieve the end. If I want to attend a conference in Boston, I need to go to Boston. Given my desire to attend the conference, going to Boston becomes a need.

Not all wants are needs. If I want to go to Boston, I might choose buy an airplane ticket. But I don't need to buy a plane ticket. I could instead travel to Boston by car or by train. Buying a ticket is a possible means to the end, but not a necessary means. So buying a plane ticket is a want, but not a need.

A need, then, is made up of three elements:

It's the third element, the element of necessity, that distinguishes needs from other wants. And it's that additional element that leads us to consider needs more important than other wants.

So now I've shown that needs are more important than wants, right? Well, yes, with important conditions: A need is more important than a want if the value underlying the need is more important than the value underlying the want, and if the beliefs underlying the need are reliable. Those conditions are important. If we lull ourselves into believing that all needs are (obviously) more important than wants, we forget to test the underlying values and beliefs. And sometimes those values and beliefs don't hold up under scrutiny.

If we're going to claim that this requirement is more important than that one, we owe it to ourselves to explicitly test the values and beliefs by which we assign the requirements their importance.

What can happen if we choose to leave those beliefs and values tacit? Here's an example of a time when I focused so much on something I thought I needed that I didn't bother to ask myself what problem I was solving.

I was writing a conference paper about resistance, and I kept referring to "the person you are asking to change." I got tired of writing that, and it seemed like an awkward phrase to repeat so often. I tried the word "client," but that didn't seem quite right. So I wrote to a group of writer friends, and said, "I need a better word." They offered lots of ideas, but I wasn't entirely happy with any of them. (I was happy that nobody suggested the word "target," a metaphor that I do not want to promote.)

Finally, Jerry Weinberg said, "What's wrong with 'person'?"

I tried "person," and it fit nicely in some places, and awkwardly in others. I was stumped. So I asked myself, "What is wrong with 'person'? What am I trying to do here? What problem am I trying to solve with a better word?"

As I looked closer at what I was writing, I noticed that the reason I was repeating "the person you are asking to change" so often was that I was trying to avoid the awkward "him or her." Aha! My real goal was to find words that were both gender-inclusive and graceful. By focusing so intently on my "need" for a better word, I had distracted myself from discovering my real goal, the deeper value. Once I realized that my real goal was to find graceful gender-inclusive terms, I solve the problem easily.

I think you'll agree that this example is relatively harmless. I wasted a few hours of my time, and perhaps a few hours of my friends' time. Not a major disaster.

But what if something similar happens on your projects, on your requirements? What if the deeper need behind some "critical" requirement turns out not to be very important after all? What if the requirement will not really satisfy the underlying need? What if there are better ways to satisfy the underlying need? What if you discover these problems only after you spend precious time, money, and attention to implement the requirement?

Don't let your need to quickly sort requirements distract you from understanding the requirements more fully. Take the time — especially for the requirements that you are sure are "needs" — to test your underlying beliefs and values. What underlying value motivates this requirement? Will implementing this requirement really satisfy the underlying value? What makes us think so? Is this requirement necessary, or might there be simpler, less costly ways to satisfy the underlying need?