product-architecture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product Architecture System

产品架构系统

"A roadmap is not a feature list. It's a sequence of bets on how to create value."
This skill covers the Product System — structuring what you're building and why now. It turns validated opportunities into bets, organizes work into capability blocks, and creates roadmaps that communicate strategy without false precision.
Related skills:
product-strategy
,
product-discovery
,
product-delivery
,
ai-native-product
,
product-leadership

"路线图不是功能列表,它是一系列关于如何创造价值的投注。"
本技能覆盖产品体系——梳理你正在构建的内容以及当下推进的原因。它将经过验证的机会转化为投注项,将工作归类到不同能力模块中,同时产出能够传递战略且不存在虚假精确性的路线图。
相关技能:
product-strategy
,
product-discovery
,
product-delivery
,
ai-native-product
,
product-leadership

When to Use This Skill

何时使用该技能

Use this skill when:
  • Organizing your product into capability blocks
  • Converting discovery opportunities into prioritized bets
  • Building or updating your roadmap
  • Writing solution briefs before engineering commits
  • Preparing for planning cycles (quarterly, annually)
  • Communicating product direction to stakeholders
Cadence: Quarterly planning, ongoing refinement | Owner: PM with trio input

当你需要做以下事项时使用本技能:
  • 将产品梳理为不同的能力模块
  • 将调研发现的机会转化为有优先级的投注项
  • 搭建或更新你的路线图
  • 在研发确认投入前撰写解决方案概要
  • 为规划周期(季度、年度)做准备
  • 向利益相关方同步产品方向
使用频率: 季度规划、持续优化 | 负责人: 产品经理,需产品/设计/研发三方输入

The Problem This Solves

解决的问题

Most teams have:
  1. Feature lists masquerading as roadmaps
  2. No clear connection between strategy and what gets built
  3. Solution briefs that are either too vague or too prescriptive
  4. Backlogs organized by urgency, not impact
The Product Architecture System creates a clear hierarchy: Strategy → Bets → Blocks → Features, with traceable connections at each level.

大多数团队都存在以下问题:
  1. 伪装成路线图的功能列表
  2. 战略和实际研发内容之间没有明确关联
  3. 解决方案概要要么过于模糊要么过于死板
  4. 待办事项按紧急度而非影响力排序
产品架构系统搭建了清晰的层级: 战略 → 投注项 → 模块 → 功能,每个层级之间都有可追溯的关联。

Philosophy

核心理念

Core Beliefs

核心信念

  1. Bets over features — We're not building features, we're placing bets on outcomes
  2. Roadmaps show direction, not dates — Commitments are for sprints, not quarters
  3. Problems before solutions — Every bet must connect to a validated opportunity
  4. Solution briefs over PRDs — Just enough spec to start, emergent detail through building
  5. Blocks organize complexity — Group capabilities by customer value, not technical architecture
  1. 投注优先于功能 —— 我们不是在做功能,而是对产出结果下注
  2. 路线图展示方向而非日期 —— 承诺只适用于 sprint,不适用于季度周期
  3. 问题优先于解决方案 —— 每个投注项都必须关联经过验证的机会
  4. 解决方案概要优先于PRD —— 只需提供足够启动开发的说明,细节在研发过程中逐步明确
  5. 模块用于梳理复杂度 —— 按客户价值而非技术架构分组能力

What This Framework Rejects

本框架不认可的做法

  • Feature factories (build what's requested, not what matters)
  • Date-driven roadmaps (false precision creates false expectations)
  • Disconnected backlogs (no traceability to strategy)
  • Waterfall PRDs (200-page specs nobody reads)
  • Tech-driven architecture (organizing by system, not customer)

  • 功能工厂(只做被要求的内容,而非真正有价值的内容)
  • 日期驱动的路线图(虚假精确性会带来错误预期)
  • 无关联的待办列表(无法追溯到战略)
  • 瀑布式PRD(没人读的200页说明文档)
  • 技术驱动的架构(按系统而非客户需求组织内容)

Progress Tracking

进度跟踪

Display progress during architecture work:
[████░░░░░░░░░░░░░░░░] 25% — Phase 1/4: Mapping Capability Blocks
[████████░░░░░░░░░░░░] 50% — Phase 2/4: Converting Opportunities to Bets
[████████████░░░░░░░░] 75% — Phase 3/4: Writing Solution Briefs & Roadmap
[████████████████████] 100% — Phase 4/4: Communicating Product Direction
架构工作期间的进度展示:
[████░░░░░░░░░░░░░░░░] 25% — 第1/4阶段:梳理能力模块
[████████░░░░░░░░░░░░] 50% — 第2/4阶段:将机会转化为投注项
[████████████░░░░░░░░] 75% — 第3/4阶段:撰写解决方案概要与路线图
[████████████████████] 100% — 第4/4阶段:同步产品方向

Framework Components

框架组成

1. Product Blocks & Features

1. 产品模块与功能

What is a Block?
A block is a capability area that delivers distinct customer value. Blocks organize your product by what customers can accomplish, not by technical architecture.
Good Block Examples:
  • "Onboarding" (helps users get started)
  • "Reporting" (helps users understand performance)
  • "Collaboration" (helps teams work together)
  • "Integrations" (connects to existing workflows)
Bad Block Examples (Tech-Driven):
  • "Backend services"
  • "API layer"
  • "Database module"
Block Portfolio View:
BlockOwnerMaturityStrategic PriorityActive Bets
Onboarding[PM]GrowthP12
Reporting[PM]MatureP21
Collaboration[PM]NewP13
Integrations[PM]GrowthP30
Block Maturity Stages:
StageDefinitionFocus
NewUnproven, high uncertaintyFind PMF within block
GrowthValidated, expandingScale and optimize
MatureStable, well-understoodMaintain, incremental improvements
SunsetDeclining valueDeprecate or replace
Features Within Blocks:
Each block contains features. Features are the specific capabilities users interact with.
BLOCK: Reporting
├── Feature: Dashboard builder
├── Feature: Scheduled reports
├── Feature: Export to PDF
└── Feature: Custom metrics
0→1 Mode: One block, maybe two. Don't over-structure before you have PMF.
Scaling Mode: Multiple blocks with clear owners. Block health reviews quarterly.

什么是模块?
模块是能够交付独立客户价值的能力领域。模块按用户可实现的目标组织产品,而非按技术架构划分。
好的模块示例:
  • "新手引导"(帮助用户上手)
  • "数据报表"(帮助用户了解性能)
  • "协作能力"(帮助团队协同工作)
  • "集成能力"(对接现有工作流)
不好的模块示例(技术驱动):
  • "后端服务"
  • "API层"
  • "数据库模块"
模块总览视图:
模块负责人成熟度战略优先级活跃投注项数量
新手引导[PM]增长期P12
数据报表[PM]成熟期P21
协作能力[PM]新增期P13
集成能力[PM]增长期P30
模块成熟度阶段:
阶段定义重点
新增期未经验证,不确定性高在模块内找到PMF
增长期经过验证,正在扩张规模化与优化
成熟期稳定,认知清晰维护,渐进式改进
衰退期价值不断下降下线或替换
模块内的功能:
每个模块包含多个功能。功能是用户可交互的具体能力。
模块: 数据报表
├── 功能: 仪表盘搭建器
├── 功能: 定时报表
├── 功能: 导出为PDF
└── 功能: 自定义指标
0→1阶段: 1个模块,最多2个。在找到PMF前不要过度设计结构。
规模化阶段: 多个模块,有明确的负责人。每季度做模块健康度评审。

2. The Bet Backlog

2. 投注项待办列表

What is a Bet?
A bet is a time-boxed investment with a hypothesis, success metrics, and kill criteria. Unlike features, bets explicitly acknowledge uncertainty.
Bet Format:
BET: [Name]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Hypothesis: We believe that [action] will result in [outcome]
Target metric: [Metric] from [baseline] to [target]
Timebox: [Duration]
Block: [Which block this belongs to]
Opportunity: [Link to validated opportunity in OST]
Kill criteria: [When we stop]
Scale criteria: [When we double down]
Effort: [T-shirt size]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Bet Categories:
CategoryDescriptionExample
Value creationNew capabilities that solve customer problemsNew reporting feature
GrowthAcquisition, activation, expansionOnboarding improvements
PlatformInfrastructure, scalability, efficiencyPerformance optimization
TrustSecurity, compliance, reliabilitySOC 2 certification
MoatBuilding defensibilityProprietary data features
Portfolio Balance:
CategoryTarget AllocationRationale
Core (proven, incremental)70%Keep the lights on, serve existing customers
Adjacent (related, moderate risk)20%Expand to new use cases or segments
Transformational (new, high risk)10%Explore future opportunities
Bet Prioritization:
Use ICE, RICE, or simple compare-and-contrast:
BetImpactConfidenceEffortScorePriority
AHighHighMedium[X]P0
BHighLowLow[X]P1
CMediumHighLow[X]P1
Backlog Rules:
  • Every bet traces to a validated opportunity
  • Maximum 3 P0 bets at any time
  • Bets without kill criteria don't make the backlog
  • Review and reprioritize quarterly (or when evidence changes)

什么是投注项?
投注项是有时间限制的投入,包含假设、成功指标和终止条件。和功能不同,投注项明确承认不确定性。
投注项格式:
投注项: [名称]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
假设: 我们相信[行动]将带来[结果]
目标指标: [指标]从[基准值]提升到[目标值]
时间限制: [时长]
所属模块: [该投注项归属的模块]
关联机会: [链接到OST中经过验证的机会]
终止条件: [我们停止投入的节点]
规模化条件: [我们加倍投入的节点]
投入成本: [T恤尺码估算]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
投注项分类:
分类描述示例
价值创造解决客户问题的新能力新的报表功能
增长获客、激活、扩张新手引导优化
平台基础设施、扩展性、效率性能优化
信任安全、合规、可靠性SOC 2认证
护城河构建竞争壁垒专有数据功能
投入组合平衡:
分类目标占比逻辑
核心(经过验证,渐进式)70%保障业务正常运行,服务现有客户
相邻(相关,中等风险)20%拓展到新的使用场景或用户群体
变革性(全新,高风险)10%探索未来机会
投注项优先级排序:
使用ICE、RICE或简单的对比法:
投注项影响力置信度投入成本得分优先级
A[X]P0
B[X]P1
C[X]P1
待办列表规则:
  • 每个投注项都要关联经过验证的机会
  • 任何时候最多只能有3个P0优先级的投注项
  • 没有终止条件的投注项不能进入待办列表
  • 每季度(或有新的证据时)评审并重新调整优先级

3. Roadmap

3. 路线图

Roadmap Philosophy:
A roadmap is a communication tool, not a contract. It shows direction and priorities, not delivery dates.
Roadmap Formats:
FormatAudiencePurpose
Now / Next / LaterTeam, stakeholdersCurrent priorities without dates
Quarterly themesExecutives, boardStrategic direction by time horizon
Outcome roadmapTeam, stakeholdersWhat outcomes we're targeting when
Now / Next / Later Format:
NOW (Current quarter - high confidence)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• [Bet A] — [Brief description]
• [Bet B] — [Brief description]

NEXT (Next quarter - medium confidence)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• [Bet C] — [Brief description]
• [Bet D] — [Brief description]

LATER (Future - low confidence, subject to change)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• [Bet E] — [Brief description]
• [Bet F] — [Brief description]
Quarterly Themes Format:
QuarterThemeKey BetsTarget Outcome
Q1"Foundation"[Bets][Outcome metric]
Q2"Scale"[Bets][Outcome metric]
Q3"Expand"[Bets][Outcome metric]
Q4"Optimize"[Bets][Outcome metric]
Outcome Roadmap Format:
Instead of showing features, show outcomes:
TimeframeOutcomeHow We'll KnowKey Bets
Q1Improve activation rate30% → 45%[Bets focused on this]
Q2Reduce churn5% → 3%[Bets focused on this]
H2Enter new segment10 customers[Bets focused on this]
Roadmap Anti-Patterns:
Anti-PatternWhy It FailsInstead
Date commitmentsCreates false expectationsTime horizons (Now/Next/Later)
Feature listsNo strategic contextOutcome-focused themes
Too detailedCan't see forest for treesHigh-level, drill down on request
Never updatedBecomes fictionReview quarterly minimum
No trade-offs visibleHides resource constraintsShow what we're NOT doing
0→1 Mode: 4-6 week horizon max. Roadmap changes weekly. Focus on learning milestones.
Scaling Mode: Quarterly themes. Public roadmap for customers. Cross-team dependencies tracked.

路线图理念:
路线图是沟通工具,不是合同。它展示方向和优先级,不是交付日期。
路线图格式:
格式受众用途
现在/下一步/未来团队、利益相关方无日期的当前优先级展示
季度主题高管、董事会按时间周期的战略方向展示
结果导向路线图团队、利益相关方不同周期的目标结果展示
现在/下一步/未来格式:
现在(当前季度 - 高置信度)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• [投注项A] — [简短描述]
• [投注项B] — [简短描述]

下一步(下个季度 - 中等置信度)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• [投注项C] — [简短描述]
• [投注项D] — [简短描述]

未来(更长期 - 低置信度,可能调整)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• [投注项E] — [简短描述]
• [投注项F] — [简短描述]
季度主题格式:
季度主题核心投注项目标结果
Q1"基础搭建"[投注项列表][结果指标]
Q2"规模化"[投注项列表][结果指标]
Q3"拓展"[投注项列表][结果指标]
Q4"优化"[投注项列表][结果指标]
结果导向路线图格式:
不展示功能,而是展示目标结果:
时间周期结果衡量标准核心投注项
Q1提升激活率30% → 45%[聚焦该目标的投注项]
Q2降低流失率5% → 3%[聚焦该目标的投注项]
下半年进入新细分市场10个客户[聚焦该目标的投注项]
路线图反模式:
反模式失败原因替代方案
固定日期承诺带来错误预期时间周期划分(现在/下一步/未来)
功能列表没有战略背景结果导向的主题
过于详细只见树木不见森林高粒度展示,按需下钻细节
从不更新变成虚构内容至少每季度评审一次
看不到取舍隐藏资源限制明确展示我们不会做的内容
0→1阶段: 最多4-6周的周期。路线图每周调整,聚焦学习里程碑。
规模化阶段: 季度主题。对外发布客户可见的公开路线图,跟踪跨团队依赖。

4. Solution Briefs

4. 解决方案概要

What is a Solution Brief?
A solution brief is a lightweight spec that provides enough context to start building without over-prescribing the solution. It replaces heavyweight PRDs.
Solution Brief Format:
SOLUTION BRIEF: [Name]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CONTEXT
• Bet: [Link to bet]
• Opportunity: [Link to validated opportunity]
• Block: [Which block]

THE PROBLEM
[2-3 sentences on what problem we're solving and for whom]

CUSTOMER QUOTE
"[Actual quote from discovery]"

SUCCESS METRICS
• Primary: [Metric] from [baseline] to [target]
• Secondary: [Metric]
• Guardrail: [What we won't let degrade]

SOLUTION APPROACH
[High-level description of approach — NOT detailed specs]

KEY DECISIONS MADE
• [Decision 1]: [Rationale]
• [Decision 2]: [Rationale]

OPEN QUESTIONS
• [Question 1]
• [Question 2]

CONSTRAINTS
• Must: [Non-negotiable requirements]
• Must not: [Explicit exclusions]
• Timeline: [If relevant]

ASSUMPTIONS TO VALIDATE
• [Assumption 1]
• [Assumption 2]

OUT OF SCOPE
• [What we're explicitly NOT doing]
• [What we're explicitly NOT doing]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Solution Brief Principles:
PrincipleWhy
Problem firstEveryone must understand WHY before HOW
Customer evidenceGrounds the work in reality
Metrics up frontDefines success before building
Open questions explicitAcknowledges uncertainty
Out of scope clearPrevents scope creep
What NOT to Include:
  • Detailed UI specs (emerge through design process)
  • Technical implementation details (engineering decides)
  • Project timelines (delivery system handles)
  • Edge cases (discover through building)
Brief Evolution:
StageDetail LevelWho Owns
DraftProblem + metrics + high-level approachPM
Shaped+ Key decisions + constraintsPM + Design
Ready+ Engineering input on feasibilityTrio
In progressLiving doc, updated as we learnTrio
0→1 Mode: Brief can be a Slack message or Notion doc. Speed > formality.
Scaling Mode: Template enforced. Linked to bet tracking. Archive for future reference.

什么是解决方案概要?
解决方案概要是轻量的说明文档,提供足够的上下文来启动研发,同时不会对解决方案做过度限定。它替代了厚重的PRD。
解决方案概要格式:
解决方案概要: [名称]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

背景
• 关联投注项: [投注项链接]
• 关联机会: [经过验证的机会链接]
• 所属模块: [归属的模块]

问题描述
[2-3句话说明我们要解决什么问题,为谁解决]

客户原话
"[调研过程中获取的真实用户反馈]"

成功指标
• 核心指标: [指标]从[基准值]到[目标值]
• 次要指标: [指标]
• 防护指标: [我们不允许下降的指标]

解决方案方向
[方向的高粒度描述 —— 不是详细的规格说明]

已确定的关键决策
• [决策1]: [决策逻辑]
• [决策2]: [决策逻辑]

待确认问题
• [问题1]
• [问题2]

限制条件
• 必须满足: [不可协商的要求]
• 必须排除: [明确不包含的内容]
• 时间线: [如果相关的话]

待验证的假设
• [假设1]
• [假设2]

不在范围内
• [我们明确不会做的内容]
• [我们明确不会做的内容]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
解决方案概要原则:
原则原因
问题优先所有人都必须先理解为什么做,再考虑怎么做
客户证据基于现实开展工作
提前明确指标在研发前定义成功标准
明确待确认问题承认不确定性
清晰划定范围防止范围蔓延
不应包含的内容:
  • 详细的UI规格(在设计过程中逐步明确)
  • 技术实现细节(由研发团队决定)
  • 项目时间线(由交付体系处理)
  • 边缘场景(在研发过程中逐步发现)
概要演进过程:
阶段细节程度负责人
草稿问题 + 指标 + 高粒度方向产品经理
成型+ 关键决策 + 限制条件产品经理 + 设计师
就绪+ 研发对可行性的输入产品/设计/研发三方
进行中活文档,随认知更新产品/设计/研发三方
0→1阶段: 概要可以是Slack消息或者Notion文档,速度 > 形式。
规模化阶段: 强制使用模板,关联到投注项跟踪,归档供未来参考。

Key Outputs

核心产出

OutputDescriptionUpdate Cadence
Block portfolioMap of capability areas with ownersQuarterly
Bet backlogPrioritized list of betsWeekly refinement, quarterly reprioritization
RoadmapNow/Next/Later or quarterly themesMonthly update, quarterly refresh
Solution briefsLightweight specs for active betsAs bets move to building

产出描述更新频率
模块总览带负责人的能力领域地图每季度
投注项待办列表有优先级的投注项列表每周优化,每季度重新排序
路线图现在/下一步/未来或者季度主题每月更新,每季度刷新
解决方案概要活跃投注项的轻量说明文档当投注项进入研发阶段时产出

Templates

模板

This skill includes templates in the
templates/
directory:
  • block-portfolio.md
    — Block inventory and health tracking
  • bet-backlog.md
    — Bet format and prioritization
  • roadmap.md
    — Now/Next/Later and quarterly themes
  • solution-brief.md
    — Lightweight spec template

本技能在
templates/
目录下包含模板:
  • block-portfolio.md
    —— 模块清单和健康度跟踪
  • bet-backlog.md
    —— 投注项格式和优先级排序
  • roadmap.md
    —— 现在/下一步/未来和季度主题模板
  • solution-brief.md
    —— 轻量说明文档模板

Using This Skill with Claude

配合Claude使用本技能

Ask Claude to:
  1. Design block structure: "Help me organize [product] into capability blocks"
  2. Convert opportunity to bet: "Turn this opportunity into a bet with hypothesis and metrics"
  3. Prioritize bets: "Help me prioritize these bets using [framework]"
  4. Create roadmap: "Build a Now/Next/Later roadmap from these bets"
  5. Review roadmap: "Critique this roadmap for common anti-patterns"
  6. Write solution brief: "Create a solution brief for [bet]"
  7. Scope solution: "What should be in vs. out of scope for [bet]?"
  8. Define success metrics: "What metrics should we track for [bet]?"
  9. Plan quarterly themes: "Help me define themes for the next 4 quarters"
  10. Balance portfolio: "Is my bet portfolio balanced? What's missing?"

可以让Claude做以下事:
  1. 设计模块结构: "帮我把[产品]梳理为不同的能力模块"
  2. 将机会转化为投注项: "把这个机会转化为带假设和指标的投注项"
  3. 投注项优先级排序: "帮我用[框架]给这些投注项排序"
  4. 创建路线图: "基于这些投注项搭建一个现在/下一步/未来的路线图"
  5. 评审路线图: "检查这个路线图有没有常见的反模式"
  6. 撰写解决方案概要: "为[投注项]创建一个解决方案概要"
  7. 界定解决方案范围: "[投注项]的范围应该包含什么,不包含什么?"
  8. 定义成功指标: "[投注项]应该跟踪什么指标?"
  9. 规划季度主题: "帮我为接下来4个季度定义主题"
  10. 平衡投入组合: "我的投注项组合平衡吗?缺少什么?"

Connection to Other Skills

和其他技能的关联

When you need to...Use skill
Define strategy that informs bets
product-strategy
Validate opportunities before betting
product-discovery
Plan delivery and measurement
product-delivery
Adapt for AI product bets
ai-native-product
Manage portfolio across products
product-leadership

当你需要...使用技能
定义为投注项提供依据的战略
product-strategy
在投注前验证机会
product-discovery
规划交付和衡量方式
product-delivery
适配AI产品投注
ai-native-product
管理跨产品的组合
product-leadership

Anti-Patterns to Avoid

需要避免的反模式

Anti-PatternWhy It FailsInstead
Feature factoryNo connection to outcomesBet-based backlog
Date-driven roadmapFalse precision, broken trustTime horizons
PRD novelsNobody reads, out of date instantlySolution briefs
Stakeholder-driven backlogPolitics over impactEvidence-based prioritization
Tech-organized blocksDoesn't reflect customer valueCustomer-outcome blocks
No kill criteriaZombie projects never dieEvery bet has exit conditions

反模式失败原因替代方案
功能工厂和结果没有关联基于投注项的待办列表
日期驱动的路线图虚假精确性,破坏信任时间周期划分
PRD长篇大论没人读,很快就过时解决方案概要
利益相关方驱动的待办列表政治优先于影响力基于证据的优先级排序
按技术组织的模块不反映客户价值基于客户结果的模块
没有终止条件僵尸项目永远不会终止每个投注项都要有退出条件

Quick Reference: Architecture Quality Checklist

快速参考:架构质量检查清单

Before committing to a quarter:
  • Every bet traces to opportunity — No orphan features
  • Kill criteria defined — Know when to stop
  • Portfolio is balanced — 70/20/10 or similar
  • Roadmap shows trade-offs — What we're NOT doing is clear
  • Solution briefs exist — For all "Now" bets
  • Metrics are measurable — Can actually track success
  • Team has capacity — Bets fit within available resources
  • Dependencies mapped — Know what blocks what

在确认季度规划前检查:
  • 每个投注项都关联机会 —— 没有孤立的功能
  • 已定义终止条件 —— 知道什么时候停止
  • 投入组合平衡 —— 70/20/10或类似比例
  • 路线图展示了取舍 —— 明确我们不会做的内容
  • 解决方案概要已就绪 —— 所有「现在」阶段的投注项都有
  • 指标可衡量 —— 确实能跟踪成功情况
  • 团队有足够容量 —— 投注项在可用资源范围内
  • 依赖已梳理 —— 知道什么内容会阻塞进度

Sources & Influences

来源与参考

  • Marty Cagan — INSPIRED, EMPOWERED
  • Ryan Singer — Shape Up (Basecamp)
  • Teresa Torres — Continuous Discovery Habits
  • Gibson Biddle — Product strategy frameworks

  • Marty Cagan —— 《INSPIRED》、《EMPOWERED》
  • Ryan Singer —— 《Shape Up》(Basecamp)
  • Teresa Torres —— 《Continuous Discovery Habits》
  • Gibson Biddle —— 产品战略框架