Shape Up Summary: Basecamp's Method and How to Run It With AI (2027)

Your team has missed its last several sprint commitments. The backlog passed 400 tickets a while ago, and grooming still takes a full morning every week. Then someone forwards Basecamp's Shape Up with a one-line note: “should we do this?” This guide comes from the BuildBetter team, which helps B2B product teams connect what customers ask for with what actually ships. It covers three things: a faithful Shape Up summary, a way to pilot the method next cycle without buying anything, and how AI prototyping and customer evidence fit into a method written before either was cheap.

What Is Shape Up? A Plain-Language Definition

Shape Up is a product development method written by Ryan Singer at Basecamp and published free online in 2019. Senior people shape rough but bounded solutions to problems. Leadership bets on a few of them at a betting table. Small teams then build each bet in a fixed six-week cycle, followed by a two-week cool-down.

Three ideas carry the whole method:

• Appetite replaces estimates. You decide how much time a problem is worth before anyone designs a solution.
• Work is shaped at the right level of abstraction. A pitch is more concrete than a vague wish and less concrete than a wireframe spec.
• There is no backlog. Pitches that don't get chosen are not stored, groomed, or implicitly promised.

The book comes from the same company that published Getting Real (2006) and Rework (2010) by Jason Fried and David Heinemeier Hansson. That company was founded as 37signals, renamed Basecamp in 2014, and renamed 37signals again in 2022. Basecamp is now the name of its project management product, so this article uses “Basecamp (now 37signals)” where the distinction matters. Singer spent about 17 years there in design, product strategy, and head-of-product roles. Jason Fried wrote the book's foreword.

Shape Up fixes time and varies scope. Scrum-style estimation tries to fix scope and then misses on time.

The full book, Shape Up: Stop Running in Circles and Ship Work that Matters, is free at basecamp.com/shapeup, and a PDF is available there too. This page summarizes it and does not replace it.

Why Sprints Keep Missing, and Where Shape Up Breaks Too

Sprints usually miss because the work entering them was never shaped, so the hard parts turn up mid-sprint. Shape Up targets five specific failure modes:

• Estimates on unshaped work are guesses. A ticket that says “add reminders” hides the timezone logic, the bounced-email handling, and the settings UI until someone starts building.
• Two weeks is too short to finish anything meaningful. Work spills into the next sprint, and commitments turn into fiction that everyone politely ignores.
• A growing backlog creates implied promises and grooming overhead. Hundreds of tickets nobody will build still need triage, re-ranking, and explanations to the customers who asked for them.
• Teams get tasks instead of problems. Nobody owns the outcome, so scope creep goes unchallenged.
• No time is protected for bugs, cleanup, or thinking. That time gets taken from committed work instead.

The calendar math is part of the appeal. A six-week build plus a two-week cool-down is an eight-week cycle, or about 6.5 cycles a year, compared with 26 two-week sprints. That means fewer planning meetings and fewer moments where a commitment can be missed.

Where Shape Up fails in practice

Shape Up has failure modes of its own, and teams that adopt it run into them predictably:

• Shaping becomes a bottleneck when only one or two senior people know how to do it.
• Pitches rest on the shaper's intuition rather than customer evidence, so teams build the wrong idea, just well shaped.
• Larger organizations bolt Shape Up onto quarterly roadmaps and dependency chains, which quietly brings the backlog back.
• Cool-down becomes overflow time for unfinished cycle work, which defeats its purpose.
• Teams skip hill charts and lose the early-warning signal the method depends on.

The sections below explain how to run Shape Up as written. After that, they show how AI-era prototyping and customer evidence can patch its two weakest points: shaping on intuition and never checking what happened after release.

Shape Up Summary in 10 Minutes: The Core Ideas, Part by Part

The book has three parts: Shaping, Betting, and Building. Each part produces something the next part depends on. Shaping produces pitches, betting turns pitches into commitments, and building turns those commitments into shipped work.

Part 1: Shaping

Shaping is done by a small senior group on a separate track from building. It is mostly design work, and it needs both interface and technical judgment. Shaped work has three properties:

• Rough: it leaves the team room to design the details.
• Solved: the main elements are worked out and connected.
• Bounded: it has an appetite and explicit exclusions.

Singer argues that wireframes are too concrete and leave designers no room to work, while plain words are too abstract and leave teams guessing at the hard parts. Shaping sits between the two. In later talks, he added a framing step that comes before shaping: agreeing with the business on what the problem is and whether it deserves an appetite at all.

Appetite

Set the time budget before you design the solution. A small batch is one designer plus one or two programmers for one to two weeks, and that team may finish several small batches in one cycle. A big batch is the same team for the full six weeks. In the book's framing, estimates start with a design and end with a number, while appetites start with a number and end with a design. Appetite is a constraint you choose, not an estimate you predict. If no solution fits the appetite, you drop or reframe the problem. You don't raise the budget.

Breadboarding

Breadboarding borrows a term from electrical engineering. It is a text-and-arrows sketch with three elements:

• Places: screens and dialogs the user navigates to, written underlined.
• Affordances: buttons and fields the user acts on, listed under each place.
• Connection lines: arrows showing how affordances move the user between places.

Use a breadboard when the flow matters more than the visuals.

Fat-marker sketches

Fat-marker sketches are drawn with a line so thick it cannot hold detail. Use them when the visual arrangement matters. The thick line is deliberate, because it stops anyone from making UI decisions too early.

Rabbit holes and no-gos

Before the betting table, the shaper looks for technical unknowns and design traps (rabbit holes) and either patches them or removes them from the solution. No-gos are the things explicitly excluded from scope.

The pitch

A pitch is a written document meant to be read asynchronously before the betting table. It has five ingredients. Here is a template you can copy:

• Problem: the specific situation, who hits it, and what they do today.
• Appetite: small batch (1–2 weeks) or big batch (6 weeks), and why it is worth that much.
• Solution: breadboard and/or fat-marker sketch of the core elements.
• Rabbit holes: the risks you found and how the solution patches each one.
• No-gos: what this bet will not do.

Part 2: Betting

The betting table is a short meeting of senior stakeholders held during cool-down. They choose which pitches get bet on for the next cycle. The book's chapter title states the rule: bets, not backlogs. Pitches that aren't chosen are not saved. Anyone who still cares about one re-pitches it next time.

Six-week cycles and the circuit breaker

Six weeks is long enough to build something meaningful and short enough that the team feels the deadline from day one. By default, a project that isn't done at the end of the cycle does not get an automatic extension. This circuit breaker limits the cost of a bad bet to one cycle.

Cool-down

Cool-down is two weeks between cycles with no scheduled work. Programmers and designers fix bugs, explore ideas, and clean up. Leadership uses the same two weeks to hold the betting table. Cool-down takes 25% of calendar time, which skeptics call expensive. The counterpoint is that bug fixing and cleanup happen anyway. Shape Up just stops taking that time from committed work.

Part 3: Building

Teams are assigned projects, not tasks. The team gets the whole shaped pitch and full responsibility for it, and works out its own tasks.

Scopes

Teams organize the work into scopes: integrated slices of the project that can be finished independently, named in the team's own language. The book's advice is to get one piece done early, finishing a single slice end to end instead of building the whole backend first.

Hill charts

Each scope is plotted as a dot on a hill. The uphill side is the figuring-out phase, where unknowns remain. The downhill side is execution, where the remaining work is known. A scope that stays uphill for too long is the early warning to cut it or rethink it. Hill charts show a kind of progress that a count of completed tasks hides.

Scope hammering

Fixed time forces trade-offs. For each item, ask whether it is a must-have. Compare the work against what customers have today, not against an ideal version. Mark nice-to-haves so they can be dropped without debate.

How to Run Your First Shape Up Cycle Starting This Week (No Tools Needed)

You can pilot Shape Up with a shared doc, a whiteboard, and one willing team. Follow these steps in order:

1. Freeze the backlog. Don't delete it, but stop grooming it. Pull the 5–10 problems customers raised most often last quarter, and note who raised each one and what workaround they use today.
2. Name one or two shapers. Give them two weeks to shape in parallel with current work. Include at least one senior technical person so shaping doesn't depend on a single PM.
3. Set appetite first. For each candidate problem, decide whether it is worth a small batch (1–2 weeks) or a big batch (6 weeks) before anyone sketches a solution.
4. Shape the solution. Breadboard the flow or fat-marker sketch the layout. Then list the rabbit holes and no-gos.
5. Write pitches. Use the five-ingredient template and keep each pitch under two pages.
6. Hold a betting table of 60–90 minutes. Invite the people who own product, engineering, and the business. Bet only on what fits the cycle's capacity. A six-engineer team can run roughly three big bets, or a mix of big and small batches.
7. Hand each bet to a team. Each team is one designer plus one or two programmers. They map scopes in week one and update a hill chart every week.
8. Apply the circuit breaker at week six, then run a real two-week cool-down with no scheduled work.

Pilot rule: run one cycle with one team before converting the whole organization. At the end, compare the scope that team shipped against what it shipped in its last three sprints. If you can't explain the difference with evidence, run a second cycle before deciding.

What Changes When AI Can Build a Prototype in Hours

Shape Up was written when building anything just to test it cost days. In 2027, an AI coding assistant can produce a rough working spike in an afternoon. That changes where uncertainty sits during shaping. Controlled research supports the speed claim for this kind of work: in a 2023 experiment by Peng and colleagues, developers using GitHub Copilot finished a well-specified, greenfield JavaScript HTTP server task about 55% faster than a control group. That kind of task closely resembles a shaping spike.

The counterweight matters just as much. In METR's July 2025 randomized trial, experienced open-source developers working in their own mature repositories took about 19% longer with AI tools, while believing AI had sped them up by about 20%. AI speed is real for throwaway spikes. It is not guaranteed for production work in complex codebases.

Four practical changes

• Shaping can include a working spike, not just a sketch. Use a throwaway prototype to resolve a rabbit hole before the bet, such as a tricky integration, a data model question, or an awkward interaction. The spike informs the pitch and is never shipped as the solution.
• Pitches can cite customer evidence. The Problem section should carry the real requests: how many accounts asked, what workaround they use, and who specifically raised it. That keeps the betting table from becoming a contest of opinions.
• Put the spike in front of 2–5 customers during shaping. Record whether each one could complete the job in their own workflow. Marty Cagan names four discovery risks: value, usability, feasibility, and business viability. A spike tested this way mostly addresses feasibility and usability, partly addresses value, and does all of it before the six-week commitment.
• Cool-down can review what customers did with the last release. Did they complete the job? Did they come back? Which scopes went unused? Those answers become evidence for the next betting table.

What should not change

Fixed appetite, the circuit breaker, no backlog, and team ownership all stay. Faster AI building is a reason to shape more carefully, not to fit more scope into six weeks.

Cheap prototypes tempt teams to skip shaping entirely. A fast build of an unshaped idea is still unshaped.

Worked Example: From Raw Customer Requests to a Shaped Pitch

This is an illustrative scenario with round numbers, not a case study. It shows how evidence, appetite, and a spike combine into one pitch.

Setting: a B2B invoicing SaaS company. In one quarter, 23 requests from 17 accounts mention “reminders.” They break down as 11 support tickets, 8 mentions on sales or CS calls, and 4 Slack messages from account managers.

1. Cluster the raw requests. The pile contains five distinct asks: automatic overdue reminders (14), custom email templates (4), SMS reminders (2), escalation to a manager (2), and a per-client reminder schedule (1). Each request keeps its requester's name and quote attached.
2. Identify the job and the workaround. Every Monday, finance admins export overdue invoices to a spreadsheet and email clients by hand. By their own account, this takes about an hour a week per admin.
3. Set the appetite. Leadership decides the problem is worth a small batch: two weeks, one designer plus one programmer. It is not worth six weeks.
4. Shape the solution. The breadboard runs: Invoice settings → “Remind after X days” toggle → default reminder email → activity log entry on the invoice. A fat-marker sketch shows the settings panel.
5. Build an AI spike. A programmer builds a throwaway prototype in an afternoon. It exposes one rabbit hole: whose timezone determines “X days overdue,” the client's or the sender's? The patch is to calculate everything in the account's timezone and note that in the pitch.
6. Test the spike with three requesting customers. Two of the three set it up without help. The third needed per-client schedules, so that becomes a no-go for this bet.
7. Write the pitch.
   • Problem: the evidence counts plus two named requesters.
   • Appetite: 2 weeks.
   • Solution: the breadboard and sketch.
   • Rabbit holes: timezone handling; bounced emails go to the activity log only.
   • No-gos: custom templates, SMS, escalation, per-client schedules.
8. Decide at the betting table. Leadership bets the small batch this cycle. The SMS and escalation asks are declined and not logged to a backlog. The table also defines what cool-down will check: the share of the 17 requesting accounts that turn reminders on within 30 days, and whether the Monday spreadsheet workaround stops.

The example shows three things. Evidence narrowed five asks down to one. Appetite capped the cost at two weeks. The spike removed the riskiest unknown before anyone committed to the bet.

Shape Up's Betting Table vs Ship First's 'Small Working Answer' Loop

Ship First: How to Build Self-Improving Products is a free book by Spencer Shulem, cofounder and CEO of BuildBetter. Its core loop has four steps. A customer asks for something. You build a small working answer. They try it in their own workflow. What happens next tells you what to improve. The two approaches overlap but put the decision in different places.

Where Shape Up is stronger

Shape Up protects team focus for six uninterrupted weeks, limits losses with the circuit breaker, and forces explicit scope decisions through appetite and no-gos.

Where the Ship First loop is stronger

The Ship First loop ties each piece of work to a specific customer and job. It matches the experiment to the question, whether that means conversations, grounded personas, surveys, prototypes, or working releases. It also follows a release after it ships instead of moving straight on to the next bet.

How to combine them

Use Ship First's evidence habits to fill the pitch's Problem section and to structure the cool-down review. Keep Shape Up's appetite and betting table as the mechanism for making commitments. Shaping the bet is covered among Ship First's opening chapters, so the two books fit together where they meet.

Adjacent Questions: Shape Up vs Scrum, Continuous Discovery, and Lean Startup

Shape Up vs Scrum

Shape Up and Scrum differ on almost every planning mechanic:

• Fixed six-week cycles instead of two-week sprints.
• Appetite instead of story-point estimates.
• No backlog instead of a groomed product backlog.
• Hill charts instead of burndown charts.
• Teams own the whole project instead of pulling individual tasks.

Shape Up and Continuous Discovery Habits

Teresa Torres's Continuous Discovery Habits (2021) describes weekly customer touchpoints run by the product trio, plus the opportunity solution tree (outcome → opportunities → solutions → assumption tests). Both can feed shaping directly. Torres covers discovery. Shape Up covers commitment and delivery.

Shape Up and The Lean Startup

Eric Ries's build-measure-learn loop from The Lean Startup (2011) maps onto spike, pitch, cycle, and cool-down review. Shape Up adds the time box that Lean Startup leaves open.

Is Shape Up still relevant in 2027?

Yes, with one update. Shaping and cool-down should now include working prototypes and a look at how customers actually behaved after release.

Does Shape Up work for large companies?

It works best with small autonomous teams and few cross-team dependencies. Larger organizations often run it separately in each product area rather than company-wide.

Common Shape Up Mistakes (and Why They Fail)

Most failed Shape Up adoptions break one of the method's constraints while keeping its vocabulary. These are the eight most common mistakes:

• Treating appetite as an estimate. Teams extend the cycle because the work is “almost done,” which removes the circuit breaker and its cap on losses.
• Over-shaping into wireframes and specs. The team loses room to solve the problem, and the process becomes waterfall in six-week chunks.
• Under-shaping into a one-line idea. Rabbit holes surface in week four, and scope hammering turns into panic.
• Keeping a secret backlog of declined pitches. This recreates grooming debt under a different name.
• Using cool-down to finish cycle work. Bugs and exploration never get time, and the next cycle starts with a tired team.
• Pitching without customer evidence. The betting table ends up rewarding whoever is most persuasive.
• Shipping the AI spike. Prototype code written to answer a question becomes production debt.
• Never checking what customers did after release. Without that check, the next bet repeats the last mistake.

When You Need Tooling (and When a Doc Is Enough)

A shared doc and a spreadsheet of requests work fine for one or two teams handling up to roughly 150–200 pieces of customer feedback a month. Past that point, especially when evidence is spread across call recordings, support tickets, and Slack, shapers spend more time hunting for evidence than shaping. A second threshold arrives when more than about three pitches compete at each betting table. Attaching consistent evidence to every pitch by hand is the first step teams skip under pressure.

1. BuildBetter. BuildBetter captures calls, support tickets, and Slack conversations as customer evidence in one place. It then helps turn clusters of requests into PRDs and tickets that keep each requester and quote attached. That is useful for filling a pitch's Problem section and for the cool-down review of what customers did with the last release. One honest caveat: if you need enterprise survey distribution at scale or a dedicated research-repository workflow, tools built for those categories go deeper.
2. Basecamp. It has built-in hill charts and is the most direct way to run the method as written.
3. The AI coding assistant your team already uses. Use it for throwaway shaping spikes. You don't need to buy anything new.

None of these tools is required. The method in this guide works with a doc.

Shape Up FAQ

What is Shape Up in one sentence?

Shape Up is Basecamp's product development method in which senior people shape bounded solutions, leadership bets on them at a betting table, and small teams build them in six-week cycles followed by a two-week cool-down.

Is the Shape Up book free?

Yes. Ryan Singer's Shape Up (Basecamp, 2019) is free to read online at basecamp.com/shapeup, and a free PDF download is available there.

What is appetite in Shape Up?

Appetite is how much time the business is willing to spend on a problem: either a small batch of one to two weeks or a big batch of six weeks. It is set before the solution is designed and replaces estimation.

What goes in a Shape Up pitch?

A pitch has five ingredients: problem, appetite, solution (usually breadboards or fat-marker sketches), rabbit holes, and no-gos. Pitches are written to be read asynchronously before the betting table.

Why does Shape Up have no backlog?

Pitches that aren't bet on are not stored centrally. Anyone who still believes in one re-pitches it later, which avoids grooming overhead and implied promises. Individuals and departments may still keep their own informal lists of ideas.

How does AI change Shape Up?

AI prototyping lets shapers test a working spike with customers before the bet, so pitches can carry real evidence. Fixed appetite, the circuit breaker, and cool-down should stay unchanged.

Related Reading

1. Ship First: How to Build Self-Improving Products by Spencer Shulem. It is free, 24 chapters, and available as PDF and EPUB. It covers the small-working-answer loop, choosing the right experiment, and following a release through after it ships.
2. Customer-Led Development by Spencer Shulem, the longer book that Ship First accompanies.
3. Shape Up by Ryan Singer (Basecamp, 2019, free online).
4. Continuous Discovery Habits by Teresa Torres (2021).
5. Inspired by Marty Cagan (2008; 2nd edition 2017) and Empowered (2020, with Chris Jones).
6. The Lean Startup by Eric Ries (2011).
7. The Four Steps to the Epiphany by Steve Blank (2005).
8. Getting Real (2006) and Rework (2010) by Jason Fried and David Heinemeier Hansson.

Get Ship First Free

If your pitches need better customer evidence and your cool-downs need a real review of what customers did, Ship First by Spencer Shulem shows how BuildBetter makes the loop of customer asks, small working answer, customer tries it, and improve repeatable. The book is free, with 24 chapters and 6 illustrations, in PDF and EPUB. Get Ship First here (email signup).

Sources and Further Reading

• Shape Up by Ryan Singer, free online: https://basecamp.com/shapeup
• 37signals on Wikipedia (company background): https://en.wikipedia.org/wiki/37signals
• Lean startup on Wikipedia: https://en.wikipedia.org/wiki/Lean_startup
• Scrum on Wikipedia: https://en.wikipedia.org/wiki/Scrum_(software_development)
• Ship First by Spencer Shulem: https://www.buildbetter.ai/ship-first
• Customer-Led Development on Kindle: https://www.amazon.com/dp/B0HM3FMZLN

Make Churn Optional

Shape Up gives your team a way to commit to work. BuildBetter supplies the evidence those commitments should rest on: every call, ticket, and Slack thread, with requesters and quotes attached, turned into PRDs and tickets your team can actually bet on. Then you can see what customers did after you shipped.

Make churn optional. Book a demo.