product-architecture
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseProduct 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-strategyproduct-discoveryproduct-deliveryai-native-productproduct-leadership"路线图不是功能列表,它是一系列关于如何创造价值的投注。"
本技能覆盖产品体系——梳理你正在构建的内容以及当下推进的原因。它将经过验证的机会转化为投注项,将工作归类到不同能力模块中,同时产出能够传递战略且不存在虚假精确性的路线图。
相关技能: , , , ,
product-strategyproduct-discoveryproduct-deliveryai-native-productproduct-leadershipWhen 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:
- Feature lists masquerading as roadmaps
- No clear connection between strategy and what gets built
- Solution briefs that are either too vague or too prescriptive
- Backlogs organized by urgency, not impact
The Product Architecture System creates a clear hierarchy: Strategy → Bets → Blocks → Features, with traceable connections at each level.
大多数团队都存在以下问题:
- 伪装成路线图的功能列表
- 战略和实际研发内容之间没有明确关联
- 解决方案概要要么过于模糊要么过于死板
- 待办事项按紧急度而非影响力排序
产品架构系统搭建了清晰的层级: 战略 → 投注项 → 模块 → 功能,每个层级之间都有可追溯的关联。
Philosophy
核心理念
Core Beliefs
核心信念
- Bets over features — We're not building features, we're placing bets on outcomes
- Roadmaps show direction, not dates — Commitments are for sprints, not quarters
- Problems before solutions — Every bet must connect to a validated opportunity
- Solution briefs over PRDs — Just enough spec to start, emergent detail through building
- Blocks organize complexity — Group capabilities by customer value, not technical architecture
- 投注优先于功能 —— 我们不是在做功能,而是对产出结果下注
- 路线图展示方向而非日期 —— 承诺只适用于 sprint,不适用于季度周期
- 问题优先于解决方案 —— 每个投注项都必须关联经过验证的机会
- 解决方案概要优先于PRD —— 只需提供足够启动开发的说明,细节在研发过程中逐步明确
- 模块用于梳理复杂度 —— 按客户价值而非技术架构分组能力
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:
| Block | Owner | Maturity | Strategic Priority | Active Bets |
|---|---|---|---|---|
| Onboarding | [PM] | Growth | P1 | 2 |
| Reporting | [PM] | Mature | P2 | 1 |
| Collaboration | [PM] | New | P1 | 3 |
| Integrations | [PM] | Growth | P3 | 0 |
Block Maturity Stages:
| Stage | Definition | Focus |
|---|---|---|
| New | Unproven, high uncertainty | Find PMF within block |
| Growth | Validated, expanding | Scale and optimize |
| Mature | Stable, well-understood | Maintain, incremental improvements |
| Sunset | Declining value | Deprecate 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 metrics0→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] | 增长期 | P1 | 2 |
| 数据报表 | [PM] | 成熟期 | P2 | 1 |
| 协作能力 | [PM] | 新增期 | P1 | 3 |
| 集成能力 | [PM] | 增长期 | P3 | 0 |
模块成熟度阶段:
| 阶段 | 定义 | 重点 |
|---|---|---|
| 新增期 | 未经验证,不确定性高 | 在模块内找到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:
| Category | Description | Example |
|---|---|---|
| Value creation | New capabilities that solve customer problems | New reporting feature |
| Growth | Acquisition, activation, expansion | Onboarding improvements |
| Platform | Infrastructure, scalability, efficiency | Performance optimization |
| Trust | Security, compliance, reliability | SOC 2 certification |
| Moat | Building defensibility | Proprietary data features |
Portfolio Balance:
| Category | Target Allocation | Rationale |
|---|---|---|
| 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:
| Bet | Impact | Confidence | Effort | Score | Priority |
|---|---|---|---|---|---|
| A | High | High | Medium | [X] | P0 |
| B | High | Low | Low | [X] | P1 |
| C | Medium | High | Low | [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:
| Format | Audience | Purpose |
|---|---|---|
| Now / Next / Later | Team, stakeholders | Current priorities without dates |
| Quarterly themes | Executives, board | Strategic direction by time horizon |
| Outcome roadmap | Team, stakeholders | What 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:
| Quarter | Theme | Key Bets | Target 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:
| Timeframe | Outcome | How We'll Know | Key Bets |
|---|---|---|---|
| Q1 | Improve activation rate | 30% → 45% | [Bets focused on this] |
| Q2 | Reduce churn | 5% → 3% | [Bets focused on this] |
| H2 | Enter new segment | 10 customers | [Bets focused on this] |
Roadmap Anti-Patterns:
| Anti-Pattern | Why It Fails | Instead |
|---|---|---|
| Date commitments | Creates false expectations | Time horizons (Now/Next/Later) |
| Feature lists | No strategic context | Outcome-focused themes |
| Too detailed | Can't see forest for trees | High-level, drill down on request |
| Never updated | Becomes fiction | Review quarterly minimum |
| No trade-offs visible | Hides resource constraints | Show 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:
| Principle | Why |
|---|---|
| Problem first | Everyone must understand WHY before HOW |
| Customer evidence | Grounds the work in reality |
| Metrics up front | Defines success before building |
| Open questions explicit | Acknowledges uncertainty |
| Out of scope clear | Prevents 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:
| Stage | Detail Level | Who Owns |
|---|---|---|
| Draft | Problem + metrics + high-level approach | PM |
| Shaped | + Key decisions + constraints | PM + Design |
| Ready | + Engineering input on feasibility | Trio |
| In progress | Living doc, updated as we learn | Trio |
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
核心产出
| Output | Description | Update Cadence |
|---|---|---|
| Block portfolio | Map of capability areas with owners | Quarterly |
| Bet backlog | Prioritized list of bets | Weekly refinement, quarterly reprioritization |
| Roadmap | Now/Next/Later or quarterly themes | Monthly update, quarterly refresh |
| Solution briefs | Lightweight specs for active bets | As bets move to building |
| 产出 | 描述 | 更新频率 |
|---|---|---|
| 模块总览 | 带负责人的能力领域地图 | 每季度 |
| 投注项待办列表 | 有优先级的投注项列表 | 每周优化,每季度重新排序 |
| 路线图 | 现在/下一步/未来或者季度主题 | 每月更新,每季度刷新 |
| 解决方案概要 | 活跃投注项的轻量说明文档 | 当投注项进入研发阶段时产出 |
Templates
模板
This skill includes templates in the directory:
templates/- — Block inventory and health tracking
block-portfolio.md - — Bet format and prioritization
bet-backlog.md - — Now/Next/Later and quarterly themes
roadmap.md - — Lightweight spec template
solution-brief.md
本技能在目录下包含模板:
templates/- —— 模块清单和健康度跟踪
block-portfolio.md - —— 投注项格式和优先级排序
bet-backlog.md - —— 现在/下一步/未来和季度主题模板
roadmap.md - —— 轻量说明文档模板
solution-brief.md
Using This Skill with Claude
配合Claude使用本技能
Ask Claude to:
- Design block structure: "Help me organize [product] into capability blocks"
- Convert opportunity to bet: "Turn this opportunity into a bet with hypothesis and metrics"
- Prioritize bets: "Help me prioritize these bets using [framework]"
- Create roadmap: "Build a Now/Next/Later roadmap from these bets"
- Review roadmap: "Critique this roadmap for common anti-patterns"
- Write solution brief: "Create a solution brief for [bet]"
- Scope solution: "What should be in vs. out of scope for [bet]?"
- Define success metrics: "What metrics should we track for [bet]?"
- Plan quarterly themes: "Help me define themes for the next 4 quarters"
- Balance portfolio: "Is my bet portfolio balanced? What's missing?"
可以让Claude做以下事:
- 设计模块结构: "帮我把[产品]梳理为不同的能力模块"
- 将机会转化为投注项: "把这个机会转化为带假设和指标的投注项"
- 投注项优先级排序: "帮我用[框架]给这些投注项排序"
- 创建路线图: "基于这些投注项搭建一个现在/下一步/未来的路线图"
- 评审路线图: "检查这个路线图有没有常见的反模式"
- 撰写解决方案概要: "为[投注项]创建一个解决方案概要"
- 界定解决方案范围: "[投注项]的范围应该包含什么,不包含什么?"
- 定义成功指标: "[投注项]应该跟踪什么指标?"
- 规划季度主题: "帮我为接下来4个季度定义主题"
- 平衡投入组合: "我的投注项组合平衡吗?缺少什么?"
Connection to Other Skills
和其他技能的关联
| When you need to... | Use skill |
|---|---|
| Define strategy that informs bets | |
| Validate opportunities before betting | |
| Plan delivery and measurement | |
| Adapt for AI product bets | |
| Manage portfolio across products | |
| 当你需要... | 使用技能 |
|---|---|
| 定义为投注项提供依据的战略 | |
| 在投注前验证机会 | |
| 规划交付和衡量方式 | |
| 适配AI产品投注 | |
| 管理跨产品的组合 | |
Anti-Patterns to Avoid
需要避免的反模式
| Anti-Pattern | Why It Fails | Instead |
|---|---|---|
| Feature factory | No connection to outcomes | Bet-based backlog |
| Date-driven roadmap | False precision, broken trust | Time horizons |
| PRD novels | Nobody reads, out of date instantly | Solution briefs |
| Stakeholder-driven backlog | Politics over impact | Evidence-based prioritization |
| Tech-organized blocks | Doesn't reflect customer value | Customer-outcome blocks |
| No kill criteria | Zombie projects never die | Every 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 —— 产品战略框架