37signals way
/SKILLBuild lean, opinionated products using the 37signals philosophy from Getting Real, Rework, and Shape Up.
--- name: 37signals-way description: 'Build lean, opinionated products using the 37signals philosophy from Getting Real, Rework, and Shape Up. Use when the user mentions "Getting Real," "Rework," "Shape Up," "37signals," "Basecamp method," "six-week cycles," "fixed time variable scope," "appetite vs. estimates," "betting table," "breadboarding," "fat marker sketch," "build less," "underdo the competition," or "opinionated software." Also trigger when cutting scope to ship faster, running small teams, avoiding long-term roadmaps, or eliminating meetings. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.' license: MIT metadata: author: wondelai version: "1.1.0" --- # 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 well-defined pitch force you to find the essential version. ## Scoring Goal: 10/10. Rate product plans, feature scopes, and team processes on a scale of 0:10 against these principles. Report the current score and the specific changes needed to reach 10/10. - 9-10: Fixed-time cycles, well-defined pitches, small teams, no backlog, opinionated defaults, clear copy - 7-8: Mostly structured work and small teams, but some scope creep or process overhead - 5-6: Some structuring occurs, but backlogs persist, teams are too large, or personal preferences override decisions - 3-4: Heavy process (standups, sprints, story points) with occasional efforts toward simplicity - 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 only 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 | Remove 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 ### 2. Shaping the Work Core concept: Before work reaches a team, a senior person who bridges the product and technical worlds makes it rough (leaving room to maneuver), solved (with the main elements figured out), and bounded (with the scope limited by the team’s capacity). Why it works: Raw ideas waste the team’s time; detailed specs turn teams into mere order-takers. Shaping removes the biggest unknowns while leaving design f