Shape Up Skill for Claude

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

• 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

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:

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

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:

• 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

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