shape-up

name	shape-up
description	Escape the build trap and endless backlogs. Use Basecamp's methodology to ship meaningful work in 6-week cycles with fixed time, variable scope. Use when: **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
license	MIT
metadata	{"author":"ClawFu","version":"1.0.0","mcp-server":"@clawfu/mcp-skills"}

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.

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.

What Claude Does vs What You Decide

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

What This Skill Does

1. Introduces shaping - Defining work at the right level of abstraction
2. Sets appetites over estimates - How much time is this worth?
3. Enables cycles - 6-week focused work, 2-week cooldown
4. Empowers teams - Autonomy within boundaries
5. Provides betting tables - Principled prioritization
6. Manages scope dynamically - Must-haves vs. 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]

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.

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.

Instructions

Step 1: Understand the Shape Up Principles

## 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

---

Step 2: The Shaping Process

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

[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.

### 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

---

Step 3: The Cycle

## 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

---

Step 4: The Betting Table

## 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.

---

Step 5: Managing Scope

## 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:**

    ┌─────────────────────────────────┐
    │                 ↗ 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

Input:

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

Output:

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.

Appetite

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:

1. In-app notification center (bell icon, dropdown)
2. Notifications for: @mentions, task assignments, due dates
3. 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.

No-Gos

• 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.

---

Example 2: Scope Hammering Mid-Cycle

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:

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

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

Recommendation

Cut now:

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

Keep:

1. Date filters (finish in 2 days)
2. 3 chart types (line, bar, pie - 3-4 days for remaining 1)
3. 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

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

Post-Cycle Small Batch Candidates

• 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

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:

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.

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)

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.

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

---

Checklists & Templates

Pitch Template

## 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 Checklist

## 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

---

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

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