Ryan Singer
Author of Shape Up
Where to hear and read about Ryan Singer1 book · 1 episode or test
BookShape Up
Lenny's PodcastA better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up")Ryan Singer is the author of Shape Up and was one of the first few hires at 37signals (Basecamp), where he spent years shaping product and sat on the betting table. The thing most worth learning from him is to fix the time budget first, then shape a solution that fits it with engineering, product and design in the same room before anyone builds.
Estimates start with a design and end with a number. Appetites start with a number and end with a design.
Shape Up: Stop Running in Circles and Ship Work that Matters
Ryan Singer: the story and the lessons
1Ryan Singer's path from early 37signals hire to Shape Up author
Singer was one of the first few hires at 37signals. He wrote Shape Up, published in 2019, after 17 years of building product there.
He also describes about 15 years at Basecamp, and says he knew only its inside story when he wrote the book.
Basecamp's habits came from a three-person team with scarce programming time. The first Basecamp was built in 2003 by three people. David Heinemeier Hansson coded only 10 hours a week from July 2003 to the February 2004 launch, so none of his time could go to work that got thrown away.
Fitting scope to a time budget became a reflex. Jason Fried wanted forward movement and a product in someone's hands.
Shaping began as short sketching sessions between two people. For years Singer shaped with Jason Fried, covering both the technical and the UX side himself. A few strokes of a Sharpie on a big pad would show the idea worth building.
The goal was an idea sharp enough to get a confident yes from David, with no reversing later. It was never a solo document, a requirements list or a polished Figma file.
He prototyped breadboarding and scope mapping on real Basecamp projects. In 2009 Basecamp merged four separate SaaS products into one suite with single sign-on and unified billing. 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.
Slow hiring let the way of working spread without a formal process. With no investment money there was never a moment of sudden growth. Each new person joined one at a time and the team adapted.
Singer calls this a fortunate side effect of not taking investment. Only when it stopped working did he take over the job of systematizing it.
2Why Singer says growing teams lose the ability to ship
Growth quietly breaks a team's ability to finish work. Basecamp grew from four people to over fifty. By 2015 the product team had quadrupled and everyone worked remotely, and the core team struggled to pass its instincts to new hires.
Projects dragged with no clear end, product managers lost time for strategy, and founders wondered why features stopped shipping as they had early on.
The formal process started when a project hit week six with no answers. About ten years in, a Basecamp project reached week six or seven with many open questions and no quick answers. That was the moment the team formalized how it worked.
The fix was structure and vocabulary: repeating cycles settled at six weeks, formal pitching and betting, and a name for up-front design, shaping.
The pain peaks at 30 to 50 people in product and engineering. Trouble starts at the first handoff, when a founder gives a project to a PM. By 30 to 50 people, engineering and product sit apart, executives point fingers, and engineering time drifts into refactoring.
Singer says this group is the biggest market but hard to reach, because the topic is sensitive and he mostly hears about it late.
He says most teams ship too few features, not too many. Most teams cannot ship predictably at all. The signs are work that drags with no visible end, burnout, and work that stops being exciting.
A real feature factory would be healthy, and only its input would need fixing.
Singer fixes the risk of not shipping before the risk of building wrong. Shape Up targets shipping on time. For building the wrong thing he points to Competing Against Luck, and to Bob Moesta's Demand-Side Sales 101 as the most tactical entry point.
His reason: "You can have the best strategy in the world, but if you can't act on it, what good does it do?"
A project that ships can still be a failure. Jason Fried's foreword says doing the work the wrong way wrecks morale and erodes trust. 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.
3How Singer sets an appetite and narrows the problem
Singer fixes the time budget first and lets scope bend. An appetite starts with a number and ends with a design. Basecamp gave a calendar one six-week cycle, because only about 10% of customers had used calendars in past versions.
An appetite is not a forecast of how long work takes. It is a constraint the design must fit.
Six weeks is a ceiling, set by how far a team can see. Six weeks is the furthest ahead Basecamp could see well enough to land something. Smaller work gets one or two weeks, as a Small Batch.
Basecamp tried two-week cycles and found planning overhead and broken momentum cost more than the work produced.
He asks customers when they needed it, not why. A request for complex permission rules, easily six weeks, was really someone archiving a file without knowing it would vanish for everyone. A warning on the archive action took one day.
A calendar request shrank to one need, seeing free spaces, from a customer who drove through traffic to check a chalkboard booking calendar.
He meets raw ideas with a calm soft no. The default reply is "Interesting. Maybe some day." Saying yes too early builds an endless pile and sets expectations you may fail to meet.
Flat rejection risks losing something that later information shows is valuable.
He splits grab-bag redesigns into problem-specific projects. Basecamp's vague Files 2.0 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.
Singer calls fixed time with varying scope on unshaped work cruel. Handing a team a big concept and six weeks, then cutting scope at the deadline, kills morale. Shape first so scope can flex around a defined core.
He quotes Bob Moesta: "You can't put 10 pounds of crap in a five pound bag."
4How Ryan Singer runs a shaping session
Singer puts a senior engineer, product person and designer in one room. The engineer must be senior in knowledge, the one who knows where the bodies are buried. The product person brings why this is an opportunity. They whiteboard together and try to break each idea.
Showing work to engineering later lets problems blow up and sends it back to the drawing board.
He has the engineer open the code during shaping. A fintech team planned to drop an onboarding step by piping in bank partner data. Opening the code showed three bank-specific branches, so the team could weigh which were worth doing instead of finding them in week four.
Singer likens the engineer to a grumpy old plumber who opens the walls before giving a quote.
He tries to break several ideas rather than polish one. The calendar had Idea A, a scrolling agenda view, and Idea B, a plain month view. Two or three sessions of about three hours usually settle work the current stack can do.
Between sessions people sketch and run a spike or two. Staying on one idea for three hours means circling small details.
He sketches with breadboards and fat markers, not Figma. A breadboard is words only: places, affordances and connection lines. A fat marker sketch uses strokes so broad that detail is hard to add. Figma comes once the layout is settled.
Breadboarding Autopay showed that a Turn on Autopay button on the invoice raised whether the current invoice was also paid. The team moved Autopay into the payment step.
A well-shaped idea fits in under ten moving pieces. The calendar became a two-month dot grid, a scrolling agenda view underneath, month navigation and a create button.
His test: "It's shaped if we can give this to a technical person and they say, 'Yeah, I know what to go build now.'"
He asks experts whether it fits six weeks, not whether it is possible. Experts review at a whiteboard, never slides, and the idea is framed as just an idea. Explaining why it fits the appetite makes them partners in keeping it small.
"In software, everything is possible but nothing is free."
Shaped work is rough, solved and bounded. Rough leaves room for designers, solved connects the main elements, and bounded gives an appetite plus explicit exclusions. The Dot Grid calendar ruled out dragging, multi-day spanning and color coding.
Detailed mockups bias whoever works on them next, especially when a senior person drew them.
He dials the level of detail to the build team. The usual failure is too little detail, with engineers saying they are not getting enough. Junior engineers get more guidance, dialed back over later projects.
A senior who wants a say in the approach should join shaping as the technical voice.
5How Basecamp's pitches, betting table and cycles work
Every pitch has five parts: problem, appetite, solution, rabbit holes, no-gos. The problem is told as one specific story of the status quo failing. The Payment Form pitch said URLs would never live on custom domains for v1 and ruled out WYSIWYG editing.
Without a specific problem, "there's no test of fitness to judge whether one solution is better than the other."
Basecamp drops the central backlog and bets on recent pitches. Rejected pitches are let go, and anyone who cares tracks them on their own list. Support keeps its own list of recurring issues and shares the top ones with Product in infrequent one-on-ones.
Recurrence is the signal. A problem heard once and never again may not have been real.
The betting table is small, senior and final. It is the CEO, the CTO, a senior programmer and Singer. They read pitches ahead, rarely meet past an hour or two, and their plan needs no further approval.
Cycles run six weeks followed by a two-week cool-down, and betting happens in cool-down, not while everyone rushes to ship.
A bet caps the downside at six weeks. Unfinished work gets no extension by default. Leftovers return only if reshaped and bet on again. This circuit breaker stops runaway projects.
"If we bet six weeks on something, the most we can lose is six weeks." A softer version for most teams is to pull a stuck project back into shaping.
Only real crises interrupt a cycle. Data loss, the app grinding to a halt, or many customers seeing the wrong thing. Most bugs wait for cool-down, and big ones are pitched.
Once a year, around the holidays, Basecamp gives a full cycle to a bug smash.
Even multi-year work is bet one cycle at a time. HEY launched in July 2020 after a year of R&D by Jason, David and Jonas, nearly a year of production, and two cleanup cycles that cut the feature set.
Hill Charts got one internal-only cycle first, then a second shaped cycle to round it out and ship it.
After launch he waits a few days and gives a gentle no. Releases draw a burst of requests and complaints, strongest when workflows change. The intensity fades within days.
"Saying yes, on the other hand, takes away your freedom in the future. It's like taking on debt."
6How Singer's teams build and track progress
He hands teams whole projects, not task lists. Discovered tasks outnumber imagined ones, and only the people building can see how the pieces fit. Done means deployed before the cycle ends, QA included.
"Splitting the project into tasks up front is like putting the pitch through a paper shredder."
He protects the quiet first days of a cycle. Teams spend a few days learning the system with no deploys or checked-off tasks. Asking for status early pushes that exploration underground.
If silence has not begun to break after about three days, step in and see what is going on.
Teams build one core, small, novel slice end to end first. On Clients in Projects, one designer and one programmer built the visibility toggle first. About three days in it was demoed to a manager, tweaked and called done.
Anything that teaches nothing is stubbed. An interview app used HTTPAuth with a hard-coded password and real data very early.
Scopes are found by doing real work, around the end of week one. A message-drafts team pulled out Start New and finished it, then split the rest into Locate, Trash and Save/Edit, and later Save/Edit into Send, Store and Reply.
Generic names like front-end or bugs signal a bad scope. A loose-task list past three to five items means a scope is missing.
Builders also draw nine boxes at kickoff. Nine boxes of major implementation chunks exposes too much scope and lets seniors coach juniors. Six weeks is 30 business days, so that is about four days each.
More than ten and the team is back in ticket land.
He tracks scopes on hill charts, not task counts. A scope climbs uphill while the approach is unclear and runs downhill once the work is visible. A Notify scope sat still because it mixed three parts at different stages, and splitting it showed each part's real position.
"A dot that doesn't move is effectively a raised hand." Managers read snapshots instead of asking for status.
The riskiest scopes go uphill first. 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.
The aim is to finish with only polish left to cut.
He judges readiness against what customers have today. Cut scope with questions like "Could we ship without this?" and "Is this a new problem or one customers already live with?" Cutting scope never lowers the bar on code or design.
Extensions are rare and only for must-haves that are all downhill. Basecamp had no QA for years and now, with millions of users and about a dozen product people, has one QA person near the end of cycles.
7Singer's advice on adopting Shape Up
He starts teams with a pilot of three to six weeks. Pick a problem that matters, is timely, and is big enough to feel like a win. The book's version protects one designer and two programmers from all interruptions on one project that fits comfortably in six weeks.
It works best when the heads of product and engineering agree there is a problem and choose the people and project together.
He warns against adopting six-week cycles without shaping. Dev teams like dropping Scrum rituals but skip the hard thinking. They scramble to shape as they build, hold more meetings, and still run out of time.
Without engineering and product shaping together, "that time box isn't going to go well."
He tells teams to adopt pieces only for a pain they have. His advice is to wait until it hurts more. Pain shows up upstream, where a sales lead, a CEO's shower idea or research produces a vague ask.
A signal is a new head of product or CTO and the same problems. If unfamiliarity is the main objection, things may be fine.
He says to rebuild what Basecamp got for free. Basecamp's designers all coded, founders stayed in problem definition until 2021, and no sales org pressed engineering for time. Engineering also got a clear six-week runway each cycle.
Where a wall exists, someone must learn whom to bring together and how to run the session. At Basecamp that knowledge often sat in one head.
He moves the PM upstream to narrow the problem. PMs add the most value before the time box starts, digging into business context and negotiating with whoever brought the idea, such as the CPO, to find its core.
His contrast: narrowing the problem, "rather than shepherding the process or being a ritual master."
He scales the practices to team size and keeps the core truths. Teams of two or three can skip cycles, cool-downs and the betting table but should still set an appetite and shape. Basecamp, about 50 people with roughly a dozen on product, uses SIP and Ops teams to absorb interruptions.
Six weeks may not be the right length for every team. If someone else controls programmer time, send one better-bounded project through the existing schedule.
8Where Shape Up has failed and what Singer learned
Basecamp bet a redesign on faith and lost six weeks. It 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.
His rule since: never assume a designer will solve what shaping could not, and walk a use case in slow motion before betting.
Teams that copied Basecamp without an engineer kept overrunning. Adopters who handed over PRDs or Figma files with no engineer in shaping saw projects run over.
A Figma file or PRD meets engineering and gets a reality check, often sending work back to the drawing board.
Singer assumed the method had failed when he first consulted. In his first consulting project the team picked the engineer best suited to join product in shaping, and things worked. His reaction: "Now I'm in the world I know again."
He realized he had been "in a foreign country" and that engineering has to be in the room.
He knew the book left gaps once it reached other companies. He wrote it knowing only Basecamp's inside story, and few teams are structured like Basecamp. His course Shaping in Real Life covers cases like designers who don't code and contested engineering time.
A second edition is likely to show how Basecamp works today, while his own work bridges the gap. His reader forum never took off, because people don't like to discuss shipping struggles.
A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up")
Ryan Singer explains Shape Up, a way of building product that fixes a time budget (the appetite) and shapes the solution to fit it, with engineering, product and design working out the idea together before any build starts. It is worth hearing for the concrete shaping techniques and the real-world reasons teams adopt it and fail at it.
Singer was one of the first few hires at 37signals. He wrote Shape Up, published in 2019, after 17 years of building product there.
He also describes about 15 years at Basecamp, and says he knew only its inside story when he wrote the book.
Basecamp's habits came from a three-person team with scarce programming time. The first Basecamp was built in 2003 by three people. David Heinemeier Hansson coded only 10 hours a week from July 2003 to the February 2004 launch, so none of his time could go to work that got thrown away.
Fitting scope to a time budget became a reflex. Jason Fried wanted forward movement and a product in someone's hands.
Shaping began as short sketching sessions between two people. For years Singer shaped with Jason Fried, covering both the technical and the UX side himself. A few strokes of a Sharpie on a big pad would show the idea worth building.
The goal was an idea sharp enough to get a confident yes from David, with no reversing later. It was never a solo document, a requirements list or a polished Figma file.
Slow hiring let the way of working spread without a formal process. With no investment money there was never a moment of sudden growth. Each new person joined one at a time and the team adapted.
Singer calls this a fortunate side effect of not taking investment. Only when it stopped working did he take over the job of systematizing it.
The formal process started when a project hit week six with no answers. About ten years in, a Basecamp project reached week six or seven with many open questions and no quick answers. That was the moment the team formalized how it worked.
The fix was structure and vocabulary: repeating cycles settled at six weeks, formal pitching and betting, and a name for up-front design, shaping.
The pain peaks at 30 to 50 people in product and engineering. Trouble starts at the first handoff, when a founder gives a project to a PM. By 30 to 50 people, engineering and product sit apart, executives point fingers, and engineering time drifts into refactoring.
Singer says this group is the biggest market but hard to reach, because the topic is sensitive and he mostly hears about it late.
He says most teams ship too few features, not too many. Most teams cannot ship predictably at all. The signs are work that drags with no visible end, burnout, and work that stops being exciting.
A real feature factory would be healthy, and only its input would need fixing.
Singer fixes the risk of not shipping before the risk of building wrong. Shape Up targets shipping on time. For building the wrong thing he points to Competing Against Luck, and to Bob Moesta's Demand-Side Sales 101 as the most tactical entry point.
His reason: "You can have the best strategy in the world, but if you can't act on it, what good does it do?"
Singer fixes the time budget first and lets scope bend. An appetite starts with a number and ends with a design. Basecamp gave a calendar one six-week cycle, because only about 10% of customers had used calendars in past versions.
An appetite is not a forecast of how long work takes. It is a constraint the design must fit.
Six weeks is a ceiling, set by how far a team can see. Six weeks is the furthest ahead Basecamp could see well enough to land something. Smaller work gets one or two weeks, as a Small Batch.
Basecamp tried two-week cycles and found planning overhead and broken momentum cost more than the work produced.
He asks customers when they needed it, not why. A request for complex permission rules, easily six weeks, was really someone archiving a file without knowing it would vanish for everyone. A warning on the archive action took one day.
A calendar request shrank to one need, seeing free spaces, from a customer who drove through traffic to check a chalkboard booking calendar.
Singer calls fixed time with varying scope on unshaped work cruel. Handing a team a big concept and six weeks, then cutting scope at the deadline, kills morale. Shape first so scope can flex around a defined core.
He quotes Bob Moesta: "You can't put 10 pounds of crap in a five pound bag."
Singer puts a senior engineer, product person and designer in one room. The engineer must be senior in knowledge, the one who knows where the bodies are buried. The product person brings why this is an opportunity. They whiteboard together and try to break each idea.
Showing work to engineering later lets problems blow up and sends it back to the drawing board.
He has the engineer open the code during shaping. A fintech team planned to drop an onboarding step by piping in bank partner data. Opening the code showed three bank-specific branches, so the team could weigh which were worth doing instead of finding them in week four.
Singer likens the engineer to a grumpy old plumber who opens the walls before giving a quote.
He tries to break several ideas rather than polish one. The calendar had Idea A, a scrolling agenda view, and Idea B, a plain month view. Two or three sessions of about three hours usually settle work the current stack can do.
Between sessions people sketch and run a spike or two. Staying on one idea for three hours means circling small details.
He sketches with breadboards and fat markers, not Figma. A breadboard is words only: places, affordances and connection lines. A fat marker sketch uses strokes so broad that detail is hard to add. Figma comes once the layout is settled.
Breadboarding Autopay showed that a Turn on Autopay button on the invoice raised whether the current invoice was also paid. The team moved Autopay into the payment step.
A well-shaped idea fits in under ten moving pieces. The calendar became a two-month dot grid, a scrolling agenda view underneath, month navigation and a create button.
His test: "It's shaped if we can give this to a technical person and they say, 'Yeah, I know what to go build now.'"
He dials the level of detail to the build team. The usual failure is too little detail, with engineers saying they are not getting enough. Junior engineers get more guidance, dialed back over later projects.
A senior who wants a say in the approach should join shaping as the technical voice.
A bet caps the downside at six weeks. Unfinished work gets no extension by default. Leftovers return only if reshaped and bet on again. This circuit breaker stops runaway projects.
"If we bet six weeks on something, the most we can lose is six weeks." A softer version for most teams is to pull a stuck project back into shaping.
He hands teams whole projects, not task lists. Discovered tasks outnumber imagined ones, and only the people building can see how the pieces fit. Done means deployed before the cycle ends, QA included.
"Splitting the project into tasks up front is like putting the pitch through a paper shredder."
Builders also draw nine boxes at kickoff. Nine boxes of major implementation chunks exposes too much scope and lets seniors coach juniors. Six weeks is 30 business days, so that is about four days each.
More than ten and the team is back in ticket land.
He starts teams with a pilot of three to six weeks. Pick a problem that matters, is timely, and is big enough to feel like a win. The book's version protects one designer and two programmers from all interruptions on one project that fits comfortably in six weeks.
It works best when the heads of product and engineering agree there is a problem and choose the people and project together.
He warns against adopting six-week cycles without shaping. Dev teams like dropping Scrum rituals but skip the hard thinking. They scramble to shape as they build, hold more meetings, and still run out of time.
Without engineering and product shaping together, "that time box isn't going to go well."
He tells teams to adopt pieces only for a pain they have. His advice is to wait until it hurts more. Pain shows up upstream, where a sales lead, a CEO's shower idea or research produces a vague ask.
A signal is a new head of product or CTO and the same problems. If unfamiliarity is the main objection, things may be fine.
He says to rebuild what Basecamp got for free. Basecamp's designers all coded, founders stayed in problem definition until 2021, and no sales org pressed engineering for time. Engineering also got a clear six-week runway each cycle.
Where a wall exists, someone must learn whom to bring together and how to run the session. At Basecamp that knowledge often sat in one head.
He moves the PM upstream to narrow the problem. PMs add the most value before the time box starts, digging into business context and negotiating with whoever brought the idea, such as the CPO, to find its core.
His contrast: narrowing the problem, "rather than shepherding the process or being a ritual master."
Teams that copied Basecamp without an engineer kept overrunning. Adopters who handed over PRDs or Figma files with no engineer in shaping saw projects run over.
A Figma file or PRD meets engineering and gets a reality check, often sending work back to the drawing board.
Singer assumed the method had failed when he first consulted. In his first consulting project the team picked the engineer best suited to join product in shaping, and things worked. His reaction: "Now I'm in the world I know again."
He realized he had been "in a foreign country" and that engineering has to be in the room.
He knew the book left gaps once it reached other companies. He wrote it knowing only Basecamp's inside story, and few teams are structured like Basecamp. His course Shaping in Real Life covers cases like designers who don't code and contested engineering time.
A second edition is likely to show how Basecamp works today, while his own work bridges the gap. His reader forum never took off, because people don't like to discuss shipping struggles.
Shape Up: Stop Running in Circles and Ship Work that Matters
Shape Up is Basecamp's method for shipping software: shape work up front at the right level of abstraction, bet fixed six-week cycles on it with no default extension, and let small teams own the project while cutting scope to fit the time. It is worth reading for its concrete tools, including appetites, breadboards, fat marker sketches, scopes and hill charts, which help growing teams that have lost the ability to ship.
Basecamp's habits came from a three-person team with scarce programming time. The first Basecamp was built in 2003 by three people. David Heinemeier Hansson coded only 10 hours a week from July 2003 to the February 2004 launch, so none of his time could go to work that got thrown away.
Fitting scope to a time budget became a reflex. Jason Fried wanted forward movement and a product in someone's hands.
He prototyped breadboarding and scope mapping on real Basecamp projects. In 2009 Basecamp merged four separate SaaS products into one suite with single sign-on and unified billing. 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.
Growth quietly breaks a team's ability to finish work. Basecamp grew from four people to over fifty. By 2015 the product team had quadrupled and everyone worked remotely, and the core team struggled to pass its instincts to new hires.
Projects dragged with no clear end, product managers lost time for strategy, and founders wondered why features stopped shipping as they had early on.
The formal process started when a project hit week six with no answers. About ten years in, a Basecamp project reached week six or seven with many open questions and no quick answers. That was the moment the team formalized how it worked.
The fix was structure and vocabulary: repeating cycles settled at six weeks, formal pitching and betting, and a name for up-front design, shaping.
Singer fixes the risk of not shipping before the risk of building wrong. Shape Up targets shipping on time. For building the wrong thing he points to Competing Against Luck, and to Bob Moesta's Demand-Side Sales 101 as the most tactical entry point.
His reason: "You can have the best strategy in the world, but if you can't act on it, what good does it do?"
A project that ships can still be a failure. Jason Fried's foreword says doing the work the wrong way wrecks morale and erodes trust. 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.
Singer fixes the time budget first and lets scope bend. An appetite starts with a number and ends with a design. Basecamp gave a calendar one six-week cycle, because only about 10% of customers had used calendars in past versions.
An appetite is not a forecast of how long work takes. It is a constraint the design must fit.
Six weeks is a ceiling, set by how far a team can see. Six weeks is the furthest ahead Basecamp could see well enough to land something. Smaller work gets one or two weeks, as a Small Batch.
Basecamp tried two-week cycles and found planning overhead and broken momentum cost more than the work produced.
He asks customers when they needed it, not why. A request for complex permission rules, easily six weeks, was really someone archiving a file without knowing it would vanish for everyone. A warning on the archive action took one day.
A calendar request shrank to one need, seeing free spaces, from a customer who drove through traffic to check a chalkboard booking calendar.
He meets raw ideas with a calm soft no. The default reply is "Interesting. Maybe some day." Saying yes too early builds an endless pile and sets expectations you may fail to meet.
Flat rejection risks losing something that later information shows is valuable.
He splits grab-bag redesigns into problem-specific projects. Basecamp's vague Files 2.0 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.
He sketches with breadboards and fat markers, not Figma. A breadboard is words only: places, affordances and connection lines. A fat marker sketch uses strokes so broad that detail is hard to add. Figma comes once the layout is settled.
Breadboarding Autopay showed that a Turn on Autopay button on the invoice raised whether the current invoice was also paid. The team moved Autopay into the payment step.
He asks experts whether it fits six weeks, not whether it is possible. Experts review at a whiteboard, never slides, and the idea is framed as just an idea. Explaining why it fits the appetite makes them partners in keeping it small.
"In software, everything is possible but nothing is free."
Shaped work is rough, solved and bounded. Rough leaves room for designers, solved connects the main elements, and bounded gives an appetite plus explicit exclusions. The Dot Grid calendar ruled out dragging, multi-day spanning and color coding.
Detailed mockups bias whoever works on them next, especially when a senior person drew them.
Every pitch has five parts: problem, appetite, solution, rabbit holes, no-gos. The problem is told as one specific story of the status quo failing. The Payment Form pitch said URLs would never live on custom domains for v1 and ruled out WYSIWYG editing.
Without a specific problem, "there's no test of fitness to judge whether one solution is better than the other."
Basecamp drops the central backlog and bets on recent pitches. Rejected pitches are let go, and anyone who cares tracks them on their own list. Support keeps its own list of recurring issues and shares the top ones with Product in infrequent one-on-ones.
Recurrence is the signal. A problem heard once and never again may not have been real.
The betting table is small, senior and final. It is the CEO, the CTO, a senior programmer and Singer. They read pitches ahead, rarely meet past an hour or two, and their plan needs no further approval.
Cycles run six weeks followed by a two-week cool-down, and betting happens in cool-down, not while everyone rushes to ship.
A bet caps the downside at six weeks. Unfinished work gets no extension by default. Leftovers return only if reshaped and bet on again. This circuit breaker stops runaway projects.
"If we bet six weeks on something, the most we can lose is six weeks." A softer version for most teams is to pull a stuck project back into shaping.
Only real crises interrupt a cycle. Data loss, the app grinding to a halt, or many customers seeing the wrong thing. Most bugs wait for cool-down, and big ones are pitched.
Once a year, around the holidays, Basecamp gives a full cycle to a bug smash.
Even multi-year work is bet one cycle at a time. HEY launched in July 2020 after a year of R&D by Jason, David and Jonas, nearly a year of production, and two cleanup cycles that cut the feature set.
Hill Charts got one internal-only cycle first, then a second shaped cycle to round it out and ship it.
After launch he waits a few days and gives a gentle no. Releases draw a burst of requests and complaints, strongest when workflows change. The intensity fades within days.
"Saying yes, on the other hand, takes away your freedom in the future. It's like taking on debt."
He hands teams whole projects, not task lists. Discovered tasks outnumber imagined ones, and only the people building can see how the pieces fit. Done means deployed before the cycle ends, QA included.
"Splitting the project into tasks up front is like putting the pitch through a paper shredder."
He protects the quiet first days of a cycle. Teams spend a few days learning the system with no deploys or checked-off tasks. Asking for status early pushes that exploration underground.
If silence has not begun to break after about three days, step in and see what is going on.
Teams build one core, small, novel slice end to end first. On Clients in Projects, one designer and one programmer built the visibility toggle first. About three days in it was demoed to a manager, tweaked and called done.
Anything that teaches nothing is stubbed. An interview app used HTTPAuth with a hard-coded password and real data very early.
Scopes are found by doing real work, around the end of week one. A message-drafts team pulled out Start New and finished it, then split the rest into Locate, Trash and Save/Edit, and later Save/Edit into Send, Store and Reply.
Generic names like front-end or bugs signal a bad scope. A loose-task list past three to five items means a scope is missing.
He tracks scopes on hill charts, not task counts. A scope climbs uphill while the approach is unclear and runs downhill once the work is visible. A Notify scope sat still because it mixed three parts at different stages, and splitting it showed each part's real position.
"A dot that doesn't move is effectively a raised hand." Managers read snapshots instead of asking for status.
The riskiest scopes go uphill first. 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.
The aim is to finish with only polish left to cut.
He judges readiness against what customers have today. Cut scope with questions like "Could we ship without this?" and "Is this a new problem or one customers already live with?" Cutting scope never lowers the bar on code or design.
Extensions are rare and only for must-haves that are all downhill. Basecamp had no QA for years and now, with millions of users and about a dozen product people, has one QA person near the end of cycles.
He starts teams with a pilot of three to six weeks. Pick a problem that matters, is timely, and is big enough to feel like a win. The book's version protects one designer and two programmers from all interruptions on one project that fits comfortably in six weeks.
It works best when the heads of product and engineering agree there is a problem and choose the people and project together.
He scales the practices to team size and keeps the core truths. Teams of two or three can skip cycles, cool-downs and the betting table but should still set an appetite and shape. Basecamp, about 50 people with roughly a dozen on product, uses SIP and Ops teams to absorb interruptions.
Six weeks may not be the right length for every team. If someone else controls programmer time, send one better-bounded project through the existing schedule.
Basecamp bet a redesign on faith and lost six weeks. It 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.
His rule since: never assume a designer will solve what shaping could not, and walk a use case in slow motion before betting.
37signals
