{"id":"37signals-way","name":"37signals-way","summary":"「Getting Real(リアルにする)」「Rework(再加工)」「Shape Up(形を整えろ)」という37signalsの哲学を用いて、スリムで意見を述べた製品を作りましょう。","body":"# The 37signals Product Development Framework\n\nA 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.\n\n## Core Principle\n\n**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.\n\n## Scoring\n\n**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.\n\n- **9-10:** Fixed-time cycles, shaped pitches, small teams, no backlog, opinionated defaults, clear copy\n- **7-8:** Mostly shaped work and small teams, but some scope creep or process overhead\n- **5-6:** Some shaping happens, but backlogs persist, teams are too large, or preferences replace decisions\n- **3-4:** Heavy process (standups, sprints, story points) with occasional simplicity efforts\n- **0-2:** Feature factory: long-term roadmaps, large teams, estimation rituals, no shaping\n\n### 1. Build Less, Underdo the Competition\n\n**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.\n\n**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.\n\n**Key insights:**\n- Half a product beats a half-assed product — do a few things well, not many things poorly\n- Be a curator, not a hoarder: say no to good ideas so the great ones can breathe\n- Make tiny decisions — big ones are hard to make and hard to reverse; small ones build momentum\n- Underdo the competition: let them build the Swiss Army knife while you build the steak knife\n- Focus on what won't change — speed, simplicity, reliability, ease of use\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| **Feature prioritization** | Default answer is no | Reporting dashboard requested → ship CSV export covering 90% of use cases |\n| **MVP scoping** | Cut until it hurts, then cut more | Drop user accounts for v1; use email magic links |\n| **Competitive strategy** | Underdo, don't outdo | Competitor has 50 integrations; ship 3 that work flawlessly |\n\nSee [references/build-less.md](references/build-less.md) when deciding what to cut — curation tactics, the constraints-as-feature argument, and worked scope-cut examples.\n\n### 2. Shaping the Work\n\n**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).\n\n**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.\n\n**Key insights:**\n- A shaped pitch has five elements: problem, appetite, solution, rabbit holes, no-gos\n- Breadboard flows as places, affordances, and connections — structure without visual design\n- Fat marker sketches keep abstraction high; wireframes invite pixel-level feedback before the concept is validated\n- Rabbit holes (scope-blowing risks) get addressed in the pitch, not during the build\n- No-gos make boundaries visible, preventing scope creep before it starts\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| **Feature design** | Breadboard before mockup | \"Invite teammate\": Settings → invite form → email sent → accept link → dashboard |\n| **Scope definition** | Set appetite first | \"A 2-week appetite problem, not a 6-week one\" shapes which solution fits |\n| **Risk management** | Call out rabbit holes upfront | \"Permissions could get complex — limit to owner/member for v1\" |\n\n**Ethical boundary:** Set appetites that reflect the problem's genuine value — never artificially small to pressure teams.\n\nSee [references/shaping-work.md](references/shaping-work.md) 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.\n\n### 3. Betting and Cycles\n\n**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.\n\n**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.\n\n**Key insights:**\n- Abolish the backlog — if an idea is important, it will come back\n- Six weeks is long enough for meaningful work, short enough to feel the deadline\n- Variable scope: teams cut non-essential scope to hit the fixed deadline, never the reverse\n- Plan one cycle at a time — long-term roadmaps are stale commitments\n- Most pitches don't get bet on, and that's healthy\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| **Roadmap replacement** | Bet each cycle | 3-4 shaped pitches every 6 weeks instead of a 12-month roadmap |\n| **Risk management** | Circuit breaker kills zombies | 70% done at week 6? It doesn't ship — re-shape and re-bet if it still matters |\n| **Capacity planning** | Cool-down between cycles | Two weeks for bugs, tech debt, exploration, recovery |\n\n**Ethical boundary:** Apply the circuit breaker honestly — to kill zombies, not politically inconvenient projects; the point is focus, not unsustainable pressure.\n\nSee [references/betting-cycles.md](references/betting-cycles.md) 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.\n\n### 4. Small Teams and Execution\n\n**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.\n\n**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.\n\n**Key insights:**\n- Scopes replace tasks — group related work into named slices that move independently on the hill\n- Meetings are toxic: write it up instead\n- Get real: working HTML with real data on day 2 beats a Figma mockup on day 5\n- Launch now, iterate later — software in users' hands beats plans in a deck\n- Design and programming integrate from day one — no handoff phases\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| **Team structure** | Three people max, no PM | One designer + two programmers per 6-week bet |\n| **Progress tracking** | Hill charts, not burndowns | \"Invitations\" uphill (permissions unclear); \"Email templates\" downhill (executing) |\n| **Communication** | Async-first, write it up | A written update or 5-minute video instead of a 30-minute meeting |\n\n**Ethical boundary:** Autonomy requires genuinely manageable scope — if a team consistently works overtime to hit six weeks, fix the shaping, not the team.\n\nSee [references/small-teams-execution.md](references/small-teams-execution.md) when a team is mid-build — reading and updating hill charts, slicing scopes, async communication norms, and getting real with working HTML.\n\n### 5. Opinionated Software and Clear Communication\n\n**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.\n\n**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.\n\n**Key insights:**\n- Pick the best default and ship it — revisit only if data shows it fails most users\n- Epicycles (features patching problems earlier features created) compound complexity\n- \"Not now\" is a valid, healthy answer to good feature requests\n- Out-teach the competition; sell your by-products (books, posts, tools)\n- Interface copy is your best marketing — every label and error message builds or burns trust\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| **Feature requests** | Default no, no false promises | \"Thanks for the suggestion. We're not planning this right now.\" |\n| **UI copy** | Plain language | \"Your file is saved\" not \"Your asset has been successfully persisted to the cloud\" |\n| **Error messages** | Honest and helpful | \"We couldn't send that email. Check the address and try again.\" |\n| **Preferences** | Eliminate; choose defaults | Detect timezone from the browser; ship one good theme |\n| **Marketing** | Honest positioning | \"Basecamp is not for everyone. Here's who it's for and who it's not for.\" |\n\nSee [references/opinionated-software.md](references/opinionated-software.md) when responding to feature requests or removing settings, and [references/ux-ui-copy.md](references/ux-ui-copy.md) when writing interface copy, empty states, or error messages.\n\n## Common Mistakes\n\n| Mistake | Why It Fails | Fix |\n|---------|-------------|-----|\n| Maintaining a backlog | Grows forever; false progress; diluted focus | Abolish it; bet on shaped pitches each cycle |\n| Estimating instead of setting appetite | Estimates grow to fill time and invite negotiation | Ask \"how much time is this problem worth?\" |\n| Pixel-perfect mockups before shaping | Too concrete too early; invites bikeshedding | Breadboards and fat marker sketches first |\n| Extending a six-week cycle | Zombie projects teach teams deadlines are fake | Circuit breaker: not done means not shipped |\n| Adding preferences instead of deciding | Complexity for all users to serve a few | Pick the best default and ship it |\n| Daily standups and status meetings | Interrupt maker flow; reporting overhead | Hill charts for visibility; async updates |\n| Saying yes to good feature requests | Good features still add non-essential complexity | Default to no; bet only on what matters this cycle |\n| Planning multiple cycles ahead | Stale commitments reduce responsiveness | Plan one cycle at a time |\n\n## Quick Diagnostic\n\n| Question | If No | Action |\n|----------|-------|--------|\n| Is there a fixed time constraint on this work? | Scope expands indefinitely | Set a six-week (or smaller) appetite first |\n| Is the work shaped (rough, solved, bounded)? | Scope problems surface mid-build | Define problem, appetite, solution, rabbit holes, no-gos |\n| Can a team of 2-3 people do this? | Too big | Break into independent six-week bets |\n| Said no to at least 5 things this cycle? | Building too much | Cut ruthlessly at the betting table |\n| Is the team figuring out its own tasks? | Micromanagement; team not empowered | Hand off shaped pitches, not task lists |\n| Tracking progress with hill charts? | False precision masks uncertainty | Switch to uphill (figuring out) vs. downhill (executing) |\n| Is there a cool-down after this cycle? | Burnout; no cleanup time | Schedule two unstructured weeks between cycles |\n| Does the software have a clear opinion here? | Decisions deferred to users via preferences | Pick the best default; remove the setting |\n\nSee [references/case-studies.md](references/case-studies.md) 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.\n\n## Further Reading\n\n- [*\"Getting Real\"*](https://www.amazon.com/Getting-Real-Smarter-Successful-Application/dp/0578012812?tag=wondelai00-20) by Jason Fried & David Heinemeier Hansson\n- [*\"Rework\"*](https://www.amazon.com/Rework-Jason-Fried/dp/0307463745?tag=wondelai00-20) by Jason Fried & David Heinemeier Hansson\n- [*\"Shape Up: Stop Running in Circles and Ship Work that Matters\"*](https://www.amazon.com/Shape-Up-Circles-Ship-Work/dp/B09ZSY1MWP?tag=wondelai00-20) by Ryan Singer\n- [*\"It Doesn't Have to Be Crazy at Work\"*](https://www.amazon.com/Doesnt-Have-Crazy-Work/dp/0062874780?tag=wondelai00-20) by Jason Fried & David Heinemeier Hansson\n- [*\"Remote: Office Not Required\"*](https://www.amazon.com/Remote-Office-Required-Jason-Fried/dp/0804137501?tag=wondelai00-20) by Jason Fried & David Heinemeier Hansson\n\n## About the Authors\n\n**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*.","author":"@wondelai","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/wondelai/skills/tree/main/37signals-way","license":"MIT","category":"writing","lang":"en","tokens":3151,"stars":0,"calls30d":2,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/betting-cycles.md","size":12904,"sha256":"613d9ed557da859bafd967af8bbcc48edc01bf55d0183525f64e05d0fda3623e"},{"path":"references/build-less.md","size":11201,"sha256":"48500268ff95fdce54974d40eb552ae132acea24a13071b06c3adbe25aef1887"},{"path":"references/case-studies.md","size":15873,"sha256":"50625bc95946c218d08b3bdc1f887c2b167c372facb67c736d3c80376f89a23e"},{"path":"references/opinionated-software.md","size":14139,"sha256":"f1eb37b97d01672b983ae9c346810b4e9f01efb2baec928227334fd9c52db951"},{"path":"references/shaping-work.md","size":13984,"sha256":"fecc4fa39c2687325ff0c94b15071f28fca71c1858c842fb6f03b6b49699c34d"},{"path":"references/small-teams-execution.md","size":13979,"sha256":"5d625f4a9f59e938034546f6447631c6e3b27e194c81849717bc9af1e9584915"},{"path":"references/ux-ui-copy.md","size":15491,"sha256":"2508245ab77dd66b8ef3a48dcb16a78e08c0896fc1431cd61327f966991e035b"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":["www.amazon.com"]}}