Shape Up: The Product Manager's Guide to Fixed-Time, Variable-Scope Development
Shape Up is a product development methodology created by Basecamp where teams commit to fixed time windows (typically six weeks) and deliberately vary scope to fit. A product manager shapes the problem and solution at the right level of abstraction, bets on which projects deserve cycles, then gives a small team full autonomy to build and ship. Cool-down periods between cycles prevent burnout and create space for fixes, exploration, and preparation.
Overview
Shape Up is a product development framework that emerged from nearly two decades of practice at Basecamp (formerly 37Signals). Ryan Singer, Basecamp's Head of Strategy, codified the approach in his 2019 book Shape Up: Stop Running in Circles and Ship Work that Matters, published freely online. The framework was born from a specific frustration: traditional project management methods either gave teams too little direction ("build something related to notifications") or too much (a pixel-perfect spec with 47 Jira tickets). Shape Up carves out a middle path. Work gets shaped to the right level of abstraction before anyone writes code, then a small team owns the entire execution without a product manager hovering over daily standups.
The core claim of Shape Up is deceptively simple: fix the time, flex the scope. Most product teams do the opposite. They define exactly what they want built, then ask "how long will this take?" and watch the timeline stretch. Shape Up flips that relationship. A product manager sets an appetite, say six weeks, and the team figures out what version of the solution fits inside that boundary. This forces real tradeoffs upfront instead of letting scope creep happen quietly over months. It also means every cycle has a hard deadline. Work ships or it doesn't. There is no "just two more sprints."
The framework divides work into four distinct phases that repeat on a cadence. First, shaping happens before any cycle begins. Senior people (often a product manager working with a technical partner) define the problem, sketch a solution at the right altitude, and identify rabbit holes that could blow up the timeline. Second, the betting table is where leadership decides which shaped pitches deserve a full cycle of team time. This replaces the traditional backlog. There is no groomed list of hundreds of tickets. If a pitch doesn't get bet on, it's not kept around as organizational debt. Third, building is the execution phase where a small, integrated team (usually one or two designers and one or two programmers) takes the shaped pitch and figures out the implementation details themselves. Fourth, cool-down is a one-to-two week breather between cycles for bug fixes, technical exploration, and recharging.
Shape Up sits in an interesting position relative to other product development methods. It shares Scrum's love of timeboxing but rejects the sprint-by-sprint micromanagement, the daily standups, the velocity tracking, and the product backlog. It shares Kanban's respect for flow and autonomy but imposes hard boundaries that Kanban deliberately avoids. It's philosophically closer to Basecamp's own company values: small teams, high autonomy, minimal meetings, and a bias toward shipping. Critics point out that Shape Up was designed for a bootstrapped company of roughly 50 people building one product, and that its assumptions about team trust, skill level, and organizational flatness don't always transfer to larger or more regulated environments. Those critics have a point. But the underlying mental model, that appetite should drive scope rather than the other way around, has proven useful far beyond Basecamp's walls. Teams at Intercom, Notion community builders, and dozens of mid-stage startups have adapted elements of Shape Up even when they don't adopt the full framework.
For a product manager, Shape Up represents a significant shift in role. You spend less time writing detailed requirements and managing a backlog. You spend more time thinking deeply about problems before committing resources, writing compelling pitches that frame the opportunity and boundary conditions, and then stepping back during execution. The product manager's leverage moves upstream, to the shaping and betting phases, where decisions have the highest impact. Hamster provides a workspace where teams can run Shape Up cycles with AI agents handling the coordination, from shaping pitches to tracking hill chart progress.
How It Works
Step 1: Set the Appetite
Before any shaping begins, a product manager decides how much time a particular problem is worth. This is the appetite: a time budget that constrains the solution rather than an estimate that predicts the timeline. Common appetites are "small batch" (one to two weeks) and "big batch" (six weeks). The appetite is not arbitrary. It reflects the strategic importance of the problem, the opportunity cost of committing a team, and the risk tolerance for the solution. " If the answer is no, either the problem isn't important enough or it needs to be broken into smaller bets. Watch out for setting appetites based on what someone thinks the solution should look like rather than what the problem is worth. The appetite should come before the solution, not after.
Step 2: Shape the Work
Shaping is the most intellectually demanding phase. A product manager (often working with a senior designer or technical lead) takes a raw idea and develops it into a pitch with the right level of abstraction. Start by clearly defining the problem, ideally grounded in real user behavior or business data. Then sketch a solution using [breadboards and fat-marker sketches](/skills/using-breadboards-and-fat-marker-sketches) that show the flow and key elements without prescribing visual design or implementation details. Identify rabbit holes: technical uncertainties, edge cases, or scope traps that could blow up the timeline. Call them out explicitly and either solve them during shaping or declare them out of scope. A well-shaped pitch answers three questions: what are we solving, what does the rough solution look like, and what are we deliberately not doing? " for any major scenario.
Step 3: Write the Pitch
The pitch is the artifact that carries the shaped work into the betting table. It is a structured document, not a Jira epic or a Slack message. A strong pitch includes five elements: the problem (why this matters now), the appetite (how much time it's worth), the solution (breadboards or fat-marker sketches), rabbit holes (risks identified and addressed), and no-gos (what is explicitly excluded). Write pitches with enough context that someone who wasn't in the shaping conversation can evaluate the bet. Avoid two common failure modes: writing too abstractly ("improve onboarding") so the team has no direction, or writing too concretely (detailed wireframes and task lists) so the team has no room to maneuver. The pitch should be shareable asynchronously. Teams that only pitch verbally lose the ability to evaluate bets thoughtfully. See [shaping product pitches](/skills/shaping-product-pitches) for detailed templates and examples.
Step 4: Run the Betting Table
The betting table is a short meeting (typically one to two hours) where a small group of decision-makers reviews the available pitches and decides which ones get a team for the next cycle. This is not backlog grooming. There is no ranked list of 50 items. Only fully shaped pitches are eligible. " Pitches that aren't selected are dropped, not deferred into a backlog. If a pitch is genuinely important, someone will re-pitch it in a future cycle. This is intentional. It prevents organizational debt and forces the product manager to fight for what matters most right now. A common mistake is treating the betting table as a formality where the highest-paid person's favorite pitch always wins. For the process to work, there must be genuine deliberation and the possibility of saying no. See [running betting table sessions](/skills/running-betting-tables) for facilitation approaches.
Step 5: Kick Off the Build Cycle
Once bets are placed, a small integrated team (one designer and one or two programmers) receives the pitch and begins the cycle. The first few days are critical. The team reads the pitch, asks clarifying questions, and then starts mapping scopes, which are meaningful slices of the project that can be completed independently. Scopes are not tasks. A scope like "invitation flow" contains design, front-end, and back-end work bundled together. The team decides the order of scopes based on risk: tackle the scariest, most uncertain scope first to reduce the chance of a late-cycle surprise. The product manager's role during the build is to be available for scope questions and boundary decisions but not to run standups or review daily progress. Progress is tracked via [hill charts](/skills/tracking-progress-with-hill-charts) where each scope is a dot on a hill, showing whether it's in the figuring-out phase (uphill) or the execution phase (downhill). If a scope gets stuck uphill for too long, that's a signal for the team to cut scope or escalate.
Step 6: Manage Scope During the Cycle
As the cycle progresses, the team will inevitably encounter things that don't fit, edge cases, nice-to-haves, and unexpected complexity. Shape Up handles this through deliberate scope management. " The team actively trims scope to protect the deadline rather than extending the timeline to include everything. This requires a product manager who has clearly communicated the boundaries in the pitch and who supports the team's decisions to cut. A common anti-pattern is a product manager who shaped the pitch with explicit no-gos but then adds them back as "quick additions" mid-cycle. If scope management feels painful, it usually means the shaping was too abstract or the appetite was too tight for the problem. See [setting appetites and cutting scope](/skills/setting-appetites-and-managing-scope) for tactics.
Step 7: Ship at the End of the Cycle
At the end of the cycle, the work either ships or it doesn't. There is no "carry-over" into the next cycle. This is the hard boundary that makes Shape Up work. If the team didn't finish, the work is evaluated fresh: was the shaping insufficient? Was the appetite wrong? Should it be re-pitched with a different approach? Sometimes the answer is to pitch a smaller follow-up. Sometimes the answer is to let it go. This binary outcome eliminates the zombie projects that haunt traditional product teams, features that are perpetually "almost done" for months. Shipping doesn't necessarily mean releasing to all users. It can mean deploying behind a feature flag or to a beta group. The point is that the team has built something complete and coherent within the boundary.
Step 8: Run the Cool-Down Period
After every cycle, a one-to-two week cool-down period begins. During cool-down, there are no shaped projects and no deadlines. Team members use this time for activities that don't fit neatly into a cycle: fixing bugs that surfaced during the build, addressing small quality-of-life improvements, exploring new technologies, writing pitches for the next betting table, or simply resting. Cool-down is where a product manager often does their best shaping work, because they have uninterrupted time to think deeply about the next set of problems. Resist the temptation to fill cool-down with "quick projects" or to shorten it when there's pressure to ship faster. The cool-down is what makes the cadence sustainable over years, not just quarters. See [planning cool-down periods](/skills/planning-cooldown-periods) for structuring this time effectively.
When to Use
- When your team is drowning in a backlog of hundreds of tickets and every sprint planning session feels like rearranging deck chairs. Shape Up replaces that accumulated decision debt with a clean betting table where only fully shaped pitches compete for real commitment, giving a product manager a way to reset the prioritization conversation entirely.
- When you have a small-to-medium product team (roughly 3-15 builders) that is skilled enough to own execution decisions, and you want to give them meaningful autonomy rather than prescribing daily tasks. Shape Up's model of shaping the boundaries upfront and then stepping back during the build requires trust but rewards it with speed and ownership.
- When your product has entered a phase of sustained development, past the initial launch where everything is urgent, and the product manager needs a repeatable cadence for evaluating, committing to, and shipping improvements. The six-week cycle creates a rhythm that makes stakeholder communication predictable and reduces the constant re-negotiation of priorities.
- When scope creep is your team's chronic failure mode. If past projects consistently ballooned from "two weeks" to "three months" because nobody enforced boundaries, the fixed-time constraint in Shape Up acts as a structural intervention. The appetite forces hard scoping decisions before engineering time is spent.
- When your organization values shipping tangible outcomes over generating output metrics like velocity or story points. Shape Up measures progress by whether scopes move over the hill, not by how many tickets get closed. This is a good fit for teams that have tried Scrum and found the ceremony-to-value ratio too high.
When Not to Use
- When your team is in the first weeks of building a brand-new product and doesn't yet know what the product should be. Shape Up assumes you have a clear enough problem space to shape specific solutions. In a zero-to-one phase, you need rapid experimentation, user interviews, and throwaway prototypes more than six-week build cycles. The shaping process can actually slow you down when the entire product direction is still open.
- When you operate in a heavily regulated industry (healthcare, finance, defense) where detailed upfront specifications, traceability matrices, and sign-off processes are legally required. Shape Up's deliberately abstract pitches and variable scope conflict with environments where you need to document exactly what will be built before a single line of code is written. The "cut scope to fit the appetite" principle may violate compliance requirements.
- When your team is very large (50+ engineers) and works on a monolithic product with deep cross-team dependencies. Shape Up was designed for small, autonomous teams working on relatively independent scopes. If shipping a feature requires coordinated changes across six teams, the six-week cycle becomes a synchronization nightmare. You may need something more like SAFe or a custom coordination layer, even if those approaches feel heavier.
- When your product primarily requires ongoing maintenance, infrastructure work, or support-driven bug fixes rather than new feature development. Shape Up's shaping and betting process is designed for discretionary product work, problems worth investing weeks into. If 80% of your team's time goes to keeping the lights on, the overhead of shaping pitches for the remaining 20% may not be justified.
- When your team lacks the seniority or trust to work autonomously during a build cycle. Shape Up gives the building team significant freedom, and if your team includes mostly junior developers who need daily guidance, or if your organization's culture requires managers to approve granular decisions, the autonomy model will either be performative or chaotic. Build the team's capability first.
Examples
Example: B2B SaaS Startup Replacing Scrum with Shape Up
A 12-person SaaS company building project management software had been running two-week sprints for two years. Their backlog had 340 items, sprint planning took half a day, and engineers complained that they could never get deep into a problem before the sprint ended. The product manager proposed switching to six-week cycles with Shape Up. In the first cycle, they shaped three pitches and bet on two: a redesigned reporting dashboard and an improved CSV import flow. The reporting team shipped a focused version, cutting real-time updates (originally in scope) to hit the deadline. The import team got stuck on a rabbit hole involving encoding edge cases that the shaping hadn't identified, and the project didn't ship. The product manager re-shaped the import pitch with the encoding problem explicitly scoped out, bet on it in cycle two, and the team shipped it in four weeks. After three cycles, the team reported higher satisfaction, the backlog was replaced with a pitch archive, and the product manager spent roughly 60% less time in planning meetings. The main lesson: their first shaping attempt wasn't rigorous enough about identifying technical rabbit holes, and they adjusted by involving a senior engineer in all future shaping sessions.
Example: E-Commerce Team Using Shape Up for Seasonal Features
A 25-person e-commerce platform team needed to ship a gift-card system before the holiday season, roughly 10 weeks away. The product manager set a six-week appetite and shaped a pitch that included purchasing, redeeming, and balance-checking. During shaping, they identified that multi-currency support and partial redemption were rabbit holes that could each consume two weeks alone. Both were declared no-gos for the first cycle. The building team (two engineers, one designer) shipped a working gift-card system that supported single-currency purchase and full redemption in five weeks. During the subsequent cool-down, they fixed three edge cases customers found. The product manager then shaped a follow-up pitch for partial redemption and bet on it for the next cycle. Multi-currency was deprioritized entirely after customer research showed only 4% of their user base transacted in multiple currencies. The key insight was that the appetite-setting process forced the team to separate the "must ship for holiday" core from the "would be nice someday" extras before engineering began, rather than discovering the scope problem at week eight of a twelve-week project.
Example: Developer Tools Company Adapting Shape Up for Platform Work
A developer tools company with 40 engineers tried adopting Shape Up across three product teams. Two teams (dashboard and integrations) adapted well. The third team, responsible for core infrastructure, struggled. Their work involved database migrations, API versioning, and performance optimization, problems that didn't fit neatly into shaped pitches with clear user-facing outcomes. The product manager tried shaping infrastructure pitches, but the "solution" section felt forced because the real work was investigation and experimentation. After two frustrating cycles, they adapted the model: infrastructure work got a dedicated "exploration appetite" format where the pitch defined the problem and success criteria but not a solution shape. The team had six weeks to investigate, prototype, and ship an improvement. If the improvement didn't meet the success criteria, they wrote up what they learned and the product manager decided whether to re-bet. This hybrid approach worked well. The lesson was that Shape Up's shaping process assumes you can sketch a solution direction upfront, which works for product features but breaks for deep technical work where the solution only emerges through investigation.
Example: Agency Using Shape Up for Client Projects
A digital product agency with eight people adopted Shape Up to manage client engagements. Each client project was structured as a series of six-week cycles. During sales, the product manager and lead designer would shape the first cycle's pitch collaboratively with the client, defining the problem and appetite. The betting table was replaced with a client alignment meeting where the shaped pitch was presented and agreed upon. The main adaptation was transparency: clients received hill chart updates weekly instead of traditional status reports with percentage-complete metrics. Initially, clients found hill charts confusing because a scope could sit at 30% uphill for days while the team was doing research. " After two cycles, clients reported feeling more informed about actual project risk than they had with previous agencies using traditional reporting. The agency completed 85% of cycles on time, compared to roughly 50% of fixed-scope projects delivered on time in their previous workflow. They would do one thing differently next time: shape the first cycle during the sales process rather than after signing, to surface misaligned expectations before money changes hands.
Skills in This Method
Managing Six-Week Build Cycles
How to structure and execute fixed-time build cycles including setting appetites, forming small teams, and enforcing the circuit breaker when time runs out.
Planning Cool-Down Periods
How to structure the cool-down period between cycles for bug fixes, technical debt, exploration, and preparing the next round of shaped work.
Setting Appetites and Cutting Scope
How to set a time appetite for a project and then deliberately cut scope and identify must-haves versus nice-to-haves to fit within the fixed timebox.
Shaping Product Pitches
How to define problems, set appetites, and craft shaped pitches with fat-marker sketches and breadboarding before committing engineering resources.
Tracking Progress with Hill Charts
How to use hill charts to visualize whether scopes are in the uphill (figuring it out) or downhill (executing) phase and communicate progress without status meetings.
Running Betting Table Sessions
How to facilitate the betting table meeting where stakeholders review shaped pitches and decide which projects to commit to in the next cycle.
Mapping Scopes Instead of Tasks
How to organize work into meaningful scopes — integrated slices of front-end and back-end work — instead of traditional task lists during the building phase.
Using Breadboards and Fat-Marker Sketches
How to use breadboarding for flow design and fat-marker sketching for visual concepts to define solutions at the right level of abstraction during shaping.