1. KANO 模型基础：五种需求类型的定义与特征
KANO 模型由东京理工大学教授狩野纪昭（Noriaki Kano）在 1980 年代提出，它从根本上改变了产品经理对“用户满意度”与“功能实现程度”之间关系的认知。在数据产品领域，团队资源有限，用户需求多样，使用 KANO 模型可以有效区分需求的优先级，避免在用户无感的功能上浪费时间，同时确保核心体验不出问题。
1.1 五个需求类型的核心定义
KANO 将需求划分为五类。下面的表格汇总了每个类型的定义、数据产品场景案例以及用户访谈中的典型信号。
| 需求类型 | 定义特征 | 数据产品场景举例 | 用户访谈信号 |
|---|---|---|---|
| 基本型 (Must-be) | 理所当然存在。不满足则极度不满，满足也不会提升满意度。 | 报表数据必须准确无误；系统不能频繁崩溃。 | 用户反复抱怨稳定性或准确性，认为“这是最基本的”。 |
| 期望型 (Performance) | 用户明确想要的。实现越多、越好，满意度线性提升。 | 查询响应速度更快；图表交互更丰富（钻取、联动）。 | 直接提出：“我希望能够……”、“速度需要更快”。 |
| 兴奋型 (Excitement) | 超越用户预期。没提供用户不介意，提供了会非常惊喜。 | 智能异常归因分析；自然语言查询（NL2SQL）。 | 用户看到后表现出惊讶：“哇，这个功能太棒了”。 |
| 无差异型 (Indifferent) | 提供或不提供都对满意度无影响。 | 数据详情页的“导出为 XPS 格式”按钮。 | 用户点头说“都可以”，或直接忽略该功能。 |
| 反向型 (Reverse) | 提供后反而导致满意度下降。 | 强制使用 AI 自动合并异常数据，分析师无法查看原始脏数据。 | 用户明确反对：“不要这样，这会干扰我的工作流”。 |
业务问题映射：在数据产品中，最常见的问题是团队把大量时间花在“期望型”需求的优化上（如增加图表配色），而忽略了“基本型”稳定性问题，导致用户整体满意度始终在低位徘徊。优先级判断失误的根源往往在于缺乏分类意识。
1.2 KANO 用户满意度二维矩阵
下图展示了 KANO 模型的核心分类矩阵。横轴代表“功能实现程度”（从左到右逐渐充分），纵轴代表“用户满意度”（从下到上逐渐满意）。每种曲线代表一类需求的走势。
内容化表达提示：在撰写产品需求文档（PRD）时，可以将每个需求卡片打上 KANO 标签。例如，在用户故事（User Story）的标题后加后缀 [Must-be] 或 [Exciting]，以便团队快速对齐优先级。
1.3 用户访谈：如何通过对话识别需求属性
KANO 模型有一套标准化的问卷方法，通过正向和反向两个问题来判断需求归属。在数据产品的用户访谈中，可以通过以下几个典型对话捕捉线索：
- 基本型识别：用户说“我要是在系统里查不到数据，那我肯定要找你们麻烦”。这表明“数据可查”是必须满足的硬性要求。
- 期望型识别：用户说“现在查询要等 20 秒，如果能降到 5 秒以内就太好了”。这属于明确的性能提升要求。
- 兴奋型识别：用户说“我从来没有想过这个报表还能自动做归因分析，太方便了”。这说明该功能超出了用户的预期。
- 无差异型识别：用户说“这个报表的配色怎么改都行，我无所谓，能看清数字就行”。这表明美观性在目前阶段不是关键。
- 反向型识别：用户说“别给我自动生成结论，每次都把我的分析逻辑打乱”。这表明自动化功能在特定场景下干扰了工作流。
需求拆解避坑：不要凭直觉给需求贴标签。比如“数据及时性”常常被当作期望型需求，但在强时效性的业务场景（如实时风控）中，它实际上是一个基本型需求，延迟 5 分钟就会导致业务停摆。必须结合具体业务上下文来判断。
1.4 方案表达与指标验证
针对不同类型的需求，验收标准和验证指标需要差异化定义。下表给出了在设计交付物时的模板参考：
| 需求类型 | 验收标准范例 | 核心指标 | 数据来源 |
|---|---|---|---|
| 基本型 | 系统可用性 ≥ 99.9%；数据延迟 ≤ 10 分钟；数据正确率 100%。 | MTBF（平均无故障时间） | 运维监控、数据质量报告 |
| 期望型 | 页面加载时间 ≤ 2 秒；查询响应时间 ≤ 5 秒；图表钻取层级 ≥ 3 层。 | P50/P95 响应时间、用户任务完成率 | APM、用户行为日志（埋点） |
| 兴奋型 | 智能洞察推送覆盖率 ≥ 80%；用户主动点击率 ≥ 15%。 | 功能发现率、NPS（净推荐值）提升幅度 | A/B 测试、用户调研问卷 |
| 无差异型 | 该功能用户使用率 < 5%，且移除后 NPS 无变化。 | 功能使用频次、满意度前后对比 | 用户行为日志、对照实验 |
| 反向型 | 用户投诉率下降；功能关闭率 < 5%。 | 负反馈率、功能关闭申请单数 | 客服工单、用户反馈中心 |
1.5 交付物模板：KANO 需求分类清单
作为产品经理，在收集需求后，可以使用下面的结构化模板进行归档。这份清单可以直接作为 PRD 的附录交付给开发和测试团队。
【KANO 需求分类清单】
项目版本：v2.4.1
模板填充人：数据PM 张三
更新日期：2025-04-05
1. 基本型需求
- [PB-001] 日历周期查询：用户必须能选择自然周、月和季度。
- [PB-002] 数据导出稳定性：导出超过 10 万行数据时系统不能崩溃。
2. 期望型需求
- [PF-001] 交叉筛选：支持维度值拖拽到图表区域进行过滤。
- [PF-002] 自定义指标计算：支持用户输入简单的公式（SUM/AVG）生成衍生指标。
3. 兴奋型需求
- [EX-001] 智能预警推送：基于数据波动自动生成“涨跌归因”的卡片消息推送到 IM 工具。
4. 无差异需求
- [ID-001] 主题色切换（深色/浅色模式）- 当前版本无差异可能性大，需上线后观测数据。
5. 反向需求（已驳回/下架）
- [RV-001] 强制统一数值格式：业务方要求所有数据保留两位小数，经评估与实际业务单位不一致，已发起否决。
通过以上结构化的分类、访谈技巧、指标验证和交付物模板，团队可以在需求评审阶段就排除掉无差异型和反向型需求，优先锁定基本型作为“必须交付线”，再根据资源情况决定期望型和兴奋型的投入占比。