pm

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Product Strategy & Execution Skill

产品策略与执行技能

Core Philosophy

核心理念

Transform vague product ideas into concrete, executable strategies with clear metrics, user impact, and technical feasibility.

将模糊的产品想法转化为具备明确指标、用户影响和技术可行性的具体可执行策略。

When to Use This Skill

适用场景

Product discovery and opportunity assessment
PRD (Product Requirements Document) creation
Feature prioritization and roadmap planning
Stakeholder alignment documents
Go-to-market strategy
Product metrics and success criteria definition

产品探索与机会评估
PRD（产品需求文档）撰写
功能优先级排序与路线图规划
利益相关方对齐文档
Go-to-market 上市策略制定
产品指标与成功标准定义

Execution Framework

执行框架

1. Problem Definition Phase

1. 问题定义阶段

Before diving into solutions, deeply understand:

What is the actual user problem? (Not what stakeholders think it is)
What evidence validates this problem exists?
What is the cost of NOT solving this problem?
Who are the users affected and what's their current workaround?

Output a Problem Statement:

Clear, concise articulation
Quantified impact (users affected, revenue at stake, time wasted)
Current state vs desired state

在着手制定解决方案前，先深入理解：

真实的用户问题是什么？（而非利益相关方所认为的问题）
有哪些证据可以证明该问题真实存在？
不解决这个问题的代价是什么？
受影响的用户有哪些，他们当前的替代解决方案是什么？

输出问题陈述：

清晰、简洁的表述
量化影响（受影响用户数、涉及营收、浪费的时间）
当前状态与预期状态的对比

2. Opportunity Sizing

2. 机会规模评估

Calculate potential impact using:

TAM/SAM/SOM framework
User segmentation analysis
Revenue/engagement/efficiency impact projections
Competitive positioning assessment

Deliver:

Expected business metrics (revenue, retention, MAU growth)
User value metrics (time saved, success rate, NPS impact)
Strategic value (market position, moat building)

使用以下维度计算潜在影响：

TAM/SAM/SOM 框架
用户分群分析
营收/参与度/效率影响预测
竞争定位评估

交付内容：

预期业务指标（营收、留存、MAU 增长）
用户价值指标（节省的时间、成功率、NPS 影响）
战略价值（市场地位、壁垒构建）

3. Solution Exploration

3. 方案探索

Generate multiple solution approaches:

Quick wins vs long-term bets
Build vs buy vs partner analysis
MVP vs full feature comparison
Technical feasibility assessment

For each solution provide:

User experience flow (narrative form)
Key technical requirements
Resource estimate (eng weeks, design weeks)
Risk assessment
Dependencies and blockers

生成多种解决方案思路：

快速见效项 vs 长期投入项
自研 vs 采购 vs 合作分析
MVP vs 完整功能对比
技术可行性评估

为每个方案提供：

用户体验流程（叙事形式）
核心技术要求
资源预估（开发人周、设计人周）
风险评估
依赖项与阻塞点

4. Prioritization Matrix

4. 优先级矩阵

Evaluate using ICE Score framework:

Impact (1-10): Business + user value
Confidence (1-10): Evidence quality
Ease (1-10): Implementation simplicity

Additional filters:

Strategic alignment score
Technical debt consideration
Team capacity reality check

使用 ICE Score 框架进行评估：

Impact 影响（1-10分）：业务+用户价值
Confidence 置信度（1-10分）：证据质量
Ease 易实施性（1-10分）：实现复杂度

额外筛选条件：

战略对齐评分
技术债务考量
团队容量实际校验

5. PRD Structure

5. PRD 结构

When creating PRDs, include:

撰写 PRD 时，需包含以下内容：

Executive Summary

执行摘要

Problem statement
Proposed solution (1 paragraph)
Success metrics
Resource ask

问题陈述
提议方案（1段话说明）
成功指标
资源申请

User Stories & Jobs-to-be-Done

用户故事与 Jobs-to-be-Done

Primary user personas
User journey maps
Job stories: "When [situation], I want to [motivation], so I can [outcome]"

核心用户画像
用户旅程地图
任务故事："当[场景]时，我想要[动机]，以便我可以[达成结果]"

Requirements

需求

Functional requirements (what it must do)
Non-functional requirements (performance, security, accessibility)
Out of scope (explicitly stated)

功能需求（必须实现的能力）
非功能需求（性能、安全、可访问性）
排除范围（明确声明不做的内容）

Success Metrics

成功指标

Leading indicators (what we can measure immediately)
Lagging indicators (long-term impact)
Counter-metrics (what we DON'T want to harm)

先导指标（可立即测量的内容）
滞后指标（长期影响）
反向指标（我们不希望受到负面影响的指标）

Go-to-Market

上市方案

Launch plan
Communication strategy
Training requirements
Rollout phases

发布计划
沟通策略
培训要求
分阶段上线安排

6. Stakeholder Communication

6. 利益相关方沟通

Tailor communication by audience

根据受众调整沟通内容

Executives: Impact, cost, timeline - 3 bullets max
Engineering: Technical requirements, edge cases, scalability
Design: User problems, success criteria, constraints
Sales/CS: Value prop, customer benefits, FAQs

高管： 影响、成本、时间线 - 最多3个要点
研发团队： 技术要求、边界场景、可扩展性
设计团队： 用户问题、成功标准、约束条件
销售/客户成功团队： 价值主张、客户收益、常见问题解答

Output Format Principles

输出格式原则

Always Include

必须包含

TL;DR at top - Busy execs need the headline
Clear decision required - What needs to be decided and by when
Data over opinions - Link to research, metrics, user feedback
Risks explicitly called out - What could go wrong
Next steps with owners - Who does what by when

开头放置 TL;DR - 忙碌的高管需要快速获取核心信息
明确需要做出的决策 - 需要决定什么、截止时间是什么
数据优先于观点 - 附上研究、指标、用户反馈的链接
明确披露风险 - 可能出现的问题
带负责人的后续行动 - 谁在什么时间前完成什么事

Never Include

禁止包含

Jargon without definitions
Solutions before problems
Unvalidated assumptions
Vague timelines like "Q2" without dates
Success metrics without baselines

未加定义的行业黑话
先讲解决方案再讲问题
未经验证的假设
模糊的时间线比如"Q2"没有具体日期
没有基准线的成功指标

Quality Checks

质量检查

Before delivering any product document

交付任何产品文档前

Advanced Techniques

高级技巧

Jobs-to-be-Done Framework

Jobs-to-be-Done 框架

Instead of: "User wants a faster dashboard" Use: "When I arrive at work Monday morning, I want to immediately see which deals need attention, so I can prioritize my week before my calendar fills up"

错误示例："用户想要一个更快的仪表盘" 正确用法："当我周一早上到公司时，我想要立刻看到哪些交易需要关注，以便我可以在日程排满前规划好整周的优先级"

Working Backwards (Amazon style)

倒推法（亚马逊风格）

Start with the press release announcement, then work backwards to figure out what to build.

从新闻通稿的发布内容开始倒推，确定需要开发的内容。

Outcome over Output

结果重于产出

Focus on user outcomes achieved, not features shipped. "Users complete onboarding 40% faster" beats "Built 5 new onboarding screens"

关注达成的用户结果，而非发布的功能数量。"用户完成 onboarding 的速度提升40%" 优于 "开发了5个新的 onboarding 页面"

Common Pitfalls to Avoid

需要避免的常见陷阱

Feature Factory Syndrome - Shipping features nobody asked for
The HiPPO Problem - Highest Paid Person's Opinion trumps data
Sunk Cost Fallacy - Continuing failed initiatives because of past investment
Assumption Stacking - Building assumptions on assumptions
Scope Creep - "While we're at it, let's also..."

功能工厂综合征 - 发布没人需要的功能
HiPPO 问题 - 最高薪人士的观点凌驾于数据之上
沉没成本谬误 - 因为过去的投入而继续推进失败的项目
假设堆叠 - 在假设的基础上再叠加新的假设
范围蔓延 - "既然我们在做这个，不如也把..."

Example Application

应用示例

User Request: "Help me write a PRD for a new analytics dashboard"

Elite PM Approach:

First clarify: What problem does the current dashboard not solve?
Who specifically is struggling and what's their current workaround?
What business metric improves if we solve this?
What have we tried before and why didn't it work?
THEN begin PRD with validated problem statement

用户请求："帮我为一个新的分析仪表盘写一份 PRD"

优秀产品经理的做法：

首先明确：当前仪表盘解决不了的问题是什么？
具体是哪些用户遇到了困难，他们当前的替代方案是什么？
如果我们解决了这个问题，哪些业务指标会得到提升？
我们之前尝试过什么方法，为什么没成功？
基于验证过的问题陈述才开始撰写 PRD

Metrics That Matter

核心指标

Product Health:

Activation rate (% users reaching "aha moment")
Engagement frequency (DAU/MAU ratio)
Feature adoption rate
Time to value
Net Retention Rate

Execution Health:

Velocity vs plan
Scope creep percentage
Bug escape rate
Deploy frequency
Time to resolve customer issues

产品健康度：

激活率（达到"啊哈时刻"的用户占比）
参与频率（DAU/MAU 比值）
功能 adoption 率
价值交付时长
净留存率

执行健康度：

实际进度 vs 计划进度
范围蔓延百分比
线上 Bug 泄漏率
发布频率
客户问题解决时长

Final Principle

最终原则

The best product managers make decisions reversible. Structure every decision as a two-way door when possible. Test, learn, iterate. Perfect is the enemy of shipped.