wdavidturner 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 | Don't ask "how long?" — decide how much time you're willing to spend |
| unshaped-work | A Figma file or PRD is not shaped work — you need collaborative clarity |
| shaping-without-engineering | Shaping without a senior engineer is a recipe for blowups |
| ten-pound-bag | You can't put 10 pounds of scope in a 5 pound time box |
| fuzzy-problem | "Build a calendar" is not a problem — narrow it down first |
High Impact
| Pattern | What It Teaches |
|---|---|
| too-abstract-shaping | Fat marker sketches must communicate the idea, not just be blurry wireframes |
| scope-hammering | Cut scope before you start, not when you're out of time |
| tickets-not-projects | Give teams whole projects, not shredded tickets |
| hill-chart-theater | Hill charts show real progress, not status theater |
| missing-kickoff | Builders must translate shaped work into 9 or fewer implementation scopes |
| cool-down-skipping | Teams need breathing room between cycles to reset |
Medium Impact
| Pattern | What It Teaches |
|---|---|
| betting-table-dysfunction | Betting is a real commitment, not a backlog shuffle |
| junior-detail-dial | Adjust shaping detail based on who's building |
| circuit-breaker-fear | 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.