Chapter 6: The Shape Up Method

You lead a product team that is no longer moving at the speed it did as a startup. Your projects are dragging and your teams feel burned out. You follow the standard agile rituals of two-week sprints and daily standups. You spend hours writing detailed product requirements documents that your engineers do not actually read. Your designers produce high-fidelity Figma files that make first contact with engineering only to be rejected as technically impossible. You find yourself stuck in a loop of endless estimates and missed deadlines. Every time a project reaches the end of a sprint, you realize there is more work to do and you extend the timeline again. This fuzzy, never-ending state is the ever-expanding blob of unresolved complexity. You are trapped in a world of paper shredder ticket management where no one sees the whole picture. You feel the pressure to scale while maintaining the urgency of your early days. You must decide whether to continue managing tiny tickets or to adopt a method that Varys scope to protect time. The tension lies between the desire for perfect features and the business need for predictable shipping. You face a reality where estimates are always wrong and work expands to fill all available time. You must either master the art of shaping or watch your product velocity die.

CORE SKILL OR PRINCIPLE

The core principle of the Shape Up method is to stop asking how long a project will take and start asking how much that project is worth. This requires a fundamental shift from estimates to appetites. An estimate is a guess about the future that is usually wrong because humans are poor estimators. An appetite is a fixed budget of time that the business is willing to spend to solve a specific problem. You do not start a project until you can see the end from the beginning. This involves a creative process called shaping where you define the boundaries of a solution before you commit resources. You vary the scope of the project to fit within the fixed time box rather than extending the time to fit the scope. You work in six-week cycles because this is the longest period you can reliably see into the future without unresolved complexity exploding. This method empowers teams by giving them the whole problem to solve rather than a list of granular tasks. You preserve startup urgency by treating every cycle like a mini-startup mission that must land within its budget.

EVIDENCE FROM THE CONVERSATION

The Shape Up method was developed over seventeen years at 37signals while building Basecamp. It emerged as a way to maintain the startup way of working even as the company grew. Evidence from high-performing teams shows that the paper shredder approach to management kills morale. When you take a big idea and split it into one hundred tiny tickets, the team loses the context of the whole. This results in unexpected complexity surfacing in the final weeks of a project. Ryan Singer notes that the first step away from work by founders is often where project disconnects begin.

The six-week limit serves as a critical maximum for technical certainty. Projects longer than six weeks often contain hidden time bombs of technical debt or misunderstood requirements. By setting a ceiling, you force the team to ask what valuable slice of a problem they can actually land. Basecamp found that this timeframe allows for meaningful work without the burnout of shorter, back-to-back sprints.

Successful implementation requires senior engineering involvement during the shaping phase. Ryan Singer uses the analogy of a grumpy plumber who insists on looking at the pipes behind the wall before giving a quote. If engineers are only involved after designs are finished, you face a high risk of project blowout. Shaping sessions that include a product lead, a designer, and a senior engineer can resolve three months of work in a few hours.

The method also relies on a circuit breaker principle. If a project is not on track to finish within its six-week appetite, the default response is to let it die rather than giving it more time. This prevents the demoralizing state of long-running projects that never end. It forces the organisation to bring the project back to the shaping table to understand what was missed.

PRACTICAL BREAKDOWN

To implement Shape Up, you must first define your appetite for a problem. Ask yourself if this problem is worth six weeks of engineering time or only one week. If the business is only willing to spend two weeks, you must shape a version of the solution that is simple and effective for that timeframe. You cannot just cut a six-week project down to two weeks at the last minute. You must shape it for that budget from the start.

The shaping session is the most important ritual in this method. It is a collaborative wrestling match between product, design, and engineering. You must narrow down the problem to a specific frame. For example, do not just build a calendar. Instead, build a dot grid that helps users see empty spaces in their schedule. This boundary setting is the input for all shaping work.

Use breadboarding to map out the flows of your solution. Draw the places where users start and the buttons they will hit. Describe what the system does with that information and where it sends the user next. This is done at a low fidelity so that you can move fast and try different approaches without being precious about pixels.

Conduct fat marker sketches to visualize the user experience. Use a thick pen on a whiteboard to ensure you stay at the right level of detail. If you can draw it with a fat marker, you have identified the moving parts without over-specifying the interface. The goal of a fat marker sketch is to communicate the idea so clearly that a technical person says they know what to build.

You must perform a technical feasibility check during the session. Open the code and look at the existing infrastructure. If you find that a proposed step has three different branches based on legacy integrations, you must decide if you will build all three or only one. This horse-trading of scope allows you to stay within your appetite.

The output of shaping is a pitch that defines the problem and the shaped solution. It should be a single idea that the team can hold in their heads. When you kick off the project, give this whole picture to the team and let them define their own implementation tasks.

SKILL APPLICATION

Apply the six-week cycle to your core product development. This cycle should include two distinct phases: shaping and building. While one team is building a shaped project, the leaders are shaping the projects for the next cycle. This creates a steady metabolism for the organisation.

Use the nine-box implementation framework during project kickoffs. Ask the builders to draw a grid with nine boxes representing the major chunks of implementation work. If you have thirty business days in a cycle, each box represents roughly four days of work. This exercise helps the team notice if there is too much scope and allows for early coaching on implementation approach.

Monitor progress using hill charts rather than standard burndown charts. A hill chart visualizes work as a climb from the unknown to the known. The left side of the hill is for figuring out the solution. The right side is for pure execution. If a project is still on the left side of the hill in week five, you have a shaping problem.

Implement the circuit breaker when projects drag. If the six weeks are up and the project is not finished, do not automatically grant an extension. Instead, stop the work and evaluate why the project blew up. This forces you to get better at framing problems and sussing out technical unknowns.

Move the product manager upstream. The PM should spend less time chasing tickets and more time understanding the business context and narrowing down problems. Their job is to negotiate with leadership to find the most valuable slice of a problem that the team can land in a cycle.

Use shorter two-week appetites for growth experiments or small landing pages. Not every project needs six weeks. However, do not bundle unrelated small tasks into a six-week cycle just to fill the time. Treat each project as a distinct mission with its own shaped solution.

Foster a culture where designers and engineers are interested in the broader scope of their work. Hire for polymathism and an attitude of ownership. When builders understand the why and the what, they can make better trade-offs in the weeds of the code.

ACTION CHECKLIST

• Identify one project in your current backlog that has been dragging for more than two months.
• Stop writing a detailed requirements document for your next project and schedule a three-hour shaping session instead.
• Invite one senior engineer, one designer, and the product lead to this shaping session.
• Define a fixed appetite for this project: is it worth two weeks or six weeks of time?
• Narrow down the problem to a specific frame and set boundaries on what you will not build.
• Use breadboarding to map out the functional steps and logic of the solution on a whiteboard.
• Create a fat marker sketch of the primary user interface to visualize the moving parts.
• Ask the engineer to open the code during the session and identify any hidden technical complexities in the proposed flow.
• Negotiate and cut scope until everyone in the room believes the solution can land within the time budget.
• Write a one-page pitch that explains the problem, the shaped solution, and the appetite.
• Present this pitch to the team and ask the builders to create a nine-box grid of implementation chunks.
• Commit to a "no extension" rule for this pilot project to test the circuit breaker mindset.
• Check in weekly to see if the team is on the left or right side of the hill for each major scope.
• Protect the building team from all external meetings and distractions during their cycle.
• Review the outcome at the end of the cycle: did the project land, and what did you learn about your shaping skills?
• Spend four hours this week researching your customers' struggling moments to find the next problem to frame.
• Remove one high-fidelity design phase from your next small project and go straight from fat marker sketch to code.
• Audit your current team structure and identify if your PMs are spending more than fifty percent of their time on project management.
• Transition one recurring standup meeting into a hill chart update in an async document.
• Commit to a six-week cycle for your next major feature launch.