The 37signals Product Development Framework

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 when deciding what to cut — curation tactics, the constraints-as-feature argument, and worked scope-cut examples.