第2章：案例背景全景 — 产品类型、团队规模、业务目标与用户痛点
任何产品需求分析与RICE优先级排序，都必须建立在清晰的案例背景之上。本章将围绕一个典型的中型企业SaaS产品案例，从产品类型、团队规模、业务目标和用户痛点四个维度展开全景描述，为后续章节的用户访谈、需求拆解和方案表达提供统一的上下文。
2.1 案例核心要素概览
本课程选用的案例产品为“SmartTask企业版”——面向中小团队的轻量级项目协作SaaS工具。产品类型定位为SaaS订阅型 + 协作工具，具有多租户、跨平台、按席位收费的特征。团队规模为12人产品研发团队（3名产品经理、6名后端/前端工程师、1名QA、1名设计师、1名运维兼数据）。业务目标：3个月内将月活跃用户留存率从35%提升至50%。用户痛点：老用户频繁流失，关键协作功能（如任务依赖、跨项目看板）缺失或体验劣化。
以下SVG图将上述四要素的结构关系以可视化方式呈现：
2.2 产品类型与需求特点
不同产品类型对应不同的需求分析颗粒度与RICE权重偏好。下表对比了常见产品类型在需求验证中的关键差异：
| 产品类型 | 需求来源特征 | RICE影响因子侧重 | 验证周期 |
|---|---|---|---|
| SaaS订阅工具 | 用户行为数据+客服反馈 | Reach（活跃用户量） | 周级A/B测试 |
| B2B企业服务 | 关键客户高管访谈 | Impact + Effort | 2-4周可用性测试 |
| C端消费应用 | 漏斗分析+App Store评分 | Confidence + Reach | 天级灰度实验 |
| 内部工具/平台 | 业务流程痛点+事故报告 | Effort + Impact | 单次迭代验证 |
💡 本节要点：案例中的SmartTask属于“SaaS订阅工具”，因此在后续RICE计算中，Reach（受影响用户数）将作为首要权重因子，而Impact的评估需结合客户流失风险。
2.3 团队规模对需求工作的约束
12人团队（含3名PM）意味着需求交付节奏为双周迭代，每个迭代可承载高优先级需求数量不超过3个（基于历史Velocity）。团队规模带来的两个关键实践要求：
- 需求筛选必须前置：产品经理需提前1～2个迭代完成需求验证与RICE评分，避免开发排期临时变更。
- 沟通成本控制：需求文档应精简（一页式PRD），所有用例用表格表达，减少口头传递偏差。
2.4 业务目标与用户痛点的映射关系
业务目标为“3个月MAU留存从35%提升至50%”，核心驱动力是解决老用户流失的最大原因：任务依赖功能缺失和跨项目看板操作卡顿。痛点与目标之间的定量映射如下：
| 用户痛点 | 影响留存占比（估算） | 对应改善动作 | 预计留存提升 |
|---|---|---|---|
| 任务依赖无法设置 | 42% | 上线任务依赖关系引擎 | +8% |
| 跨项目看板切换体验差 | 28% | 重构看板数据加载+缓存 | +5% |
| 通知与协作反馈延迟 | 18% | 优化WebSocket推送 | +3% |
| 其他（性能/UI等） | 12% | 持续优化 | +1% |
⚠️ 重要提示：以上留存影响占比为产品经理基于现有用户流失报告、竞品分析和客服工单关键词聚类得出的初步估算。该数据将在第4章“用户访谈”中通过真实用户反馈进行校准，并用于后续RICE评分中的Impact和Confidence字段计算。
2.5 实践要点
- 实践1：用四要素框架统一团队认知。在启动任何需求分析前，产品经理应组织一次15分钟的“案例背景对齐”会议，确保研发、设计、测试人员对产品类型、团队容量、业务目标和核心痛点形成共识，避免后续需求拆解时的上下文错位。
- 实践2：痛点影响占比必须量化。不要满足于“用户觉得不好用”等定性描述，应结合客服工单标签、行为日志统计（如功能点击频次、流失前最后操作）估算每个痛点对留存/转化率的权重，这是RICE中Impact值的重要依据。
- 实践3：团队规模直接决定需求交付节奏。12人团队双周迭代最多承载3个高优先级需求。因此在第5章“需求拆解”时，每个Feature必须拆成可独立上线的子需求，以满足迭代切刀要求。