Two ways to split a feature list into buckets. Kano sorts by how each feature affects user satisfaction. MoSCoW sorts by stakeholder priority within a fixed timebox.
Last updated: 2026-04-01
Developed in the 1980s by Professor Noriaki Kano. Each feature lands in one of five categories from a paired survey: must-be, performance, attractive, indifferent, or reverse. Data comes from users, not the team.
Best for product teams that want a research-backed view of what to build, drop, or invest more in.
Created in 1994 by Dai Clegg at Oracle and later adopted by DSDM. Items go into Must have, Should have, Could have, and Won't have (this time). The buckets reflect what the business needs to ship in a fixed timebox.
Best for release planning, sprint scoping, and stakeholder negotiations under a deadline.
Paired survey: "How would you feel if X were present?" + "How would you feel if X were absent?"The combination of answers maps each feature to one of the five categories. Aim for at least 100 responses per persona.
No formula. Place each item in one of the four buckets, given a fixed timeframe.Most teams cap Must have at around 60% of capacity so the rest of the buckets are real and the team has slack.
| Criteria | Kano | MoSCoW |
|---|---|---|
| Origin | Noriaki Kano, 1980s, Japan | Dai Clegg at Oracle, 1994 |
| Categories | Must-be, Performance, Attractive, Indifferent, Reverse | Must have, Should have, Could have, Won't have |
| Input source | User survey responses | Stakeholder and team judgment |
| Best fit | Strategy and feature investment decisions | Release planning under a fixed deadline |
| Time to apply | Days to weeks (survey + analysis) | One workshop session |
| Data needs | 100+ responses per persona | None beyond the team in the room |
| Output | Feature category assignment | Bucket placement against a timebox |
| Stability | Categories stable over a quarter or longer | Buckets reset each release |
Pros
Cons
Pros
Cons
Score your own data with both frameworks. Compare results and pick the one that fits your team.
Yes, and many teams do. Run Kano first to understand which features are must-be, performance, or attractive from a user's view. Use MoSCoW to bucket those into a release. Kano informs strategy. MoSCoW informs scope.
Not yet. PM Toolkit has a Kano model calculator that auto-classifies features from your survey responses. MoSCoW is a workshop technique without a formal calculation, so it doesn't need a tool.
Aim for at least 100 responses per persona. Below that, the boundary between performance and attractive features gets noisy. If you have multiple personas, you'll need 100 from each.
Because the bucket of things you explicitly aren't doing is more valuable than the list of things you might. Won't have for this release prevents the same items from creeping back into Must have a week later.
Neither, on its own. Pre-launch, you don't have users to survey for Kano, and your stakeholders are probably the founders. Use both later. Pre-launch, keep the backlog small enough that Impact/Effort or ICE is enough.