Shape Up

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

What Claude Does vs What You Decide

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)

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:

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

Betting Criteria Evaluation

1. Improved Search (6-week)

Verdict: CANDIDATE

2. Team Permissions (6-week)

Verdict: STRONG CANDIDATE

3. API for Integrations (6-week)

Verdict: CANDIDATE

4. Onboarding Improvements (2-week)

Verdict: STRONG CANDIDATE (small batch)

The Bet

Available capacity:

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

Decision:

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