Table of Contents
How 37signals developed a radical approach to product development that solves the chronic problems of endless sprints, missed deadlines, and projects that never seem to finish.
Most product teams are trapped in cycles they can't escape: endless sprints that stretch into months, beautiful designs that engineers can't build, requirements that expand faster than progress, and the constant anxiety of never knowing when projects will actually finish. After 17 years of building products at 37 signals, Ryan Singer formalized a completely different approach that consistently ships meaningful work.
Key Takeaways
- Work backwards from appetite (time you're willing to spend) instead of forwards from estimates to eliminate scope creep and endless extensions
- Six weeks is the maximum timeframe where teams can realistically see the end from the beginning and shape solutions accordingly
- Shaping sessions bring engineers, designers, and product people together to solve problems before committing resources, not after projects start
- Most teams fail from too little detail in planning, not too much—shaped projects need enough clarity that builders know what to implement
- The "circuit breaker" principle: if projects can't finish in their timeframe, return to shaping mode rather than extending deadlines indefinitely
- Engineering should be involved in solution design from day one to surface technical constraints and opportunities before they become time bombs
- Successful teams replace the "paper shredder" of breaking projects into tickets with whole ideas that teams can understand and own
- Companies typically need Shape Up when they reach 30-50 people and founders can no longer be involved in every product decision
- Product managers shift upstream to focus on problem definition and business context rather than project coordination and ritual management
Timeline Overview
- 00:00–09:56 — Origins and Context: How Shape Up emerged from 37signals' constraint of having only 10 hours per week of engineering time, the urgency culture that demanded constant forward movement, and why traditional processes break down as companies scale
- 09:56–26:29 — Core Shape Up Elements: Working backwards from appetite rather than estimates, the six-week maximum timeframe principle, and why shaping is fundamentally different from writing PRDs or creating detailed mockups
- 26:29–46:57 — Shaping Sessions Deep Dive: The collaborative process of bringing engineers, designers, and product people together to solve problems, typical session duration and participants, and what good shaping outputs actually look like
- 46:57–01:02:48 — Balancing Detail and Ownership: Why teams need more detail than they think, how to calibrate based on team seniority, and the difference between prescriptive specifications and clear direction that enables creativity
- 01:02:48–01:18:25 — Implementation Strategies: How to start with pilot projects, warning signs that indicate your current process is failing, and adapting Shape Up principles to different company contexts and constraints
- 01:18:25–01:28:26 — Role Evolution: How product managers shift from project coordination to problem definition, why feature factories aren't actually efficient, and the upstream focus that creates more strategic impact
- 01:28:26–01:41:53 — Basecamp's Unique Context: What made 37signals different (every designer codes, no sales pressure, founder involvement), how to adapt principles when you don't have these advantages, and realistic expectations for implementation
The Appetite-Driven Revolution: Why Working Backwards Changes Everything
The fundamental insight that powers Shape Up challenges how most product teams think about project planning. Instead of estimating how long something will take and then fighting scope creep when it expands, teams decide upfront how much time they're willing to invest and then shape solutions to fit that constraint.
"We are not going to start something unless we can see the end from the beginning. We're not going to take a big concept and then say what's the estimate for this thing. We're going to go the other way around and say what is the maximum amount of time we're willing to go before we actually finish something."
This reversal transforms the entire product development dynamic. Traditional approaches create endless negotiation cycles: engineers estimate, product managers argue for more features, deadlines slip, and teams lose confidence in their ability to ship predictably. Appetite-driven development eliminates this chaos by establishing the constraint first.
"It's kind of like if you're going to buy a car or you're going to rent a new flat... you have to have like a budget in mind, right? And the budget then is how you choose between all kinds of alternatives and make a lot of hard choices and tradeoffs."
The six-week maximum emerges from practical experience about how far teams can realistically see into the future. Beyond six weeks, too many unknowns accumulate—technical complexities, changing requirements, emerging priorities. Within six weeks, teams can identify the major risks and shape solutions that account for them.
But this isn't about cramming any project into six weeks. It's about recognizing that if you can't envision a meaningful solution within six weeks, the problem hasn't been shaped properly. This forces crucial conversations about what's actually important and what can be deferred or eliminated entirely.
Shaping: The Collaborative Art of Problem-Solving Before Building
Most product development processes separate planning from building, creating handoff friction between strategy and execution. Shape Up's shaping sessions eliminate this gap by bringing technical, design, and product perspectives together to solve problems collaboratively before any commitments are made.
"What we need to do in a shaping session when it's going well is we come out with some kind of drawing or diagram where engineers, product and design are all looking at that and they're saying 'we understand that. I know exactly what to go build.'"
These aren't typical requirements meetings or design reviews. Shaping sessions involve intensive problem-solving where participants wrestle with both the problem and potential solutions until they reach clarity about what's actually possible and valuable within the time constraint.
Consider the calendar example from the book. Rather than building "a calendar" (which could mean anything), the team shaped a specific solution: a two-month dot grid showing availability, with a scrolling agenda view underneath and navigation controls. This level of specificity means everyone understands exactly what success looks like.
"If it's shaped well, you can usually describe it in less than 10 moving pieces. If I can say it's going to have this, this, this, this, this and this, and that's how we're going to let people see the empty spaces, that's a good indicator that it's clear enough."
The sessions require the right mix of expertise in the room. You need someone who understands the business problem and user needs, someone who knows the technical constraints and opportunities, and someone who can think through the user experience implications. Without this mix, solutions either ignore technical reality or miss business value.
The Home Renovation Analogy: Why Technical Reality Must Shape Solutions
One of Ryan's most powerful analogies explains why technical expertise must be involved in solution design from the beginning, not discovered during implementation.
"If you're doing a home renovation, you can have the most beautiful rendering of the new bedroom and we're going to have these lamps on the side of the bed that are coming out from the wall. But if you haven't checked if there's electricity in that wall there or not, it's going to drastically change the cost and the time and everything."
This captures the essential problem with most product development: beautiful designs that ignore implementation reality, creating painful discovery moments deep into development cycles. Teams spend weeks building towards a vision, only to discover fundamental constraints that force complete redesigns.
Shaping sessions prevent this by bringing the "grumpy old plumber" perspective into early problem-solving. When engineers examine actual code during shaping rather than after building starts, they surface complexity early when it can inform smart tradeoffs rather than derail projects.
"If we're in the shaping room and we didn't kick this thing off yet, we didn't even greenlight the project yet, and we have an engineer there... they're saying 'yeah that all sounds great, let's take a quick look at the code and figure out what screen you're actually talking about.'"
This early technical involvement transforms potential disasters into strategic choices. Instead of discovering mid-project that a feature requires three different integration approaches, teams can decide upfront whether to tackle all three, focus on the largest user segment, or find a different approach entirely.
The Circuit Breaker Principle: What Happens When Projects Don't Finish
Shape Up's approach to project failures challenges the common responses of either extending deadlines indefinitely or cutting scope to meaningless fragments. The circuit breaker principle provides a third option that preserves both team morale and business value.
"If a project is not on track to actually finish after the six weeks, we're just going to cancel it and rethink... what we can do is say we're not going to keep reinvesting in something that we don't understand."
This isn't about abandoning valuable work arbitrarily. It's about recognizing when projects reveal themselves to be poorly shaped and need different approaches. Rather than pushing through with inadequate understanding, teams return to shaping mode with new information.
"Let's take this out of build mode and bring this back into shaping mode, which might mean different people, a different conversation, asking different questions... to sus out what is it that's fuzzy here, what is it that we couldn't see."
The circuit breaker creates accountability for shaping quality while avoiding the morale damage of shipping compromised solutions. Teams learn that project "failures" often indicate shaping problems rather than execution problems, improving their ability to shape better projects in the future.
This principle requires organizational courage that many teams lack. It's emotionally difficult to stop work that's already in progress, especially when stakeholders are expecting delivery. But continuing work on poorly shaped projects typically creates bigger problems: demoralized teams, disappointed users, and technical debt that complicates future development.
Why Most Teams Need More Detail, Not Less
A common reaction to Shape Up is concern about being too prescriptive and stifling creativity. Ryan's experience reveals the opposite problem: most teams suffer from too little detail in their planning, not too much.
"I got to tell you, the dominant failure case that I see in the real world is always, again and again, not enough detail. And it's also the most common failure mode where engineers run back to the product folks and say 'I'm not getting enough from you.'"
The key insight involves understanding what kind of detail helps versus hurts. Micromanaging implementation details ("use this specific database schema") destroys autonomy and expertise. But providing clear problem definition and solution direction ("here's what users need to accomplish and here's the approach we've validated") enables creative implementation.
"What's really interesting is it's not a universal thing. The amount of detail that the team is going to feel helps them is a dial that we can turn that depends on who's on the team."
Junior team members often need more guidance to be successful and learn from senior practitioners. Senior team members can work with higher-level direction but should participate in shaping sessions if they want influence over fundamental approach decisions. The goal is calibrating detail levels to maximize both clarity and creative ownership.
"If there's someone on the build team who really feels that they should be involved in the fundamental decisions about the approach, then a better solution would be to actually bring them into the shaping."
This creates a virtuous cycle where the most capable technical people help shape solutions, ensuring both technical feasibility and creative engagement from the team responsible for implementation.
The Reality Check: Basecamp's Unique Advantages
Understanding Shape Up requires honest acknowledgment of what made 37signals unique and how other organizations can adapt the principles without identical circumstances.
"Every designer codes... I don't just mean HTML, I mean like running the app locally, going into the place where that view is rendered to make that thing look the way that they want it to look... every designer. Where's the wall between design and engineering? Those moments don't even exist."
This level of technical integration eliminates most handoff friction and miscommunication that plague traditional product teams. When designers can implement their own ideas, the gap between vision and reality shrinks dramatically.
Similarly, 37signals operated without traditional sales or marketing pressure. There were no urgent customer requests forcing scope changes mid-project, no sales commitments requiring specific features by certain dates. This created the protected development environment that enabled consistent six-week cycles.
"Imagine you have no sales or you have no marketing... it means that there isn't contention for engineering time, there isn't all these different sources of requests that you have to wrestle with."
Most companies can't replicate these conditions exactly, but they can create approximations. Some teams carve out protected development time by negotiating with stakeholders upfront. Others involve sales and customer success in shaping sessions so they understand what's possible within time constraints.
The principle remains valuable even when the context differs: teams need enough protection from external chaos to focus on shaped problems for meaningful periods. How that protection gets created varies, but without it, Shape Up degrades into traditional project management.
Implementation Strategy: Starting Small and Building Confidence
Teams interested in Shape Up often want to transform everything immediately, but Ryan advocates for careful pilot projects that demonstrate value before broader adoption.
"What usually works best is okay, we're going to try a pilot project... choose a problem that's important enough to all of us that we think it's meaningful, it's going to be worth trying to do well... it's not so small that we're not going to actually learn this new muscle."
The pilot should be sized appropriately for learning—big enough to exercise shaping and building muscles, small enough to limit risk if things go wrong. Three to six weeks often provides the right balance for first attempts.
"Usually, what happens too is if we have an engineering team that's going to become free to do this work for those X number of weeks, that's the upper limit on how long we can spend shaping."
This constraint actually helps teams learn faster. When shaping must be completed before the engineering team becomes available, it forces focused problem-solving rather than endless perfectionism in planning phases.
Success breeds adoption organically. When one team consistently ships meaningful work using Shape Up principles while other teams struggle with traditional approaches, the contrast becomes obvious to leadership and adjacent teams. But this requires genuine commitment to doing pilots well rather than half-hearted experiments.
Signs Your Current Process Is Broken
Rather than advocating universal adoption, Ryan helps teams recognize when their current approaches aren't working and Shape Up principles might help.
"The place where it's most obvious is at the end of the line when we thought we were going to be done and this thing is just dragging and dragging and dragging... we're running in place, we keep going in circles on this, we don't see the end."
But problems often start much earlier in the process. Fuzzy problem definitions that never get negotiated down to specific, solvable challenges. Beautiful designs that engineers can't implement within reasonable timeframes. Requirements documents that nobody actually reads or understands.
"If we just say 'dashboard' and we don't negotiate what that means, if we just say 'calendar' and we don't negotiate what that actually is, then what do we experience? This kind of fuzzy thing where it's really hard to get to a conclusive answer about 'yeah, that's what we need to go do.'"
The accumulation of these problems creates organizational friction that's expensive and demoralizing. Teams spend more time in meetings talking about work than actually doing work. Projects that should take weeks stretch into months. Talented people become frustrated with constantly changing requirements and unclear expectations.
"When we get in that situation, if we're at the end of the six weeks and it's not looking good... we can't just cut off what we agreed to that made this thing valuable. We can't just cut the scope and say 'oh well, now we managed to ship inside of six weeks.' That's going to kill everybody's morale."
These problems typically emerge when companies reach 30-50 people and can no longer rely on founder involvement in every decision. The informal coordination that works for small teams breaks down, but traditional process solutions often create more problems than they solve.
The Product Manager Evolution: From Coordination to Strategy
Shape Up fundamentally changes what product managers do day-to-day, shifting them from project coordination and ritual management toward deeper strategic work.
"What we see in really Shape Up teams when they hit their stride is that the PM moves upstream. So the PM is less busy with 'how do I get this project to not be in a bad state when it's getting built' and they're way more in 'how do I understand the business context, how do I narrow down the problem.'"
Traditional agile processes often trap product managers in tactical coordination: running standups, updating tickets, mediating between design and engineering, and generally keeping projects moving forward. This work is necessary but not strategically valuable.
"Getting deeper understanding of the business and the problem and the customer domain and what problem is worth solving and what slice of that problem is the valuable slice to argue that we should spend a few weeks on—that's the place where the PMs can really contribute a lot."
This upstream focus becomes possible when shaping provides enough clarity that teams can operate autonomously during building phases. Instead of constant check-ins and course corrections, product managers can invest time in understanding customer needs, identifying valuable problems, and negotiating with stakeholders about priorities.
The shift requires different skills and mindset. Product managers must become comfortable with ambiguity and skilled at problem definition rather than solution specification. They need to work effectively with both technical and business stakeholders to shape problems that are simultaneously valuable and feasible.
Common Questions
Q: How do you handle dependencies between teams when using Shape Up cycles?
A: Good engineering leadership can often eliminate dependencies through architectural choices. When dependencies are unavoidable, senior engineers should participate in shaping to negotiate realistic solutions upfront.
Q: What if stakeholders demand specific features by specific dates?
A: Shape Up requires appetite conversations with stakeholders about what's possible in given timeframes. This often means negotiating scope or timelines upfront rather than discovering conflicts mid-project.
Q: Can Shape Up work with quarterly planning cycles?
A: Yes, many teams adapt by aligning their cycles to quarters or by demonstrating consistent delivery that gives them credibility to operate independently of rigid quarterly requirements.
Q: How do you prevent the circuit breaker from being used too frequently?
A: Frequent circuit breaker activation indicates poor shaping. The solution is improving shaping skills, not avoiding the circuit breaker when projects are genuinely poorly shaped.
Q: What's the minimum team size where Shape Up makes sense?
A: The inflection point typically comes when founders can no longer be involved in every product decision, often around 30-50 people total across product and engineering.
Conclusion: Escaping the Cycle of Endless Sprints
Ryan Singer's Shape Up methodology offers a proven alternative to the chronic problems plaguing most product teams: endless sprints that never culminate in meaningful shipping moments, beautiful designs that ignore technical reality, and the constant anxiety of never knowing when projects will actually finish.
The approach succeeds because it addresses root causes rather than symptoms. Instead of adding more meetings to fix communication problems, it brings the right people together to solve problems before committing resources. Instead of better estimation techniques to fix timeline problems, it works backwards from time constraints to shape realistic solutions.
Most importantly, Shape Up acknowledges that product development is fundamentally about creative problem-solving under constraints, not predictable manufacturing processes. The framework provides structure without destroying the creativity and ownership that motivated teams need to do their best work.
Implementation requires adapting principles to specific organizational contexts rather than copying Basecamp's exact processes. But the core insights remain valuable: shape problems before committing resources, work backwards from time constraints, bring technical reality into early problem-solving, and create environments where teams can focus on meaningful work without constant interruption.
For teams trapped in cycles of technical debt sprints, endless refinement meetings, and projects that never seem to finish, Shape Up offers a path toward sustainable product development that consistently ships work that matters.
Practical Implications
• Start with appetite, not estimates — decide how much time you're willing to invest, then shape solutions to fit that constraint rather than expanding timelines when scope grows
• Bring engineers into shaping sessions — surface technical constraints and opportunities during problem-solving, not after building starts and discovers insurmountable complexity
• Shape problems to 10 moving pieces or fewer — if you can't describe the solution clearly and concisely, it's not ready for building regardless of how much time you spend on figma files
• Use the circuit breaker on poorly shaped projects — return unclear projects to shaping mode rather than extending deadlines indefinitely or cutting scope to meaningless fragments
• Run pilot projects before org-wide adoption — demonstrate value with meaningful but bounded experiments rather than attempting wholesale process transformation
• Focus PMs upstream on problem definition — shift from project coordination toward business context, customer insight, and problem framing that enables autonomous team execution
• Protect teams from constant context switching — create environments where teams can focus on shaped problems for meaningful periods without interruption from competing priorities
• Calibrate detail levels to team experience — provide enough clarity for successful execution while preserving creative ownership over implementation approaches
• Negotiate problem scope before solution design — narrow broad concepts like "calendar" or "dashboard" to specific, solvable problems before investing in detailed solution work
