第2章 适用场景识别：哪些项目/阶段适合使用KANO模型、哪些不适合、前置决策清单
1. 适用场景分析
KANO模型的核心价值在于从用户主观满意度出发对需求进行分类与优先级排序。以下四类项目/阶段特别适合引入KANO模型：
| 项目/阶段类型 | 典型示例 | 适用原因 |
|---|---|---|
| 新产品/新服务规划 | 智能家居APP从0到1的需求清单筛选 | 用户尚未验证，需区分基本型、期望型与兴奋型需求，避免资源浪费在“用户无感”的功能上 |
| 已有产品功能迭代优先级排序 | 电商平台“购物车凑单提醒” vs “订单修改” 排期冲突 | 存量功能已积累用户反馈，可通过KANO问卷量化满意度影响，指导版本节奏 |
| 用户体验专项优化 | 银行APP转账流程简化、账单可视化改版 | 优化类需求常处于“做得好无感、做不好投诉”的灰色地带，KANO能识别哪些是“基本型”底线，哪些是“兴奋型”亮点 |
| 多需求并行时的资源分配决策 | 季度22个需求并行，研发产能仅够支撑8个 | KANO结合矩阵可快速将需求归入四个象限，优先保障基本型、筛选高价值期望型、谨慎投入兴奋型 |
关键判断依据：但凡需求的结果直接影响终端用户的主观满意度，且团队有足够的用户样本开展调研，就可以优先考虑使用KANO模型。
2. 不适合场景分析
以下场景中KANO模型的信度与效度会大幅下降，建议改用其他优先级评估工具：
| 项目/阶段类型 | 典型示例 | 不适合原因 |
|---|---|---|
| 法律法规合规性需求 | GDPR隐私政策更新、金融监管报表上报 | 强制必须完成，不论用户满意度高低；KANO的“分类”在此无决策价值，直接用“必须清单”管理 |
| 技术实现方案选型 | 数据库迁移、API协议升级、微服务拆分 | 属于内部技术决策，终端用户无感知；KANO调研无法获得有效反馈，应使用技术评估矩阵 |
| 紧急缺陷修复 | 线上支付接口500错误、数据丢失修复 | 时间窗口极短且必须修复，无需分类；直接进入紧急处理通道 |
| 成本控制驱动型需求 | 服务器降配、CDN切换为低成本厂商 | 决策核心是ROI与风险，用户满意度只是其中一环，KANO单一维度不足以支撑 |
| 内部管理工具需求 | 工单系统权限升级、内部报表导出优化 | 用户为内部员工，满意度评价易受组织因素干扰；建议用“效率收益矩阵”替代 |
常见误区：不要因为KANO模型“有名”就盲目套用。遇到强制型、技术型、紧急型需求时，强行使用KANO不仅浪费时间，还会误导优先级排序。务必先经过本章第3节“前置决策清单”的过滤。
3. 前置决策清单
在决定是否使用KANO模型之前，必须逐项核对以下四项检查。四项全部通过，方可进入KANO问卷与矩阵流程；任意一项不通过，建议切换至其他评估方法。
| 序号 | 检查项 | 判断标准 | 通过/不通过 |
|---|---|---|---|
| 1 | 需求是否直接面向终端用户？ | 用户能清晰感知该功能的有无或好坏 | □ 通过 □ 不通过 |
| 2 | 需求是否涉及用户主观满意度？ | 用户对该需求的态度存在“满意/无所谓/不满意”的差异 | □ 通过 □ 不通过 |
| 3 | 是否有足够的用户样本进行调研？ | 样本量 ≥ 30（B2B场景可放宽至15），且覆盖目标用户画像 | □ 通过 □ 不通过 |
| 4 | 需求是否具有可量化的属性？ | 能转化为“有/无”“多/少”“快/慢”等可对比描述 | □ 通过 □ 不通过 |
操作建议：将上述四项清单制作为团队内部“KANO模型准入Checklist”，每次启动需求优先级评估前，由产品经理与需求分析师共同签字确认。建议在项目看板中增加“KANO适用性检查”列，未通过的需求直接路由到其他评估流程。
4. 前置条件
在进入KANO模型正式流程前，必须完成以下三项前置工作：
- 已完成用户画像定义 —— 至少明确目标用户的角色、使用场景、核心痛点，确保调研对象与画像一致。
- 具备用户调研渠道 —— 可触达目标用户的问卷系统、访谈邀约或内测社区已就绪。
- 有明确的需求列表 —— 待评估需求已形成结构化清单（含需求ID、描述、来源、提出时间），避免在调研过程中临时增删导致数据混乱。
5. 操作步骤
适用场景识别阶段共5步，按顺序执行：
- Step 1 需求来源分类
将待评估需求按来源打标：用户反馈 / 竞品分析 / 业务方提报 / 技术规划 / 合规要求。合规要求、技术规划类直接标记为“不适用KANO”。 - Step 2 前置决策清单核对
产品经理逐项填写第3节的四项检查表，任一“不通过”则终止KANO流程，转入其他评估通道。 - Step 3 用户可感知性评估
对通过清单的需求，由需求分析师判断：每个需求能否用一句话让用户理解“有这个功能 vs 没有这个功能”的区别。不能则退回补充说明或标记为不适用。 - Step 4 适用性确认并记录
在需求管理系统中将“KANO适用性”字段标记为“适用”或“不适用”，并填写决策理由。 - Step 5 输出适用需求清单
生成《KANO模型待评估需求清单》，作为下一章问卷设计的输入。
6. 输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 名称 | 《待评估需求原始清单》 | 《KANO模型适用需求清单》 |
| 格式 | Excel / 项目管理工具需求列表 | 结构化表格（含需求ID、描述、来源、适用性标记、决策理由） |
| 责任人 | 产品经理 / 需求分析师 | 产品经理审核、需求分析师归档 |
| 关键字段 | 需求ID、需求描述、提出方、提出日期、紧急程度 | 需求ID、适用性标记（适用/不适用）、决策理由、决策日期、决策人 |
7. 责任边界
| 角色 | 职责 | 免责边界 |
|---|---|---|
| 产品经理 | 发起前置决策清单核对；确认需求是否面向终端用户；签字确认适用性结论 | 不负责问卷编写与用户邀约（由需求分析师与用户研究团队承接） |
| 需求分析师 | 执行Step 1~Step 5全流程操作；维护《KANO模型适用需求清单》；记录决策理由 | 不负责最终优先级排期决策（由产品经理与研发负责人共同决定） |
| 用户研究团队 | 验证是否有足够用户样本；提供调研渠道支持 | 不负责需求筛选与适用性判断 |
8. 记录材料
本章需归档以下两份记录：
- 《KANO模型前置决策清单核对表》 —— 每项需求一行，包含四项检查结果、最终结论、决策人签名、日期。
- 《KANO模型适用需求清单》 —— 通过适用性检查的需求清单，作为下一章的正式输入。
模板建议：在项目管理工具（如Confluence、Notion）中创建“KANO模型需求评估”页面，内嵌决策清单表格和适用需求清单，每次迭代更新一个版本，保留历史记录。
9. 异常处理
| 异常场景 | 表现 | 处理措施 |
|---|---|---|
| 需求描述模糊，无法判断用户可感知性 | 需求描述使用大量技术术语，难以转化为用户语言 | 退回需求提出方，要求补充“用户视角的一句话描述”；必要时由需求分析师代为重构并确认 |
| 前置决策清单中第3项“用户样本不足” | 目标用户群体极小（如B2B定制化场景），可调研样本 < 15 | 转为“深度访谈+定性KANO”模式，降低样本量要求至5~8人，但需在结论中标注“定性结论，仅供参考” |
| 需求同时包含用户侧和技术侧属性 | 例如“数据库迁移同时优化查询速度”，用户能感知速度变化 | 拆分为独立需求项：技术方案选型部分走技术评估矩阵，用户感知部分进入KANO流程 |
| 团队首次使用KANO模型，误判频繁 | 大量需求被误判为“不适用”，或不适用的需求被放入KANO流程 | 组织30分钟“KANO适用性校准会”，由有经验的产品负责人带领团队逐条过检，形成团队共识 |
10. 验收标准
本章工作完成以下四项验收即视为合格：
- 前置决策清单完成率100% —— 所有待评估需求均经过四项检查核对，无遗漏。
- 适用性标记准确率 ≥ 90% —— 随机抽取20%需求由独立评审人复核，标记错误率不超过10%。
- 输出物完整归档 —— 《KANO模型前置决策清单核对表》与《KANO模型适用需求清单》均已上传至指定知识库，格式符合模板要求。
- 责任边界清晰 —— 每项需求的决策人、决策日期、决策理由字段均填写完整，可追溯。