Shape Up: Stop Running in Circles and Ship Work that Matters

The bottom line

Teams ship reliably when they fix the time, shape the work before committing, and let a small team cut scope to fit a six-week bet. A builder who caps every bet's downside stops running projects that never end and regains the ability to ship.

Key takeaways

• Decide how much time an idea is worth before designing anything. An appetite starts with a number and ends with a design, so time stays fixed and scope bends. Ch. Set Boundaries
  • A customer asked for complex permission rules, easily a six-week job. The real problem was a file archived by someone who didn't know it would vanish for everyone, so Basecamp added a warning to the archive action in one day.
  • A vague "Files 2.0" project became a mess because nobody knew what done meant. Split into "Better file previews" and "Custom folder colors," each with its own appetite, every piece shipped.
• Hand builders work that is rough, solved and bounded. Wireframes leave designers no room, and one-line requests leave no edges. Ch. Principles of Shaping
  • A full calendar could take six months, and only about 10% of customers had used one. Basecamp gave it one six-week cycle and shaped a read-only two-month dot grid, with dragging, multi-day spans and color coding ruled out.
• Remove the rabbit holes before anyone commits to the work. One surprise two-week problem eats a third of a six-week budget. Ch. Risks and Rabbit Holes
  • Basecamp bet on redesigning how client projects appear on the home screen and assumed the designer would find a way. Nobody found a workable design in six weeks, and the project was abandoned.
  • For To-Do Groups, shapers settled the tricky case of completed items up front: leave them as before and append the group name. It was a bit messy but made the problem far smaller.
• Bet one six-week cycle at a time and cancel unfinished work by default. A capped bet can lose at most its six weeks, and no backlog drags old ideas along. Ch. The Betting Table
  • Basecamp tried two-week cycles and found the planning overhead and broken momentum cost more than the work produced. Years of experiments led to six weeks plus a two-week cool-down.
  • The betting table is the CEO, the CTO, a senior programmer and Ryan Singer. They read pitches ahead, rarely meet past an hour or two, and their plan needs no further approval.
• Give the team the whole project and have it finish one real slice first. Discovered tasks outnumber imagined ones, and only working software proves progress. Ch. Get One Piece Done
  • On Clients in Projects, one designer and one programmer built the visibility toggle first, the most central piece. About three days in, it was demoed to a manager, tweaked and called done.
• Track each scope by what is still unknown, and push the riskiest ones uphill first. Task lists grow as work is found, so counts hide where a project is stuck. Ch. Show Progress
  • A team facing geocoding, which it had never done, and an email template went after the geocoder first. The template could be done in a day in the final week, while geocoding could hide weeks of new problems.
  • A "Notify" scope sat still on the hill because it mixed three parts at different stages. Splitting it into separate scopes showed each part's real position.

An estimate begins with a design and produces a number. An appetite begins with a number and produces a design.

Ryan Singer, Set Boundaries

Growing teams lose the ability to ship, and that is the risk to fix first

As software teams grow they stop shipping, and the first problem to solve is the risk of not shipping on time, not the risk of building the wrong thing.

• Growth quietly breaks a team's ability to finish work. Ch. Introduction
  • Projects drag on with no clear end.
  • Product managers lose the time they need for strategy.
  • Founders wonder why features stopped shipping the way they did early on.
  • Basecamp hit all three as it grew from four people to over fifty.
  • By 2015 the product team had quadrupled and everyone worked remotely. The core team struggled to pass its instincts on to new hires.
  • The fix was structure and vocabulary. Ad-hoc project lengths became repeating cycles, settled at six weeks after some experimenting. Pitching and betting became formal steps, and up-front design got a name: shaping.
• A project that ships can still be a failure. Ch. Foreword by Jason Fried
  • Doing the work the wrong way can wreck morale, grind people down and erode trust.
  • Many projects run long, pile up at the end and set teams against each other. Some would have been better off dying.
  • Jason Fried flips the old saying. Execution matters, but a bad way of executing is the root of whatever goes wrong.
  • Basecamp skipped waterfall, agile, scrum, sprints, stand-ups, backlogs, Kanban and velocity tracking. Its own process grew over nearly 15 years of trial, notes and iteration.
  • The result is a small team that ships a lot, quickly and at high quality, and stays together for years.
• Fix shipping before discovery, using three risk reducers. Ch. Introduction
  • Shaping settles open questions, rabbit holes and tangled dependencies before anything is committed.
  • Betting caps each project at six weeks with no default extension. That rule works as a circuit breaker.
  • Building pairs design and code early, one end-to-end piece at a time, starting with the most unknown parts.
  • The method does not guard against building the wrong thing. For that, Singer points to Competing Against Luck.
  • Singer's reason for the order: You can have the best strategy in the world, but if you can't act on it, what good does it do?
  • The parts feed each other. Autonomous teams need less managing, which frees senior people to shape better work, which gives teams clearer edges and more autonomy.
• The habits came from real constraints and hard projects. Ch. Introduction
  • With only ten programming hours a week, fitting scope to a time budget became a reflex.
  • Programming ideas like factoring, levels of abstraction and separation of concerns carried over to product design.
  • Basecamp started in 2003 as a tool that a web design consultancy built for its own use. David Heinemeier Hansson spent ten hours a week coding it, from the early prototypes in July 2003 until the launch in February 2004.
  • In 2009 Basecamp merged four separate SaaS products into one suite with single sign-on and unified billing. Customers had to change usernames and passwords. Singer prototyped breadboarding and scope mapping to manage it.
  • In 2012 the team rebuilt Basecamp 2.0 from scratch. The surface area was large, yet the project went surprisingly smoothly.

Decide what an idea is worth before designing it, and narrow the problem

A raw idea becomes shapeable only once it has a fixed time budget and a narrow, specific problem behind it.

• Size every idea as a Small Batch or a Big Batch before talking solutions. Ch. Set Boundaries
  • A Small Batch is one designer and one or two programmers for one or two weeks. Several are grouped into one six-week cycle.
  • A Big Batch is the same team for a full six weeks.
  • Ask what the idea deserves: a quick fix, a full cycle, a redesign of existing parts, or a minor tweak.
  • If the work cannot fit six weeks, narrow the problem. If it still will not shrink, break off a meaningful part that can be shaped to six weeks.
  • An appetite is not a forecast of how long work takes. It is a constraint the design must fit.
• A fixed deadline forces the cuts that protect quality. Ch. Set Boundaries
  • With a week left on this book, the choice was typo fixes or a new chapter section. The typos won.
  • A solution is good only relative to the time you want to spend and how much the thing matters.
  • With no fixed deadline, that trade would never have been made. With fixed scope, no time would have been left for quality.
  • The constraint works twice. It limits what gets designed during shaping. Later it pushes builders to separate core work from peripheral work.
  • A hot dog is the perfect meal when you are hungry and rushed. Context, not abstract merit, decides what fits.
• Meet raw ideas with a calm soft no. Ch. Set Boundaries
  • First contact is too early to commit. Saying yes to everything builds an endless pile.
  • The idea gets a neutral reply and stays out of any backlog.
  • The default reply is Interesting. Maybe some day.
  • Flat rejection risks losing something that later information shows is valuable.
  • Visible excitement also sets expectations you may fail to meet once the idea competes with other priorities.
• Narrow the problem by asking when, not why. Ch. Set Boundaries
  • Ask the customer when they wanted it and what they were doing. Find where their workflow broke.
  • A request for a calendar shrank to one need: seeing free spaces.
  • Her office booked meeting rooms on a chalkboard wall calendar. Working from home, she drove through bad traffic to check it and found no free slot for her client.
  • Seeing open slots from home would have saved her an hour. Basecamp's agenda view could not show empty spaces.
  • The appetite also caps research. If no specific pain point appears and the issue is not critical, walk away and wait for a better story.
• Redesigns and "2.0" labels with no single problem are grab-bags, not projects. Ch. Set Boundaries
  • Nobody can say where a grab-bag starts or ends.
  • Reframe each one around one problem, such as sharing multiple files taking too many steps.
  • Ask what is not working, in what context, and which parts of the current design can stay.
  • If a vague effort is already underway, split it into smaller projects, each with its own appetite.

Hand builders work that is rough, solved and bounded

Shaped work sits between a mockup and a one-liner. It is rough enough to leave room, solved enough to build, and bounded enough to stop.

• Too much detail and too little both break a fixed-time project. Ch. Principles of Shaping
  • An exact mockup can hide costly implementation that the drawing never shows.
  • With scope fixed, the team cannot drop a design choice that costs more than it is worth.
  • A request like "build a calendar view" gives no basis for trade-offs, and nothing marks what is out.
  • Counter-intuitive as it may seem, the more specific the work is, the harder it can be to estimate.
  • Detailed mockups bias whoever works on them next, more so when a senior person drew them. Saying "ignore how I drew it" does not undo that.
  • A vague request leaves the team solving a problem with no context. They have to guess what was meant.
• Rough, solved and bounded together give the team room inside guard rails. Ch. Principles of Shaping
  • Rough: visibly unfinished, so builders see where their judgement goes.
  • Solved: main elements connected at the macro level, not split into tasks.
  • Bounded: an appetite plus explicit exclusions show where to stop.
  • Roughness leaves the details open. The solution and boundaries keep the team from overbuilding, wandering or getting stuck.
  • Solved work can still hide icebergs that only surface during building.
  • The result is not a spec. It works like the rules of a game that can be played many ways.
• Shaping belongs to a small group on a private track, apart from building. Ch. Principles of Shaping
  • It blends interface ideas, technical options and business priorities, so it needs a generalist or one to three people.
  • It cannot be scheduled, because unshaped work is still unknown.
  • Nothing is committed yet, so shapers can shelve or drop an idea freely.
  • Shapers need not be programmers. They must be technical enough to judge what is possible, easy or hard.
  • During each six-week cycle, teams build earlier shaped work while shapers prepare candidates for later cycles.
  • For speed, shape alone or with one trusted partner who shares background, talks in shorthand and takes frank feedback.
  • Sketches at this stage are often unreadable to anyone outside the room. That is fine, because they are not deliverables.
• Breadboards and fat marker sketches keep the work concrete but rough, and they end in a short list of elements. Ch. Find the Elements
  • Four questions guide the work: where does it fit, how do you reach it, what are the key parts, and where does it lead?
  • Breadboards use words only: places, affordances and connection lines.
  • Fat marker sketches handle 2D layout with strokes too broad for detail.
  • To breadboard, start at a point in the existing product. Write each place's name and underline it. List its buttons, fields and copy beneath. Then draw lines to where each leads. Leave open whether a place is a screen or a modal, since the flow is the same.
  • An invoicing team first put "Turn on Autopay" on the invoice. That raised whether the current invoice was paid too, and it muddled the confirmation. So they made Autopay an option during payment. Customer logins to turn it off exceeded the appetite, so invoicers got a disable control on the existing customer page.
  • Basecamp's team kept making fake to-dos like "Needs testing," padded with dash lines, to divide lists. Fat marker sketches turned that workaround into dividers, with loose to-dos above and grouped ones below.
  • Fat marker sketches constrain less than breadboards. It is easy to get attached to a sidebar you happened to draw. They still beat jumping to wireframes early.

Remove the rabbit holes, then write the pitch

Shaped work is ready to bet on only after its visible risks are closed and it is written as a pitch that ties a specific problem to an appetite, a solution and explicit limits.

• Slow down after sketching and hunt for holes that could stretch the project far past its appetite. Ch. Risks and Rabbit Holes
  • Aim for a thin-tailed risk profile. Parts should be independent, familiar and fit together in known ways.
  • Ask four questions. Is there new technical work? Are we assuming how parts fit? Are we assuming a design exists that we could not produce ourselves? Should a hard decision be settled now?
  • Test doubtful assumptions with experts by asking whether the idea fits six weeks, not whether it is possible at all.
  • Trace one use case in slow motion, step by step from start to end, and note every gap that still needs design. Fast, broad sketching tends to skip these gaps.
  • A thin tail means a slight chance of one extra week and no reason to run much longer. Technical unknowns, unsolved design and misunderstood interdependencies can push a project to several times its appetite.
  • Expert review runs at a whiteboard, never slides, so the clay stays wet. Frame it as just an idea, rebuild it from the start, get feedback on the worked-out version, then invite radical simplifications. In software, everything is possible but nothing is free.
  • Some unknowns always remain. The aim is to remove the visible ones, because the team's later practices only leave room for the truly unexpected. Review may also send the idea back for more shaping.
• Close each hole before the bet by dictating patches, declaring cases out of bounds and cutting extras. Ch. Risks and Rabbit Holes
  • A patch can be a worse design. Lower risk is worth that trade.
  • Name unsupported use cases, because teams naturally try to cover them all.
  • Cut exciting but unneeded parts. The feature must be valuable without them.
  • Group notifications let a user pick "Programmers" instead of checking off five people. The same idea fit to-do assignment and chat mentions. The shapers kept only the faster flow for posting messages and ruled the rest out of bounds.
  • Color-coded To-Do Groups looked more interesting and maybe more useful. They were cut from the core. The team could hear about them as a nice-to-have, but everyone assumed the feature worked without them.
  • Handing a deep design problem to a team on deadline is irresponsible. Untangling interdependencies inside a short cycle burns the little time it has. Ruling cases out matters less as a team gets better at scope hammering, but it is still worth doing.
• A pitch needs five ingredients: problem, appetite, solution, rabbit holes and no-gos. Ch. Write the Pitch
  • Tell the problem as one specific story of the status quo failing. Without it, nobody can judge one solution against another.
  • Stating the appetite cuts debate. A better solution always exists, so the real question is what fits the time.
  • A problem with no solution attached is unshaped work and not ready to bet.
  • A bare request like "add tabs to the iPad app" drifts into endless UI debate. A stated problem also lets people question demand, so they avoid six weeks on a clever fix for a small group of low-retention customers.
  • Payment Form settled a rabbit hole in a few lines: exactly how URLs get created, and no custom domains for v1. Its no-go banned WYSIWYG editing. Users could only add a logo and change header text on a separate "customize" page.
  • Basecamp's to-do grouping pitch opened with a workaround people already used, shown in two screenshots. The notifications pitch opened with two videos and ended with user behavior data backing its trade-offs.
• Make the solution visible to readers without context, then share it for written critique, not votes. Ch. Write the Pitch
  • Pitch drawings go a step more concrete than private sketches. They stop short of wireframes, which box in designers.
  • Readers take in the pitch on their own time, so the betting meeting stays short.
  • Comments poke holes or add missing facts. The yes or no stays with the betting table.
  • On the Dashboard pitch, readers could not picture where the new affordances went, even with a box drawn on the screen. Shapers dropped that linchpin part to fat-marker detail and told designers they were free to find a different layout.
  • Raw breadboards read as a soup of words and arrows to anyone who did not watch them form. Redraw sketches cleanly, use separate colors for labels, and add call-outs so specific elements can be discussed.
  • Basecamp posts pitches as Messages under a "Pitch" category in a private Team called Product Strategy. Sketches come from an iPad with Notability. In one case the CTO added technical thoughts in the comments.

Bet one six-week cycle at a time, with no backlog and no default extension

Scheduling works as a series of short, deliberate bets on fresh pitches, with nothing carried forward unless someone bets on it again.

• Drop the central backlog and let important ideas come back on their own. Ch. Bets, Not Backlogs
  • Backlogs swell to hundreds of items nobody reaches, and the pile makes people feel behind when they are not.
  • Each department keeps its own list, or none. These lists help their owners advocate. They never feed the table directly.
  • Support tracks the requests that recur most. In an occasional one-on-one, it tells Product the top issues. Product adds them to its own list of possible projects and may pick just one now. Support can lobby again at a later meeting.
  • Recurrence is the signal. A recurring bug returns when customers complain again or new customers hit it. A problem heard once and never again may not have been real.
  • A good pitch can lose only because of timing. It survives if someone tracks it their own way and pitches it again six weeks later. It then arrives with fresh context and a person behind it.
• A bet buys uninterrupted time and starts each cycle from a clean slate. Ch. The Betting Table
  • Interruptions cost more than the time taken, because the team has to rebuild its momentum.
  • Unfinished work gets no extension by default. Leftovers return only if they are reshaped and bet on again.
  • Even "just a few hours" requests break the commitment: Losing the wrong hour can kill a day. Losing a day can kill a week.
  • A feature expected to take two cycles still gets one bet. Shape a six-week target that ends fully built and working. Bet the next six weeks only if the first goes as planned. Otherwise redefine the work or pause it.
  • No extension is a default, not an absolute. A longer roadmap can exist, but it lives in people's heads and side conversations, not as a commitment. The whole system fails without buy-in from the top.
• Bugs earn time by severity, like any other work. Ch. The Betting Table
  • Most bugs can wait six weeks or longer, and many never need fixing.
  • Small bugs go to cool-down. Big ones are shaped into pitches.
  • Only a real crisis stops a cycle: data loss, the app grinding to a halt, or many customers seeing the wrong thing.
  • A back-end process slows the app, and a programmer wants to make a synchronous step asynchronous. Rather than interrupt other work, the programmer pitches it, and senior people decide whether it is worth a cycle.
  • Once a year, around the holidays, Basecamp gives a full cycle to a bug smash. Travel and time off make normal projects hard then. The team organizes itself around the most important bugs and long-standing front-end and back-end issues.
• At the table, weigh pitches with five questions and probe any refusal. Ch. Place Your Bets
  • Ask: does the problem matter, is the appetite right, is the solution attractive, is it the right time, and are the right people free?
  • Once bets are made, someone from the table posts a kick-off message naming the projects and who works on them.
  • When someone rejects an appetite, first add missing facts, such as how vocal the affected customers are or how many support steps the problem takes. Then ask how a two-week version would feel. That can expose the real objection, such as a technical dependency. Finally, drop the idea or shape a smaller one.
  • A sweeping solution can mean the problem is not narrow enough. Narrowing might give 80% of the benefit from 20% of the change. Count hidden costs like lost screen space, but spend only moments on design at the table.
  • A well-shaped pitch can still wait if recent work makes it the wrong time, whether for a news splash, overdue fixes or team morale. People are picked by expertise, recent work and calendars.
• After launch, wait out the reaction and default to a gentle no. Ch. Move On
  • Releases draw a burst of requests and complaints, strongest when workflows change, even visually.
  • Each yes is debt against the next cycle. A no keeps the idea open for shaping.
  • A small minority may demand the change be reversed. Wait a few days, because the intensity fades. Recall why the change was made and who it helps.
  • A truly important request becomes the top shaping priority next cycle while builders work on another bet. The shaped version is pitched once those six weeks end.

Give the team the whole project and build one real slice first

A team that owns the whole pitch, defines its own tasks and integrates one small slice end to end learns the real shape of the work faster than any up-front plan.

• Assign whole projects, not task lists, and let the team define the work inside the pitch's boundaries. Ch. Hand Over Responsibility
  • Splitting a pitch up front hands everyone disconnected fragments and loses the bigger picture.
  • Plans on paper rarely survive practice. The people building are best placed to spot missing pieces.
  • A designer adds a button to the desktop interface. Then she sees it has no obvious home in the mobile webview, so she logs a new task nobody had imagined.
  • A designer's first pass has good hierarchy, but explanatory copy is needed in a spot that breaks the layout. That one discovery creates two tasks: rework the layout and write the copy.
  • A programmer doing a database migration reads the model and finds a method another part of the project will need changed later. Tasks often surface during unrelated work.
  • This is not total freedom. Shaping already drew the outline, and the team fills it in. Splitting the project into tasks up front is like putting the pitch through a paper shredder.
• Done means deployed before the cycle ends, and the quiet first days count as real work. Ch. Hand Over Responsibility
  • Testing and QA fit inside the cycle. Help docs, marketing and announcements can wait for cool-down because their risk is thin-tailed.
  • Early on, people learn the existing system and hunt for a starting point. Asking for status pushes that exploration underground.
  • Without deployment, the appetite, the budget and the circuit breaker mean nothing. Small Batch teams may deploy each small project whenever they like, as long as it lands before the cycle ends.
  • Basecamp kicks off by creating a new Basecamp project, adding the team and posting the pitch, or a distilled version, first on the Message Board. Remote teams then use the chat room to book a call for questions the write-up left open.
  • Make it normal to say "I'm still figuring out where to start." If the silence hasn't begun to break after about three days, step in and see what is going on.
• Integrate one slice through design and code first, picked because it is core, small and novel. Ch. Get One Piece Done
  • Screens with no back end stay speculative. Back-end logic with no UI cannot be judged.
  • Core means the rest is meaningless without it. Small means done in days. Novel breaks a tie, since unfamiliar work removes more uncertainty.
  • On Clients in Projects, the designer tried toggle affordances in HTML templates while the programmer spiked the access model. The programmer then wired the toggle to appear on every supported content type, change state and save, though it did not yet change visibility.
  • Client invite UI mirrored the existing user UI. Starting there would move the project forward but remove no uncertainty. Renaming a client was still required, just not worth proving first.
  • Start in the middle on the interesting problem. Stub login and setup instead of building them first.
• Give programmers raw affordances and keep the early back end strategically patchy. Ch. Get One Piece Done
  • Programmers need inputs, buttons and places where stored data shows up. Font, color and spacing come later.
  • The back end supplies only what the next design step needs. Anything that teaches nothing about the problem gets hard-coded.
  • A course registration screen asked for arrival time but not departure, with pulldown options matched to rules on charging for meals and overnight stays. A calendar date picker failed because multi-week course phases couldn't be labeled in day boxes. A pulldown with option groups replaced it.
  • An interview app's first piece hard-coded the project (Basecamp) and subject (Jan), used plain blue and purple links, and put adding and editing "pulls" on separate screens. The team tested that navigation before any styling.
  • Real interviews meant sensitive data. Rather than build logins, the team used plain HTTPAuth with a hard-coded password and entered real data very early.
• Once real work shows how tasks connect, factor the project into named scopes. Ch. Map The Scopes
  • A scope is an integrated slice, finishable in a few days or less, named for this project. Accurate scopes tend to appear around the end of week one.
  • Organize lists by project structure, not by person, so you can see which areas are finished.
  • A fundraiser run as one list per volunteer hides the event's state. Lists for Food Menu, Venue Setup and Light/Sound show it at a glance.
  • A message-drafts team had finished tasks but nothing to show near the end of week one. They pulled out Start New and finished it, split the rest into Locate, Trash and Save/Edit, then split Save/Edit into Send, Store and Reply.
  • Redraw a scope if its doneness is hard to judge, if its name is generic like "front-end" or "bugs", or if it is too big to finish soon. File bugs under the scope they affect.
  • Layer-cake work keeps design and code in one scope. Iceberg work may split the UI off, but first ask whether the complexity is needed. A Chowder list for loose tasks past three to five items signals a missing scope. A ~ marks nice-to-haves.

Track what is unknown, push risk uphill first, and hammer scope to fit

A fixed cycle ships when status is read as unknown versus solved, the scariest work goes first, and scope keeps getting cut against what customers have today.

• Real status is whether the approach is still being figured out, not how many tasks are checked off. Ch. Show Progress
  • Estimates mislead. Four hours on a familiar task is reliable. On a novel task it can become two or three days.
  • Every scope climbs uphill while the approach is unclear, then runs downhill once all the work is visible.
  • Percent complete only makes sense at the top of the hill.
  • A dinner host starts at the bottom left with only a date. Learning some guests are vegetarian rules out grilling and points to Indian over Italian, which is halfway up. A recipe and shopping list reach the top. Now estimates exist: an hour to shop, 30 minutes of prep, 45 of cooking.
  • The climb has three thirds. First, "I've thought about this." Second, "I've validated my approach." Last, "I've built far enough that I don't believe other unknowns remain."
  • An empty to-do list proves nothing. A scope may have no tasks yet, and QA can still add new ones.
• Managers read stuck work from hill snapshots, so they never have to nag for status. Ch. Show Progress
  • Comparing past snapshots shows what moves and what stalls.
  • People hide what they cannot solve. A stalled dot flags it without anyone speaking up.
  • Uphill and downhill language keeps the talk on the work, not the person.
  • A dot that doesn't move is effectively a raised hand
  • A recurring-events project showed three scopes. "Future-applying edits" still had real unknowns. "Global recurring events" was closest to done. When "Autosave" sat uphill too long, the manager skipped the general check-in and asked which unknown was holding it.
  • Inside the stuck "Notify" scope, the work was fine. Delivery code was mostly done. The email design was nearly figured out. The in-app display had not started.
  • Backsliding means the uphill work was solved in someone's head. A theory like "I'll just use that API" often turns out harder. Teams new to hill charts backslide a lot at first.
• Send the scariest scopes uphill first so that only polish is left to cut at the end. Ch. Show Progress
  • Work expands to fill the time available, so surprises found late are dangerous.
  • For each scope at the bottom, ask which could be thrown together fast if time ran out.
  • This mirrors the journalist's inverted pyramid. The essential facts go first so the tail can be cut.
  • Starting with the email template would have been the trap. Copy and design polish could have swallowed weeks.
  • Once a critical scope is over the top, leave it there. Then look for anything else that matters. The goal is to finish with only nice-to-haves and maybes outstanding.
• "Good enough" means better than what customers have today, not equal to an ideal design. Ch. Decide When to Stop
  • Work always exceeds time, so shipping on time means shipping something imperfect.
  • Scope creep is natural, so teams get the authority to keep cutting.
  • Cutting scope never lowers the bar on code, design, copy or performance.
  • Find the baseline first. How do customers solve this today, and what clumsy workaround does the feature remove? Then ask how much longer they should wait while the team debates design A versus design B.
  • Hammering questions include these. Could we ship without this? Is it a new problem or one customers already live with? How likely is the case? Is it core or an edge? How aligned is that use case with the intended audience?
  • Tilde-marked nice-to-haves can stay on a scope after it is called done. They usually never get built.
• QA and review improve the work but never block it, and only all-downhill must-haves earn extra time. Ch. Decide When to Stop
  • Designers and programmers own basic quality and write their own tests.
  • Uphill work found at the end means the shaping had a hole. That work goes back to shaping.
  • For years Basecamp had no QA role. Later its edge cases hit hundreds or thousands of users. Now, with millions of users and about a dozen product people, one QA person joins near the end to hunt edge cases.
  • QA findings start as nice-to-haves on a separate list. The team triages them, and any must-have moves onto its scope.
  • Code review is not a checkpoint. It happens when there is time, mostly as a chance to teach.
  • Extensions are rare and usually a couple of weeks. Cool-down can absorb a few must-haves. Running into it often signals a shaping or team problem.
• One tool can hold scopes as lists and track them on a hill. Ch. How to Implement Shape Up in Basecamp
  • Each scope becomes a To-Do List, and its tasks become items.
  • Each list is tracked as a dot on the Hill Chart.
  • "Cycle 4: Autopay" had scopes "Start Autopay" and "ACH Option." Start Autopay held one UI design task and one task to wire it to the existing recurring billing API.
  • Updating means dragging dots from unknown to known to done, with optional notes. Clicking the "last update" timestamp shows the history, newest first.

Keep the core truths and adjust the practices to product stage and team size

The standard cycle fits an existing product and a mid-sized team, so new products, tiny teams and first-time adopters keep the core truths but change the practices.

• New products need three different modes before the standard process applies. Ch. Place Your Bets
  • An existing product has fixed code and design that leave an empty space for each feature, so shaped bets can ship.
  • A new product moves from R&D (spiking, no shipping) to production (shaped cycles) to cleanup (must-haves only, two cycles at most).
  • R&D teams are senior people only. Nobody can delegate what they don't yet understand, and early architecture decides what is possible later.
  • In production mode, shipping means merging into the main codebase and not expecting to touch it again. Nothing reaches customers yet, so a team can build a feature that may not make the final cut, as long as it knows that.
  • Cleanup skips shaping and runs like a bug smash. Team boundaries drop, work merges in the smallest pieces, and leadership trims the V1, because less surface means fewer questions, less support and less to maintain. The risk is that cleanup becomes cover for launch nerves.
  • HEY launched in July 2020 after two years. Jason (CEO), David (CTO) and Jonas (senior designer) spent the first year in R&D. Nearly a year of production followed with all of Basecamp's teams. Two cleanup cycles then cut the feature set significantly.
• Even multi-year work is bet one cycle at a time. Ch. Place Your Bets
  • Each cycle can show the idea isn't ready or that it works, so the next bet stays open.
  • Risky features on existing products can be framed as internal-only first cycles.
  • Early on, the HEY table did not know the work would take two years, and switching back to Basecamp was always an option. R&D and production overlapped, with seniors handing off settled areas while exploring new ones.
  • Nobody knew if Hill Charts would work, and releasing it felt too risky. One cycle built a version just good enough for internal use, with no plan to ship. Once the team felt confident, a second shaped cycle rounded it out and shipped it. The risk was that the second cycle might never be scheduled.
• Shaping, capped bets and separating knowns from unknowns hold at any size. Ch. Adjust to Your Size
  • Skipped trade-offs come back later, forced by deadlines or technical limits in a rush.
  • Open-ended commitments hurt every team, whatever the bet length.
  • Shaping sets boundaries for whoever builds, even if that is your future self.
  • Unknowns exist whether or not anyone draws a hill chart. Separating them lets a team order the work and keep capacity in reserve.
• The practices should scale with headcount. Ch. Adjust to Your Size
  • A team of two or three can drop cycles, cool-downs, pitches and the betting table, with bets of two weeks, then three.
  • Growing teams need dedicated shapers and support roles to protect builders.
  • Small teams can't commit long stretches, because each person juggles programming, customer requests and infrastructure. They still shape, bet and build. Be deliberate about which hat you're wearing and what phase you're in.
  • Basecamp has about 50 people and roughly a dozen on product. A SIP team (Security, Infrastructure, and Performance), an Ops team and technical people on Support absorb interruptions, so Core Product designers and programmers stay on cycle work.
  • Shapers come from a founder who shifts roles or an employee moved from in-cycle design to out-of-cycle shaping. Six weeks may not be the right length for every team.
• Adoption can start small, and success is judged by what shipped. Ch. How to Begin to Shape Up
  • Three entry points: one protected six-week experiment, shaping alone, or six-week cycles first.
  • Idle people or unused hours don't matter if the project ships.
  • The experiment: shape one project that fits comfortably, leave extra time, protect one designer and two programmers from all interruptions, skip the betting table, and give them a shared room or chat.
  • Scope mapping comes once getting one piece done is habitual. Hill charts come once scopes are well defined. A successful first run builds credibility for wider change.
  • When a CTO controls programmer time, send one better-bounded project through the existing schedule to show what defined work looks like. Moving from two-week sprints to six weeks frees capacity that then pulls a team toward shaping.

Put it to work

Fix the time on your next piece of work, shape it before anyone builds, and let a small team cut scope until it ships inside the cycle.

1. Run one protected six-week experiment. Shape one significant project that fits comfortably in six weeks. Reserve one designer and two programmers for it, and let nobody interrupt them. Ch. How to Begin to Shape Up
   • Scope the first run conservatively and leave extra time. Skip the betting table, scope maps and hill charts until the team can get one piece done.
   • If someone else controls programmer time, start with shaping alone. Send one better-bounded project through the existing schedule and let it make the case.
2. Set the appetite and narrow the problem before sketching. Call the idea a small batch or a big batch first. Then find the exact moment the customer's current workflow breaks. Ch. Set Boundaries
   • Ask a customer when they wanted the feature and what they were doing, not why. One call shrank a calendar request to "help me see free spaces."
   • Meet raw ideas with a calm soft no: "Interesting. Maybe some day." Early enthusiasm sets expectations you may not meet.
3. Sketch the solution in words and thick lines. Breadboard places, affordances and connections, or use a fat marker sketch when the layout is the problem. End with a short list of concrete elements. Ch. Find the Elements
   • Playing through the Autopay flow showed a "Turn on Autopay" button raised a confusing question about the current invoice. The team moved Autopay into the payment step and reused the existing confirmation page.
   • Skip wireframes here. Detailed mockups bias whoever comes next, especially people junior to you.
4. Write a pitch with all five parts. State the problem as one specific story, the appetite, the solution, the rabbit holes and the no-gos. Post it where the people who bet can read it on their own time. Ch. Write the Pitch
   • The Payment Form pitch said URLs would never live on custom domains for v1, and ruled out WYSIWYG editing of the form.
   • Before writing, check risky assumptions with a technical expert at a whiteboard. Ask whether it fits in six weeks, not whether it is possible.
5. Bet one cycle at a time, and keep no backlog. During the two-week cool-down, a few senior people choose from recent pitches. Pitches that lose are let go, and whoever believes in one brings it back. Ch. The Betting Table
   • Drop everything only for a real crisis: data loss, the app grinding to a halt, or many customers seeing the wrong thing. Most bugs wait for cool-down.
   • Support keeps its own list of recurring issues and lobbies Product in infrequent one-on-ones. Issues that keep coming back earn a pitch.
6. Hand over the whole project and draw scopes from real work. The team writes its own tasks, builds one core slice first, and groups tasks into scopes once the structure shows. Ch. Map The Scopes
   • A message drafts team had finished tasks but nothing to show by the end of week one. They pulled out "Start New" as one integrated scope, finished it, then split the rest into Locate, Trash and Save/Edit.
   • Expect a few quiet days of orientation. Check in only if the silence lasts past about three days.
7. Judge against the baseline and hammer scope to fit. Ask whether the work beats what customers do today. Mark nice-to-haves with ~, and extend only for must-haves that are all downhill. Ch. Decide When to Stop
   • Treat every QA finding as a nice-to-have until the designer and programmer triage it. Move real must-haves onto the scope they affect.
   • After launch, wait a few days before reacting and answer requests with a gentle no. More time on that area needs a new bet.

The book's words

A handful of words let a team talk about time, risk and scope without talking past each other.

• Appetite How much time an idea is worth, set before any design, so time stays fixed and scope bends.
  • A Small Batch is one designer and one or two programmers for one or two weeks. A Big Batch is the same team for a full six weeks.
• Shaped work Work defined as rough, solved and bounded before any team commits to build it.
  • One to three people do it on a private track that runs alongside building.
• Breadboard A word-only sketch of places, affordances and the lines connecting them, with no visual design.
  • Borrowed from electrical engineering, where a breadboard has all the real components and wiring but no industrial design.
• Fat marker sketch A sketch drawn with strokes so broad that adding detail is hard or impossible.
  • Use a large Sharpie on paper or an iPad with a big pen size when the 2D arrangement is the core problem.
• Rabbit hole A technical unknown, unsolved design problem or tangled dependency that could push a project far past its appetite.
  • Group notifications looked useful for to-dos and chat mentions too. The team kept only message notifications and declared the rest out of bounds.
• Bet A commitment of a team's uninterrupted cycle to a shaped pitch, with a defined payout and a capped downside.
  • "When we put six weeks into something, six weeks is the most we can lose."
• Circuit breaker The default rule that a project unfinished at the end of its cycle is cancelled, not extended.
  • Extensions are rare, usually a couple of weeks, and only for must-haves with no unknowns left.
• Scope An integrated slice of the project, design and code together, that can be finished on its own in a few days or less.
  • On Clients in Projects the team talked in scope names like Bucket Access, Invite Clients and Visibility Toggle. Generic names like "front-end" or "bugs" signal a bad scope.
• Uphill and downhill Uphill work still has unknowns to figure out. Downhill work is pure execution.
  • On a hill chart, a dot that does not move works like a raised hand that something might be wrong.
• Scope hammering Repeated, forceful cutting of design, implementation or use cases so the work fits the time box.
  • Ask questions like "Could we ship without this?" and "Is this a new problem or one customers already live with?"

Chapter by chapter

Where each idea is in the book.

• Foreword by Jason Fried How a team works shapes what it can achieve, and finishing work the wrong way carries real costs to morale, trust and long-term progress. Basecamp built its own way of working over nearly 15 years, rejecting common methods, and lays it out in full here.
• Introduction Growing software teams lose the ability to ship. Basecamp regains it with six-week cycles, work shaped up front by a senior group, and small autonomous teams, all aimed at one risk: not shipping on time.
• Principles of Shaping Shaped work must sit at the right level of abstraction, between over-detailed wireframes and vague one-line requests. Good shaped work is rough, solved, and bounded, and it is done on a separate private track before any team commits to build it.
• Set Boundaries Before designing anything, decide how much time an idea deserves and pin down the specific problem behind it. A fixed time budget plus a narrow problem definition turns a vague raw idea into something you can shape a solution for.
• Find the Elements After setting an appetite and defining the problem, shapers turn a vague idea into a few concrete solution elements by sketching fast at a deliberately rough level of detail. Breadboards and fat marker sketches keep the work concrete enough to decide things while leaving room for designers later.
• Risks and Rabbit Holes Before betting on shaped work, find and remove the holes that could blow a fixed six-week window, so the project's risk looks thin-tailed. Patch rabbit holes, declare cases out of bounds, cut extras, and check assumptions with technical experts.
• Write the Pitch A shaped idea is not ready until it is written up as a pitch that pairs a specific problem with an appetite, a concrete-enough solution, called-out rabbit holes and explicit no-gos, so the people who schedule work can make an informed bet.
• Bets, Not Backlogs Teams do not need a central backlog. Before each six-week cycle, they bet on a few fresh, shaped pitches, let the rest go, and trust that important ideas will come back through people who track and advocate for them on their own.
• The Betting Table Work is scheduled as bets, not plans. A small senior group meets during a two-week cool-down and commits fixed six-week cycles of uninterrupted time to shaped pitches, with a hard cap on what any project can cost.
• Place Your Bets Bets should fit where a product sits in its development arc. Existing products get standard shaped bets that ship, while new products move through R&D, production and cleanup modes, each with different shaping, team makeup and shipping expectations, and every bet is still placed one cycle at a time.
• Hand Over Responsibility Give the team the whole shaped project, not a list of tasks, and let them define the work themselves within the pitch's boundaries. Done means deployed within the cycle, and the early quiet period of orientation is real work that managers should protect.
• Get One Piece Done Early in a cycle, a team should build one small, core, novel slice of the project all the way through, design and code together, so they have something real to click within the first week or so. Integrating vertically beats finishing horizontal layers that only come together at the end.
• Map The Scopes Break a project into scopes: integrated slices that can each be finished on their own in a few days or less. Find them by doing real work, not by planning up front. They become the language the team uses to track and discuss progress.
• Show Progress To-do counts and estimates cannot show real status because lists grow as work is discovered and estimates hide uncertainty. Plotting each scope on a hill, uphill for figuring out and downhill for execution, lets teams show what is unknown versus solved and lets managers see progress and stuck work without asking.
• Decide When to Stop Near the end of a fixed cycle there is always more work than time, so teams must decide what is good enough by comparing to what customers have today, not to an ideal, and must constantly hammer scope down to fit the time box. Extending a project is rare and only allowed when the remaining work is true must-haves that are all downhill.
• Move On Shipping a feature triggers a wave of requests, bugs and complaints. Teams should wait out the reaction, avoid committing to changes on the spot, and treat the feedback as raw ideas that must be shaped and bet on like anything else.
• Conclusion The Shape Up method is tightly interwoven, so teams may need to experiment to pull out and adapt the right pieces. Even without full adoption, its core language and concepts can be put to use right away.
• How to Implement Shape Up in Basecamp Shape Up can run inside one tool. A small Basecamp Team holds shaping and betting, a Basecamp Project holds each cycle project, To-Do Lists hold scopes, and the Hill Chart tracks each scope from unknown to done.
• Adjust to Your Size The core truths of Shape Up hold at any size: shape work before committing, bet deliberately with a capped downside, and separate knowns from unknowns while building. The specific practices, like six-week cycles, cool-downs and a betting table, should scale with the size of the team.
• How to Begin to Shape Up Teams can adopt Shape Up gradually rather than all at once. Start with one experiment, with shaping, or with longer cycles, get good at shipping first, and judge success by the outcome at the end of the cycle.
• Glossary Shape Up runs on a shared vocabulary. Work is shaped before anyone commits to it, teams bet fixed six-week cycles on it, and scope is cut to fit the time rather than time stretched to fit the scope.