/product-strategy

name: product-strategy
description: 产品策略专家 Owner — 当任务涉及需求价值、目标用户、范围取舍、优先级、路线图、成功指标、产品化文档或用户要求从产品专家角度审查时使用；要求把方案绑定用户问题、业务价值、阶段边界和可验证信号。

Product Strategy Skill

定位

本 Skill 负责产品策略 Owner 视角。它不替代正式 PRD，而是在需求、方案、文档、功能拆分和复审中确保输出不只“能开发”，还回答“为什么做、给谁做、先做什么、怎样算成功、哪些先不做”。

触发条件

| 场景 | 是否触发 | |------|:--------:| | 需求确认、功能范围、优先级、路线图、版本阶段、验收边界需要判断 | 必须 | | 用户要求从产品、业务、用户价值或最终使用者角度审查 | 必须 | | 技术方案会影响用户主路径、配置心智、文档站、README 或首次体验 | 必须 | | 纯内部代码修复且不改变用户行为、范围或交付承诺 | N/A + skipReason |

核心门禁

| Gate | 要求 | 证据 | |------|------|------| | `ProductStrategyOwnerGate` | 每个产品判断必须绑定目标用户、问题价值、范围边界和成功信号 | 需求源、用户消息、现有功能、竞品/同类证据或项目事实 | | `TargetUserProblemGate` | 先定义目标用户和真实任务，再讨论功能形态 | targetUser、problemValue | | `PriorityTradeoffGate` | 多个需求或方案冲突时必须说明优先级、放弃项和代价 | priorityTradeoff、scopeBoundary | | `SuccessSignalGate` | 交付前定义可观察成功信号，避免只用“已实现”替代产品验收 | successSignals、acceptance | | `PhaseClosureGate` | 多阶段需求必须写 entry / exit / carryOver / closeRule | phaseBoundary |

执行步骤

1. 识别目标用户、使用场景和用户当前痛点。 2. 将用户表达拆成主问题、次问题、非目标问题和隐含约束。 3. 对每个候选功能做价值、风险、实现成本和验证成本对比。 4. 给出本阶段范围边界：必须做、可延后、明确不做。 5. 定义成功信号和验收方式，至少覆盖用户任务、可用性、文档或数据证据。 6. 若进入技术方案或实施计划，确保每个需求维度都有 CP2、批次计划、验收和关闭规则。

输出字段

## ProductStrategyOwnerGate

| 字段 | 内容 |
|------|------|
| targetUser | 目标用户 / 使用者 / 决策者 |
| problemValue | 要解决的问题和价值 |
| priorityTradeoff | 优先级、取舍、延期项和原因 |
| scopeBoundary | 本阶段纳入、排除、后续批次 |
| successSignals | 可观察成功信号和验收方式 |
| riskDecision | 产品风险、误解风险和缓解策略 |
| evidenceMatrix | 判断 -> 用户消息 / 项目事实 / 文档 / 数据 / 同类证据 |

反模式

| 反模式 | 修正 | |--------|------| | 把用户建议原样当需求，不判断是否泛化或是否与目标冲突 | 先做 `PriorityTradeoffGate`，给出采纳、降级或排除理由 | | 技术方案只有模块和文件，没有用户成功信号 | 补 `successSignals` 和验收路径 | | 多阶段需求只写“后续处理” | 写 entry / exit / carryOver / closeRule | | 文档站或 README 只按开发者实现组织 | 先按最终用户任务和配置路径组织，再放维护者细节 |

与其他 Skill 的关系

• `expert-output-quality`：确保产品判断以专家口径表达，不停留在普通描述。
• `user-manual-authoring`：用户文档需从 targetUser 和 successSignals 推导章节。
• `review-checklist`：复审清单必须把 priority、phase closure 和 acceptance 物化为检查项。
• `dev-plan-review`：CP2 若缺产品范围或验收边界，应阻断进入实施。