@umacloud/knowledge 1.0.1

package/product/06-glossary/product-glossary.md

@@ -0,0 +1,462 @@
+---
+id: product-glossary
+title: 产品管理术语表 (Product Management Glossary)
+domain: product
+category: 06-glossary
+difficulty: intermediate
+tags: [agent, checklist, glossary, product, 产品策略与方法论, 增长与商业指标, 数据分析方法, 用户研究与设计]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 产品管理术语表 (Product Management Glossary)
+
+> 收录 50+ 核心产品管理术语，覆盖产品策略、增长指标、用户研究、开发流程、数据分析等领域。
+> 适用于 PRD 编写、团队沟通、产品评审、面试准备等场景。
+
+---
+
+## 产品策略与方法论
+
+### MVP (Minimum Viable Product)
+
+最小可行产品。用最少的功能验证核心价值假设的产品版本。
+
+目的不是做一个简陋的产品，而是用最小投入回答关键问题："用户是否需要这个解决方案？"成功的 MVP 聚焦一个核心场景，做到"刚好够用"。
+
+常见误区：
+- 把 MVP 等同于 Demo 或 Alpha 版
+- 功能太多，失去"最小"的意义
+- 功能太少，无法验证核心假设
+- 只做前端原型不做后端，无法验证完整流程
+
+### PMF (Product-Market Fit)
+
+产品市场匹配。产品真正满足了目标市场需求的状态。
+
+判断标准：
+- **Sean Ellis 测试**：>= 40% 用户表示"如果不能再使用会非常失望"
+- **自然增长**：用户主动推荐，获客成本下降
+- **留存曲线趋平**：长期留存稳定在一定水平
+- **需求拉动**：用户主动要求更多功能
+
+达到 PMF 之前应聚焦验证和迭代，之后才投入大规模增长。在 PMF 前烧钱做增长是最常见的创业死因。
+
+### North Star Metric (北极星指标)
+
+最能反映产品核心价值的单一指标。好的北极星指标同时反映用户价值和商业价值。
+
+经典示例：
+- **Airbnb**：预订间夜数（Nights Booked）
+- **Spotify**：总收听时长（Time Spent Listening）
+- **Slack**：每周发送消息的团队数
+- **Facebook**：日活跃用户数（DAU）
+
+团队用它对齐优先级，避免指标过多导致失焦。北极星指标不是唯一指标，而是最重要的方向指引。
+
+### Product Vision (产品愿景)
+
+描述产品在 3-5 年后希望达到的理想状态。不是功能列表，而是用户价值和市场定位的描绘。
+
+常用格式："为 [目标用户]，解决 [核心问题]，通过 [独特方式]，区别于 [竞品]，最终实现 [理想状态]"。
+
+好的愿景应该：激励人心、方向清晰、可被所有团队成员理解和复述。是所有产品决策的方向指引。
+
+### Product Strategy (产品策略)
+
+连接产品愿景和执行的中间层。回答"为了实现愿景，现阶段应该聚焦什么"。
+
+包含：
+- 目标市场选择（先打哪个市场）
+- 竞争策略（差异化 / 成本领先 / 聚焦）
+- 关键赌注（Bet）和阶段性目标
+- 不做什么（同样重要）
+
+策略错了，执行再好也到不了目的地。
+
+### Jobs To Be Done / JTBD (待完成的工作)
+
+Clayton Christensen 提出的需求分析框架。核心洞察：用户不是"购买产品"，而是"雇佣产品来完成某项工作"。
+
+分析维度：
+- **功能性**：完成什么任务（"帮我从 A 到 B"）
+- **情感性**：获得什么感受（"让我感到安心"）
+- **社会性**：展现什么形象（"让别人觉得我有品味"）
+
+经典案例：人们买电钻不是要电钻，是要墙上的洞。更深层：人们要的是挂上全家福照片的温馨感。
+
+### Lean Startup (精益创业)
+
+Eric Ries 提出的创业方法论。核心循环：
+
+1. **Build**：构建假设并制作 MVP
+2. **Measure**：收集用户行为数据
+3. **Learn**：验证或推翻假设
+
+强调快速迭代、数据驱动决策、避免浪费。关键概念：验证性学习（Validated Learning）、转型（Pivot）、持续部署。适用于高不确定性的新产品/新市场。
+
+---
+
+## 增长与商业指标
+
+### AARRR (Acquisition, Activation, Retention, Revenue, Referral)
+
+Dave McClure 提出的海盗指标模型（Pirate Metrics）：
+
+1. **获取 (Acquisition)**：用户从哪来？渠道效率如何？
+2. **激活 (Activation)**：首次体验是否成功？Aha Moment 到达率？
+3. **留存 (Retention)**：用户是否持续回来？
+4. **变现 (Revenue)**：用户是否付费？ARPU 是多少？
+5. **推荐 (Referral)**：用户是否传播？病毒系数（K-factor）是多少？
+
+是增长分析和漏斗优化的基础框架。每个环节都有对应的优化策略。
+
+### OKR (Objectives and Key Results)
+
+目标与关键结果。由 Intel 发明、Google 推广的目标管理框架：
+
+- **Objective**：定性的方向（激励人心、有挑战性）
+- **Key Results**：定量的衡量标准（可测量、有时限、3-5 个）
+
+与 KPI 的区别：OKR 鼓励设置有挑战的目标（60-70% 完成即可），KPI 通常要求 100% 完成。OKR 不与绩效考核直接挂钩。
+
+示例：
+- O：成为最受用户信赖的在线学习平台
+- KR1：NPS 从 45 提升到 60
+- KR2：课程完成率从 30% 提升到 50%
+- KR3：付费续订率从 65% 提升到 80%
+
+### A/B Test (A/B 测试)
+
+将用户随机分为两组，分别展示版本 A（对照组）和版本 B（实验组），通过统计方法比较哪个版本的目标指标更好。
+
+关键要素：
+- 足够大的样本量（使用统计功效分析计算）
+- 单一变量控制（每次只测一个变化）
+- 统计显著性（p < 0.05）
+- 足够的实验时长（覆盖完整的用户周期）
+
+避免"peek 问题"：中途看数据就下结论，导致假阳性。
+
+### DAU (Daily Active Users)
+
+日活跃用户数。一天内至少有一次有效交互的独立用户数。
+
+"有效交互"的定义因产品而异：
+- 社交产品：发送消息或浏览动态
+- 电商产品：浏览商品或搜索
+- SaaS 产品：使用核心功能
+
+是衡量产品活跃度的核心指标之一。DAU 的同比/环比变化反映产品健康度。
+
+### MAU (Monthly Active Users)
+
+月活跃用户数。一个月内至少有一次有效交互的独立用户数。
+
+DAU/MAU 比率（Stickiness，粘性指数）的参考标准：
+- **> 50%**：极高粘性（微信、WhatsApp 级别）
+- **20-30%**：一般水平（大多数 SaaS 产品）
+- **< 10%**：需要警惕，用户可能不够活跃
+
+### Retention (留存率)
+
+用户在首次使用后，在后续特定时间点仍然活跃的比例：
+
+- **次日留存 (Day 1)**：> 40% 为社交/游戏产品的健康线
+- **7 日留存 (Day 7)**：> 20% 为多数产品的健康线
+- **30 日留存 (Day 30)**：> 10% 为多数产品的健康线
+
+留存曲线应在某个时间点趋平（稳定留存），否则说明产品缺乏长期价值。用同期群分析（Cohort Analysis）追踪不同批次用户的留存表现。
+
+### Churn Rate (流失率)
+
+在特定时间段内停止使用产品的用户比例。Churn = 1 - Retention。
+
+SaaS 产品参考标准：
+- 月流失率 < 3%：优秀
+- 月流失率 3-5%：健康
+- 月流失率 5-10%：需要关注
+- 月流失率 > 10%：需要紧急干预
+
+降低流失率比获取新用户的 ROI 通常更高（获客成本是留存成本的 5-7 倍）。
+
+### LTV (Lifetime Value / 客户生命周期价值)
+
+一个用户在整个使用周期内为产品贡献的总收入。
+
+简化公式：`LTV = ARPU x 平均生命周期月数`
+
+更精确的公式考虑毛利率和折现率：`LTV = ARPU x 毛利率 / 月流失率`
+
+健康基准：**LTV/CAC > 3**（每花 1 元获客，能赚回 3 元）。LTV 指导获客预算上限和用户分层运营策略。
+
+### CAC (Customer Acquisition Cost)
+
+客户获取成本。获得一个新付费用户的平均花费。
+
+公式：`CAC = (总营销费用 + 总销售费用) / 新增付费用户数`
+
+包含：广告费、内容营销、销售人员成本、渠道佣金等。
+
+**CAC 回收期 (Payback Period)** < 12 个月为健康。超过 18 个月说明获客效率需要优化。
+
+### NPS (Net Promoter Score)
+
+净推荐值。通过一个问题衡量用户忠诚度："您有多大可能向朋友推荐我们的产品？"（0-10 分）
+
+- **9-10 分**：推荐者（Promoter）
+- **7-8 分**：被动者（Passive）
+- **0-6 分**：贬损者（Detractor）
+
+NPS = 推荐者占比 - 贬损者占比。范围 -100 到 +100。
+
+参考标准：
+- **> 70**：世界级（Apple、Tesla）
+- **> 50**：优秀
+- **> 30**：良好
+- **> 0**：需要改进
+- **< 0**：需要紧急干预
+
+### ARPU (Average Revenue Per User)
+
+每用户平均收入。公式：`ARPU = 总收入 / 活跃用户数`。按月或年计算。用于衡量变现效率、用户价值分层、定价策略评估。
+
+### MRR (Monthly Recurring Revenue)
+
+月度经常性收入，SaaS 产品的核心收入指标：
+
+- **New MRR**：新客户带来的收入
+- **Expansion MRR**：老客户升级/加购带来的增量
+- **Churned MRR**：流失客户减少的收入
+- **Contraction MRR**：老客户降级减少的收入
+
+Net New MRR = New + Expansion - Churned - Contraction
+
+### GMV (Gross Merchandise Volume)
+
+总交易额。电商/交易平台的核心规模指标。GMV 不等于收入（Revenue），平台收入通常是 GMV 的佣金比例（Take Rate）。
+
+注意：GMV 虚高（大量取消/退款/刷单）是常见的虚假繁荣信号。应关注净 GMV 和实际履约率。
+
+### Conversion Rate (转化率)
+
+从一个阶段到下一个阶段的用户比例。常见转化率：
+
+- **注册转化率**：访客 → 注册用户
+- **激活转化率**：注册用户 → 完成核心动作
+- **付费转化率**：注册用户 → 付费用户
+- **下单转化率**：加购 → 下单 → 支付成功
+
+优化转化率是增长最高效的手段之一（不需要更多流量）。
+
+### Cohort Analysis (同期群分析)
+
+按用户注册/首次使用的时间将用户分组（Cohort），分别追踪每组的留存、付费等指标随时间的变化。
+
+核心价值：能发现产品改进是否真正提升了新用户的留存（而非被老用户数据掩盖）。例如：1 月注册用户的 30 日留存是 15%，3 月注册用户的 30 日留存是 22%，说明产品改进有效。
+
+是产品分析最重要的方法之一。
+
+---
+
+## 需求与开发流程
+
+### User Story (用户故事)
+
+从用户视角描述需求的格式。标准格式："作为 [角色]，我想要 [功能]，以便 [价值]"。
+
+示例："作为买家，我想要按价格排序商品，以便快速找到符合预算的选择"。
+
+遵循 INVEST 原则：
+- **I**ndependent（独立的）
+- **N**egotiable（可协商的）
+- **V**aluable（有价值的）
+- **E**stimable（可估算的）
+- **S**mall（小的）
+- **T**estable（可测试的）
+
+### Acceptance Criteria (验收标准)
+
+定义用户故事"完成"的可验证条件。常用 Given-When-Then 格式：
+
+```
+Given 用户在商品列表页
+When 点击"价格从低到高"排序
+Then 列表按价格升序排列
+And 排序按钮显示选中状态
+And 页面不刷新（前端排序）
+```
+
+好的验收标准：具体、可测试、无歧义、覆盖边界情况。
+
+### PRD (Product Requirements Document)
+
+产品需求文档。描述产品功能需求的完整文档。通常包含：
+
+- 背景和目标
+- 用户故事和场景
+- 功能清单和优先级
+- 交互说明和界面原型
+- 数据需求
+- 非功能需求（性能/安全/兼容性）
+- 排期和里程碑
+- 成功指标
+
+核心是确保团队对"做什么"和"为什么做"达成一致。
+
+### Sprint (冲刺)
+
+Scrum 框架中的固定时间迭代周期，通常 1-2 周。每个 Sprint 包含：
+
+1. **Sprint Planning**：确定本 Sprint 的目标和任务
+2. **Daily Standup**：每日 15 分钟同步进展和阻塞
+3. **Sprint Review**：向利益相关者演示交付物
+4. **Sprint Retrospective**：团队回顾改进点
+
+每个 Sprint 结束应产出可交付的产品增量（Potentially Shippable Increment）。
+
+### Backlog (待办列表)
+
+按优先级排序的需求/任务列表：
+
+- **Product Backlog**：包含所有已知需求，由 PO 维护
+- **Sprint Backlog**：当前 Sprint 要完成的任务，由开发团队维护
+
+Backlog Grooming/Refinement 是定期维护 Backlog 的活动：重新排序、拆分大故事、补充细节、移除过时条目。建议每个 Sprint 花 10% 的时间做 Grooming。
+
+### Roadmap (产品路线图)
+
+展示产品在未来一段时间（季度/半年/年度）的规划方向和关键里程碑。
+
+好的 Roadmap：
+- 主题驱动（"提升新用户激活率"）而非功能列表（"做 A/B/C 功能"）
+- 有明确的目标和成功指标
+- 区分高确定性（近期）和探索性（远期）工作
+- 允许调整
+
+避免：精确到天的时间承诺、功能堆砌、当作合同。
+
+### Feature Flag (功能开关)
+
+通过配置控制功能是否对用户可见，无需重新部署代码：
+
+- **灰度发布**：先给 5% 用户开放，逐步扩大
+- **A/B 测试**：对比组和实验组看不同版本
+- **紧急回滚**：一键关闭问题功能
+- **客户定制**：按客户/套餐开放不同功能
+
+工具：LaunchDarkly、Unleash、Flagsmith、自建。是 Continuous Delivery 的关键基础设施。
+
+### Technical Debt (技术债务)
+
+为了短期交付速度而做出的技术妥协，需要在未来偿还（重构）。
+
+类型：
+- **有意的**："先这么做，下个版本重构"
+- **无意的**："当时不知道更好的方案"
+- **环境变化**：技术栈过时、需求变更导致架构不适配
+
+适度的技术债务是正常的，关键是：有意识地记录、定期偿还、不让利息（维护成本）超过本金。建议每个 Sprint 分配 15-20% 的时间偿还技术债务。
+
+---
+
+## 用户研究与设计
+
+### Persona (用户画像)
+
+基于真实用户研究数据创建的虚拟代表人物。包含：
+
+- 人口统计（年龄/职业/教育）
+- 行为模式（使用频率/偏好渠道）
+- 目标和动机（为什么用这个产品）
+- 痛点和需求（遇到什么困难）
+
+好的 Persona 帮助团队做决策时想象"这个人会怎么用"。常见错误：基于假设而非数据、画像过多（3-5 个足够）、做完就束之高阁。
+
+### User Journey Map (用户旅程地图)
+
+可视化用户完成目标的端到端体验：
+
+- **阶段**：了解 → 考虑 → 购买 → 使用 → 推荐
+- **行为**：每个阶段用户做了什么
+- **触点**：通过什么渠道/界面交互
+- **痛点**：遇到什么困难
+- **情感曲线**：各阶段的情绪变化
+- **机会点**：可以改善的地方
+
+帮助团队从用户视角审视体验全局，发现跨部门协作的优化点。
+
+### Usability Testing (可用性测试)
+
+观察真实用户使用产品完成特定任务的过程，发现设计和交互中的问题。
+
+Jakob Nielsen 研究表明 **5 个用户就能发现 80% 的可用性问题**。
+
+关键方法和指标：
+- 出声思维法（Think Aloud）
+- 任务完成率（Completion Rate）
+- 任务完成时间（Time on Task）
+- 错误次数（Error Count）
+
+### Information Architecture / IA (信息架构)
+
+组织和结构化产品内容/功能的方式，帮助用户找到信息和完成任务。
+
+包含：导航结构、分类体系、标签命名、搜索策略。
+
+验证方法：
+- **卡片分类 (Card Sorting)**：让用户对内容进行分组和命名
+- **树状测试 (Tree Testing)**：验证用户能否通过导航找到目标
+
+好的 IA 让用户"不用想就知道去哪找"。
+
+---
+
+## 数据分析方法
+
+### Funnel Analysis (漏斗分析)
+
+追踪用户在关键流程中每一步的转化和流失：
+
+```
+首页访问 (100%) → 搜索 (60%) → 商品详情 (35%) → 加购 (15%) → 下单 (8%) → 支付成功 (6%)
+```
+
+每一步的转化率揭示最大的优化机会（从转化率最低的环节入手）。注意：要区分整体漏斗和分群漏斗（不同渠道/用户类型的表现差异很大）。
+
+### Attribution (归因分析)
+
+确定哪些营销渠道/触点对用户转化贡献最大：
+
+- **末次触点归因 (Last Touch)**：归功于最后一个触点
+- **首次触点归因 (First Touch)**：归功于第一个触点
+- **线性归因**：所有触点平均分配
+- **时间衰减归因**：越近期的触点权重越高
+- **数据驱动归因**：机器学习模型自动分配
+
+帮助优化营销预算分配，减少在低效渠道上的浪费。
+
+### Segmentation (用户分群)
+
+按特征将用户划分为不同群组进行分析。常用维度：
+
+- **行为分群**：活跃度、使用频率、功能偏好
+- **价值分群**：付费等级、LTV 高/中/低
+- **人口统计**：年龄、地区、职业
+- **渠道来源**：自然搜索、付费广告、社交推荐
+
+目的是发现"不同用户群的需求和行为有何不同"，从而做差异化运营和产品策略。
+
+---
+
+## Agent Checklist
+
+- [ ] 团队对 MVP 的定义一致：验证假设而非交付半成品
+- [ ] 北极星指标已确定，团队对齐
+- [ ] AARRR 漏斗各环节有明确的跟踪指标
+- [ ] LTV/CAC > 3，CAC 回收期 < 12 个月
+- [ ] 用户故事遵循 INVEST 原则，验收标准使用 Given-When-Then 格式
+- [ ] 产品路线图以主题驱动，非功能堆砌
+- [ ] 用户画像基于真实研究数据，非假设
+- [ ] 关键流程有漏斗分析和同期群分析
+- [ ] A/B 测试有足够样本量和统计显著性
+- [ ] 技术债务有记录和定期偿还计划（每 Sprint 15-20%）

package/product/feature-prioritization-framework.md

@@ -0,0 +1,40 @@
+---
+id: feature-prioritization-framework
+title: feature-prioritization-framework
+domain: product
+category: feature-prioritization-framework.md
+difficulty: intermediate
+tags: [feature, framework, prioritization, product]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 功能优先级决策框架（深度版）
+
+### 目标
+- 统一需求排期口径，避免“拍脑袋优先级”导致资源浪费。
+
+### 四维评分模型
+- 业务价值：是否直接推动收入、留存、效率提升。
+- 用户价值：是否解决高频痛点或关键任务阻塞。
+- 实现成本：研发、测试、运维、培训与迁移成本。
+- 风险敞口：合规、安全、稳定性、依赖不确定性。
+
+### 评分规则
+- 每维 1-5 分，最终分数 = (业务价值+用户价值)×权重 - (实现成本+风险敞口)×权重。
+- 默认权重：业务价值0.35、用户价值0.25、实现成本0.2、风险0.2。
+- 分数相近时，以“减少关键链路风险”优先。
+
+### 决策门禁
+- 涉及账号、支付、权限、数据导出功能时，风险评分必须由安全与运维双签。
+- 涉及跨系统变更时，必须有回滚方案与兼容策略。
+- 未给出可量化验收标准的需求不得进入开发。
+
+### 输出模板
+- 需求名称
+- 预期业务影响
+- 用户受益群体
+- 估算工作量
+- 依赖项与风险
+- 发布策略与回滚方案

package/product/kpi-and-metric-tree.md

@@ -0,0 +1,37 @@
+---
+id: kpi-and-metric-tree
+title: kpi-and-metric-tree
+domain: product
+category: kpi-and-metric-tree.md
+difficulty: intermediate
+tags: [and, kpi, metric, product, tree, 与指标树方法库]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## KPI 与指标树方法库
+
+### 目标
+- 建立从战略目标到页面行为指标的可追踪链路。
+
+### 指标层级
+- 北极星指标：反映核心价值交付。
+- 一级指标：新增、活跃、留存、收入、成本。
+- 二级指标：转化率、漏斗流失率、成功率、时延、错误率。
+- 过程指标：页面点击、操作耗时、失败类型分布。
+
+### 指标树构建步骤
+- 明确业务目标与目标时间窗。
+- 拆解关键用户行为路径。
+- 为每个路径节点定义成功与失败指标。
+- 绑定阈值与预警规则。
+
+### 指标验收规则
+- 每个新功能至少绑定 1 个业务指标和 2 个质量指标。
+- 指标必须有口径说明、数据源、更新频率、负责人。
+- 指标上生产前必须完成一次历史基线对齐。
+
+### 常见失败模式
+- 指标只统计访问量，不统计任务成功率。
+- 指标口径跨团队不一致，导致决策冲突。

package/product/product-discovery-and-prd-deep-dive.md

@@ -0,0 +1,41 @@
+---
+id: product-discovery-and-prd-deep-dive
+title: product-discovery-and-prd-deep-dive
+domain: product
+category: product-discovery-and-prd-deep-dive.md
+difficulty: intermediate
+tags: [and, deep, discovery, dive, prd, product, 产品环节深度知识库]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 产品环节深度知识库
+
+### 目标
+- 把业务目标转化为可执行需求，保证“价值、可行性、可验收”一致。
+
+### 关键方法
+- 用户任务拆解：角色、场景、触发、行为、成功定义。
+- 价值优先级：业务价值、用户价值、实现成本、风险敞口四维评分。
+- 需求边界定义：必须做、应当做、可延后，避免范围失控。
+- 验收标准前置：每个能力必须有可量化结果。
+
+### PRD 必备结构
+- 背景与目标
+- 用户与场景
+- 业务流程与状态流转
+- 功能清单与非功能要求
+- 数据与指标定义
+- 风险与依赖
+- 验收与上线条件
+
+### 常见失败模式
+- 需求写“功能名”而不是“用户结果”。
+- 没有异常流和回退策略。
+- 验收标准不可量化，导致开发与测试认知不一致。
+
+### 执行清单
+- 需求评审前完成术语统一。
+- 关键链路必须补充时序图或状态图。
+- 上线前确认指标埋点与监控项已对齐。