{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-07-12T12:36:44.384Z"},"content":[{"type":"documentation","id":"80b10c82-794c-455e-a49f-55f077069f00","slug":"customer-needs-vs-wants","title":"Customer Needs vs. Wants: How to Tell What Users Actually Need (2026)","url":"https://www.koji.so/docs/customer-needs-vs-wants","summary":"A customer need is the underlying goal or problem someone is trying to solve — stable, often unspoken, and the real reason they buy. A customer want is a specific requested solution or feature — a surface preference that is easy to state but frequently wrong about what will satisfy the need. Building directly to stated wants causes feature bloat, which is why 64-80% of shipped features are rarely or never used. The Kano Model shows that differentiating features (delighters) are the ones customers never ask for. Uncover real needs by anchoring in past behavior, laddering with why, observing workarounds, and applying Jobs-to-Be-Done. AI-moderated platforms like Koji automate the laddering that separates need from want across hundreds of customers.","content":"## Customer Needs vs. Wants: The Short Answer\n\nA **customer need** is the underlying goal, problem, or outcome a person is trying to achieve — it is stable, often unspoken, and it is *why* they buy. A **customer want** is a specific solution or feature they ask for — it is a surface-level preference, easy to state, and frequently wrong about what will actually satisfy the need.\n\nThe classic illustration comes from Harvard marketing professor Theodore Levitt:\n\n> \"People don't want a quarter-inch drill. They want a quarter-inch hole.\"\n> — attributed to Theodore Levitt (who in turn credited Leo McGivena)\n\nThe drill is the *want*. The hole is the *need*. And if you only listen to the want, you will keep improving drills while a competitor sells the customer a laser level, an anchor that needs no hole, or a service that hangs the shelf for them. Great products are built by satisfying the need, not by shipping the literal want.\n\nThe most-quoted version of this idea — the apocryphal Henry Ford line, *\"If I had asked people what they wanted, they would have said faster horses\"* — makes the same point, even though there is no evidence Ford ever said it. Customers describe their desired solution in the vocabulary of what already exists. Your job is to hear past the want to the need underneath.\n\n---\n\n## Needs vs. Wants: A Side-by-Side\n\n| Dimension | Customer Need | Customer Want |\n|---|---|---|\n| What it is | Underlying goal or problem to solve | A specific requested solution or feature |\n| Stability | Stable over time | Shifts with trends and available options |\n| Awareness | Often unspoken or unconscious | Easy to state out loud |\n| Example | \"Reduce the time I spend on expense reports\" | \"Add a bulk-upload button\" |\n| Risk if ignored | You solve the wrong problem | You build features nobody adopts |\n| How you find it | Probing, observation, Jobs-to-Be-Done | Just ask — customers volunteer these |\n\nThe trap is that wants are *loud* and needs are *quiet*. Customers hand you wants for free in every feedback form. Needs have to be excavated.\n\n---\n\n## Why Building to Wants Is So Dangerous\n\nWhen teams build directly to stated wants, they get feature bloat — a long tail of features that individual customers requested but almost no one uses. The data is sobering. The Standish Group's classic feature-usage research found that **45% of features are never used and another 19% are rarely used** — roughly two-thirds of everything built. Pendo's product-benchmark analysis reported that **about 80% of features in the average software product are rarely or never used**.\n\nMuch of that waste is a needs-vs-wants failure. A customer wanted a button; the team built the button; the button did not address the actual job, so it sat unused. Meanwhile the real need — maybe \"help me trust that this report is correct\" — went unmet, and churn crept up for reasons the roadmap never named.\n\nThe **Kano Model** formalizes why \"just give customers what they ask for\" fails. It sorts needs into three types:\n\n- **Basic (must-be) needs** — Expected and rarely articulated. Their absence causes anger; their presence earns no praise. Customers almost never *ask* for these, yet failing them is fatal.\n- **Performance needs** — The stated wants. More is better, and customers will happily list them. These are table stakes, not differentiation.\n- **Delighters (excitement needs)** — Unspoken needs the customer cannot articulate because they do not know the solution is possible. These create loyalty — and you can only find them by understanding the need, never by asking what the customer wants.\n\nKano's uncomfortable lesson: the features that differentiate you are precisely the ones customers will never request. If your roadmap is just a tally of stated wants, you are building a product with no delighters and, often, unexamined gaps in the basics.\n\n---\n\n## The Jobs-to-Be-Done Lens\n\nThe cleanest way to separate need from want is to ask what **job** the customer is \"hiring\" your product to do. Jobs-to-Be-Done reframes every feature request as evidence of a deeper goal:\n\n- Want: *\"I want dark mode.\"* → Possible job: *\"Help me use this late at night without eye strain.\"*\n- Want: *\"I want more export formats.\"* → Possible job: *\"Let me get my data into the tool my boss actually reviews.\"*\n- Want: *\"I want faster onboarding.\"* → Possible job: *\"Help me look competent to my team in week one.\"*\n\nOnce you know the job, you can evaluate whether the requested want is even the best way to do it — or whether a different, unrequested solution would serve the need far better. That is exactly the space where category-defining products are built.\n\n---\n\n## How to Uncover the Real Need Behind a Want\n\nYou cannot get to needs by asking \"what do you want?\" — that question only ever returns wants. Use these techniques instead:\n\n### 1. Ask about the last time, not the ideal future\nAnchor every conversation in a real, recent event: *\"Walk me through the last time you ran into this.\"* Past behavior reveals needs; hypothetical wishes reveal wants. This is the core discipline of the Mom Test.\n\n### 2. Ladder with \"why\"\nWhen a customer states a want, ask \"why\" (or \"what would that let you do?\") three to five times. Each answer moves up the ladder from feature → benefit → underlying need. The want \"add a bulk-upload button\" ladders to \"because I upload 200 files a week\" to \"because month-end close is a nightmare\" to the real need: *\"help me finish the close faster and with fewer errors.\"*\n\n### 3. Watch what people do, not just what they say\nObserve the workarounds. A spreadsheet someone maintains on the side, a manual copy-paste ritual, a sticky note on a monitor — these are needs made visible. People under-report the workarounds they have normalized, so behavior often reveals needs their words omit.\n\n### 4. Separate the ask from the outcome\nFor every request, capture two things: the want (what they asked for) and the outcome (what they are trying to achieve). Prioritize on the outcome. Multiple different wants often ladder to the same need — and solving the need once can retire a dozen feature requests.\n\n---\n\n## The Modern Approach: Uncovering Needs at Scale with AI\n\nLaddering to a real need takes skill and patience — the interviewer has to notice a want, resist taking it at face value, and probe another layer deeper. Doing that well across enough customers to trust the pattern has traditionally required a trained researcher and weeks of calls. Most teams do not have that, so they default to counting wants in a feedback tool.\n\nAI-native platforms like **Koji** change the economics. A Koji **AI-moderated interview** is built to ladder: when a participant states a want, the AI automatically asks *why*, *when was the last time*, and *what were you trying to get done* — the exact follow-ups that separate need from want — with every participant, over voice or text, in parallel.\n\n- **Adaptive probing at scale.** Instead of five interviews, you can run the same rigorous, need-seeking conversation with hundreds of customers and let the AI ladder each one to the underlying job. Teams using AI-assisted research report reaching insight in days rather than weeks.\n- **Structured questions to size the need.** Pair open-ended probing with `ranking` (which outcome matters most), `scale` (how painful is this today), and `single_choice` questions to quantify how widely a need is felt — not just how loudly one customer asked. See the [structured questions guide](/docs/structured-questions-guide).\n- **Automatic thematic analysis.** Koji clusters distinct wants that share an underlying need, so \"I want bulk upload,\" \"I want an API,\" and \"I want a Zapier integration\" surface together as one job: *get my data out faster*. That is the insight a roadmap can actually act on.\n\nWhile a legacy survey tool like SurveyMonkey can tabulate which features customers *say* they want, an AI-native platform like Koji is designed to reveal the need underneath — and it democratizes that skill so any PM or founder, not just a research specialist, can do it.\n\n---\n\n## Common Mistakes\n\n- **Treating the feature request as the requirement.** The request is a clue, not a spec. Ladder to the need first.\n- **Averaging wants into a Frankenstein product.** Ten customers wanting ten different features often share one need — build for the need, not the ten features.\n- **Ignoring basic needs because no one asks for them.** Reliability, speed, and trust are rarely requested and always required.\n- **Confusing loud with important.** The most vocal want is not necessarily the most widely felt need. Quantify before you prioritize.\n- **Asking customers to design the solution.** They are experts in their need, not in your product. Own the solution; let them own the problem.\n\n---\n\n## Related Resources\n\n- [Structured Questions Guide](/docs/structured-questions-guide) — the six question types that quantify how widely a need is felt\n- [Jobs-to-Be-Done Framework](/docs/jobs-to-be-done-framework) — the definitive lens for finding the job behind the want\n- [The Mom Test Methodology](/docs/mom-test-methodology) — how to talk to customers without triggering wants\n- [Customer Needs Analysis](/docs/customer-needs-analysis) — a full workflow for identifying and prioritizing needs\n- [Customer Pain Points Research](/docs/customer-pain-points-research) — surfacing the problems behind the requests\n- [Problem Validation Guide](/docs/problem-validation-guide) — confirming the need is real before you build\n- [Observational Research Guide](/docs/observational-research-guide) — reading needs from behavior, not words\n\nCustomers will always hand you wants. The teams that win are the ones who treat every want as a doorway to a deeper need — and who have the research muscle to walk through it at scale.","category":"Research Methods","lastModified":"2026-07-11T03:19:01.174549+00:00","metaTitle":"Customer Needs vs. Wants: How to Tell What Users Actually Need (2026) | Koji","metaDescription":"Customers ask for wants but buy to satisfy needs. Learn the difference between customer needs and wants, why building to stated wants causes feature bloat, and how to uncover the real need with Jobs-to-Be-Done, laddering, and AI research.","keywords":["customer needs vs wants","needs vs wants","customer needs and wants","difference between needs and wants","stated vs underlying needs","uncover customer needs","jobs to be done needs","customer wants","user needs analysis","kano model needs"],"aiSummary":"A customer need is the underlying goal or problem someone is trying to solve — stable, often unspoken, and the real reason they buy. A customer want is a specific requested solution or feature — a surface preference that is easy to state but frequently wrong about what will satisfy the need. Building directly to stated wants causes feature bloat, which is why 64-80% of shipped features are rarely or never used. The Kano Model shows that differentiating features (delighters) are the ones customers never ask for. Uncover real needs by anchoring in past behavior, laddering with why, observing workarounds, and applying Jobs-to-Be-Done. AI-moderated platforms like Koji automate the laddering that separates need from want across hundreds of customers.","aiPrerequisites":["Basic familiarity with product or customer research"],"aiLearningOutcomes":["Define the difference between customer needs and wants","Explain why building to stated wants causes feature bloat","Use the Kano Model to classify needs into basic, performance, and delighter types","Apply Jobs-to-Be-Done and laddering to uncover the need behind a request","Quantify and prioritize needs at scale with AI-moderated research"],"aiDifficulty":"beginner","aiEstimatedTime":"12 minutes"}],"pagination":{"total":1,"returned":1,"offset":0}}