shape-up

What this skill does

# 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