Need

Origin & evolution

The need-versus-solution distinction has a long pedigree in marketing, but its sharpest modern statement comes from the jobs🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →-to-be-done tradition. Theodore Levitt's line, often repeated, captured it: people who buy a quarter-inch drill do not want a drill, they want a quarter-inch hole. Anthony Ulwick built a formal method on the same instinct, arguing in Defining Customer Needs that most teams confuse needs with solutions, specifications📋SpecificationFoundationsA canonical open standard or specification that primitives and products conform toView reference →, or vague benefit statements, and that a need is properly framed as a measurable outcome🏆OutcomeStrategyA desired business or user outcomeView reference → the customer wants from getting a job done.

A recurring split in the literature is between articulated and latent needs. Articulated needs are the ones a person can state plainly, such as "I want longer battery life." Satisfying them tends to produce incremental improvement. Latent needs sit below conscious expression, and surfacing them is where larger product moves come from. One argument worth keeping is that latent needs are less mysterious than they sound: the usual block is shallow questioning, and repeated "why" follow-up draws them out.

The field's most common abuse is the Maslow pyramid. Abraham Maslow's 1943 paper A Theory of Human Motivation proposed a hierarchy, but he never drew a pyramid, and he never claimed one level must be fully met before the next begins. Bridgman, Cummings and Ballard traced the pyramid to a 1960 management graphic by the consultant Charles McDermid, not to Maslow at all. Teams that rank user needs into rigid tiers are quoting a diagram their source never endorsed.

How it works in practice

A scheduling tool gets a steady stream of requests for a darker calendar theme. Read as a want, the answer is to ship dark mode. The team instead interviews fifteen of the askers and finds the pattern underneath: most of them are checking the calendar late at night from bed, on a phone, and the bright screen wakes a sleeping partner. The need is to glance at tomorrow without disturbing anyone in a dark room. Dark mode serves part of it, but so does a low-brightness lock-screen widget that never opens the full app, which tests better. Six months later a new request arrives for a different colour scheme. The need has not changed; only the proposed solution has. Holding the need stable lets the team evaluate the new ask in seconds.

Need vs. its neighbours

• Job is the progress a person is trying to make in a situation, framed as a verb. A need is the requirement that the job exposes. One job typically surfaces several needs, which is why the graph routes them through job_surfaces_needJobsurfacesNeedcausal rather than collapsing the two.
• Desired outcome🌟Desired OutcomeUserWhat the user hopes to achieveView reference → is the measurable result that signals a need has been met, such as "cut the time to reconcile an invoice💳InvoiceSales & RevenueAn invoice for billingView reference → from twenty minutes to two." The need is the requirement; the desired outcome is how you would know it was satisfied.
• Opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → is a need the team has chosen to act on, weighed against others. Every opportunity points back to a need, but most needs never become opportunities. Naming the need first keeps the prioritisation honest.

In the graph

In the Unified Product Graph, a need lives in the Users and Needs region and acts as the durable target beneath shifting feature requests🙏Feature RequestCustomer FeedbackA user-submitted feature requestView reference →. A persona🎭PersonaUserAn archetype representing a user segmentView reference → reaches it through persona_experiences_needPersonaexperiencesNeedsemantic, a job exposes it through job_surfaces_needJobsurfacesNeedcausal, and a chosen bet attaches through opportunity_addresses_needOpportunityaddressesNeedcross-domain. Qualitative evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → anchors it: feedback_theme_validates_needFeedback ThemevalidatesNeedcross-domain ties a recurring theme to the need so it rests on observed demand, not assertion. The forward link need_fulfilled_by_capabilityNeedfulfilled byCapabilityhierarchy then connects the requirement to whatever the product builds to meet it, so a feature⭐FeatureProduct SpecificationA product capability or featureView reference → can always be traced back to the human requirement it serves. A need with no fulfilling capability💪CapabilityStrategyAn ability that enables value deliveryView reference → is a visible gap; a capability serving no need is visible scope creep.