1. KANO模型核心概念：五类需求的定义与区分
适用场景
- 产品团队需要从大量用户反馈中筛选出高优先级功能时
- 功能清单已存在，但无法决定先做哪些、推迟哪些、放弃哪些时
- 希望识别能带来用户惊喜的低成本亮点功能时
- 需要与干系人（老板、开发、运营）对齐需求排序标准时
前置条件
- 已完成至少一轮用户访谈或调研，收集到原始功能需求列表。
- 团队成员（至少产品经理 + 设计师 + 核心开发）了解KANO模型的基本分类原则。
- 准备一份包含正反双向问题的KANO问卷模板（详见后续章节）。
操作步骤（概念理解部分）
- 定义基本型需求（Must-Be）：用户认为理所当然必须具备的功能。不提供则强烈不满；提供则用户不会特别满意（因为“本该如此”）。
- 定义期望型需求（One-Dimensional）：用户明确期望的功能。提供越多/越好，满意度线性上升；不提供则满意度下降。
- 定义兴奋型需求（Attractive）：用户从未想过但提供后会带来惊喜的功能。不提供不会不满；提供则满意度大幅提升。
- 定义无差异需求（Indifferent）：不论是否提供，用户感受无明显变化。
- 定义反向需求（Reverse）：用户不想要的功能。提供后满意度下降；不提供则满意度维持或上升。
核心口诀：
基本＝没它不行，在意但不说感谢；
期望＝给得越多越满意，不给就扣分；
兴奋＝没想到，但给了就加惊喜分，不给不扣分；
无差异＝给不给无所谓；
反向＝给了反而不爽。
输入输出物
| 输入 | 输出 |
|---|---|
| 未分类的功能列表（如：用户反馈、竞品分析、脑暴清单） | 五类需求分类对照表（每个功能一个分类） |
| KANO分类评估矩阵（二维表格） | 每个功能的分类结果（M / O / A / I / R） |
责任边界
- 产品经理：组织概念培训，确保团队理解五类定义的差异；主导分类结果的评审。
- 设计师/用户研究员：提供用户语境案例，协助识别兴奋型与反向需求。
- 开发代表：从技术实现角度确认某些分类是否合理（如“全量实时同步”可能本就是基本要求）。
- 不可推卸：需求分类决策权归产品经理，但必须基于真实问卷数据，而非主观臆断。
记录材料
课程配套记录表格示例（仅展示概念版，完整表格将在第5章问卷设计时给出）：
| 功能名称 | 正向问题（满足时）| 反向问题（不满足时）| 分类代码 | 分类说明 |
|-----------|-------------------|---------------------|----------|------------------------|
| 登录 | 您感觉如何？ | 您感觉如何？ | M | 基本型：必须存在 |
| 深色调主题| 您感觉如何？ | 您感觉如何？ | O | 期望型：越多越好 |
| 全屏震动 | 您感觉如何？ | 您感觉如何？ | A | 兴奋型：意外惊喜 |
| 悬浮按钮 | 您感觉如何？ | 您感觉如何？ | I | 无差异：没啥感觉 |
| 强制广告 | 您感觉如何？ | 您感觉如何？ | R | 反向：不给更好 |异常处理
- 边界模糊：某个功能同时符合基本型和期望型特征时，优先归类为基本型（安全第一），并标注争议，后续通过问卷数据校准。
- 团队分歧：组织简短的“分类辩论会”，每人必须用用户视角而非个人偏好论证，不能达成一致时留为待定项，放入后续问卷中测试。
- 反向需求误判：若某功能在问卷中显示出“反效果”，不要直接删除，先检查问卷措辞是否带有诱导性。
验收标准
- 团队成员能独立区分5类需求，并各举一个与自身产品相关的实例。
- 没有功能被错标为“基本型”却实际无人关注（可通过小范围访谈交叉验证）。
- 所有分类结果记录在统一格式的需求分类表中，备后续问卷设计使用。