37signals-way

Solid

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.

AI & Automation 1,295 stars 135 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 96/100

Stars 20%
100
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# 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,...

Details

Author
wondelai
Repository
wondelai/skills
Created
4 months ago
Last Updated
yesterday
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

lean-startup

Design MVPs, validated learning experiments, and pivot-or-persevere decisions using Build-Measure-Learn. Use when the user mentions "MVP scope", "validated learning", "pivot or persevere", "vanity metrics", "test assumptions", "innovation accounting", "build-measure-learn", or "minimum viable experiment". Also trigger when deciding what to include in a first version, measuring startup progress, or evaluating whether to change direction on a product bet. Covers innovation accounting and actionable metrics. For 5-day prototype testing, see design-sprint. For customer motivation analysis, see jobs-to-be-done.

1,295 Updated yesterday
wondelai
AI & Automation Featured

lean-startup

Design MVPs, validated learning experiments, and pivot-or-persevere decisions using Build-Measure-Learn. Use when the user mentions "MVP scope", "validated learning", "pivot or persevere", "vanity metrics", or "test assumptions". Covers innovation accounting and actionable metrics. For 5-day prototype testing, see design-sprint. For customer motivation analysis, see jobs-to-be-done. Trigger with 'lean', 'startup'.

2,359 Updated today
jeremylongshore
Web & Frontend Listed

escaping-build-trap

Product management framework based on Melissa Perri's "Escaping the Build Trap". Use this skill whenever the user is discussing product strategy, roadmap construction, product team maturity, or symptoms of feature-factory behavior — even if they do not explicitly say "build trap" or "outcome-driven." Triggers include: (1) diagnosing whether a team is stuck shipping features without measuring outcomes, (2) shifting from output-driven to outcome-driven product development, (3) evaluating product manager archetypes (Waiter, Project Manager, Mini-CEO, Strategic) or team maturity, (4) designing a strategy deployment cascade from vision to product initiatives to team-level options, (5) converting a feature roadmap into an outcome roadmap, (6) running a pre-mortem against a quarterly plan to detect build-trap patterns before committing, (7) coaching a PM who is acting as an order-taker for stakeholder requests, (8) writing the case for killing a low-adoption feature.

0 Updated 2 weeks ago
tomaszstaniak