From rationing the build to navigating abundance: using Kano to position your product

A practical guide to the Kano model, Jobs-to-be-Done, and why structured judgement matters more — not less — as execution gets cheap.

Most feature debates are really arguments about taste dressed up as arguments about priority. Someone wants the shiny thing, someone wants the safe thing, and the loudest voice usually wins. The Kano model is a cheap, fast way to replace that argument with evidence about how users actually perceive a feature — not whether they'd use it, but how they'd feel with it and without it.

I've leaned on this at See-Mode, where we were building a medical imaging platform for radiologists and sonographers who were highly sceptical, time-poor expert users, and again at Atlassian. In both cases the value wasn't a tidy roadmap ranking. It was the conversations the survey forced — and, at See-Mode especially, the way it revealed that users who shared a job title were doing entirely different jobs, and that a feature one group would love another would resent. That's a positioning insight, and it's the part I'll spend the most time on.

This is a practical guide to running it, reading it, and — just as importantly — knowing where it stops being useful.

First, the framing problem Kano doesn't solve

Kano evaluates a solution. It tells you how people perceive a thing you're proposing to build. It says nothing about whether you're solving the right problem in the first place. That's the job of Jobs-to-be-Done.

The premise of JTBD, popularised by Clayton Christensen and developed in a more quantitative direction by Tony Ulwick and Bob Moesta, is that customers don't buy products — they hire them to make progress in a situation. The canonical example is Christensen's milkshake study: a fast-food chain tried to lift milkshake sales by improving flavour and texture based on customer surveys, and nothing moved. When researchers looked at when milkshakes sold, they found a large share went to solo commuters before 9am, who were hiring the milkshake to make a boring drive less dull, to occupy one hand, and to stave off hunger until lunch. The competition wasn't other milkshakes. It was bananas, bagels, and boredom.

The lesson generalises. If a customer asks you to mow their front lawn, the job isn't a shorter lawn. It might be presenting a respectable face to the neighbours. Understand that, and your solution space widens dramatically — a mowing service, yes, but also low-maintenance landscaping, artificial turf, or pouring concrete. Each is a legitimate way to get the same job done.

So the two frameworks sit at different altitudes:

• JTBD operates at the problem level. Why does the user want this? What progress are they trying to make? This is where positioning and differentiation are actually won or lost.
• Kano operates at the solution level. Given a candidate solution, how will users perceive each part of it?

You need the first to choose what to build. You use the second to pressure-test how a specific build will land. Run Kano without the JTBD framing and you'll optimise a solution to a problem nobody cares about — a beautifully prioritised milkshake that still loses to a banana.

The mechanics: a question pair per feature

For each feature you're considering, you ask two questions. This functional/dysfunctional pairing is the whole trick — it captures two dimensions that a single "how much do you want this?" rating collapses into one.

• Functional: "How would you feel if you had [feature]?"
• Dysfunctional: "How would you feel if you didn't have [feature]?"

Each is answered on the same five-point scale:

1. I like it
2. I expect it
3. I'm neutral
4. I can live with it
5. I dislike it

The dysfunctional question is the one people fumble. You're asking how they'd feel about the absence of the feature, so a positive feeling about absence ("I like not having it") is meaningful signal, not a contradiction.

Reading the pairs: the classification grid

Cross the two answers and each feature lands in a category. Here's the grid (functional answer down the side, dysfunctional across the top):

The categories, in plain terms:

• Table stakes (classically must-be): users expect it; its presence earns no credit, but its absence actively hurts. Like brakes on a car. (Functional "expect", dysfunctional "dislike".)
• Differentiators (classically performance or one-dimensional): more is better, less is worse, in a roughly linear way. Users like having it and dislike not having it. This is where you compete openly. (Functional "like", dysfunctional "dislike".)
• Delighters (classically attractive): unexpected upside. Users love it when present but don't miss it when absent. These create the "wow" and are the raw material of differentiation — but only until competitors copy them. (Functional "like", dysfunctional neutral-ish.)
• Anti-features (classically reverse): users actively don't want this. Building it makes the product worse for them. (Functional negative, dysfunctional positive.)
• Indifferent: users don't care either way. Don't spend money here.
• Question(able): a contradictory or confused answer (e.g. "like it" both ways), usually signalling a poorly worded question or a respondent who misread it. Treat as a data-quality flag, not a category.

A point worth internalising: categories decay over time. Today's delighter becomes tomorrow's differentiator and next year's table stake. In-car GPS, fingerprint unlock, same-day delivery — all started as delighters and are now expected. Re-run the survey periodically; a positioning built on a delighter has a shelf life.

Turning categories into strategy

The classification only earns its keep when it changes a decision. The default playbook:

• Build table stakes to "good enough," then stop. You won't win on these, and you can't afford to lose on them. Match the category norm with minimum viable effort and move on. Over-investing here is one of the most common ways teams waste roadmap.
• Avoid anti-features entirely. Easy to say, surprisingly easy to violate — these are often pet features championed internally that a segment of users genuinely dislikes. Kano gives you the evidence to kill them.
• Compete deliberately on differentiators. Decide where you want to be above the market line and resource it properly. This is conscious, expensive, and where head-to-head competition happens.
• Invest in delighters as your differentiation engine — selectively. A small number of well-chosen delighters is what makes a product feel distinct. But they're expensive to find, easy to copy, and decay fast, so treat them as a renewable bet rather than a one-off.

This is also where Kano connects back to positioning. Your differentiators and delighters are your positioning — they're the reasons a user picks you over the banana. Your table stakes are merely the cost of being in the category at all. If your candidate solution surfaces no differentiators or delighters, that's not a prioritisation problem; it's a signal that you may be building a commodity, and you should go back up to the JTBD level and reconsider the problem.

Same product, different desires: what the categories reveal about who you're building for

The single most useful thing Kano did for us at See-Mode wasn't ranking features. It was exposing that the same job title hid completely different jobs, that the same feature could be a delighter to one person and an intruder to another, and that the thing standing between us and adoption was sometimes not a feature at all but the sheer breadth of work the tool had to cover. All of these are positioning insights, not roadmap insights, and they're where the model quietly earns its keep.

Same role, different situation. Take a sonographer. At a public hospital, they're often working up extreme pathology and feeding their findings to surgeons — clinical accuracy is everything, and the worksheet is a vehicle for expressing complex pathology richly and precisely. A feature that lets them capture nuance in detail is a delighter. Now take a sonographer at a busy private radiology clinic, scanning hundreds of largely normal patients a day. Their job is throughput and craft under time pressure; the constraint is workflow. For them, rich free-form pathology expression is overhead, and what delights is transcription and pre-filled notes that clear the routine cases fast so they can spend attention where it's actually needed. Same role, same software, opposite categories — because the underlying job is set by the situation, not the job title. If you'd averaged those two populations together, you'd have built a muddy compromise that served neither, and you'd never have seen it in the data. This is why "segment before you average" isn't a survey hygiene tip. It's the difference between a product with a sharp position and one that's vaguely for everyone.

Same feature, different stakeholder — and the tension is the point. The second revelation was about roles in the buying and using chain, and here Kano surfaces something most prioritisation methods bury. The economic buyer — a vascular surgeon, a head of radiology — cares about clinical consistency: the criteria applied the same way, every time, without exception. To them, a feature that standardises and enforces clinical logic is close to a must-be. But the sonographer running the scan often sees themselves as an investigator. Creative problem-solving is the value they bring; their judgement and intuition is the craft. To that person, a tool that automates or replaces clinical reasoning isn't a delighter at all — it reads as an intruder, an anti-feature, a quiet statement that their expertise is fungible. The exact same capability lands as a must-be for the buyer and an anti-feature for the user.

Naively, that looks like an impossible product decision. It isn't — because the conflict isn't really about whether to build the feature. It's about how you frame it to each group. To the surgeon, it's consistency and defensibility. To the sonographer, the same capability has to be positioned as augmentation that handles the routine and surfaces what's worth their attention — a tool that amplifies their investigation rather than supplanting it. Kano is what makes that tension visible in the first place: when a feature splits hard across stakeholders, you've found not a build/kill decision but a messaging problem, and a place where the words you choose determine whether the product is adopted or resisted. That's positioning in the truest sense — the same thing, told differently to different people, because they're hiring it for different reasons and protecting different identities.

Sometimes the table stake is scope itself. Not every must-be is a small feature you can knock out cheaply. One of the hardest categories we ran into wasn't a feature at all — it was coverage. Sonography spans more than thirty distinct study types, and sonographers told us plainly that they didn't want a workflow tool that only served 5 or 10% of their work. The reason is structural: nobody reorganises how they work to accommodate a tool they can only use on a sliver of cases, because the cost of switching between two systems all day swamps the benefit on the slice. Broad coverage was therefore a table stake — its presence earns no applause, its absence is simply disqualifying — and it happened to be the single most expensive thing on the roadmap to satisfy. That combination is worth naming, because it breaks the comfortable assumption that table stakes are cheap hygiene and delighters are the expensive bets. Sometimes the most costly thing you must build is the one that wins you no credit at all.

Here's the part that's easy to get wrong, and where Kano and segmentation rescue each other. The instinct is to say a strong enough differentiator will overcome an unmet table stake. It won't, not directly — no delighter compensates for a tool the user can't actually adopt, because they never get far enough in to enjoy it. What a differentiator can do is buy you the right to ask for adoption while you build toward coverage. But the sharper move is to change the denominator. Coverage of every study type is a disqualifying fraction of a generalist's workload; coverage of vascular studies is a far larger share of a vascular sonographer's. The same coverage fact is an unmet table stake for one segment and a nearly-met one for another — so the answer to a scope gap is usually not "out-delight it" but "pick a beachhead where the gap is smallest," earn the position there, and expand.

This is the route we took at See-Mode: focus on vascular rather than try to boil the ocean of thirty-plus study types at once. But the honest part of the story is what it taught us about the threshold itself. Narrowing to vascular didn't make the coverage table stake disappear — it reasserted itself at finer grain. Even within vascular there were six or so further study types we didn't yet support, and for a sonographer those gaps still bit. The lesson isn't the comforting "find the segment where the problem vanishes." It's that a coverage threshold is recursive: choosing a beachhead shrinks the gap, but rarely closes it, and you'll meet the same must-be again one level down. So the real discipline is to pick the beachhead where the remaining gap is smallest and most defensible, be clear-eyed that you're not done, and keep closing it. A table stake like coverage isn't a wall you clear once. It's a floor you keep raising.

The general lesson: when Kano categories diverge across your respondents, don't rush to average them into a single verdict. The divergence is the finding. It tells you your market is segmented by situation or by role, and it tells you where you'll need different positioning, different defaults, or different language for each group. A clean, uniform category result is comfortable. A split one is more valuable.

Does any of this survive when execution is cheap?

Here's the obvious objection. Kano was born in a world where building was the bottleneck. You could ship maybe a handful of things a quarter, so the whole game was choosing — ranking a list you couldn't fully build. But if AI lets a small team stand up a working version of almost anything in an afternoon, why ration at all? Why not build a thousand solutions and let the market sort them out? Prioritisation-as-ranking starts to look like a relic.

It's the right question, and the lazy answer — "Kano is dead, just A/B test everything" — is wrong. Cheap execution doesn't retire the framework. It changes its job and, on balance, raises its value. Four reasons:

Cheap building makes discrimination scarce, not abundant. When everyone can ship a thousand features, table stakes commoditise overnight and any visible delighter gets cloned within the week. The half-life of differentiation collapses. So the bottleneck moves off the factory floor and onto a harder question: of the thousand things you could ship, which ones actually shift how a user perceives the product, versus which are noise they'll never notice? That's a discrimination problem, and the functional/dysfunctional split is a discrimination instrument. As building gets cheaper, the relative value of knowing what's worth having built goes up.

You can't A/B test your way to a delighter. Live experimentation measures behaviour on things users already encounter, which is great for the differentiator axis — more of what they already like. But a delighter is unexpected by definition. Users don't know to want it, won't go looking for it, and a behavioural metric on a feature nobody anticipated is weak signal. Worse, experimentation optimises toward local maxima and is structurally blind to the attractive-quadrant leap. No A/B test on milkshake flavours ever surfaces the insight that the milkshake is competing with boredom. That leap comes from understanding the job and asking the perception question directly — exactly what JTBD and Kano are for.

A thousand solutions to the wrong job is a thousand wrong solutions. Cheap execution doesn't fix a framing error — it amplifies it. Aim at the wrong problem and abundance just means you now build a thousand things nobody wants instead of three. Volume multiplies whatever direction you're pointed in, which makes the JTBD framing more load-bearing, not less. The discipline that decides which mountain to climb matters more precisely because climbing got cheap.

But the cheap thing to do is still to ask first. It's tempting to conclude that since building is now cheap, you should build the thousand things and run your perception checks afterward, on real features users have touched. I don't buy it, and the reason is a cost error. Kano never needed a built feature — the functional/dysfunctional question works on a described one: a sentence, a mock, a Figma frame. Asking was always cheap and still is. What "throw it at the wall and measure" actually costs isn't the build anymore; it's the things cheap execution doesn't make cheap — your own attention to evaluate a thousand shipped probes, the user goodwill you burn putting half-formed work in front of people, and the brand cost of shipping noise. So the trade is a cheap input (asking) against expensive ones (attention, goodwill, focus). Run Kano before and you point the cheap build engine at the few things worth making. That's the whole win: when execution is cheap, the constraint moves to focus, and asking-before-building is how you buy focus. The model earns its keep most by guiding the build, not auditing it.

There's one honest exception, and it's worth keeping rather than waving away. Stated perception of a genuine delighter is weak — people systematically under-predict their reaction to something they've never experienced, which is exactly what makes a delighter a delighter. So for that one quadrant, a light check after shipping a cheap prototype is a sensible backstop. The shape, then, is asymmetric: Kano-before to focus the build by default, and a cheap behavioural read after only to confirm the handful of delighter bets where asking alone can't be trusted. Before guides; after only verifies the unverifiable.

So the answer to "is it valuable when you can build a thousand solutions?" is: yes, and arguably more so — but its job changes from rationing the build to navigating the abundance. The scarce resources in an age of cheap execution are judgement and taste: knowing which job to serve, and knowing which few of the thousand things you could build are the ones worth pointing your cheap build engine at. Kano is a judgement instrument. It doesn't get less useful when the constraint moves from production to discernment — it moves with the constraint.

A pragmatic process

How I'd actually run it:

1. Start at the job, not the feature. Use qualitative interviews to understand the progress users are trying to make and where current solutions fall short. The features you take into a Kano survey should be hypotheses about serving that job better.
2. Write each feature as a single clear sentence. If a user can't picture it, the responses are noise. Pre-test the wording with a few people internally.
3. Keep the feature list short. Each feature is two questions; a long list produces survey fatigue and junk data toward the end.
4. Pair the survey with interviews. The categories tell you what; the conversation tells you why. The "why" is what actually informs the solution. This is the step most teams skip, and it's the most valuable one.
5. Mind your sample. For qualitative directional insight, even 12–24 of the right users can reveal clear patterns — Jan Moorman at projekt202 cites that range as a useful study size. For confident quantitative classification you'll want substantially more (100+), but don't let the pursuit of statistical rigour stop you running a small, sharp study that changes a decision this week.
6. Segment before you average. As above — a feature can be a delighter for one situation or role and indifferent, or an anti-feature, for another. The divergence is the finding; averaging it away destroys the most valuable signal in the study.

Where it breaks down

Kano is a lens, not an oracle. Be honest about its limits:

• It evaluates solutions, not problems. Worth repeating because it's the failure mode that costs the most. A well-run Kano study on the wrong feature set just helps you build the wrong thing more efficiently.
• It measures stated perception, not behaviour. People are unreliable narrators of their own future feelings, especially about features they've never used. Treat results as directional, and validate delighters with real usage where you can.
• It can't see what you didn't ask about. The survey only classifies features you thought to include. The breakthrough delighter — the thing that genuinely differentiates you — often isn't on the list, because if it were obvious you'd have built it. Kano won't generate that idea. Product taste and a deep grasp of the job will.
• Categories are unstable. As above — a snapshot, not a permanent truth.
• It quantifies feeling, not effort or value. A delighter that takes two years to build may be a worse bet than a differentiator you can ship next month. Always read Kano against a cost/effort axis, not in isolation.

The honest summary

Kano's real value isn't the 2x2 or the tidy category labels. It's a structured, low-cost way to quickly evaluate problem × solution fit and surface how users perceive a candidate solution — to separate the features that merely keep you in the game from the ones that actually distinguish you, and to do it with evidence rather than the loudest opinion in the room.

But it only works inside a clear understanding of the broader job your user is hiring you for, and it still demands taste to imagine a solution worth testing in the first place. JTBD tells you which mountain to climb. Kano helps you check your footing on the way up. Neither replaces the judgement of deciding it's the right mountain.

And as execution gets cheaper, that's the part that matters more. When anyone can build anything, the constraint stops being can we make it and becomes can we tell what's worth having made. Production was never the scarce thing for long. Discernment is. Frameworks like these don't lose their value in an age of abundance — they're how you keep your bearings in it.

Use it to test your instincts, not to outsource them.