37signals-way

What this skill does

# The 37signals Product Development Framework

A complete system for building profitable software products without bloat, bureaucracy, or burnout. Over fifteen years, 37signals distilled their approach into three books: *Getting Real* (2006) established the "build less" ethos, *Rework* (2010) challenged conventional business wisdom, and *Shape Up* (2019) operationalized everything into a repeatable development process. Together they form a philosophy, a mindset, and a method for small teams that ship meaningful work on a predictable cadence.

## Table of Contents

- [Core Principle](#core-principle)
- [Scoring](#scoring)
- [1. Build Less, Underdo the Competition](#1-build-less-underdo-the-competition)
- [2. Shaping the Work](#2-shaping-the-work)
- [3. Betting and Cycles](#3-betting-and-cycles)
- [4. Small Teams and Execution](#4-small-teams-and-execution)
- [5. Opinionated Software and Clear Communication](#5-opinionated-software-and-clear-communication)
- [Common Mistakes](#common-mistakes)
- [Quick Diagnostic](#quick-diagnostic)
- [Reference Files](#reference-files)
- [Further Reading](#further-reading)
- [About the Authors](#about-the-authors)

## Core Principle

**Build less.** The best products are not the ones with the most features but the ones that do fewer things exceptionally well. Simplicity is not a starting point — it is the destination.

**The foundation:** Traditional product development adds. The 37signals way subtracts. Getting Real says: build half a product, not a half-assed product. Rework says: say no to almost everything by default. Shape Up says: fix the time, flex the scope. All three converge on the same truth — constraints are not obstacles to great work, they are what make great work possible. When you have six weeks, three people, and a shaped pitch, you cannot afford to build the wrong thing. You are forced to find the essential version. That is the advantage.

## Scoring

**Goal: 10/10.** When reviewing or creating product development plans, feature scopes, team processes, or product strategies, rate them 0-10 based on adherence to 37signals principles. A 10/10 means fixed-time cycles, shaped work, small autonomous teams, ruthless scope cutting, opinionated defaults, and clear honest communication. Lower scores indicate feature bloat, process overhead, or decision-deferring. Always provide the current score and specific improvements 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 unnecessary process overhead
- **5-6:** Mixed — 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 with long-term roadmaps, large teams, estimation rituals, and no shaping

### 1. Build Less, Underdo the Competition

**Core concept:** Competitive advantage through deliberate omission. Fewer features, fewer preferences, fewer moving parts. Instead of matching competitors feature-for-feature, do less — but do it better. Build software you need yourself, and solve problems you understand deeply.

**Why it works:** Every feature you add has a maintenance cost, a cognitive cost to users, and an opportunity cost. Most features are used by a fraction of users but maintained by the entire team forever. By building less, you keep the product focused, the codebase manageable, and the team small. You also force yourself to identify what truly matters — the 20% of functionality that delivers 80% of the value.

**Key insights:**
- Solve your own problem first — the surest way to build something valuable is to build something you need
- Half a product is better than a half-assed product — do a few things well rather than many things poorly
- Embrace constraints — limited time, money, and people force creative solutions
- Be a curator, not a hoarder — your job is to say no to good ideas so the great ones can breathe
- Make tiny decisions — big decisions 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
- Less software means less to maintain, less to test, less to explain, and less to go wrong
- Focus on what will not change — speed, simplicity, reliability, and ease of use never go out of style

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| **Feature prioritization** | Default answer is no | A customer requests a reporting dashboard; instead, ship a CSV export that covers 90% of use cases |
| **MVP scoping** | Cut until it hurts, then cut more | Remove user accounts entirely for v1; use email-based magic links instead |
| **Competitive strategy** | Underdo, do not outdo | Competitor has 50 integrations; you ship 3 that work flawlessly |
| **Preference elimination** | Pick sensible defaults | Instead of 12 notification settings, ship one thoughtful default with an off switch |
| **Constraint adoption** | Use limits as creative fuel | Three-person team and six weeks forces you to find the simplest version that works |

**Ethical boundary:** Building less must serve users, not just save development time. 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 is given to a team, it must be shaped. Shaping means making the work rough (room to maneuver), solved (main elements figured out), and bounded (clear scope limits defined by appetite). Shaping is the critical step between a raw idea and a team project. It is done by a senior person who understands both the product and the technical landscape.

**Why it works:** Raw ideas are too vague — teams waste time figuring out what to build. Detailed specs are too rigid — teams become ticket-takers with no room for creative problem-solving. Shaping finds the sweet spot: enough definition to remove the biggest unknowns, enough freedom for the team to design the implementation. The appetite (how much time is this worth?) replaces traditional estimation (how long will this take?), flipping the dynamic from open-ended commitment to bounded investment.

**Key insights:**
- Appetite vs. estimates — start with how much time a problem is worth, not how long a solution will take
- Breadboarding maps the flow using places, affordances, and connection lines — no visual design, just structure
- Fat marker sketches are drawn at a level of abstraction that prevents bikeshedding on visual details
- Wireframes are too concrete too early — they invite pixel-level feedback before the concept is validated
- A shaped pitch has five elements: problem, appetite, solution, rabbit holes, and no-gos
- Rabbit holes are the known risks that could blow up the scope — address them in the pitch, not during the build
- No-gos explicitly define what the solution will not include — preventing scope creep by making boundaries visible
- The shaper is neither the building team nor management — it is a senior person who bridges both worlds

**Product applications:**

| Context | Application | Example |
|---------|-------------|---------|
| **Feature design** | Breadboard before mockup | Map "user invites teammate" as: Settings → Invite form → Email sent → Accept link → Dashboard |
| **Scope definition** | Set appetite first | "This is a 2-week appetite problem, not a 6-week one" — shapes what solution is appropriate |
| **Team briefing** | Hand off shaped pitches, not specs | Pitch includes problem, appetite, rough solution, rabbit holes, no-gos |
| **Design fidelity** | Fat marker, not pixel-perfect | Sketch on a tablet with a thick brush to keep abstraction high |
| **Risk management** | Call out rabbit holes in advance | "The permissio