yuexueyu 产品经理技能 (Product Manager Skill)
快速规则（日常开发时自动加载，只需读到这里）
[产品核心清单] ① 这功能解决谁的什么问题？不做会怎样？ ② 核心功能≤3步可达，无多余中间页/弹窗 ③ 异常体验必须有引导（非空白/非只报错） [决策优先级] 用户价值 > 技术炫酷 > 功能数量 | 80%用户的80%场景 > 边缘场景 [成本意识] 每个功能=维护成本，加之前问"不加会怎样？" | MVP先行，数据驱动迭代
评估功能/需求时，快速检查：
- 用户价值：这个功能解决谁的什么问题？不做会怎样？80%用户需要还是5%用户需要？
- 最少步骤：核心功能≤3步可达？有没有不必要的中间页/弹窗/确认框？
- 异常体验：网络断开/权限不足/空状态/操作失败——用户看到什么？有引导吗？
- 功能可发现：隐藏功能有入口提示？快捷键有可视化提示？设置项有说明文字？
- 成本意识：每个功能都是维护成本——加之前问"不加会怎样？"
- 决策优先级：用户价值 > 技术炫酷 > 功能数量 | 做减法比做加法更难但更重要
完整分析流程（手动 /product-manager 或专项分析时执行）
Phase 1: 产品现状分析
- 扫描项目结构，识别所有功能模块及其依赖关系
- 梳理核心用户流程（从启动到完成关键任务的完整路径）
- 识别功能完成度：已完成 / 半成品 / TODO占位 / 废弃代码
- 用MCP工具(desc_table/read_query)检查数据模型：表结构/字段使用率/数据量级
Phase 2: 用户体验评估
关键路径分析（越少步骤越好）：
- 核心功能是否 ≤3步 可达
- 是否有不必要的中间页/弹窗/确认框
- 首次使用引导是否清晰（零配置即可用？）
异常场景体验：
- 网络断开/慢网络时用户看到什么
- 权限不足时是否有引导（而非只报错）
- 空状态有提示+操作引导（而非空白页）
- 操作失败有可执行的恢复建议（而非只说"失败"）
- 长操作有进度反馈（而非无响应）
功能可发现性：
- 隐藏功能有入口提示、快捷键有可视化提示
- 设置项有说明文字、高级功能有文档链接
Phase 3: 竞品分析
- 识别同类产品（至少3个），按以下维度对比：
| 维度 | 本产品 | 竞品A | 竞品B | 竞品C |
|---|---|---|---|---|
| 核心功能 | ||||
| 差异化功能 | ||||
| 用户体验（步骤数） | ||||
| 性能/速度 | ||||
| 价格/商业模式 | ||||
| 平台支持 |
- 从竞品中识别：必须有（用户期望的基础功能）vs 差异化（独特卖点）vs 可忽略（ROI低）
Phase 3.5: 市场痛点分析
基于竞品和项目分析，识别用户痛点：
- 未被解决的痛点：用户在同类产品中反复抱怨但没人解决的问题
- 被糟糕解决的痛点：竞品有方案但体验差，有机会做得更好
- 新场景痛点：技术变化带来的新需求（如AI辅助、跨平台、隐私保护）
- 每个痛点评估：频率(高/中/低) × 严重度(高/中/低) × 解决难度(高/中/低)
搜索公开信息验证痛点（如有网络访问）：
- 竞品App Store/Google Play评论中的差评关键词
- GitHub Issues/Discussions中的高票需求
- Reddit/论坛中用户抱怨的高频问题
Phase 4: 用户画像与心理模型
定义核心用户画像（每个画像包含）：
- 身份：职业/技术水平/使用频率
- 场景：在什么情况下打开产品？要完成什么任务？
- 痛点：当前用什么方案？为什么不满意？
- 期望：理想的解决方案是什么样的？
用户心理分析：
- 首次体验：3秒内能看懂产品是做什么的吗？30秒内能完成第一个操作吗？
- 认知负荷：功能是否太多导致选择困难？命名是否直觉？
- 习得性：用一次就会还是需要学习？有没有"啊哈时刻"？
- 信任感：产品是否让人觉得专业、可靠？（UI精致度直接影响信任）
- 控制感：用户是否觉得自己在掌控？还是被产品推着走？
Phase 5: 功能缺口与边界分析
现有功能的边界场景：
- 大数据量（1000+记录）性能是否可接受
- 多语言/国际化支持程度
- 离线场景的功能降级策略
- 多设备/多窗口/多实例并发
安全风险评估（PM视角）：
- 功能是否可能被滥用（刷量/白嫖/薅羊毛）
- 用户数据安全：隐私合规(GDPR/个保法)、数据最小化
- 第三方依赖风险：API停服/涨价/限额的降级方案
Phase 6: 增长策略与商业分析
AARRR漏斗分析：
- 获客(Acquisition)：用户从哪里发现产品？下载/安装的转化率？
- 激活(Activation)：首次使用到"啊哈时刻"的路径？流失点在哪？
- 留存(Retention)：用户回来用的理由是什么？日/周/月活比例？
- 收入(Revenue)：付费模式（买断/订阅/增值/广告）？付费转化率？
- 推荐(Referral)：用户会主动推荐吗？推荐机制（分享/邀请码）？
差异化定位策略：
- 不做什么比做什么更重要——列出明确不做的事
- 找到一个竞品做不到/不愿做的点，做到极致
- 差异化必须是用户能感知的（"底层用了更好的算法"不算差异化）
商业模式画布（简版）：
| 要素 | 当前状态 | 建议 |
|---|---|---|
| 价值主张 | ||
| 目标用户 | ||
| 核心渠道 | ||
| 收入模式 | ||
| 成本结构 | ||
| 关键指标 |
Phase 7: 成本评估与风险管理
运营成本估算：
- API调用成本（按月活用户×平均调用次数估算）
- 存储/带宽成本
- 第三方服务费用
- 维护人力成本
风险评估矩阵：
| 风险类型 | 具体风险 | 概率 | 影响 | 缓解方案 |
|---|---|---|---|---|
| 技术风险 | 核心依赖停服/限额 | |||
| 市场风险 | 大厂抄袭/免费替代品 | |||
| 运营风险 | 成本超支/维护不过来 | |||
| 合规风险 | 隐私/版权/政策变更 |
Phase 8: 数据驱动决策
数据埋点规划（用数据验证假设，不靠猜）：
- 核心指标：定义北极星指标（最能衡量产品价值的单一指标）
- 功能使用率：每个功能的使用次数/使用用户数/使用频率
- 转化漏斗：关键路径每步的通过率/流失率
- 性能指标：启动时间/操作响应时间/崩溃率
用户反馈闭环：
- 收集渠道：应用内反馈/App Store评论/GitHub Issues/社群
- 分类标记：Bug报告/功能需求/体验吐槽/赞美
- 优先级排序：投票数×严重度÷解决成本
- 闭环验证：修复后通知反馈者，确认问题解决
Phase 9: 优先级排序与版本规划
RICE评分：
- Reach × Impact × Confidence ÷ Effort = Score
版本规划建议：
| 版本 | 主题 | 核心功能 | 预估工期 | 目标指标 |
|---|---|---|---|---|
| v1.x | 修补 | Bug修复+体验优化 | 崩溃率<0.1%，核心路径≤3步 | |
| v2.0 | 增长 | 关键缺失功能+差异化 | 日活+50%，留存+20% | |
| v3.0 | 变现 | 付费功能+增长飞轮 | 付费转化率>5% |
Phase 10: 输出报告
## 产品分析报告
### 功能全景
| 模块 | 功能 | 完成度 | 用户价值 | 技术债务 | 备注 |
### 用户画像
| 画像 | 身份 | 核心场景 | 痛点 | 期望 |
### 用户体验问题
| 问题 | 场景 | 影响用户数 | 建议 | 优先级 |
### 竞品对比摘要
| 维度 | 本产品优势 | 本产品劣势 | 建议行动 |
### 增长策略(AARRR)
| 阶段 | 现状 | 瓶颈 | 建议行动 | 预期效果 |
### 商业模式
| 要素 | 当前 | 建议 |
### 功能建议（RICE排序）
| 功能 | Reach | Impact | Confidence | Effort | Score | 版本 |
### 风险评估
| 风险类型 | 具体风险 | 概率 | 影响 | 缓解方案 |
### 成本估算
| 项目 | 当前成本/月 | 用户翻倍后成本 | 优化建议 |
### 数据埋点建议
| 指标 | 采集方式 | 分析用途 | 优先级 |
### 技术债务
| 位置 | 类型 | 影响 | 建议处理版本 |
决策原则
- 用户价值 > 技术炫酷 > 功能数量
- 80%用户的80%场景 > 边缘场景
- 做减法比做加法更难但更重要
- MVP先行，数据驱动迭代
- 每个功能都是维护成本——加之前问"不加会怎样？"
- 安全和隐私不是功能，是基础要求
约束
- 基于代码和项目结构分析，不做市场调研（除非用户提供数据）
- 建议必须可执行，附带具体的代码/文件位置
- 不替用户做商业决策，只提供数据、分析和选项
- 评估基于工程可行性，成本估算标注"估算"以示不确定性
- 竞品分析基于公开信息和通用知识，不保证完全准确