home / skills / wdavidturner / product-skills / shape-up

shape-up skill

/skills/shape-up

This skill helps teams apply Shape Up to set appetites, shape work within fixed time boxes, and ship meaningful outcomes.

npx playbooks add skill wdavidturner/product-skills --skill shape-up

Review the files below or copy the command above to add this skill to your agents.

Files (17)
SKILL.md
5.1 KB
---
name: shape-up
description: Use when asked to "shape up", "run a shaping session", "set an appetite", "scope a project without estimates", "betting table", or "ship in fixed cycles". Helps teams escape estimate-driven development and Scrum fatigue. The Shape Up method (created by Ryan Singer at Basecamp/37signals) uses fixed time boxes, variable scope, and collaborative shaping to ship meaningful work predictably.
---

# Shape Up

## What It Is

Shape Up is a product development methodology built on one core insight: **you cannot estimate your way to shipping—you must shape your way there.**

Traditional approaches ask "How long will this take?" and then try to hit that estimate. Shape Up flips this: decide upfront how much time you're willing to spend (the *appetite*), then shape a version of the solution that fits within that constraint.

The methodology emerged from 17 years of building Basecamp, where the founding team faced an unusual constraint: their only engineer (DHH) worked just 10 hours per week. This forced extreme clarity about what to build and ruthless scoping to ensure every hour counted. As the company grew, they formalized these practices into Shape Up to maintain startup speed at scale.

**The key shift:** Move from "What's the estimate for this?" to "What version of this can we confidently ship in the time we're willing to spend?"

## When to Use It

Use Shape Up when you need to:

- **Stop projects from dragging** — work that should take weeks is taking months
- **Escape the estimate trap** — you're tired of estimates that are always wrong
- **Give teams real autonomy** — not just ticket execution
- **Reduce meeting overhead** — Scrum rituals are consuming your time
- **Ship meaningful chunks** — not just incremental tickets that don't add up to anything
- **Align product and engineering** — there's a wall between them today
- **Maintain startup speed** — as you scale past 30-50 people

## When Not to Use It

Don't use Shape Up when:

- **You're 3 people or fewer** — just talk to each other, formalization isn't needed yet
- **There's no real complexity** — simple tasks don't need shaping
- **You can't get engineering into shaping** — without technical input, shaping fails
- **Leadership isn't bought in** — you need exec support to protect build time
- **You're doing pure maintenance** — bug fixes don't need the full process

## Patterns

Detailed examples showing how to apply Shape Up correctly. Each pattern shows a common mistake and the correct approach.

### Critical (get these wrong and you've wasted your time)

| Pattern | What It Teaches |
|---------|-----------------|
| [estimates-vs-appetite](patterns/estimates-vs-appetite.md) | Don't ask "how long?" — decide how much time you're willing to spend |
| [unshaped-work](patterns/unshaped-work.md) | A Figma file or PRD is not shaped work — you need collaborative clarity |
| [shaping-without-engineering](patterns/shaping-without-engineering.md) | Shaping without a senior engineer is a recipe for blowups |
| [ten-pound-bag](patterns/ten-pound-bag.md) | You can't put 10 pounds of scope in a 5 pound time box |
| [fuzzy-problem](patterns/fuzzy-problem.md) | "Build a calendar" is not a problem — narrow it down first |

### High Impact

| Pattern | What It Teaches |
|---------|-----------------|
| [too-abstract-shaping](patterns/too-abstract-shaping.md) | Fat marker sketches must communicate the idea, not just be blurry wireframes |
| [scope-hammering](patterns/scope-hammering.md) | Cut scope before you start, not when you're out of time |
| [tickets-not-projects](patterns/tickets-not-projects.md) | Give teams whole projects, not shredded tickets |
| [hill-chart-theater](patterns/hill-chart-theater.md) | Hill charts show real progress, not status theater |
| [missing-kickoff](patterns/missing-kickoff.md) | Builders must translate shaped work into 9 or fewer implementation scopes |
| [cool-down-skipping](patterns/cool-down-skipping.md) | Teams need breathing room between cycles to reset |

### Medium Impact

| Pattern | What It Teaches |
|---------|-----------------|
| [betting-table-dysfunction](patterns/betting-table-dysfunction.md) | Betting is a real commitment, not a backlog shuffle |
| [junior-detail-dial](patterns/junior-detail-dial.md) | Adjust shaping detail based on who's building |
| [circuit-breaker-fear](patterns/circuit-breaker-fear.md) | If it's not working, stop building and return to shaping |


## Deep Dives

Read only when you need extra detail.

- `references/shape-up-playbook.md`: Expanded framework detail, checklists, and examples.

## Resources

**Books:**
- *Shape Up* by Ryan Singer — the original free book (basecamp.com/shapeup)
- *Demand-Side Sales 101* by Bob Moesta — for the framing/problem discovery phase
- *Competing Against Luck* by Clayton Christensen — Jobs-to-be-Done theory

**Courses:**
- *Shaping in Real Life* — Ryan Singer's course on practical shaping

**Other:**
- Ryan Singer's website: ryansinger.co
- 37signals blog for ongoing insights

---

*Credit: Shape Up was created by Ryan Singer during his 17 years at Basecamp/37signals. This skill is based on his book and podcast conversations.*

Overview

This skill helps teams run Shape Up-style shaping sessions, set appetites, and scope projects without relying on time estimates. It guides product and engineering through collaborative shaping, betting table decisions, and fixed cycles so teams ship meaningful work predictably. Use it to escape estimate-driven development and reduce Scrum fatigue.

How this skill works

The skill walks you through defining an appetite (fixed time box), shaping problems into implementable pitches, and running a betting table to commit work for a cycle. It enforces collaborative shaping with engineering input, suggests scope cuts that fit the appetite, and designs cycle boundaries and cool-downs for sustainable delivery. It also surfaces patterns and anti-patterns to avoid common pitfalls.

When to use it

  • When projects stall and timelines keep slipping
  • When you want to stop estimating and instead fix an appetite
  • When you need to give teams end-to-end autonomy over a project
  • When Scrum rituals are causing meeting overload
  • When you want predictable, meaningful deliveries in fixed cycles

Best practices

  • Involve a senior engineer early in shaping to ground feasibility
  • Decide appetite upfront and shape scope to fit that time, not the other way around
  • Limit shaped pitches to a single problem and a clear no-go list
  • Use a betting table to make visible trade-offs and commitments
  • Protect cycle time with a mandatory cool-down between cycles
  • Prefer variable scope within fixed time boxes rather than stretching timelines

Example use cases

  • A product manager needs to convert a vague feature request into a shippable pitch for a six-week cycle
  • An engineering lead wants to reduce planning overhead and give builders full ownership of implementation
  • A leadership team must prioritize which pitches to fund at the betting table for the next cycle
  • A team seeks to stop incremental ticket-churn and instead ship coherent product chunks
  • A startup scaling past 30 people wants to retain startup speed without adding more process

FAQ

What’s the difference between an appetite and an estimate?

An appetite is the time you are willing to spend up front; an estimate guesses how long something will take. Shape Up fixes appetite and shapes scope to fit it.

Can Shape Up work with small teams?

Avoid over-formalizing for teams of three or fewer—Shape Up shines when cross-functional shaping and protected build cycles matter, typically as teams grow.