Mmcp.market

37signals-way skill

by wondelai·wondelai/skills·2.3k stars·MIT

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", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.

A100/100content scan

Is the 37signals-way skill safe?

Clean: nothing in its files matched our rules. We read 8 files in the folder on 2026-09-28.

No findings.

Install the 37signals-way skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills
mkdir -p ~/.claude/skills
cp -r /tmp/skills/plugins/wondelai-skills/skills/37signals-way ~/.claude/skills/37signals-way
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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.

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:

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

See 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.

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:

Ethical boundary: Apply the circuit breaker honestly — to kill zombies, not politically inconvenient projects; the point is focus, not unsustainable pressure.

See 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.

4. Small Teams and Execution

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.

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.

Key insights:

  • Scopes replace tasks — group related work into named slices that move independently on the hill
  • Meetings are toxic: write it up instead
  • Get real: working HTML with real data on day 2 beats a Figma mockup on day 5
  • Launch now, iterate later — software in users' hands beats plans in a deck
  • Design and programming integrate from day one — no handoff phases

Product applications:

Ethical boundary: Autonomy requires genuinely manageable scope — if a team consistently works overtime to hit six weeks, fix the shaping, not the team.

See 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.

5. Opinionated Software and Clear Communication

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.

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.

Key insights:

  • Pick the best default and ship it — revisit only if data shows it fails most users
  • Epicycles (features patching problems earlier features created) compound complexity
  • "Not now" is a valid, healthy answer to good feature requests
  • Out-teach the competition; sell your by-products (books, posts, tools)
  • Interface copy is your best marketing — every label and error message builds or burns trust

Product applications:

See references/opinionated-software.md when responding to feature requests or removing settings, and references/ux-ui-copy.md when writing interface copy, empty states, or error messages.

Common Mistakes

Quick Diagnostic

See 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.

Further Reading

  • "Getting Real" by Jason Fried & David Heinemeier Hansson
  • "Rework" by Jason Fried & David Heinemeier Hansson
  • "Shape Up: Stop Running in Circles and Ship Work that Matters" by Ryan Singer
  • "It Doesn't Have to Be Crazy at Work" by Jason Fried & David Heinemeier Hansson
  • "Remote: Office Not Required" by Jason Fried & David Heinemeier Hansson

About the Authors

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.

More skills from wondelai/skills

  • A37signals-wayBuild 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", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild 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", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-codeWrite readable, maintainable code through disciplined naming, small functions, and clean error handling. Use when the user mentions "clean up this code", "this function is too long", "code smells", "naming conventions", "boy scout rule", "single responsibility", or "unit test quality". Also trigger when reviewing a pull request for readability, untangling a messy function, debating comment styles, or improving error-handling patterns. Covers SRP, comment discipline, formatting, and unit testing. For refactoring techniques, see refactoring-patterns. For architecture and dependency rules, see clean-architecture.

All agent skills → · MCP servers