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