What Is a Need
What the user says, what they actually want, and the solution you plan to give—those are three different things.
A need is the state a user wants to reach in a given situation. It isn't the sentence the user says, nor the feature you plan to build. What the user says is the solution they can think of, not their problem—they're used to Excel, so they ask for export; they've seen a button in another app, so they want it too. Treat that sentence as the need, and what you build will forever trail behind someone else's imagination.
What you'll run into:
- You build exactly what the user asked for, and they're still not satisfied
- Features pile up, the product gets heavier, and the problem remains
- Two users request conflicting things and you don't know who to listen to
Six traits of a need
These six traits explain why needs are so hard to handle.
- Grounded in reality. Needs are constrained by technology and environment. The need to communicate hasn't changed, but letters became instant messages.
- Varies by person. Two people can want completely different things from the same feature. That's why you ask specific people.
- Keeps evolving. Satisfied needs breed new ones. Today's delight is tomorrow's baseline.
- Interlinked. When one need can't be met, people compensate another way. That's where workarounds come from.
- Layered. If the lower level isn't met, the higher one doesn't hold. Someone who just lost their job doesn't start with self-actualization. maslow
- In conflict. One group wants more features, another wants faster startup. Conflicts can't all be resolved—you pick a side.
The last trait is the root of many bloated products: teams avoid offending either side, add both sets of features, and end up satisfying no one. Accepting that needs conflict matters more than trying to please everyone.
Which categories actually matter
There are a dozen-plus ways to classify needs. The three that actually change your decision day to day are these.
- By whether it's spoken. Explicit needs are stated outright; latent needs are ones the user hasn't recognized. Explicit needs are visible on every competitor—latent needs are where differentiation comes from.
- By whether they'll pay. An effective need means both the will and the means to pay; an ineffective one means they want it but won't pay for it. Between "I'd use it" and "I'd pay for it" sits an entire canyon.
- By how it lands in software. Functional needs are what the thing must do—most requirement docs only write this half. Non-functional needs are how fast, how stable, how usable; skip this half and what AI generates will demo fine and fall over in production.
The last pair deserves the most attention. Say "build a search"—the functional part, AI will handle without being asked. A non-functional requirement like "must return results within a second on three thousand rows" won't occur to it unless you write it down. Need analysis in one sentence: dig one layer below the solution the user proposes, find the state they want to reach, then design your solution from there.
Walk the statement example once more. The user says "add a button to export to Excel"—that's a solution. Dig one layer down and what they actually want is "on monthly reconciliation day, turn scattered revision records into a list I can send straight to the client"—that's the need. Dig one more layer and you reach the root of the problem: records scattered, formats inconsistent, easy to miss items. "One-click statement generation" is only one of your possible answers. The same need has countless solutions: auto-consolidation, scheduled sending, a WeChat push. Get the middle layer clear and you have options; leave it vague and you're stuck building the button they happened to mention.