Shape Up

Delivery

Prioritization

Planning

Shape the problem before coding. Ryan Singer's method (Basecamp) for delivering meaningful features in 6-week cycles without an infinite backlog.

Description

Shape Up is a product development methodology created by Ryan Singer at Basecamp in 2019, which replaces short sprints and endless backlogs with 6-week cycles featuring strategic shaping upfront, a betting table to select projects, and full team autonomy during execution. Its purpose: to enable small teams to deliver complete, meaningful features without the planning overhead of traditional agile methods. Singer published Shape Up as a free online book at basecamp.com/shapeup, laying out the method Basecamp has used for over 15 years to build its products (Basecamp, HEY). Shape Up rests on a simple observation: 2-week sprints are too short to deliver something meaningful, and 3-month projects drift endlessly. Six weeks is the sweet spot. The method works like a film studio: shaping is the screenplay writing (you define the problem, the contours of the solution, and the boundaries, without specifying every detail), the betting table is the greenlight meeting (decision-makers bet on projects that deserve 6 weeks of investment), and the build is the production (the team has full freedom to make the film within the allotted time budget). Three key concepts set Shape Up apart from Scrum. Shaping produces "pitches" that define the appetite (the time budget) and the rabbit holes to avoid, not exhaustive specifications. The betting table replaces the backlog: if a pitch is not selected, it goes back to the pile with no guarantee of being picked up again, preventing the infinite accumulation of tickets. The 2-week cooldown between each cycle leaves room for technical debt, exploration, and breathing space. Basecamp, GitLab, and ConvertKit apply this method in production.

Objectives

Prioritize features
Structure development
Improve team collaboration

Used by

-Basecamp (creator of Shape Up, has used the method in production for over 15 years to develop Basecamp and HEY)
-GitLab (adopted elements of Shape Up to structure its remote development cycles)
-ConvertKit (uses Shape Up as its primary product development methodology)

Advantages

Complete feature delivery in 6 weeks. Unlike 2-week sprints that deliver fragments, Shape Up delivers entire value blocks that users perceive.
Zero infinite backlog. The betting table eliminates ticket accumulation and associated guilt. If a pitch does not convince, it disappears.
Total team autonomy during the build. No micro-management, no detailed tickets, no imposed daily standups. The team owns its solution.
Cooldown prevents burnout. The 2 weeks between each cycle offer a structural breathing space that most agile methods do not provide.

Limitations

Shaping requires experienced seniors. A poorly shaped pitch (too vague or too detailed) condemns the cycle. Without competent shapers, Shape Up does not work.
Less suited to teams of more than 15 people. Shape Up was designed for small, autonomous teams. Beyond that, coordination between cycles becomes a problem the method does not address.
The circuit breaker can frustrate teams. Abandoning a project at 80% completion because time is up requires rare organizational maturity.
No built-in urgency management. If a critical bug arrives in week 3 of a cycle, Shape Up provides no formal mechanism to handle it without disrupting the ongoing cycle.

How to apply Shape Up

1
Identify a problem to solve (raw idea)
Everything starts with an observed problem: a recurring user feedback, a friction in the journey, a business opportunity. Do not jump to the solution. Formulate the problem clearly: "New users abandon during setup because the form has 12 fields." Let raw ideas mature for a few weeks before shaping them. Output: problem formulated and validated as worth addressing.
2
Shape the pitch (4 elements)
Shaping is the strategic framing work. A pitch contains four elements: the Problem (the problem to solve), the Appetite (the time budget, set at 2 weeks "small batch" or 6 weeks "big batch"), the Solution (the outlines of the solution, sketched in fat marker sketches, not detailed wireframes), and the Rabbit Holes (traps to avoid and explicit boundaries). Shaping is done by seniors who understand both business and technology. Output: documented pitch ready for the betting table.
3
Organize the betting table
Every 6 weeks, decision-makers (CEO, CTO, Head of Product) meet to bet on which pitches deserve the next cycle. Each pitch is evaluated on its appetite (the value-to-investment ratio). If a pitch is not selected, it is not placed in a backlog: it goes back to the pile and will have to convince again at the next session. No backlog, no promise debt. Output: 1 to 3 projects selected for the 6-week cycle.
4
Form the teams for the cycle
Each project is assigned to a small team (1 designer + 1 to 2 developers). The team receives the pitch but no tickets, no user stories, no detailed backlog. They are responsible for breaking down the work, solving problems, and delivering within the 6 weeks. Autonomy is total: no imposed daily standup, no daily reporting. Output: teams formed with their assigned pitches.
5
Build during the 6-week cycle
The team works by integrating design and development from day one. Singer recommends starting with the "unknowns" (the risky parts) rather than the easy ones. Progress is tracked via a hill chart: each scope moves from "figuring things out" (uphill) to "making it happen" (downhill). If a scope remains stuck uphill at week 4, that is a warning signal. Output: complete feature delivered at the end of the cycle.
6
Use the circuit breaker if necessary
The 6-week deadline is a circuit breaker: if the project is not deliverable at the end of the cycle, it does not automatically receive additional time. The team must deliver a reduced version or the project is stopped. This constraint forces scope decisions to be made early rather than late. It is uncomfortable but it is what prevents projects from drifting indefinitely. Output: delivery or documented abandonment decision.
7
Take the 2-week cooldown
After each 6-week cycle, the entire team takes a 2-week cooldown. No shaped projects, no deadlines. This is the time to fix bugs, explore technical ideas, clean up debt, or simply breathe. The cooldown is not optional: without it, the 6-week pace becomes unsustainable. Output: bugs fixed, explorations conducted, team recharged.
8
Iterate with the next cycle
The next cycle begins with a new betting table. Pitches not selected in the previous cycle can come back, improved by learnings. Already delivered pitches can spawn shaped follow-ups. Each cycle is a clean slate: no backlog debt accumulation. Output: new cycle launched with the most promising projects.