shape-up

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Shape Up

Escape the build trap and endless backlogs. Use Basecamp's methodology to ship meaningful work in 6-week cycles with fixed time, variable scope.

摆脱构建陷阱和无穷无尽的待办事项。采用Basecamp的方法论，以固定时间、可变范围的6周周期交付有意义的工作。

When to Use This Skill

适用场景

Product planning to replace endless backlogs
Feature development with clear time boundaries
Team autonomy when you want self-directed teams
Scope management when projects tend to balloon
Startup development with limited resources
Agency/consulting projects with fixed timelines

产品规划——替代无穷无尽的待办事项
功能开发——需要明确的时间边界
团队自治——希望打造自主导向的团队
范围管理——项目范围容易失控膨胀
初创企业开发——资源有限的情况
代理/咨询项目——有固定时间期限

Methodology Foundation

方法论基础

Aspect	Details
Source	Ryan Singer - Shape Up (2019), developed at Basecamp
Core Principle	"Fixed time, variable scope. Appetite, not estimates. Shape before you build."
Why This Matters	Traditional methods either micromanage (waterfall) or leave too much open (agile sprints without direction). Shape Up gives teams direction AND autonomy.

维度	详情
来源	Ryan Singer - Shape Up (2019)，由Basecamp开发
核心原则	"固定时间，可变范围。基于投入意愿，而非估算。先梳理（Shaping），再构建。"
重要性	传统方法要么过度管控（瀑布模型），要么过于松散（缺乏方向的敏捷迭代）。Shape Up既为团队提供方向，又赋予自治权。

What Claude Does vs What You Decide

Claude的职责 vs 你的决策

Claude Does	You Decide
Structures production workflow	Final creative direction
Suggests technical approaches	Equipment and tool choices
Creates templates and checklists	Quality standards
Identifies best practices	Brand/voice decisions
Generates script outlines	Final script approval

Claude负责	由你决定
构建生产工作流结构	最终创意方向
提出技术实现方案	设备与工具选择
创建模板和检查表	质量标准
识别最佳实践	品牌/风格决策
生成脚本大纲	最终脚本审批

What This Skill Does

本技能的功能

Introduces shaping - Defining work at the right level of abstraction
Sets appetites over estimates - How much time is this worth?
Enables cycles - 6-week focused work, 2-week cooldown
Empowers teams - Autonomy within boundaries
Provides betting tables - Principled prioritization
Manages scope dynamically - Must-haves vs. nice-to-haves

介绍梳理（Shaping）流程——在合适的抽象层面定义工作内容
以投入意愿（Appetite）替代估算——这项工作值得投入多少时间？
启用周期模式——6周专注工作，2周休整期（Cooldown）
赋能团队——在边界内赋予自治权
提供Betting Table机制——基于原则的优先级排序
动态管理范围——区分必备功能（Must-haves）与锦上添花功能（Nice-to-haves）

How to Use

使用方法

Shape a Feature Idea

梳理功能想法

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

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

Plan a Cycle

规划周期

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

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

Manage Scope During Build

构建过程中管理范围

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

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

Instructions

操作步骤

Step 1: Understand the Shape Up Principles

步骤1：理解Shape Up原则

undefined

undefined

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.

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.

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

---

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

---

Step 2: The Shaping Process

步骤2：梳理工作的流程

undefined

undefined

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?

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:

Start with the raw idea
Ask: Who specifically has this problem?
Ask: In what specific situation?
Ask: What's the minimum viable solution?

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

Narrowing technique:

Start with the raw idea
Ask: Who specifically has this problem?
Ask: In what specific situation?
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:

[Search box] → [Results page] → [Template detail]
              ↓
         [No results] → [Suggest categories]

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

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:

[Search box] → [Results page] → [Template detail]
              ↓
         [No results] → [Suggest categories]

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.

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:

Problem: What are we solving?
Appetite: How long is this worth?
Solution: Fat marker sketch / breadboard
Rabbit holes: What we're explicitly NOT doing
No-gos: Boundaries and constraints

---

Pitch elements:

Problem: What are we solving?
Appetite: How long is this worth?
Solution: Fat marker sketch / breadboard
Rabbit holes: What we're explicitly NOT doing
No-gos: Boundaries and constraints

---

Step 3: The Cycle

步骤3：周期管理

undefined

undefined

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

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

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.

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

---

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

---

Step 4: The Betting Table

步骤4：Betting Table（项目优先级决策）

undefined

undefined

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.

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?

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.

---

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.

---

Step 5: Managing Scope

步骤5：范围管控（Scope Hammering）

undefined

undefined

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.

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+):

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

When you're behind (week 3+):

List all remaining work
Classify each item:
- Must-have for THIS version
- Nice-to-have (cut or defer)
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?"

"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:

        ┌─────────────────────────────────┐
        │                 ↗ Feature C     │
        │       ↗ Feature B               │
        │ ↗ Feature A            ↘ Feature D
        └─────────────────────────────────┘
         Figuring it out    Making it happen

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

---

Track progress visually:

        ┌─────────────────────────────────┐
        │                 ↗ Feature C     │
        │       ↗ Feature B               │
        │ ↗ Feature A            ↘ Feature D
        └─────────────────────────────────┘
         Figuring it out    Making it happen

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

---

Examples

示例

Example 1: Shaping a Feature

示例1：梳理功能

Input:

"We want to add notifications to our project management app. Can you help me shape this using Shape Up?"

Output:

输入:

"We want to add notifications to our project management app. Can you help me shape this using Shape Up?"

输出:

Shaped Pitch: Project Notifications

Problem

Users miss important updates because they only check the app occasionally. When they do check, they see a firehose of activity with no way to know what actually matters.

Specific situation: A project manager logs in after a day away and can't quickly tell what needs their attention.

Users miss important updates because they only check the app occasionally. When they do check, they see a firehose of activity with no way to know what actually matters.

Specific situation: A project manager logs in after a day away and can't quickly tell what needs their attention.

Appetite

6 weeks (Big Batch)

Notifications are foundational. Worth investing in properly. But not worth 3 months. We'll scope to fit 6 weeks.

6 weeks (Big Batch)

Notifications are foundational. Worth investing in properly. But not worth 3 months. We'll scope to fit 6 weeks.

Solution

Breadboard:

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

Fat marker sketch:

┌─────────────────────────────────────┐
│ 🔔 (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                     │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

What we're building:

In-app notification center (bell icon, dropdown)
Notifications for: @mentions, task assignments, due dates
Basic settings (on/off per type)

Breadboard:

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

Fat marker sketch:

┌─────────────────────────────────────┐
│ 🔔 (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                     │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

What we're building:

In-app notification center (bell icon, dropdown)
Notifications for: @mentions, task assignments, due dates
Basic settings (on/off per type)

Rabbit Holes (Explicitly OUT of Scope)

Email notifications: This is a whole separate system (deliverability, unsubscribes, formatting). Out of scope. Potential future small batch.

Mobile push notifications: Requires native app work. Out of scope.

Notification grouping: "5 comments on Project Alpha" instead of 5 separate notifications. Nice-to-have. Cut if we need time.

Real-time updates: WebSockets for instant notifications. Nice-to-have. Polling every 60 seconds is fine for V1.

Customization per project: "Only notify me for Project X." Too complex. Start with global settings only.

Email notifications: This is a whole separate system (deliverability, unsubscribes, formatting). Out of scope. Potential future small batch.

Mobile push notifications: Requires native app work. Out of scope.

Notification grouping: "5 comments on Project Alpha" instead of 5 separate notifications. Nice-to-have. Cut if we need time.

Real-time updates: WebSockets for instant notifications. Nice-to-have. Polling every 60 seconds is fine for V1.

Customization per project: "Only notify me for Project X." Too complex. Start with global settings only.

No-Gos

No email notifications
No mobile push
No notification sounds
No digest/summary views
No team-level settings

No email notifications
No mobile push
No notification sounds
No digest/summary views
No team-level settings

Risks

Risk 1: Database load Many notifications could be created. Need efficient queries. Mitigation: Tech lead should spike on notification storage approach in first 2 days of cycle.

Risk 2: UX complexity Settings can get complicated fast. Mitigation: Start with just 3 toggles. No per-project settings.

Risk 1: Database load Many notifications could be created. Need efficient queries. Mitigation: Tech lead should spike on notification storage approach in first 2 days of cycle.

Risk 2: UX complexity Settings can get complicated fast. Mitigation: Start with just 3 toggles. No per-project settings.

Example 2: Scope Hammering Mid-Cycle

示例2：周期中进行范围管控

Input:

"We're in week 4 of a 6-week cycle building a reporting dashboard. We're behind. We have: (1) 5 chart types planned, only 2 done, (2) Export to PDF not started, (3) Date filters mostly done, (4) Real-time refresh not started. Help me scope hammer."

Output:

输入:

"We're in week 4 of a 6-week cycle building a reporting dashboard. We're behind. We have: (1) 5 chart types planned, only 2 done, (2) Export to PDF not started, (3) Date filters mostly done, (4) Real-time refresh not started. Help me scope hammer."

输出:

Scope Hammer: Reporting Dashboard

Current Status (Week 4 of 6)

Item	Status	Time Needed
Chart types (5 planned)	2 done	1.5 weeks for remaining 3
Export to PDF	Not started	1 week
Date filters	80% done	2 days
Real-time refresh	Not started	1 week

Total remaining work: ~4 weeks Time available: ~2 weeks

Item	Status	Time Needed
Chart types (5 planned)	2 done	1.5 weeks for remaining 3
Export to PDF	Not started	1 week
Date filters	80% done	2 days
Real-time refresh	Not started	1 week

Total remaining work: ~4 weeks Time available: ~2 weeks

Classification

Must-Have (Core value delivery):

At least 3 chart types (line, bar, pie) - most common use cases
Date filters - useless without filtering
View/load reports - basic functionality

Nice-to-Have (Cut or defer):

4th and 5th chart types (table, area)
Export to PDF
Real-time refresh

Must-Have (Core value delivery):

At least 3 chart types (line, bar, pie) - most common use cases
Date filters - useless without filtering
View/load reports - basic functionality

Nice-to-Have (Cut or defer):

4th and 5th chart types (table, area)
Export to PDF
Real-time refresh

Recommendation

Cut now:

Real-time refresh → V2. Manual refresh button is fine.
5th chart type (area) → V2. Rarely used.
Export to PDF → V2. Users can screenshot or we do fast-follow.

Keep:

Date filters (finish in 2 days)
3 chart types (line, bar, pie - 3-4 days for remaining 1)
4th chart type (table) - useful for data review (3 days)

Cut now:

Real-time refresh → V2. Manual refresh button is fine.
5th chart type (area) → V2. Rarely used.
Export to PDF → V2. Users can screenshot or we do fast-follow.

Keep:

Date filters (finish in 2 days)
3 chart types (line, bar, pie - 3-4 days for remaining 1)
4th chart type (table) - useful for data review (3 days)

Revised Scope

Week 5:

Day 1-2: Finish date filters
Day 3-4: Build pie chart (3rd type)
Day 5: Build table view (4th type)

Week 6:

Day 1-3: Polish, bug fixes, edge cases
Day 4: Internal testing
Day 5: Ship

Week 5:

Day 1-2: Finish date filters
Day 3-4: Build pie chart (3rd type)
Day 5: Build table view (4th type)

Week 6:

Day 1-3: Polish, bug fixes, edge cases
Day 4: Internal testing
Day 5: Ship

What to Tell Stakeholders

"We're shipping a fully functional dashboard with 4 chart types (line, bar, pie, table) and date filters. Export and real-time refresh will be fast-follows in the next small batch cycle.

This gives users 90% of the value. The remaining features are polish, not core functionality."

"We're shipping a fully functional dashboard with 4 chart types (line, bar, pie, table) and date filters. Export and real-time refresh will be fast-follows in the next small batch cycle.

This gives users 90% of the value. The remaining features are polish, not core functionality."

Post-Cycle Small Batch Candidates

Export to PDF (2-week batch)
Real-time refresh (2-week batch)
Area chart type (1-week add-on)

Export to PDF (2-week batch)
Real-time refresh (2-week batch)
Area chart type (1-week add-on)

Example 3: Running a Betting Table

示例3：运行Betting Table

Input:

"We have these 5 pitches for the next cycle. How do I run a betting table to decide? (1) Improved search, (2) Team permissions, (3) Mobile app redesign, (4) API for integrations, (5) Onboarding improvements"

Output:

输入:

"We have these 5 pitches for the next cycle. How do I run a betting table to decide? (1) Improved search, (2) Team permissions, (3) Mobile app redesign, (4) API for integrations, (5) Onboarding improvements"

输出:

Betting Table: Next Cycle

Pre-Work: Pitch Review

Each pitch should be shaped with:

Clear problem statement
Appetite (2-week or 6-week)
Rough solution
Rabbit holes identified
No-gos defined

Assessment:

Pitch	Shaped?	Appetite	Team Needed
Improved search	✓ Yes	6 weeks	1D + 2E
Team permissions	✓ Yes	6 weeks	1D + 2E
Mobile app redesign	✗ Too vague	?	?
API for integrations	✓ Yes	6 weeks	0D + 3E
Onboarding improvements	✓ Yes	2 weeks	1D + 1E

Mobile app redesign: Not ready for betting. Needs shaping. Send back. Consider for future cycle.

Each pitch should be shaped with:

Clear problem statement
Appetite (2-week or 6-week)
Rough solution
Rabbit holes identified
No-gos defined

Assessment:

Pitch	Shaped?	Appetite	Team Needed
Improved search	✓ Yes	6 weeks	1D + 2E
Team permissions	✓ Yes	6 weeks	1D + 2E
Mobile app redesign	✗ Too vague	?	?
API for integrations	✓ Yes	6 weeks	0D + 3E
Onboarding improvements	✓ Yes	2 weeks	1D + 1E

Mobile app redesign: Not ready for betting. Needs shaping. Send back. Consider for future cycle.

Betting Criteria Evaluation

1. Improved Search (6-week)

Criteria	Score	Notes
Strategic fit	4/5	Supports growth, user requests
Problem significance	3/5	Pain for power users mainly
Appetite match	4/5	Well-scoped
Team availability	✓	Team A available
Dependencies	None

Verdict: CANDIDATE

2. Team Permissions (6-week)

Criteria	Score	Notes
Strategic fit	5/5	Required for enterprise deals
Problem significance	5/5	Blocking sales
Appetite match	3/5	Could expand, needs discipline
Team availability	✓	Team B available
Dependencies	None

Verdict: STRONG CANDIDATE

3. API for Integrations (6-week)

Criteria	Score	Notes
Strategic fit	4/5	Opens partner ecosystem
Problem significance	3/5	Important but not urgent
Appetite match	4/5	Scoped to read-only first
Team availability	✓	Team C available
Dependencies	None

Verdict: CANDIDATE

4. Onboarding Improvements (2-week)

Criteria	Score	Notes
Strategic fit	5/5	Direct impact on activation
Problem significance	4/5	40% drop-off in onboarding
Appetite match	5/5	Small, focused scope
Team availability	✓	Fits in any team's cycle
Dependencies	None

Verdict: STRONG CANDIDATE (small batch)

1. Improved Search (6-week)

Criteria	Score	Notes
Strategic fit	4/5	Supports growth, user requests
Problem significance	3/5	Pain for power users mainly
Appetite match	4/5	Well-scoped
Team availability	✓	Team A available
Dependencies	None

Verdict: CANDIDATE

2. Team Permissions (6-week)

Criteria	Score	Notes
Strategic fit	5/5	Required for enterprise deals
Problem significance	5/5	Blocking sales
Appetite match	3/5	Could expand, needs discipline
Team availability	✓	Team B available
Dependencies	None

Verdict: STRONG CANDIDATE

3. API for Integrations (6-week)

Criteria	Score	Notes
Strategic fit	4/5	Opens partner ecosystem
Problem significance	3/5	Important but not urgent
Appetite match	4/5	Scoped to read-only first
Team availability	✓	Team C available
Dependencies	None

Verdict: CANDIDATE

4. Onboarding Improvements (2-week)

Criteria	Score	Notes
Strategic fit	5/5	Direct impact on activation
Problem significance	4/5	40% drop-off in onboarding
Appetite match	5/5	Small, focused scope
Team availability	✓	Fits in any team's cycle
Dependencies	None

Verdict: STRONG CANDIDATE (small batch)

The Bet

Available capacity:

2 teams for 6-week bets
1 team has room for 2-week addition

Decision:

Bet	Team	Rationale
Team Permissions	Team B	Enterprise blocker, highest urgency
API for Integrations	Team C	Opens strategic opportunities
Onboarding Improvements	Team A (week 1-2)	High impact, small investment
Improved Search	Parked	Good but not highest priority now

What's NOT bet:

Mobile app redesign: Not shaped. Needs work.
Improved search: Good pitch, wrong timing. Save for next cycle.

Available capacity:

2 teams for 6-week bets
1 team has room for 2-week addition

Decision:

Bet	Team	Rationale
Team Permissions	Team B	Enterprise blocker, highest urgency
API for Integrations	Team C	Opens strategic opportunities
Onboarding Improvements	Team A (week 1-2)	High impact, small investment
Improved Search	Parked	Good but not highest priority now

What's NOT bet:

Mobile app redesign: Not shaped. Needs work.
Improved search: Good pitch, wrong timing. Save for next cycle.

Post-Betting Communication

"Next cycle:

Team B: Team Permissions (6 weeks)
Team C: API v1 (6 weeks)
Team A: Onboarding improvements (2 weeks), then cooldown tasks

Search is a strong pitch. We're parking it for the following cycle. Mobile app redesign needs more shaping before it's ready to bet."

"Next cycle:

Team B: Team Permissions (6 weeks)
Team C: API v1 (6 weeks)
Team A: Onboarding improvements (2 weeks), then cooldown tasks

Search is a strong pitch. We're parking it for the following cycle. Mobile app redesign needs more shaping before it's ready to bet."

Checklists & Templates

检查表与模板

Pitch Template

提案模板

undefined

undefined

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]

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?]

---

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

---

Betting Table Checklist

Betting Table检查表

undefined

undefined

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

---

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

---

Skill Boundaries

技能边界

What This Skill Does Well

本技能擅长

Structuring audio production workflows
Providing technical guidance
Creating quality checklists
Suggesting creative approaches

构建音频制作工作流结构
提供技术指导
创建质量检查表
提出创意方案

What This Skill Cannot Do

本技能不擅长

Replace audio engineering expertise
Make subjective creative decisions
Access or edit audio files directly
Guarantee commercial success

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

References

参考资料

Singer, Ryan. "Shape Up: Stop Running in Circles and Ship Work that Matters" (2019)
Basecamp methodology documentation
37signals (Basecamp) blog posts
Shape Up podcast appearances

Singer, Ryan. "Shape Up: Stop Running in Circles and Ship Work that Matters" (2019)
Basecamp方法论文档
37signals (Basecamp)博客文章
Shape Up播客访谈

Related Skills

Skill Metadata

技能元数据

Mode: cyborg

yaml

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

Mode: cyborg

yaml

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