shape-up

Shape Up

摆脱构建陷阱和无休止的待办事项列表。运用 Basecamp 的方法论，以固定时间、可变范围的方式，在 6 周周期内交付有意义的工作。

何时使用此技能

• 产品规划：取代无休止的待办事项列表
• 功能开发：设定明确的时间边界
• 团队自主性：希望团队能自主开展工作
• 范围管理：项目容易不断膨胀时
• 初创企业开发：资源有限时
• 代理商／咨询项目：时间线固定时

方法论基础

方面	详情
来源	Ryan Singer - Shape Up（2019），由 Basecamp 开发
核心原则	“时间固定，范围可变。考虑投入意愿，而非估算。先塑形，再构建。”
为何重要	传统方法要么事无巨细地管理（瀑布式），要么留有太多不确定性（缺乏方向的敏捷冲刺）。Shape Up 既为团队指明方向，也赋予团队自主权。

Claude 的职责与由你决定的事项

Claude 的职责	由你决定
梳理制作工作流	最终创意方向
提出技术方案	设备和工具选择
创建模板和检查清单	质量标准
确定最佳实践	品牌／风格决策
生成脚本大纲	最终脚本审批

此技能的用途

1. 介绍塑形 - 在恰当的抽象层次定义工作
2. 以投入意愿取代估算 - 这项工作值得投入多少时间？
3. 启用周期 - 6 周专注工作，2 周冷却期
4. 赋能团队 - 在边界内自主行动
5. 提供下注表 - 基于原则确定优先级
6. 动态管理范围 - 区分必需项与锦上添花项

使用方法

塑造功能构想

I want to shape this feature idea: [description]
Apply Shape Up methodology to define it at the right level.
Appetite: [2 weeks / 6 weeks]

规划周期

We have these potential projects for the next cycle:
[List of ideas]
Help me run a betting table to decide what to build.

在构建过程中管理范围

We're in week 3 of a 6-week cycle building [feature].
We're running behind. Help me apply Shape Up scope hammering.

说明

第 1 步：理解 Shape Up 原则

## The Shape Up Philosophy

### Fixed Time, Variable Scope

**Traditional approach:**
"How long will this take?" → Estimate → Build → Deadline slips

**Shape Up approach:**
"How much time is this worth?" → Appetite → Shape to fit → Ship on time

**The mindset shift:**
Instead of estimating how long a feature will take,
decide how much time you're willing to spend.
Then shape the work to fit that time.

### Appetite, Not Estimates

**Appetite:** How much time is this problem WORTH solving?

- Small batch: 2 weeks or less
- Big batch: 6 weeks max

**Key insight:**
A feature can be built in 2 weeks OR 6 months.
The question is: What version fits your appetite?

**Example:**
"Auto-complete for search"
- 6-month version: ML-powered, personalized, learns preferences
- 6-week version: Pre-populated common searches, basic matching
- 2-week version: Static list of top searches

All solve the problem. Choose based on appetite.

### Shaping vs. Building

**Shaping (Senior people):**
- Define the problem
- Set boundaries
- Identify risks
- Rough solution direction
- Leave room for builder creativity

**Building (Teams):**
- Detailed implementation
- Technical decisions
- UX specifics
- Scope management within boundaries

---

第 2 步：塑形流程

## How to Shape Work

### Step 1: Set the Appetite

Before anything else, decide:
- Is this a **small batch** (2 weeks) or **big batch** (6 weeks)?
- Is this worth doing at all at this appetite?

**Questions to ask:**
- What problem are we solving?
- How painful is this problem?
- What's the opportunity cost of not doing it?
- What's the opportunity cost of spending more time on it?

### Step 2: Narrow the Problem

Don't shape "improve search."
Shape "help new users find their first project template."

**Narrowing technique:**
1. Start with the raw idea
2. Ask: Who specifically has this problem?
3. Ask: In what specific situation?
4. Ask: What's the minimum viable solution?

### Step 3: Rough Out the Solution

**Fat marker sketches:**
Draw the solution with a thick marker (no detail).
You're defining spaces and flows, not buttons and fields.

**Breadboarding:**
For flows, use words not wireframes:

[搜索框] → [结果页面] → [模板详情] ↓ [无结果] → [建议类别]

**Key principle:**
Leave room for the builders to be creative.
Define WHAT, not exactly HOW.

### Step 4: Identify Risks and Rabbit Holes

**Rabbit holes:** Technical or design problems that could explode in scope.

**For each potential rabbit hole:**
- Name it
- Decide: Solve it in shaping? Or declare it out of scope?
- Document the boundary

**Example:**
"If we build template search, what about user-generated templates?"
Decision: Out of scope. Only show official templates.

### Step 5: Write the Pitch

**Pitch elements:**
1. **Problem:** What are we solving?
2. **Appetite:** How long is this worth?
3. **Solution:** Fat marker sketch / breadboard
4. **Rabbit holes:** What we're explicitly NOT doing
5. **No-gos:** Boundaries and constraints

---

第 3 步：周期

## Six-Week Cycles

### The Rhythm

**6 weeks building:**
- Long enough for meaningful work
- Short enough to maintain urgency
- Teams own their projects completely

**2 weeks cooldown:**
- Bug fixes
- Technical debt
- Exploration
- Shaping for next cycle
- Recovery

### Why 6 Weeks?

**Shorter (2-week sprints):**
- Not enough time for real progress
- Constant planning overhead
- Work gets chopped up artificially

**Longer (quarters):**
- Deadlines feel far away
- Scope creeps
- No urgency until the end

**6 weeks:**
- Urgent from day one
- Room to figure things out
- Clean endpoint

### Team Structure

**Small teams:**
- 1-2 designers + 1-3 programmers
- Self-managed during the cycle
- No daily standups with managers
- Check-ins when THEY need help

**Circuit breaker:**
If work isn't done at 6 weeks, it doesn't automatically continue.
It goes back to the betting table. Maybe it gets another cycle.
Maybe it doesn't.

### What Teams Do in a Cycle

**Week 1-2: Figure it out**
- Understand the shaped work
- Spike on unknowns
- Get oriented
- Early integration

**Week 3-4: Build the core**
- Make vertical slices
- Connect the pieces
- Working software early

**Week 5-6: Polish and ship**
- Cut scope if needed
- Must-haves only
- Ship by end of cycle

---

第 4 步：下注表

## Choosing What to Build

### The Betting Table

**Who:** Senior people who can make commitments
**When:** During cooldown, before next cycle
**Input:** Shaped pitches
**Output:** Cycle bets

### The Process

**1. Review pitches**
Each pitch should be complete:
- Clear problem
- Shaped solution
- Identified risks
- Appetite set

**2. Consider each bet**

For each pitch, ask:
- Is this the right time?
- Do we have the right team?
- Are there dependencies?
- What's the opportunity cost?

**3. Make decisions**

Options:
- **Bet:** Assign to next cycle
- **Park:** Good but not now
- **Kill:** Not worth doing

**No backlog:**
If you don't bet on something, it goes away.
Good ideas come back. Bad ideas don't.

### Betting Criteria

**1. Strategic fit**
Does this support current company goals?

**2. Problem significance**
How painful is this for customers?

**3. Appetite match**
Can this actually be done in the proposed time?

**4. Team availability**
Who would work on this?

**5. Dependencies**
What else needs to be true?

### Anti-Patterns

**Carry-over:**
"We didn't finish last cycle, so we'll continue."
No. Circuit breaker. Re-evaluate. Maybe it's not worth it.

**Backlog grooming:**
"Let's go through the 200 ideas and prioritize."
No. Only consider shaped pitches. Unshaped ideas aren't real options.

**Consensus:**
"Let's vote on what to build."
No. Decision-makers decide. Not democracy.

---

第 5 步：管理范围

## Scope Hammering

### The Principle

Scope grows naturally. Left unchecked, projects expand to fill time.
Your job is to constantly hammer scope back to what matters.

### Must-Haves vs. Nice-to-Haves

**Must-haves:**
- Core value delivery
- Without this, the feature doesn't work
- Absolutely required for ship

**Nice-to-haves:**
- Polish
- Edge cases
- Delighters
- "While we're at it..."

**Rule:** Identify nice-to-haves early. Cut them first.

### The Scope Hammer

**When you're behind (week 3+):**

1. **List all remaining work**
2. **Classify each item:**
   - Must-have for THIS version
   - Nice-to-have (cut or defer)
3. **Cut aggressively:**
   - What's the smallest version that still delivers value?
   - What can be a follow-up?
   - What can we not do at all?

### Scope Hammering Questions

- "Is this necessary for launch, or is it polish?"
- "What's the simplest version that still solves the problem?"
- "Can this be a fast-follow?"
- "What would happen if we just... didn't do this?"
- "Are we building for the 80% case or the edge case?"

### Hill Charts

**Track progress visually:**

    ┌─────────────────────────────────┐
    │                 ↗ 功能 C     │
    │       ↗ 功能 B               │
    │ ↗ 功能 A            ↘ 功能 D
    └─────────────────────────────────┘
     弄清楚方向    实现目标

- **Uphill:** Still figuring it out (risky)
- **Downhill:** Know what to do, just executing (safe)

**Use for:**
- Early warning when something is stuck uphill
- Identifying where help is needed
- Manager visibility without micromanagement

---

示例

示例 1：塑造一项功能

输入：

“我们想为项目管理应用添加通知。你能用 Shape Up 帮我塑造这个功能吗？”

输出：

已塑形提案：项目通知

问题

用户只偶尔查看应用，因此会错过重要更新。 他们查看应用时，面对的是海量动态，无法判断 哪些内容真正重要。

具体情境： 项目经理离开一天后登录， 无法快速判断哪些事项需要关注。

投入意愿

6 周（大批次）

通知是基础功能，值得认真投入。 但不值得花 3 个月。我们会将范围控制在 6 周内。

解决方案

面包板图：

[Activity happens] → [Notification created] → [Notification center]
                                                       ↓
                                              [Settings: what to notify]

粗略标记草图：

┌─────────────────────────────────────┐
│ 🔔 (3)                              │  ← Bell in header with count
├─────────────────────────────────────┤
│ ┌─────────────────────────────────┐ │
│ │ ● @you in Project Alpha         │ │  ← Unread notifications
│ │   Sarah mentioned you in a...   │ │
│ │   2 hours ago                   │ │
│ ├─────────────────────────────────┤ │
│ │ ○ Task completed                │ │  ← Read notifications
│ │   Build specs was marked done   │ │
│ │   Yesterday                     │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

我们要构建的内容：

1. 应用内通知中心（铃铛图标、下拉菜单）
2. 以下事项的通知：@提及、任务分配、截止日期
3. 基本设置（可按类型开启／关闭）

偏离主题（明确不在范围内）

电子邮件通知： 这是一个完全独立的系统（送达率、退订、格式）。 不在范围内。未来可作为小批次处理。

移动推送通知： 需要开发原生应用。不在范围内。

通知分组： 将 5 条独立通知合并为“Project Alpha 有 5 条评论”。 锦上添花。如果时间紧张就砍掉。

实时更新： 使用 WebSockets 即时推送通知。锦上添花。 V1 每 60 秒轮询一次即可。

按项目自定义： “只在 Project X 有更新时通知我。”过于复杂。 先从全局设置开始。

禁止事项

• 不发送电子邮件通知
• 不发送移动推送
• 不播放通知声音
• 不提供摘要/汇总视图
• 不提供团队级设置

风险

风险 1：数据库负载 可能会创建大量通知。需要高效的查询。 缓解措施： 技术负责人应在周期的前 2 天对通知存储方案进行调研。

风险 2：UX 复杂度 设置可能很快变得复杂。 缓解措施： 先从 3 个开关开始。不提供按项目设置。

---

示例 2：周期中途缩减范围

输入：

“我们正在进行一个为期 6 周的周期，目前处于第 4 周，正在开发报表仪表板。进度落后了。目前计划了：(1) 5 种图表类型，只完成了 2 种，(2) 尚未开始 PDF 导出，(3) 日期筛选器基本完成，(4) 尚未开始实时刷新。帮我缩减范围。”

输出：

范围缩减：报表仪表板

当前状态（第 4 周，共 6 周）

项目	状态	所需时间
图表类型（计划 5 种）	完成 2 种	剩余 3 种需 1.5 周
导出为 PDF	尚未开始	1 周
日期筛选器	完成 80%	2 天
实时刷新	尚未开始	1 周

剩余工作总量：约 4 周 可用时间：约 2 周

分类

必需项（交付核心价值）：

• 至少 3 种图表类型（折线图、柱状图、饼图）——覆盖最常见的使用场景
• 日期筛选器——没有筛选就毫无用处
• 查看/加载报表——基本功能

锦上添花（砍掉或延期）：

• 第 4 和第 5 种图表类型（表格图、面积图）
• 导出为 PDF
• 实时刷新

建议

现在砍掉：

1. 实时刷新 → V2。手动刷新按钮即可。
2. 第 5 种图表类型（面积图） → V2。很少使用。
3. 导出为 PDF → V2。用户可以截图，或者我们在之后快速跟进。

保留：

1. 日期筛选器（2 天内完成）
2. 3 种图表类型（折线图、柱状图、饼图——完成剩余 1 种需 3–4 天）
3. 第 4 种图表类型（表格图）——便于查看数据（3 天）

修订后的范围

第 5 周：

• 第 1–2 天：完成日期筛选器
• 第 3–4 天：构建饼图（第 3 种类型）
• 第 5 天：构建表格视图（第 4 种类型）

第 6 周：

• 第 1–3 天：优化、修复错误、处理边界情况
• 第 4 天：内部测试
• 第 5 天：发布

如何告知利益相关者

“我们将发布功能完备的仪表板，包含 4 种图表类型（折线图、柱状图、饼图、表格）和日期筛选器。导出和实时刷新将在下一个小批次周期中快速跟进。

这能为用户带来 90% 的价值。剩余功能只是优化，并非核心功能。”

周期结束后的小批次候选项

• 导出为 PDF（2 周批次）
• 实时刷新（2 周批次）
• 面积图类型（1 周附加项）

---

示例 3：组织一场押注讨论

输入：

“下一个周期有以下 5 个提案。如何组织一场押注讨论来决定？(1) 改进搜索，(2) 团队权限，(3) 移动应用重新设计，(4) 集成 API，(5) 改进引导流程”

输出：

押注讨论：下一个周期

前期工作：Pitch 评审

每个 pitch 都应包含：

• 清晰的问题陈述
• 投入时长（2 周或 6 周）
• 大致解决方案
• 已识别的陷阱
• 明确的禁区

评估：

Pitch	是否成形？	投入时长	所需团队
改进搜索	✓ 是	6 周	1D + 2E
团队权限	✓ 是	6 周	1D + 2E
移动应用重新设计	✗ 太模糊	？	？
集成 API	✓ 是	6 周	0D + 3E
改进引导流程	✓ 是	2 周	1D + 1E

移动应用重新设计： 尚未准备好投入。需要进一步打磨。 退回。考虑在未来周期中安排。

投入标准评估

1. 改进搜索（6 周）

标准	评分	备注
战略契合度	4/5	支持增长，符合用户需求
问题重要性	3/5	主要困扰高级用户
投入时长匹配度	4/5	范围明确
团队可用性	✓	团队 A 有空
依赖项	无

结论： 候选项目

2. 团队权限（6 周）

标准	评分	备注
战略契合度	5/5	企业交易所必需
问题重要性	5/5	阻碍销售
投入时长匹配度	3/5	范围可能扩大，需要严格控制
团队可用性	✓	团队 B 有空
依赖项	无

结论： 强力候选项目

3. 集成 API（6 周）

标准	评分	备注
战略契合度	4/5	拓展合作伙伴生态
问题重要性	3/5	重要但不紧急
投入时长匹配度	4/5	首期限定为只读
团队可用性	✓	团队 C 有空
依赖项	无

结论： 候选项目

4. 改进引导流程（2 周）

标准	评分	备注
战略契合度	5/5	直接影响激活率
问题重要性	4/5	引导流程中有 40% 的流失率
投入时长匹配度	5/5	范围小且聚焦
团队可用性	✓	可纳入任何团队的周期
依赖项	无

结论： 强力候选项目（小批次）

投入项目

可用产能：

• 2 个团队可承担 6 周项目
• 1 个团队可腾出时间增加一个 2 周项目

决定：

投入项目	团队	理由
团队权限	团队 B	阻碍企业交易，紧迫性最高
集成 API	团队 C	带来战略机遇
改进引导流程	团队 A（第 1–2 周）	影响大，投入小
改进搜索	暂缓	不错，但目前优先级不够高

不投入的项目：

• 移动应用重新设计：尚未成形，需要进一步打磨。
• 改进搜索：Pitch 不错，但时机不对。留到下个周期。

投入后的沟通

“下个周期：

• 团队 B：团队权限（6 周）
• 团队 C：API v1（6 周）
• 团队 A：改进引导流程（2 周），然后处理冷却期任务

搜索是一个很有竞争力的 pitch。我们将其暂缓，留到再下一个周期。 移动应用重新设计需要进一步打磨，之后才能投入。”

---

清单与模板

Pitch 模板

## Pitch: [Feature Name]

### Problem
[What problem are we solving? Who has it? When?]

### Appetite
[2 weeks / 6 weeks]

### Solution

**Breadboard:**
[Flow diagram with words]

**Fat Marker Sketch:**
[Rough visual layout - no details]

### Rabbit Holes
[What could explode in scope? How are we preventing it?]

### No-Gos
[What are we explicitly NOT building?]

### Risks
[What could go wrong? How will we mitigate?]

---

投入会议清单

## Betting Table: [Cycle Name]

### Before the Meeting
□ All pitches reviewed for completeness
□ Incomplete pitches sent back for shaping
□ Team availability mapped
□ Strategic priorities clear

### During the Meeting
□ Review each complete pitch
□ Assess against betting criteria
□ Discuss dependencies and timing
□ Make binary decisions (bet / don't bet)
□ Assign teams to bets

### After the Meeting
□ Communicate decisions to teams
□ Archive or park unbetted pitches
□ Schedule cycle kickoffs
□ Clear any dependencies

---

技能边界

此技能擅长的方面

• 规划音频制作工作流
• 提供技术指导
• 创建质量检查清单
• 提出创意方案

此技能无法做到的事

• 取代音频工程专业知识
• 做出主观的创意决策
• 直接访问或编辑音频文件
• 保证商业成功

参考资料

• Singer, Ryan.《Shape Up：Stop Running in Circles and Ship Work that Matters》（2019）
• Basecamp 方法论文档
• 37signals（Basecamp）博客文章
• Shape Up 播客访谈

Related Skills

• product-discovery - Discovery before shaping
• design-sprint - Alternative sprint format
• lean-canvas - Business model context
• first-principles - Problem definition

---

Skill Metadata

• Mode: cyborg

name: shape-up
category: product
subcategory: methodology
version: 1.0
author: MKTG Skills
source_expert: Ryan Singer
source_work: Shape Up
difficulty: intermediate
estimated_value: $5,000+ process consulting
tags: [product, process, Basecamp, cycles, shaping, scope, betting, development]
created: 2026-01-25
updated: 2026-01-25