The 37signals Product Development Framework
A system for building profitable software without bloat, bureaucracy, or burnout, distilled from three books: Getting Real (build less), Rework (say no by default), and Shape Up (fix time, flex scope). Use it to shape work, bet on six-week cycles, run small autonomous teams, and ship on a predictable cadence.
Core Principle
Build less. The best products do fewer things exceptionally well — simplicity is the destination, not the starting point. Traditional development adds; the 37signals way subtracts: build half a product (not a half-assed product), say no by default, fix the time and flex the scope. Constraints are what make great work possible — six weeks, three people, and a shaped pitch force you to find the essential version.
Scoring
Goal: 10/10. Rate product plans, feature scopes, and team processes 0-10 against these principles. Report the current score and the specific changes needed to reach 10/10.
- 9-10: Fixed-time cycles, shaped pitches, small teams, no backlog, opinionated defaults, clear copy
- 7-8: Mostly shaped work and small teams, but some scope creep or process overhead
- 5-6: Some shaping happens, but backlogs persist, teams are too large, or preferences replace decisions
- 3-4: Heavy process (standups, sprints, story points) with occasional simplicity efforts
- 0-2: Feature factory: long-term roadmaps, large teams, estimation rituals, no shaping
1. Build Less, Underdo the Competition
Core concept: Win through deliberate omission — fewer features, fewer preferences, fewer moving parts, each done better than competitors do theirs. Build software you need yourself and solve problems you understand deeply.
Why it works: Every feature carries maintenance, cognitive, and opportunity costs forever, usually for a fraction of users. Building less keeps the product focused, the codebase manageable, and the team small.
Key insights:
- Half a product beats a half-assed product — do a few things well, not many things poorly
- Be a curator, not a hoarder: say no to good ideas so the great ones can breathe
- Make tiny decisions — big ones are hard to make and hard to reverse; small ones build momentum
- Underdo the competition: let them build the Swiss Army knife while you build the steak knife
- Focus on what won't change — speed, simplicity, reliability, ease of use
Product applications:
See references/build-less.md [blocked] when deciding what to cut — curation tactics, the constraints-as-feature argument, and worked scope-cut examples.
2. Shaping the Work
Core concept: Before work reaches a team, a senior person who bridges product and technical worlds makes it rough (room to maneuver), solved (main elements figured out), and bounded (scope limited by appetite).
Why it works: Raw ideas waste team time; detailed specs turn teams into ticket-takers. Shaping removes the biggest unknowns while leaving design freedom, and appetite ("how much time is this worth?") replaces estimation ("how long will this take?") — bounded investment instead of open-ended commitment.
Key insights:
- A shaped pitch has five elements: problem, appetite, solution, rabbit holes, no-gos
- Breadboard flows as places, affordances, and connections — structure without visual design
- Fat marker sketches keep abstraction high; wireframes invite pixel-level feedback before the concept is validated
- Rabbit holes (scope-blowing risks) get addressed in the pitch, not during the build
- No-gos make boundaries visible, preventing scope creep before it starts
Product applications:
Ethical boundary: Set appetites that reflect the problem's genuine value — never artificially small to pressure teams.
See references/shaping-work.md [blocked] when drafting a pitch — the five-element pitch format, a worked breadboard, fat-marker rules, the rabbit-hole pattern table, good/bad no-go examples, and a 6-step shaping procedure.
3. Betting and Cycles
Core concept: Replace backlogs and roadmaps with a betting table: senior stakeholders bet shaped pitches into six-week cycles, separated by two-week cool-downs. Unfinished work hits the circuit breaker — it does not automatically continue.
Why it works: Backlogs grow forever, create false progress, and dilute focus; limited cycle slots force real prioritization. The circuit breaker kills zombie projects, and cool-downs prevent the burnout of continuous sprinting.
Key insights:
- Abolish the backlog — if an idea is important, it will come back
- Six weeks is long enough for meaningful work, short enough to feel the deadline
- Variable scope: teams cut non-essential scope to hit the fixed deadline, never the reverse
- Plan one cycle at a time — long-term roadmaps are stale commitments
- Most pitches don't get bet on, and that's healthy
Product applications:
Ethical boundary: Apply the circuit breaker honestly — to kill zombies, not politically inconvenient projects; the point is focus, not unsustainable pressure.
See references/betting-cycles.md [blocked] when running a betting table or planning a cycle — how the table decides, structuring the six-week/two-week rhythm, applying the circuit breaker, and the case against backlogs.
4. Small Teams and Execution
Core concept: Three-person teams (one designer, one or two programmers) work a shaped pitch autonomously — no standups, no PMs hovering. They discover their own tasks and track progress on hill charts.
Why it works: Three people can have a conversation; ten need a meeting. Teams that discover tasks from a shaped pitch develop real problem understanding, and hill charts tell the truth: uphill = still figuring out, downhill = executing known work.
Key insights:
- Scopes replace tasks — group related work into named slices that move independently on the hill
- Meetings are toxic: write it up instead
- Get real: working HTML with real data on day 2 beats a Figma mockup on day 5
- Launch now, iterate later — software in users' hands beats plans in a deck
- Design and programming integrate from day one — no handoff phases
Product applications:
Ethical boundary: Autonomy requires genuinely manageable scope — if a team consistently works overtime to hit six weeks, fix the shaping, not the team.
See references/small-teams-execution.md [blocked] when a team is mid-build — reading and updating hill charts, slicing scopes, async communication norms, and getting real with working HTML.
5. Opinionated Software and Clear Communication
Core concept: Great software makes choices instead of burying users in preferences — every preference is a decision the team could not or would not make. The same honesty applies to copy: say what you mean, skip buzzwords, teach what you know openly.
Why it works: Every added preference splits the product into more states to design, test, and support, and pushes a decision onto users who lack the context to make it well; sensible defaults reduce cognitive load and create cohesion. Clear copy builds trust where marketing-speak erodes it, and teaching openly attracts customers who share your values.
Key insights:
- Pick the best default and ship it — revisit only if data shows it fails most users
- Epicycles (features patching problems earlier features created) compound complexity
- "Not now" is a valid, healthy answer to good feature requests
- Out-teach the competition; sell your by-products (books, posts, tools)
- Interface copy is your best marketing — every label and error message builds or burns trust
Product applications:
See references/opinionated-software.md [blocked] when responding to feature requests or removing settings, and references/ux-ui-copy.md [blocked] when writing interface copy, empty states, or error messages.
Common Mistakes
Quick Diagnostic
See references/case-studies.md [blocked] for end-to-end worked scenarios when you want a model to follow — adopting Shape Up, resisting feature creep, and replacing status meetings with hill charts.
Further Reading
- "Getting Real" by Jason Fried & David Heinemeier Hansson
- "Rework" by Jason Fried & David Heinemeier Hansson
- "Shape Up: Stop Running in Circles and Ship Work that Matters" by Ryan Singer
- "It Doesn't Have to Be Crazy at Work" by Jason Fried & David Heinemeier Hansson
- "Remote: Office Not Required" by Jason Fried & David Heinemeier Hansson
About the Authors
Jason Fried is co-founder and CEO of 37signals (Basecamp, HEY) and a leading advocate for calm companies and product simplicity. David Heinemeier Hansson (DHH) is 37signals co-founder and creator of Ruby on Rails, extracted from Basecamp's codebase; together they wrote Getting Real, Rework, Remote, and It Doesn't Have to Be Crazy at Work. Ryan Singer spent 15+ years shaping product at 37signals and codified the methodology in Shape Up.
