Apply Kano and MoSCoW to a set of features and justify what to do now.
Kano and MoSCoW: from satisfaction to release scope
Classifying features and locking the scope
The Kano model, developed by Noriaki Kano, describes how features relate to user satisfaction. Must-be features (also called Basic or Expected) are table stakes: users do not notice them when present, but are strongly dissatisfied when they are absent — for example, a mobile app that does not crash. Performance features (One-dimensional) follow a linear rule: the more you deliver, the more satisfied users are — for example, page load speed or storage capacity. Attractive features (Delighters) surprise users when present and cause delight, but their absence creates no dissatisfaction — for example, an unexpected dark mode or a personalized greeting. Two additional categories exist: Indifferent (users do not care either way) and Reverse (some users dislike the feature). The practical implication: always fix Must-be issues first, then invest in Performance gains, and use Delighters to differentiate.
MoSCoW maps features to a specific release. Must-have: the release fails without it — a legal requirement, a core workflow, or a Must-be that is currently broken. Should-have: important and high-value, but the release still works without it; ship if there is time. Could-have: nice to have, low effort — include only if there is genuine slack. Won't-have (this time): explicitly out of scope for this release, but possibly reconsidered later. Naming what is out of scope is as important as naming what is in — it manages stakeholder expectations.
How the two models combine in practice: First apply Kano to understand which features are table stakes versus differentiators. Then use MoSCoW to schedule them into releases. A broken Must-be feature almost always becomes a Must-have for the next release. A Delighter with high RICE score might be a Should-have. A Performance feature close to 'good enough' becomes a Could-have. The combination gives you both a satisfaction rationale and a scheduling decision — the PM can explain both to engineering and to stakeholders.
Lesson notes
Classifying features and locking the scope
The Kano model, developed by Noriaki Kano, describes how features relate to user satisfaction. Must-be features (also called Basic or Expected) are table stakes: users do not notice them when present, but are strongly dissatisfied when they are absent — for example, a mobile app that does not crash. Performance features (One-dimensional) follow a linear rule: the more you deliver, the more satisfied users are — for example, page load speed or storage capacity. Attractive features (Delighters) surprise users when present and cause delight, but their absence creates no dissatisfaction — for example, an unexpected dark mode or a personalized greeting. Two additional categories exist: Indifferent (users do not care either way) and Reverse (some users dislike the feature). The practical implication: always fix Must-be issues first, then invest in Performance gains, and use Delighters to differentiate.
MoSCoW maps features to a specific release. Must-have: the release fails without it — a legal requirement, a core workflow, or a Must-be that is currently broken. Should-have: important and high-value, but the release still works without it; ship if there is time. Could-have: nice to have, low effort — include only if there is genuine slack. Won't-have (this time): explicitly out of scope for this release, but possibly reconsidered later. Naming what is out of scope is as important as naming what is in — it manages stakeholder expectations.
How the two models combine in practice: First apply Kano to understand which features are table stakes versus differentiators. Then use MoSCoW to schedule them into releases. A broken Must-be feature almost always becomes a Must-have for the next release. A Delighter with high RICE score might be a Should-have. A Performance feature close to 'good enough' becomes a Could-have. The combination gives you both a satisfaction rationale and a scheduling decision — the PM can explain both to engineering and to stakeholders.