inspired-product
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseEmpowered Product Teams Framework
赋能型产品团队框架
Framework for building products customers love by structuring empowered teams that solve hard problems through continuous discovery and delivery. Based on a fundamental truth: the best product companies don't ship features -- they solve problems, and they give their teams the autonomy and accountability to figure out how.
本框架旨在通过构建赋能型团队，以持续发现与交付的方式打造用户喜爱的产品。其核心理念是：顶尖的产品公司并非单纯交付功能——而是解决问题，并且赋予团队自主权与责任感，让他们自行探索解决方案。
Core Principle
核心原则
Empowered product teams = cross-functional groups given problems to solve (not features to build) who own discovery and delivery end-to-end.
The root cause of most product failures is not bad engineering or poor design -- it is that teams are building things nobody wants. Feature teams receive roadmaps and execute; empowered teams receive objectives and discover solutions. The difference between a feature factory and an innovation engine is whether teams are missionaries (driven by vision and empathy) or mercenaries (driven by a backlog handed to them).
赋能型产品团队 = 被赋予待解决问题（而非待构建功能）的跨职能小组，全程负责产品的发现与交付全流程。
大多数产品失败的根源并非糟糕的工程实现或设计，而是团队在构建无人需要的功能。功能型团队接收路线图并执行；而赋能型团队接收目标并探索解决方案。「功能工厂」与「创新引擎」的区别在于，团队是秉持愿景与同理心的“传教士”，还是仅执行他人计划的“雇佣兵”。
Scoring
评分机制
Goal: 10/10. When reviewing or creating product team structures, discovery practices, or delivery processes, rate them 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.
目标：10/10分。在评审或创建产品团队结构、发现实践或交付流程时，根据以下原则进行0-10分的评分。10分表示完全符合所有准则；分数越低说明存在需改进的差距。需始终提供当前分数以及达到10分所需的具体改进措施。
Framework
框架内容
1. Product Discovery vs Delivery
1. 产品发现 vs 产品交付
Core concept: Product work has two distinct tracks running in parallel. Discovery determines what to build (addressing risks before engineering investment). Delivery builds production-quality software at scale. Most organizations conflate these and skip discovery entirely, jumping from idea to backlog to sprint.
Why it works: Discovery is cheap and fast; delivery is expensive and slow. By validating ideas through discovery before committing engineering resources, teams avoid the most common failure mode: building something nobody wants. The dual-track approach lets discovery run ahead while delivery ships validated solutions continuously.
Key insights:
- Discovery answers four critical risks: value (will customers buy/use it?), usability (can they figure out how to use it?), feasibility (can engineers build it?), viability (does it work for the business?)
- Discovery output is validated ideas backed by evidence, not PRDs or specifications
- A team should be running 10-20 discovery iterations for every feature that reaches delivery
- Most ideas won't work -- the goal of discovery is to fail fast and cheap
- Discovery is not a phase; it runs continuously in parallel with delivery
- Engineers must participate in discovery, not just receive tickets
Product applications:
| Context | Application | Example |
|---|---|---|
| New feature evaluation | Run discovery to validate all four risks before committing | Prototype and test a new onboarding flow with 5 users before building it |
| Roadmap prioritization | Prioritize problems with strongest discovery evidence | Ship the feature with 4/5 successful user tests over the one the CEO requested |
| Sprint planning | Feed delivery backlog from validated discovery output | Only items that passed discovery testing enter the sprint backlog |
Ethical boundary: Never cherry-pick discovery evidence to justify a predetermined conclusion. Discovery must be honest inquiry, not confirmation theater.
See: references/discovery-techniques.md
核心概念：产品工作包含两条并行的独立轨道。发现轨道决定要构建什么（在投入工程资源前解决风险）；交付轨道负责规模化构建生产级软件。大多数企业会混淆这两者，完全跳过发现环节，直接从想法进入待办清单再到迭代开发。
为何有效：发现环节成本低、速度快；而交付环节成本高、周期长。通过在投入工程资源前，先通过发现环节验证想法，团队可避免最常见的失败模式：构建无人需要的功能。双轨模式让发现环节提前推进，同时交付环节持续输出经过验证的解决方案。
关键见解：
- 发现环节需解决四大核心风险：价值（用户是否愿意购买/使用？）、可用性（用户能否学会使用？）、可行性（工程师能否实现？）、商业可行性（是否符合业务需求？）
- 发现环节的产出是有证据支撑的已验证想法，而非产品需求文档（PRD）或规格说明
- 每进入交付环节的一个功能，团队应完成10-20次发现迭代
- 大多数想法无法落地——发现环节的目标是快速且低成本地试错
- 发现并非阶段性工作，而是与交付环节持续并行开展
- 工程师必须参与发现环节，而非仅接收任务工单
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 新功能评估 | 在投入资源前，通过发现环节验证四大风险 | 在构建新的用户引导流程前，先制作原型并与5名用户测试 |
| 路线图优先级排序 | 优先选择有最充分发现证据支撑的问题 | 优先交付通过4/5用户测试的功能，而非CEO要求的功能 |
| 迭代规划 | 从已验证的发现产出中筛选交付待办项 | 只有通过发现测试的内容才能进入迭代待办清单 |
伦理边界：切勿为了证明预设结论而刻意挑选发现环节的证据。发现必须是诚实的探究，而非“确认式表演”。
参考：references/discovery-techniques.md
2. Empowered Product Teams
2. 赋能型产品团队
Core concept: An empowered product team is a small, durable, cross-functional group (product manager, product designer, and engineers) given a problem to solve rather than features to build. They own both discovery and delivery and are accountable for outcomes, not output.
Why it works: When teams own problems end-to-end, they develop deep domain expertise, customer empathy, and creative solutions that no top-down roadmap can match. Feature teams are mercenaries executing someone else's plan; empowered teams are missionaries who believe in what they are building because they discovered the solution themselves.
Key insights:
- The product manager is not a project manager or backlog administrator -- they are responsible for value and viability
- The product designer owns the user experience holistically, not just visual design
- Engineers are not "resources" -- they are the best source of innovation because they know what is technically possible
- Teams should be durable (stable membership) and co-located or highly collaborative
- The product manager must have deep knowledge of customers, data, business, and industry
- Accountability means the team owns outcomes (adoption, retention, revenue) not output (stories shipped)
Product applications:
| Context | Application | Example |
|---|---|---|
| Team structure | Organize around outcomes, not components | A "new user activation" team owns the entire first-week experience across all surfaces |
| Hiring | Hire product managers for competence, not credentials | Evaluate PM candidates on customer knowledge, data fluency, and business acumen |
| Performance measurement | Measure team results, not velocity or output | Track activation rate improvement, not number of stories completed per sprint |
Ethical boundary: Empowerment requires trust. Never claim to empower teams while overriding their discovery findings with executive mandates. If leadership dictates the solution, the team is not empowered.
See: references/empowered-teams.md
核心概念：赋能型产品团队是小型、稳定的跨职能小组（包含产品经理、产品设计师与工程师），他们被赋予待解决的问题而非待构建的功能。团队全程负责发现与交付环节，并对最终成果而非输出物负责。
为何有效：当团队全程负责问题解决时，他们会积累深厚的领域专业知识、用户同理心，以及自上而下的路线图无法比拟的创新解决方案。功能型团队是执行他人计划的“雇佣兵”；而赋能型团队是“传教士”，因为他们自行探索出了解决方案，所以对自己的工作充满信念。
关键见解：
- 产品经理并非项目经理或待办清单管理员——他们需对价值与商业可行性负责
- 产品设计师需全面负责用户体验，而非仅负责视觉设计
- 工程师不是“资源”——他们是最佳的创新来源，因为他们了解技术实现的可能性
- 团队应保持稳定（成员固定），并集中办公或保持高度协作
- 产品经理需深入了解用户、数据、业务与行业
- 责任感意味着团队对成果指标（如用户 adoption、留存、收入）负责，而非输出物（如完成的故事点数）
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 团队架构 | 围绕成果而非组件构建团队 | 「新用户激活」团队负责用户首周全渠道体验 |
| 招聘 | 基于能力而非资质招聘产品经理 | 评估产品经理候选人的用户洞察能力、数据敏感度与商业判断力 |
| 绩效衡量 | 以成果而非输出作为团队考核指标 | 追踪激活率提升情况，而非每迭代完成的故事点数 |
伦理边界：切勿在宣称赋能团队的同时，用管理层指令推翻他们的发现结论。如果领导层直接指定解决方案，那么团队并非真正被赋能。
参考：references/empowered-teams.md
3. Product Discovery Techniques
3. 产品发现技巧
Core concept: Discovery is a systematic set of techniques for rapidly testing ideas against the four risks (value, usability, feasibility, viability). The core techniques include opportunity assessment, customer interviews, prototyping, and user testing -- all designed to produce evidence quickly and cheaply.
Why it works: Ideas are assumptions. Without rapid testing, teams invest months building on untested assumptions and discover failure only after launch. Discovery techniques are designed to compress learning cycles from months to days, using prototypes, experiments, and direct customer contact.
Key insights:
- Prototypes are the primary discovery tool: high-fidelity for usability testing, live-data for feasibility testing, Wizard of Oz for value testing
- Test with real target users, not colleagues or friends
- Qualitative testing (5 users) reveals usability and value problems; quantitative testing validates at scale
- Customer interviews should focus on behavior (what they did) not opinion (what they say they want)
- Data analysis reveals patterns but not causes -- combine with qualitative discovery
- Feasibility spikes let engineers explore technical risk without full implementation
Product applications:
| Context | Application | Example |
|---|---|---|
| Early-stage idea | Run an opportunity assessment before any design work | Answer: who is it for, what problem does it solve, how will we measure success? |
| Usability validation | High-fidelity prototype tested with 5 target users | Clickable Figma prototype that looks real enough to test task completion |
| Value validation | Fake door test or Wizard of Oz prototype | Add a button for an unbuilt feature and measure click-through to gauge demand |
| Feasibility validation | Engineering spike to assess technical risk | Two-day investigation to determine if real-time sync is achievable with current infrastructure |
Ethical boundary: Never deceive users in discovery testing beyond what is necessary for valid results. Wizard of Oz prototypes are acceptable; collecting payment for non-existent products is not.
See: references/discovery-techniques.md
核心概念：发现环节是一套系统化的技巧，用于快速针对四大风险（价值、可用性、可行性、商业可行性）测试想法。核心技巧包括机会评估、用户访谈、原型制作与用户测试——所有技巧都旨在快速且低成本地获取证据。
为何有效：想法本质是假设。如果不进行快速测试，团队会花费数月时间基于未验证的假设构建产品，直到上线后才发现失败。发现技巧旨在将学习周期从数月压缩至数天，通过原型、实验与直接用户接触实现快速学习。
关键见解：
- 原型是发现环节的核心工具：高保真原型用于可用性测试，实时数据原型用于可行性测试，“绿野仙踪”原型用于价值测试
- 需与真实目标用户测试，而非同事或朋友
- 定性测试（5名用户）可揭示可用性与价值问题；定量测试用于规模化验证
- 用户访谈应聚焦用户行为（他们实际做了什么）而非观点（他们说想要什么）
- 数据分析可揭示模式但无法解释原因——需与定性发现结合使用
- 可行性探索让工程师无需完整实现即可评估技术风险
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 早期想法阶段 | 在任何设计工作前开展机会评估 | 回答：面向谁？解决什么问题？如何衡量成功？有哪些替代方案？ |
| 可用性验证 | 用高保真原型与5名目标用户测试 | 可点击的Figma原型，逼真到足以测试任务完成情况 |
| 价值验证 | 采用“假门测试”或“绿野仙踪”原型 | 添加一个对应未构建功能的按钮，通过点击率衡量需求 |
| 可行性验证 | 工程师开展技术探索评估风险 | 用两天时间调研现有基础设施是否支持实时同步功能 |
伦理边界：在发现测试中，切勿超出验证结果的必要限度欺骗用户。“绿野仙踪”原型是可接受的；但向用户收取不存在产品的费用则不可取。
参考：references/discovery-techniques.md
4. Opportunity Assessment
4. 机会评估
Core concept: Before investing in any product opportunity, evaluate it against a structured set of questions that assess business value, customer need severity, market context, and organizational readiness. The opportunity assessment prevents teams from chasing low-impact work.
Why it works: Most product organizations have far more ideas than capacity. Without rigorous assessment, teams default to building what the loudest stakeholder requests or what competitors have. The opportunity assessment creates a shared framework for evaluating and comparing opportunities objectively.
Key insights:
- The key questions: What business objective does this serve? Who is the target customer? What problem are we solving? How will we know if we succeeded? What alternatives exist?
- Severity of the customer problem matters more than the elegance of the solution
- Market timing is critical -- too early is as dangerous as too late
- Assess organizational readiness: does the team have the skills, technology, and go-to-market capability?
- A strong opportunity assessment kills bad ideas early and focuses resources on high-impact work
- Share opportunity assessments broadly to build alignment before committing resources
Product applications:
| Context | Application | Example |
|---|---|---|
| Quarterly planning | Evaluate all candidate opportunities against consistent criteria | Score each opportunity on customer severity, business impact, and feasibility |
| Stakeholder requests | Respond with structured assessment, not reflexive commitment | "Let me assess this opportunity and share findings before we commit engineering" |
| Resource allocation | Direct capacity toward highest-assessed opportunities | Fund the opportunity with severe customer pain and clear business alignment over the nice-to-have |
See: references/opportunity-assessment.md
核心概念：在投入任何产品机会前，需通过结构化问题评估其商业价值、用户需求迫切度、市场环境与组织准备度。机会评估可避免团队投入低影响力的工作。
为何有效：大多数产品企业的想法数量远超执行能力。如果没有严格的评估，团队会默认构建呼声最高的利益相关方要求的功能，或竞品已有的功能。机会评估提供了一个共享框架，用于客观评估与对比不同机会。
关键见解：
- 核心问题：该机会服务于哪些业务目标？目标用户是谁？解决什么问题？如何衡量成功？有哪些替代方案？
- 用户问题的迫切度比解决方案的优雅程度更重要
- 市场时机至关重要——过早与过晚同样危险
- 评估组织准备度：团队是否具备所需技能、技术与市场化能力？
- 严谨的机会评估可尽早淘汰糟糕的想法，将资源聚焦于高影响力工作
- 广泛分享机会评估结果，在投入资源前达成共识
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 季度规划 | 用统一标准评估所有候选机会 | 从用户需求迫切度、业务影响与可行性维度为每个机会打分 |
| 利益相关方需求 | 用结构化评估替代直接承诺 | “我先对这个机会进行评估，之后分享结果，再确定是否投入工程资源” |
| 资源分配 | 将资源投入得分最高的机会 | 优先投入解决用户迫切痛点且与业务高度对齐的机会，而非锦上添花的功能 |
参考：references/opportunity-assessment.md
5. Product Vision and Strategy
5. 产品愿景与战略
Core concept: Product vision describes the future the team is working toward (2-5 years out). Product strategy is the sequence of target markets, problems, and solutions that will realize the vision. Together, they provide the context that enables empowered teams to make good autonomous decisions.
Why it works: Without a compelling vision, teams lack purpose and make disconnected decisions. Without a clear strategy, teams chase too many opportunities at once and achieve none. Vision inspires; strategy focuses. When teams understand both, they can self-organize around the right problems without constant top-down direction.
Key insights:
- Vision should be inspiring and customer-centric, describing the world you want to create -- not a list of features
- Strategy sequences the hard choices: which customers first, which problems first, which solutions first
- Product principles are the guardrails that guide decision-making when the strategy doesn't specify an answer
- OKRs translate strategy into measurable team objectives -- outcomes, not output
- Outcome-based roadmaps communicate intent without prescribing solutions
- Revisit vision annually and strategy quarterly; principles change rarely
Product applications:
| Context | Application | Example |
|---|---|---|
| Company alignment | Use vision to align all teams toward a shared future | "Every small business can access world-class financial tools" inspires without prescribing features |
| Team autonomy | Use strategy to scope what each team should focus on | "This quarter: reduce churn in mid-market segment by addressing top 3 pain points" |
| Decision-making | Use principles to resolve tradeoffs | "When in doubt, choose simplicity over power" resolves feature scope debates |
Ethical boundary: Never present a product vision that you know is unachievable to motivate teams or attract investment. Vision should be ambitious but honest.
See: references/product-vision.md
核心概念：产品愿景描述团队致力于实现的未来状态（2-5年）。产品战略是实现愿景的目标市场、待解决问题与解决方案的序列组合。两者共同为赋能型团队提供决策上下文，使其能自主做出正确决策。
为何有效：缺乏有吸引力的愿景，团队会失去目标，做出零散的决策。缺乏清晰的战略，团队会同时追逐过多机会，最终一事无成。愿景激发动力；战略聚焦方向。当团队理解两者后，无需持续的自上而下指令，即可围绕正确的问题自主组织工作。
关键见解：
- 愿景应具有启发性且以用户为中心，描述想要创造的世界——而非功能列表
- 战略需做出艰难的选择：先服务哪些用户？先解决哪些问题？先采用哪些解决方案？
- 产品原则是当战略未明确答案时，指导决策的准则
- OKRs将战略转化为可衡量的团队目标——聚焦成果而非输出
- 基于成果的路线图传达意图而非指定解决方案
- 每年回顾愿景，每季度回顾战略；原则极少变更
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 企业对齐 | 用愿景让所有团队朝着共同目标前进 | “每个小企业都能使用世界级的金融工具”——该愿景具有启发性且未指定具体功能 |
| 团队自主权 | 用战略明确每个团队的聚焦方向 | “本季度：通过解决前三大痛点，降低中端市场用户的流失率” |
| 决策制定 | 用原则解决权衡问题 | “存疑时，选择简洁而非复杂”——可解决功能范围的争议 |
伦理边界：切勿为了激励团队或吸引投资，提出明知无法实现的产品愿景。愿景应具有野心但诚实可信。
参考：references/product-vision.md
6. Continuous Value Delivery
6. 持续价值交付
Core concept: Delivery is not a one-time launch event but a continuous process of shipping small, validated increments of value. The goal is to get working software in front of real users as frequently as possible to learn and iterate based on actual behavior.
Why it works: Large, infrequent releases accumulate risk, delay learning, and create coordination nightmares. Continuous delivery enables rapid iteration: ship a validated increment, measure its impact, learn from real usage, and adjust. The feedback loop between delivery and discovery creates a learning engine that compounds over time.
Key insights:
- Ship small and often; every release is a learning opportunity
- Instrumentation is not optional -- if you cannot measure it, you cannot learn from it
- Feature flags enable decoupling deployment from release, allowing controlled rollouts and quick rollbacks
- Minimum viable product (MVP) is the smallest release that tests a hypothesis, not a half-built product
- Delivery velocity enables discovery velocity -- slow delivery means slow learning
- Technical debt is a strategic choice; manage it like financial debt with conscious tradeoffs
Product applications:
| Context | Application | Example |
|---|---|---|
| Release planning | Break large features into independently shippable increments | Release basic search first, then add filters, then add saved searches -- each delivering value |
| Risk management | Use feature flags for controlled rollout | Ship to 5% of users, measure impact, then expand or roll back based on data |
| Learning loops | Instrument every release to feed back into discovery | If search usage is lower than expected, trigger a discovery investigation into why |
Ethical boundary: Never ship untested changes to users without the ability to roll back. Continuous delivery requires continuous responsibility for the user experience.
See: references/case-studies.md
核心概念：交付并非一次性上线事件，而是持续输出经过验证的小增量价值的过程。目标是尽可能频繁地将可用软件交付给真实用户，基于实际行为学习并迭代。
为何有效：大型、低频的发布会积累风险、延迟学习并造成协调噩梦。持续交付支持快速迭代：输出经过验证的增量，衡量其影响，从真实使用中学习并调整。交付与发现之间的反馈循环形成了一个持续学习的引擎，其价值会随时间不断累积。
关键见解：
- 小步快跑，频繁发布；每次发布都是一次学习机会
- 埋点不可或缺——无法衡量就无法从中学习
- 功能开关可实现部署与发布解耦，支持可控发布与快速回滚
- 最小可行产品（MVP）是可测试假设的最小发布版本，而非半成品
- 交付速度决定发现速度——交付缓慢意味着学习缓慢
- 技术债务是一种战略选择；需像管理财务债务一样有意识地权衡
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 发布规划 | 将大型功能拆分为可独立交付的增量 | 先发布基础搜索功能，再添加筛选器，最后添加保存搜索功能——每个增量都交付价值 |
| 风险管理 | 用功能开关实现可控发布 | 先向5%的用户发布，衡量影响后再扩大范围或回滚 |
| 学习循环 | 为每次发布添加埋点，反馈至发现环节 | 如果搜索使用率低于预期，触发发现环节调查原因 |
伦理边界：切勿向用户发布未经测试的变更，且必须具备回滚能力。持续交付要求对用户体验承担持续责任。
参考：references/case-studies.md
Common Mistakes
常见误区
| Mistake | Why It Fails | Fix |
|---|---|---|
| Treating product managers as project managers | Teams become order-takers with no ownership of value or viability | Hire PMs for customer knowledge, data fluency, and business acumen; hold them accountable for outcomes |
| Skipping discovery and going straight to delivery | Teams build features nobody wants, wasting months of engineering effort | Require validated evidence (prototype tests, data analysis) before any idea enters the delivery backlog |
| Measuring output (velocity, stories shipped) instead of outcomes | Teams optimize for shipping speed rather than customer value | Define success metrics around business and customer outcomes: adoption, retention, revenue impact |
| Handing teams solutions instead of problems | Teams become feature factories with no motivation or creativity | Assign objectives and key results, not feature lists; let teams discover the best solution |
| Isolating engineers from customers | The best source of innovation never encounters the actual problem | Include engineers in customer visits, discovery sessions, and prototype testing |
| Creating a product roadmap of promised features with dates | Commitments calcify before discovery can validate; stakeholders expect delivery regardless of evidence | Use outcome-based roadmaps that communicate problems to solve, not features to build |
| Running discovery as a one-time phase before "execution" | Learning stops once building starts; teams cannot adapt to new evidence | Run discovery continuously in parallel with delivery; never stop learning |
| 误区 | 失败原因 | 解决方案 |
|---|---|---|
| 将产品经理视为项目经理 | 团队沦为执行命令的角色，对价值与商业可行性无所有权 | 招聘具备用户洞察能力、数据敏感度与商业判断力的产品经理；以成果为标准考核他们 |
| 跳过发现环节直接进入交付 | 团队构建无人需要的功能，浪费数月工程资源 | 要求任何想法进入交付待办清单前必须提供已验证的证据（原型测试、数据分析） |
| 衡量输出（速度、完成的故事点数）而非成果 | 团队优化交付速度而非用户价值 | 围绕业务与用户成果定义成功指标：用户 adoption、留存、收入影响 |
| 向团队交付解决方案而非问题 | 团队沦为功能工厂，缺乏动力与创造力 | 分配目标与关键结果（OKRs）而非功能列表；让团队探索最佳解决方案 |
| 让工程师与用户隔离 | 最佳创新来源从未接触实际问题 | 让工程师参与用户访谈、发现会议与原型测试 |
| 创建带日期的承诺型功能路线图 | 在发现环节验证前就做出承诺；利益相关方无视证据要求交付 | 采用基于成果的路线图，传达待解决的问题而非待构建的功能 |
| 将发现环节作为“执行”前的一次性阶段 | 一旦开始构建就停止学习；团队无法适应新证据 | 让发现环节与交付环节持续并行开展；永不停止学习 |
Quick Diagnostic
快速诊断
| Question | If No | Action |
|---|---|---|
| Can your PM articulate the top 3 customer problems from direct observation? | PM lacks customer knowledge | Schedule weekly customer interactions: interviews, support shadowing, user testing |
| Does your team test ideas with real users before building? | You are skipping discovery | Implement prototype testing with 5 target users for every significant idea |
| Are engineers involved in discovery, not just delivery? | You are underutilizing your best innovators | Invite engineers to customer interviews and prototype sessions |
| Does your team own outcomes (metrics) rather than output (features)? | You have a feature factory | Replace feature roadmaps with OKRs tied to business and customer outcomes |
| Can team members explain the product vision and strategy? | Teams lack context for autonomous decisions | Create and evangelize a compelling vision document and quarterly strategy |
| Do stakeholders bring problems, not solutions, to the team? | Leadership is dictating features | Coach stakeholders on the discovery process; pre-sell with opportunity assessments |
| Do you ship validated increments at least every two weeks? | Delivery is too slow for effective learning | Break work into smaller increments; invest in CI/CD and feature flags |
| 问题 | 如果答案为否 | 行动方案 |
|---|---|---|
| 你的产品经理能否基于直接观察，清晰阐述前三大用户问题？ | 产品经理缺乏用户洞察 | 安排每周用户互动：访谈、支持工作旁听、用户测试 |
| 你的团队在构建前是否会与真实用户测试想法？ | 你正在跳过发现环节 | 对每个重要想法，用5名目标用户开展原型测试 |
| 工程师是否参与发现环节，而非仅负责交付？ | 你未充分利用最优秀的创新者 | 邀请工程师参与用户访谈与原型会议 |
| 你的团队是否对成果（指标）而非输出（功能）负责？ | 你拥有的是功能工厂 | 用与业务和用户成果绑定的OKRs替代功能路线图 |
| 团队成员能否解释产品愿景与战略？ | 团队缺乏自主决策的上下文 | 创建并推广有吸引力的愿景文档与季度战略 |
| 利益相关方向团队提出的是问题而非解决方案？ | 领导层在指定功能 | 向利益相关方传授发现流程；用机会评估提前达成共识 |
| 你的团队是否至少每两周交付一次经过验证的增量？ | 交付速度过慢，无法有效学习 | 将工作拆分为更小的增量；投入CI/CD与功能开关建设 |
Reference Files
参考文件
- discovery-techniques.md: Opportunity discovery, solution discovery, prototyping techniques, user testing, and the four risks framework
- empowered-teams.md: Product team structure, roles, missionary vs mercenary teams, coaching, and accountability
- opportunity-assessment.md: Evaluating product opportunities, business alignment, market assessment, and prioritization
- product-vision.md: Creating product vision, strategy, principles, OKRs, and outcome-based roadmaps
- stakeholder-management.md: Managing stakeholders, evangelism, getting buy-in, dealing with HiPPOs, and building executive trust
- case-studies.md: Scenarios showing empowered product team principles applied to different company stages
- discovery-techniques.md：机会发现、解决方案发现、原型制作技巧、用户测试以及四大风险框架
- empowered-teams.md：产品团队架构、角色、传教士vs雇佣兵团队、指导与问责
- opportunity-assessment.md：产品机会评估、业务对齐、市场评估与优先级排序
- product-vision.md：产品愿景创建、战略、原则、OKRs与基于成果的路线图
- stakeholder-management.md：利益相关方管理、理念推广、获取支持、处理HiPPOs（职位最高者的意见）与建立管理层信任
- case-studies.md：展示赋能型产品团队原则在不同企业阶段的应用场景
Further Reading
延伸阅读
This skill is based on the empowered product teams framework developed by Marty Cagan. For the complete methodology, case studies, and deeper insights:
- "Inspired: How to Create Tech Products Customers Love" by Marty Cagan
- "Empowered: Ordinary People, Extraordinary Products" by Marty Cagan and Chris Jones
本技能基于Marty Cagan提出的赋能型产品团队框架。如需了解完整方法论、案例研究与深度见解：
- 《Inspired: How to Create Tech Products Customers Love》（《启示录：打造用户喜爱的产品》）作者：Marty Cagan
- 《Empowered: Ordinary People, Extraordinary Products》（《赋能：打造卓越产品的平凡团队》）作者：Marty Cagan与Chris Jones
About the Author
关于作者
Marty Cagan is the founder of the Silicon Valley Product Group (SVPG) and one of the most influential voices in modern product management. Before founding SVPG, Cagan served as VP of Product at eBay, where he led the product team during the company's rapid growth. He held senior product and technology roles at Hewlett-Packard, Netscape Communications, and America Online. Cagan has spent decades studying what separates the best product companies -- including Google, Amazon, Apple, and Netflix -- from the rest. His book Inspired (first edition 2008, second edition 2017) became the definitive guide to modern product management and is required reading at product organizations worldwide. His follow-up, Empowered (2020), extends the framework to address the organizational and leadership changes required to build truly empowered product teams. Through SVPG, Cagan coaches product leaders and teams at companies ranging from startups to Fortune 500 enterprises, advocating for the empowered team model over the feature-factory approach that dominates most organizations.
Marty Cagan是硅谷产品集团（SVPG）的创始人，也是现代产品管理领域最具影响力的声音之一。创立SVPG之前，Cagan曾担任eBay产品副总裁，在公司快速增长期领导产品团队。他曾在惠普、网景通信与美国在线担任高级产品与技术职位。Cagan花了数十年时间研究顶尖产品公司（包括Google、Amazon、Apple与Netflix）与其他企业的差异。他的著作《Inspired》（第一版2008年，第二版2017年）成为现代产品管理的权威指南，被全球各地的产品组织列为必读资料。他的续作《Empowered》（2020年）扩展了该框架，涵盖构建真正赋能型产品团队所需的组织与领导力变革。通过SVPG，Cagan为从初创企业到财富500强的企业提供产品领导者与团队指导，倡导赋能型团队模式，取代在大多数企业中占主导地位的功能工厂模式。