product-strategy

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is activated, always start your first response with the 🧢 emoji.

当激活本Skill时，你的第一条回复请始终以🧢表情符号开头。

Product Strategy

产品战略

A practical framework for defining product vision, building roadmaps, and making prioritization decisions that compound over time. Product strategy is the connective tissue between a company's business goals and the day-to-day work of a product team. Without it, teams ship features that users don't value, roadmaps become wish lists, and product-market fit erodes without anyone noticing. This skill covers the full strategy lifecycle: crafting a vision, building outcome-based roadmaps, scoring and sequencing work with prioritization frameworks, setting OKRs, and communicating direction to stakeholders. Agents can use this to draft strategy documents, evaluate feature trade-offs, run scoring sessions, and structure planning artifacts.

这是一套用于定义产品愿景、制定路线图，以及做出可长期产生复利效应的优先级决策的实用框架。产品战略是连接公司业务目标与产品团队日常工作的纽带。没有它，团队开发的功能用户并不认可，路线图会变成愿望清单，产品市场契合度会在无人察觉的情况下逐渐下降。本Skill覆盖战略全生命周期：打造愿景、制定基于成果的路线图、运用优先级框架对工作进行评分与排序、设定OKRs，以及向利益相关者传达方向。Agent可使用它来起草战略文档、评估功能取舍、开展评分会议，以及构建规划工件。

When to use this skill

何时使用本Skill

Trigger this skill when the user:

Needs to write or refine a product vision or strategy document
Wants to build or restructure a product roadmap
Is deciding which features to build next or how to sequence work
Asks about RICE, ICE, MoSCoW, or Kano scoring
Needs to write product OKRs or connect features to business outcomes
Is preparing a roadmap presentation for stakeholders or executives
Wants to make a build vs. buy vs. partner decision
Is evaluating product-market fit signals or pivoting direction
Asks about north star metrics or success metrics for a product area

Do NOT trigger this skill for:

Sprint planning mechanics or ticket estimation (use an agile-scrum skill)
Pricing model decisions (use a pricing-strategy skill)

当用户有以下需求时，触发本Skill：

需要撰写或完善产品愿景或战略文档
想要制定或重构产品路线图
正在决定下一步开发哪些功能或如何安排工作顺序
询问关于RICE、ICE、MoSCoW或Kano评分的问题
需要撰写产品OKRs或将功能与业务成果关联
正在为利益相关者或高管准备路线图演示文稿
想要做出自建、采购还是合作的决策
正在评估产品市场契合度信号或调整方向
询问产品领域的北极星指标或成功指标

请勿在以下场景触发本Skill：

冲刺规划机制或任务估算（使用敏捷Scrum Skill）
定价模型决策（使用定价战略Skill）

Key principles

核心原则

Strategy is about saying no - A roadmap that includes every request is not a strategy, it is a backlog. Every "yes" to one initiative is implicitly "no" to five others. The clearest signal of a weak strategy is an inability to decline requests from stakeholders with conviction and data.
Outcome-based roadmaps, not feature lists - Roadmaps organized by features (build search, add dark mode, create reports) measure output. Roadmaps organized by outcomes (reduce time-to-value by 40%, increase weekly active usage, improve onboarding completion) measure impact. Ship outcomes; features are the means, not the end.
Prioritize ruthlessly - Most teams have 10x more ideas than capacity. The job of a product leader is not to find ways to do everything - it is to find the 20% of work that delivers 80% of the impact and protect the team's focus on it.
Validate before building - The most expensive mistake in product is building something nobody wants. Every assumption in a roadmap should have a cheapest possible test: a landing page, a prototype, a sales call, a survey. Build only after validation reduces uncertainty to an acceptable level.
Align product to business goals - Product teams that operate in isolation from business metrics (revenue, retention, activation) eventually lose organizational trust and budget. Every major initiative should trace directly to a business outcome the company cares about. If you cannot draw the line, reconsider the initiative.

战略的本质是学会说不 - 包含所有请求的路线图不是战略，只是待办清单。对一个举措说“是”，就意味着对另外五个举措隐含地说“不”。战略薄弱最明显的信号就是无法凭借信念和数据拒绝利益相关者的请求。
基于成果的路线图，而非功能列表 - 按功能组织的路线图（开发搜索功能、添加深色模式、创建报表）衡量的是产出。按成果组织的路线图（将实现价值的时间缩短40%、提高周活跃用户量、优化完成注册流程）衡量的是影响。聚焦成果交付；功能只是手段，而非目的。
无情地进行优先级排序 - 大多数团队的想法数量是其执行能力的10倍。产品负责人的工作不是想方设法完成所有事情——而是找到能带来80%影响的20%工作，并保护团队专注于这些工作。
先验证再开发 - 产品开发中最昂贵的错误就是开发出没人想要的东西。路线图中的每一个假设都应该有最廉价的测试方式：着陆页、原型、销售电话、调研。只有当验证将不确定性降低到可接受的水平后，再进行开发。
让产品与业务目标保持一致 - 脱离业务指标（收入、留存、激活）运作的产品团队最终会失去组织的信任和预算。每一项重大举措都应直接关联到公司关注的业务成果。如果你无法建立这种关联，请重新考虑该举措。

Core concepts

核心概念

Vision / Strategy / Roadmap hierarchy

Vision is the 3-5 year aspirational destination: "What does the world look like if we succeed?" It is qualitative, inspiring, and stable. It changes rarely.
Strategy is the 12-18 month plan for how you get there: which customer segments, which problems, which bets. It is directional, not exhaustive.
Roadmap is the quarterly execution plan: which outcomes to drive, which initiatives to fund, what ships when. It is concrete and frequently updated.

A common mistake is writing a roadmap without a strategy, or a strategy without a vision. The hierarchy must exist for prioritization decisions to be defensible.

Prioritization frameworks

RICE (Reach, Impact, Confidence, Effort) and ICE (Impact, Confidence, Ease) are quantitative scoring models that convert gut-feel debates into structured comparisons. MoSCoW (Must Have, Should Have, Could Have, Won't Have) is a categorization system used most often for release scoping. Kano maps features to customer satisfaction curves to distinguish must-haves from delighters. See

references/prioritization-frameworks.md

for detailed scoring guides, formulas, and examples.

Product-market fit signals

Strong PMF is characterized by: >40% of users saying they would be "very disappointed" if the product disappeared (Sean Ellis test), high organic/word-of-mouth growth, strong retention curves that flatten rather than decay to zero, and sales cycles that shorten as you refine the pitch. Weak PMF shows as: feature-request-driven roadmaps, high churn despite onboarding improvements, and a sales team that cannot articulate who the product is for.

North star metric

A single metric that best captures the core value your product delivers to customers. It must be a leading indicator of long-term revenue (not revenue itself), it must be actionable by the product team, and it must be understandable by everyone in the company. Examples: Slack (messages sent per user per day), Airbnb (nights booked), Spotify (time spent listening). Choose one. Two north stars create two competing roadmaps.

愿景 / 战略 / 路线图层级

愿景是3-5年的宏伟目标：“如果我们成功了，世界会是什么样子？”它是定性的、鼓舞人心的、稳定的，很少会改变。
战略是12-18个月的实现计划：服务哪些客户群体、解决哪些问题、做出哪些赌注。它是方向性的，而非详尽无遗的。
路线图是季度执行计划：要达成哪些成果、资助哪些举措、何时交付什么内容。它是具体的，会频繁更新。

常见的错误是在没有战略的情况下制定路线图，或是在没有愿景的情况下制定战略。要让优先级决策具有说服力，这个层级必须存在。

优先级框架

RICE（覆盖用户数、影响、信心、投入）和ICE（影响、信心、易用性）是定量评分模型，可凭感觉的争论转化为结构化的比较。MoSCoW（必须有、应该有、可以有、不会有）是一种分类系统，最常用于版本范围界定。Kano模型将功能与客户满意度曲线关联，以区分必备功能和惊喜功能。详细的评分指南、公式和示例请参阅

references/prioritization-frameworks.md

。

产品市场契合度信号

强产品市场契合度的特征包括：超过40%的用户表示如果产品消失他们会“非常失望”（Sean Ellis测试）、高自然增长/口碑增长、趋于平稳而非衰减至零的高留存曲线，以及随着定位优化而缩短的销售周期。弱产品市场契合度的表现为：由功能请求驱动的路线图、尽管优化了注册流程但用户流失率仍然很高，以及销售团队无法明确说明产品面向谁。

北极星指标

最能体现产品为客户带来核心价值的单一指标。它必须是长期收入的领先指标（而非收入本身），必须是产品团队可以采取行动影响的，并且必须是公司所有人都能理解的。例如：Slack（每位用户每天发送的消息数）、Airbnb（预订的晚数）、Spotify（收听时长）。只选一个。两个北极星指标会导致两个相互竞争的路线图。

Common tasks

常见任务

Write a product vision statement

撰写产品愿景声明

A strong vision answers: who are we serving, what problem do we solve, and what does the world look like when we win?

Template:

For [target customer], who [has this problem or need],
[Product name] is a [product category] that [key benefit / why it's valuable].
Unlike [primary alternative], our product [key differentiator].

Extended narrative vision (for internal strategy docs):

undefined

一个优秀的愿景声明需要回答：我们服务谁，我们解决什么问题，以及我们成功时世界会是什么样子？

模板：

针对[目标客户]，他们[存在这个问题或需求]，
[产品名称]是一款[产品类别]，能够[核心价值/为何有价值]。
与[主要竞品]不同，我们的产品[核心差异化优势]。

扩展叙事愿景（用于内部战略文档）：

undefined

Our Vision

我们的愿景

In [timeframe], [company/product] will be [aspirational description of the future state].

[Target customers] will [be able to do / experience] [specific outcome] that was previously impossible or painful.

We will know we have succeeded when [measurable signal]:

[Signal 1]
[Signal 2]
[Signal 3]


Good vision statements are short (fits on one slide), memorable (team can recite it),
and opinionated (excludes some customers and use cases intentionally).

---

在[时间范围]内，[公司/产品]将成为[对未来状态的宏伟描述]。

[目标客户]将[能够做到/体验到]以前不可能或痛苦的[具体成果]。

当出现以下可衡量的信号时，我们就知道自己成功了：

[信号1]
[信号2]
[信号3]


优秀的愿景声明简短（能放在一张幻灯片上）、容易记住（团队可以背诵）、有主见（有意排除部分客户和使用场景）。

---

Build an outcome-based roadmap

制定基于成果的路线图

Step 1 - Identify themes from strategy

Map each strategic bet to a roadmap theme. A theme is a broad problem area, not a feature. Examples: "Reduce time-to-first-value," "Improve team collaboration," "Unlock enterprise segment."

Step 2 - Define outcomes per theme

For each theme, write one measurable outcome: the metric that would move if this theme is executed well. Outcome = metric + direction + magnitude + timeframe.

Example: "Increase 7-day activation rate from 42% to 60% by Q3."

Roadmap template:

Theme	Outcome target	Key initiatives	Quarter	Status
Activation	7-day activation 42% -> 60%	Onboarding redesign, empty state improvements	Q2	In progress
Collaboration	Teams with 3+ active members +30%	Shared workspaces, @ mentions	Q3	Planned
Enterprise	10 enterprise logos signed	SSO, audit logs, admin dashboard	Q3-Q4	Discovery

Step 3 - Sequence by dependency and impact

Order themes by: does this unblock something else? If yes, pull it earlier. Then order remaining themes by expected impact on the north star metric.

步骤1 - 从战略中确定主题

将每个战略赌注映射到一个路线图主题。主题是一个宽泛的问题领域，而非功能。例如：“缩短首次实现价值的时间”、“改善团队协作”、“开拓企业客户群体”。

步骤2 - 为每个主题定义成果

为每个主题撰写一个可衡量的成果：如果该主题执行良好，会发生变化的指标。成果=指标+方向+幅度+时间范围。

示例：“到第三季度，将7天激活率从42%提升至60%。”

路线图模板：

主题	成果目标	关键举措	季度	状态
激活	7天激活率从42%提升至60%	注册流程重设计、空状态优化	Q2	进行中
协作	拥有3名以上活跃成员的团队增加30%	共享工作区、@提及功能	Q3	计划中
企业客户	签下10个企业客户	SSO、审计日志、管理员控制台	Q3-Q4	探索中

步骤3 - 按依赖关系和影响排序

按以下顺序排列主题：这个主题是否能为其他主题扫清障碍？如果是，提前安排。然后根据对北极星指标的预期影响对剩余主题进行排序。

Prioritize with RICE, ICE, or MoSCoW

使用RICE、ICE或MoSCoW进行优先级排序

Use RICE for quarterly planning with multiple competing initiatives. Use ICE for rapid triage of a long backlog. Use MoSCoW for scoping a specific release.

RICE scoring:

Score = (Reach x Impact x Confidence) / Effort

- Reach: how many users affected per quarter (number)
- Impact: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
- Confidence: 100% = high, 80% = medium, 50% = low
- Effort: person-months required

ICE scoring (faster, less precise):

Score = Impact x Confidence x Ease (each 1-10)

MoSCoW categorization:

Must Have - release fails without this (legal, core function, blocking user flow)
Should Have - important but not blocking; include if capacity allows
Could Have - nice to have; cut first when scope is tight
Won't Have - explicitly out of scope this cycle (park, do not delete)

For detailed scoring examples and comparison tables, see

references/prioritization-frameworks.md

在有多个竞争举措的季度规划中使用RICE。在快速处理长待办清单时使用ICE。在界定特定版本范围时使用MoSCoW。

RICE评分：

分数 = (覆盖用户数 × 影响 × 信心) / 投入

- 覆盖用户数：每季度受影响的用户数量
- 影响：3=巨大，2=高，1=中等，0.5=低，0.25=极小
- 信心：100%=高，80%=中，50%=低
- 投入：所需的人月数

ICE评分（更快，精度较低）：

分数 = 影响 × 信心 × 易用性（每项1-10分）

MoSCoW分类：

必须有 - 没有它版本发布就会失败（法律要求、核心功能、阻塞用户流程）
应该有 - 重要但不阻塞；如果有能力就包含
可以有 - 有更好；范围紧张时首先砍掉
不会有 - 本周期明确排除在范围外（暂存，不要删除）

详细的评分示例和对比表格请参阅

references/prioritization-frameworks.md

。

Set product OKRs

设定产品OKRs

Product OKRs translate strategy into measurable quarterly commitments.

Structure:

Objective: [Qualitative, inspiring, directional - no metric]
  KR1: [Metric] from [baseline] to [target] by [date]
  KR2: [Metric] from [baseline] to [target] by [date]
  KR3: [Metric] from [baseline] to [target] by [date]

Rules for strong KRs:

Measure outcomes, not outputs ("activation rate increases to 60%" not "ship new onboarding flow")
Baseline must be known before the quarter starts - never set a KR on a metric you do not currently measure
70% attainment is success; 100% means the target was too conservative
Max 3 KRs per objective; max 3 objectives per team per quarter

Common anti-pattern: Writing KRs as task lists ("Launch feature X," "Complete Y project"). These are milestones, not results. Rewrite as: "Feature X drives metric M to level N."

产品OKRs将战略转化为可衡量的季度承诺。

结构：

目标：[定性、鼓舞人心、方向性的描述 - 不含指标]
  KR1：[指标] 从[基线] 提升至[目标] 截止[日期]
  KR2：[指标] 从[基线] 提升至[目标] 截止[日期]
  KR3：[指标] 从[基线] 提升至[目标] 截止[日期]

优秀KR的规则：

衡量成果，而非产出（“激活率提升至60%”而非“发布新的注册流程”）
基线必须在季度开始前确定 - 永远不要为当前未衡量的指标设定KR
完成70%即为成功；100%完成意味着目标过于保守
每个目标最多3个KR；每个团队每季度最多3个目标

常见反模式： 将KR写成任务列表（“发布功能X”、“完成Y项目”）。这些是里程碑，而非结果。应重写为：“功能X将推动指标M达到水平N。”

Create a product strategy document

创建产品战略文档

A one-page product strategy document that stakeholders can read in 5 minutes:

markdown

undefined

一份利益相关者可在5分钟内读完的单页产品战略文档：

markdown

undefined

Product Strategy - [Year / Half]

产品战略 - [年 / 半年]

Context

背景

[1-2 sentences: company stage, market conditions, and what has changed since last cycle]

[1-2句话：公司阶段、市场状况，以及自上一周期以来的变化]

Where we play

我们的战场

[Target customer segments and use cases we are optimizing for this period]

[本周期我们优化服务的目标客户群体和使用场景]

Where we do not play

非战场

[Explicit exclusions - segments, use cases, or problems out of scope]

[明确排除的内容 - 客户群体、使用场景或问题]

Strategic bets

战略赌注

[Bet 1]: [Hypothesis] - if we do X, we expect Y outcome because Z

[赌注1]：[假设] - 如果我们做X，我们预计会得到Y成果，因为Z
[赌注2]：[假设]
[赌注3]：[假设]

Key metrics

关键指标

North star: [metric and current baseline]
Supporting metrics: [2-3 metrics that feed the north star]

北极星：[指标和当前基线]
支持指标：[2-3个为北极星指标提供数据的指标]

Risks and assumptions

风险与假设

[Assumption 1] - we will validate by [date] using [method]
[Assumption 2] - we will validate by [date] using [method]

---

[假设1] - 我们将在[日期]前通过[方法]验证
[假设2] - 我们将在[日期]前通过[方法]验证

---

Make build vs. buy decisions

做出自建vs采购vs合作决策

When evaluating whether to build, buy, or partner for a capability:

Criterion	Build	Buy	Partner
Core differentiator?	Yes	No	No
Time to market critical?	No	Yes	Yes
Internal expertise exists?	Yes	No	Available externally
Long-term maintenance cost	High	Vendor dependent	Shared
Customization required?	Full control	Limited	Negotiable

Decision heuristic:

If the capability is a core differentiator AND you have the expertise: build
If the capability is commodity AND a mature solution exists: buy
If speed matters more than control AND a capable partner exists: partner
Never build what the market commoditizes; never buy what creates lock-in on your core differentiator

在评估是自建、采购还是合作获取某项能力时：

标准	自建	采购	合作
是核心差异化优势吗？	是	否	否
上市时间至关重要吗？	否	是	是
拥有内部专业知识吗？	是	否	外部可获取
长期维护成本	高	依赖供应商	共同承担
需要定制化吗？	完全可控	有限	可协商

决策启发式：

如果该能力是核心差异化优势且你拥有专业知识：自建
如果该能力是通用功能且已有成熟解决方案：采购
如果速度比控制更重要且有合适的合作伙伴：合作
永远不要自建市场上已通用的功能；永远不要采购会在核心差异化优势上造成锁定的功能

Communicate roadmap to stakeholders

向利益相关者传达路线图

Different audiences require different roadmap formats.

For executives: One-page view. Themes and outcomes only. No feature names. Answers: "What business problems are we solving and when will we see results?"

For engineering and design: Outcome-first with supporting initiatives. Includes known dependencies, risks, and confidence level. Answers: "What are we building and why does it matter?"

For customers: Public roadmap with near-term themes only. Commitments, not dates. Avoid feature-level specifics that constrain design. Answers: "Is this team moving in a direction I trust?"

For sales and customer success: Near-term deliverables with anticipated dates. Include enterprise-specific items. Answers: "What can I promise to prospects this quarter?"

不同受众需要不同的路线图格式。

面向高管： 单页视图。仅包含主题和成果。不含功能名称。回答：“我们正在解决哪些业务问题，何时能看到结果？”

面向工程和设计团队： 以成果为先，附带支持举措。包含已知依赖关系、风险和信心水平。回答：“我们要构建什么，为什么重要？”

面向客户： 仅包含近期主题的公开路线图。承诺而非日期。避免限制设计的功能级细节。回答：“这个团队的方向值得我信任吗？”

面向销售和客户成功团队： 包含近期交付成果和预期日期。包含企业专属内容。回答：“本季度我可以向客户承诺什么？”

Anti-patterns

反模式

Anti-pattern	Why it fails	What to do instead
Roadmap as a feature wish list	Treats output as success; teams ship but metrics do not move	Reframe each initiative as an outcome with a target metric
Prioritizing by loudest stakeholder	Recency and seniority bias override user impact and data	Score every request with RICE or ICE before any commitment
Annual roadmap with no updates	Markets change; a frozen roadmap becomes fiction by Q3	Review and reforecast roadmap quarterly; update stakeholders
Skipping discovery to ship faster	Builds the wrong thing faster; sunk cost forces bad decisions	Run a 1-2 week discovery sprint before committing to any major initiative
Copying competitor features	Optimizes for the competitor's strategy, not your users	Start with your own user research; competitor features are signals, not specs
Treating OKRs as a task list	Measures effort, not impact; creates busywork culture	Write KRs as metric movements, not deliverables; review weekly

反模式	失败原因	替代方案
路线图是功能愿望清单	将产出视为成功；团队交付了功能但指标没有变化	将每个举措重新定义为带有目标指标的成果
按声音最大的利益相关者优先级排序	近期性和资历偏见覆盖了用户影响和数据	在做出任何承诺前，用RICE或ICE对每个请求进行评分
年度路线图不更新	市场变化；到第三季度，固定的路线图就会变成虚构的	每季度回顾和重新预测路线图；向利益相关者更新
跳过探索以更快交付	更快地构建了错误的东西；沉没成本迫使做出错误决策	在承诺任何重大举措前，开展1-2周的探索冲刺
复制竞品功能	针对竞品的战略优化，而非针对自己的用户	从自己的用户研究开始；竞品功能是信号，而非规格
将OKRs视为任务列表	衡量努力，而非影响；造成忙碌文化	将KR写成指标变化，而非交付成果；每周回顾

References

参考资料

For detailed scoring guides, formulas, and worked examples:

```
references/prioritization-frameworks.md
```
- RICE, ICE, MoSCoW, and Kano with step-by-step examples, comparison tables, and guidance on when to use each

Only load the references file when the task requires scoring or framework selection - it is detailed and will consume context.

详细的评分指南、公式和实例：

```
references/prioritization-frameworks.md
```
- RICE、ICE、MoSCoW和Kano的分步示例、对比表格，以及何时使用每个框架的指导

仅当任务需要评分或框架选择时才加载参考资料文件 - 内容详细，会占用上下文空间。