37signals-way

# 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:**

| Context | Application | Example |
|---------|-------------|---------|
| **Feature prioritization** | Default answer is no | Reporting dashboard requested → ship CSV export covering 90% of use cases |
| **MVP scoping** | Cut until it hurts, then cut more | Drop user accounts for v1; use email magic links |
| **Competitive strategy** | Underdo, don't outdo | Competitor has 50 integrations; ship 3 that work flawlessly |

**Ethical boundary:** Cut complexity, not accessibility or safety — "less" means focused, not neglectful.

See: [references/build-less.md](references/build-less.md)

### 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:**

| Context | Application | Example |
|---------|-------------|---------|
| **Feature design** | Breadboard before mockup | "Invite teammate": Settings → invite form → email sent → accept link → dashboard |
| **Scope definition** | Set appetite first | "A 2-week appetite problem, not a 6-week one" shapes which solution fits |
| **Risk management** | Call out rabbit holes upfront | "Permissions could get complex — limit to owner/member for v1" |

**Ethical boundary:** Set appetites that reflect the problem's genuine value — never artificially small to pressure teams.

See: [references/shaping-work.md](references/shaping-work.md)

### 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:**

| Context | Application | Example |
|---------|-------------|---------|
| **Roadmap replacement** | Bet each cycle | 3-4 shaped pitches every 6 weeks instead of a 12-month roadmap |
| **Risk management** | Circuit breaker kills zombies | 70% done at week 6? It doesn't ship — re-shape and re-bet if it still matters |
| **Capacity planning** | Cool-down