37signals-way
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseThe 37signals Product Development Framework
37signals产品开发框架
A complete system for building profitable software products without bloat, bureaucracy, or burnout. Over fifteen years, 37signals distilled their approach into three books: Getting Real (2006) established the "build less" ethos, Rework (2010) challenged conventional business wisdom, and Shape Up (2019) operationalized everything into a repeatable development process. Together they form a philosophy, a mindset, and a method for small teams that ship meaningful work on a predictable cadence.
这是一套完整的体系，用于打造无冗余、无官僚主义、不会引发职业倦怠的盈利软件产品。十五年来，37signals将其方法论提炼成三本书：Getting Real（2006年）确立了「build less」的核心精神，Rework（2010年）挑战了传统商业认知，Shape Up（2019年）将所有理念落地为可复用的开发流程。三者共同构成了一套适用于小团队的哲学、思维模式和方法，帮助团队按可预测的节奏交付有价值的成果。
Table of Contents
目录
Core Principle
核心原则
Build less. The best products are not the ones with the most features but the ones that do fewer things exceptionally well. Simplicity is not a starting point — it is the destination.
The foundation: Traditional product development adds. The 37signals way subtracts. Getting Real says: build half a product, not a half-assed product. Rework says: say no to almost everything by default. Shape Up says: fix the time, flex the scope. All three converge on the same truth — constraints are not obstacles to great work, they are what make great work possible. When you have six weeks, three people, and a shaped pitch, you cannot afford to build the wrong thing. You are forced to find the essential version. That is the advantage.
**少做功能。**最好的产品不是功能最多的产品，而是将少数事情做到极致的产品。简洁不是起点，而是最终目标。
**底层逻辑：**传统产品开发是做加法，37signals的方法是做减法。Getting Real提到：做半个完整的产品，而不是一个半吊子产品。Rework提到：默认对几乎所有需求说不。Shape Up提到：固定时间，灵活调整范围。三者都指向同一个真理：约束不是优秀工作的阻碍，而是优秀工作诞生的前提。当你只有六周时间、三个人力和一个成型的提案时，你根本没有成本去做错的事，只能被迫找到最核心的解决方案，这就是优势所在。
Scoring
评分标准
Goal: 10/10. When reviewing or creating product development plans, feature scopes, team processes, or product strategies, rate them 0-10 based on adherence to 37signals principles. A 10/10 means fixed-time cycles, shaped work, small autonomous teams, ruthless scope cutting, opinionated defaults, and clear honest communication. Lower scores indicate feature bloat, process overhead, or decision-deferring. Always provide the current score and specific improvements 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 unnecessary process overhead
- 5-6: Mixed — 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 with long-term roadmaps, large teams, estimation rituals, and no shaping
**目标：10/10。**在评审或制定产品开发计划、功能范围、团队流程、产品战略时，根据符合37signals原则的程度打0-10分。10/10意味着固定时间周期、已塑形的工作、小型自治团队、 ruthless的范围裁剪、明确的默认配置、清晰诚实的沟通。分数越低代表功能冗余、流程 overhead 越多、决策越拖沓。每次评分都要给出当前分数和达到10/10所需的具体改进方向。
- **9-10分：**固定时间周期、已塑形的提案、小团队、无待办积压、明确的默认配置、清晰的文案
- **7-8分：**大部分工作已塑形、团队规模小，但存在少量范围蔓延或不必要的流程 overhead
- **5-6分：**好坏参半——有部分塑形工作，但仍存在待办积压、团队规模过大、用偏好代替决策的问题
- **3-4分：**流程繁重（站会、sprint、故事点），偶尔有简化的尝试
- **0-2分：**功能工厂模式，有长期路线图、团队规模大、有大量评估仪式，完全没有塑形环节
1. Build Less, Underdo the Competition
1. 少做功能，反向竞争
Core concept: Competitive advantage through deliberate omission. Fewer features, fewer preferences, fewer moving parts. Instead of matching competitors feature-for-feature, do less — but do it better. Build software you need yourself, and solve problems you understand deeply.
Why it works: Every feature you add has a maintenance cost, a cognitive cost to users, and an opportunity cost. Most features are used by a fraction of users but maintained by the entire team forever. By building less, you keep the product focused, the codebase manageable, and the team small. You also force yourself to identify what truly matters — the 20% of functionality that delivers 80% of the value.
Key insights:
- Solve your own problem first — the surest way to build something valuable is to build something you need
- Half a product is better than a half-assed product — do a few things well rather than many things poorly
- Embrace constraints — limited time, money, and people force creative solutions
- Be a curator, not a hoarder — your job is to say no to good ideas so the great ones can breathe
- Make tiny decisions — big decisions 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
- Less software means less to maintain, less to test, less to explain, and less to go wrong
- Focus on what will not change — speed, simplicity, reliability, and ease of use never go out of style
Product applications:
| Context | Application | Example |
|---|---|---|
| Feature prioritization | Default answer is no | A customer requests a reporting dashboard; instead, ship a CSV export that covers 90% of use cases |
| MVP scoping | Cut until it hurts, then cut more | Remove user accounts entirely for v1; use email-based magic links instead |
| Competitive strategy | Underdo, do not outdo | Competitor has 50 integrations; you ship 3 that work flawlessly |
| Preference elimination | Pick sensible defaults | Instead of 12 notification settings, ship one thoughtful default with an off switch |
| Constraint adoption | Use limits as creative fuel | Three-person team and six weeks forces you to find the simplest version that works |
Ethical boundary: Building less must serve users, not just save development time. Cut complexity, not accessibility or safety. "Less" means focused, not neglectful.
See: references/build-less.md
**核心理念：**通过主动取舍获得竞争优势。更少的功能、更少的偏好设置、更少的可变部分。不要和竞争对手逐点对齐功能，而是做得更少，但做得更好。打造你自己也需要的软件，解决你真正理解的问题。
**为什么有效：**你添加的每一个功能都有维护成本、用户认知成本和机会成本。大多数功能只有小部分用户会使用，但整个团队需要永久维护。通过少做功能，你可以保持产品聚焦、代码库可维护、团队规模精简。你也会被迫找到真正重要的部分——也就是能带来80%价值的20%功能。
核心观点：
- 先解决你自己的问题——打造你自己需要的产品，是做出有价值产品最可靠的方式
- 半个完整的产品好过一个半吊子产品——把少数事做好，好过把很多事做差
- 拥抱约束——有限的时间、资金和人力会催生创造性的解决方案
- 做 curator，不做囤积者——你的工作是对好想法说不，这样伟大的想法才有成长空间
- 做小决策——大决策难制定也难撤回，小决策可以积累动力
- 反向竞争——让竞争对手做瑞士军刀，你只做牛排刀
- 更少的代码意味着更少的维护、更少的测试、更少的说明、更少的出错可能
- 聚焦不会变化的东西——速度、简洁、可靠性、易用性永远不会过时
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 功能优先级排序 | 默认回复拒绝 | 客户要求做报表看板，你只交付能覆盖90%场景的CSV导出功能 |
| MVP范围划定 | 裁剪到觉得肉疼，然后再裁一点 | v1版本完全砍掉用户账号体系，改用邮箱魔法登录 |
| 竞争策略 | 反向做少，不做多 | 竞争对手有50个集成，你只交付3个运行完美的集成 |
| 偏好设置精简 | 选择合理的默认值 | 不要做12个通知设置，只交付一个考虑周全的默认配置加一个关闭开关 |
| 约束应用 | 把限制当作创意燃料 | 三人团队+六周周期的限制，会迫使你找到能跑通的最简单方案 |
**道德边界：**少做功能是为了服务用户，而不只是为了节省开发时间。可以裁剪复杂度，但不能裁剪可访问性和安全性。「少」意味着聚焦，而不是敷衍。
参考：references/build-less.md
2. Shaping the Work
2. 工作塑形
Core concept: Before work is given to a team, it must be shaped. Shaping means making the work rough (room to maneuver), solved (main elements figured out), and bounded (clear scope limits defined by appetite). Shaping is the critical step between a raw idea and a team project. It is done by a senior person who understands both the product and the technical landscape.
Why it works: Raw ideas are too vague — teams waste time figuring out what to build. Detailed specs are too rigid — teams become ticket-takers with no room for creative problem-solving. Shaping finds the sweet spot: enough definition to remove the biggest unknowns, enough freedom for the team to design the implementation. The appetite (how much time is this worth?) replaces traditional estimation (how long will this take?), flipping the dynamic from open-ended commitment to bounded investment.
Key insights:
- Appetite vs. estimates — start with how much time a problem is worth, not how long a solution will take
- Breadboarding maps the flow using places, affordances, and connection lines — no visual design, just structure
- Fat marker sketches are drawn at a level of abstraction that prevents bikeshedding on visual details
- Wireframes are too concrete too early — they invite pixel-level feedback before the concept is validated
- A shaped pitch has five elements: problem, appetite, solution, rabbit holes, and no-gos
- Rabbit holes are the known risks that could blow up the scope — address them in the pitch, not during the build
- No-gos explicitly define what the solution will not include — preventing scope creep by making boundaries visible
- The shaper is neither the building team nor management — it is a senior person who bridges both worlds
Product applications:
| Context | Application | Example |
|---|---|---|
| Feature design | Breadboard before mockup | Map "user invites teammate" as: Settings → Invite form → Email sent → Accept link → Dashboard |
| Scope definition | Set appetite first | "This is a 2-week appetite problem, not a 6-week one" — shapes what solution is appropriate |
| Team briefing | Hand off shaped pitches, not specs | Pitch includes problem, appetite, rough solution, rabbit holes, no-gos |
| Design fidelity | Fat marker, not pixel-perfect | Sketch on a tablet with a thick brush to keep abstraction high |
| Risk management | Call out rabbit holes in advance | "The permissions model could get complex — limit to owner/member for v1" |
Ethical boundary: Shaping must honestly bound the work. Do not define an appetite that is unrealistically small to pressure teams. The appetite should reflect the genuine value of the problem, not a desired deadline.
See: references/shaping-work.md
**核心理念：**工作交给团队之前，必须先完成塑形。塑形意味着让工作保持粗略（留调整空间）、可落地（核心元素已经想清楚）、有边界（由投入意愿定义清晰的范围限制）。塑形是 raw 想法和团队项目之间的关键步骤，由同时懂产品和技术的资深人员完成。
**为什么有效：**Raw 想法太模糊，团队会浪费时间搞清楚要做什么；详细的需求文档太僵化，团队会变成只会接 ticket 的执行者，没有创造性解决问题的空间。塑形找到了最佳平衡点：有足够的定义消除最大的不确定，也有足够的自由让团队设计实现方案。用「投入意愿（这个问题值得花多少时间）」代替传统的「评估（这个方案要花多久）」，把开放的承诺变成了有边界的投资。
核心观点：
- Appetite vs. estimates——从问题值得花多少时间出发，而不是从解决方案要花多少时间出发
- Breadboarding用页面、可操作元素和连接线梳理流程，没有视觉设计，只有结构
- Fat marker sketches的抽象程度足够高，可以避免在视觉细节上无休止争论
- 线框图太早变得太具体，在概念验证之前就会引来像素级的反馈
- 成型的提案包含五个元素：问题、投入意愿、解决方案、风险坑、明确不做的内容
- 风险坑是可能导致范围爆炸的已知风险，在提案里就明确，不要留到开发阶段处理
- 明确不做的内容会清晰定义解决方案的边界，从根源避免范围蔓延
- 塑形者既不是开发团队也不是管理层，是衔接两个群体的资深人员
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 功能设计 | 做mockup之前先做breadboarding | 将「用户邀请队友」的流程梳理为：设置页 → 邀请表单 → 发送邮件 → 接受链接 → dashboard |
| 范围定义 | 先设定投入意愿 | 「这个问题值得花2周解决，不值得花6周」——以此确定合适的解决方案 |
| 团队交底 | 交付成型的提案，不是需求文档 | 提案包含问题、投入意愿、粗略解决方案、风险坑、明确不做的内容 |
| 设计保真度 | 用fat marker，不用像素级完美 | 用粗笔触在平板上画草图，保持高抽象度 |
| 风险管理 | 提前点明风险坑 | 「权限模型可能会变复杂，v1版本只做所有者/成员两种角色」 |
**道德边界：**塑形必须诚实划定工作边界，不要设定不切实际的短投入意愿给团队施压。投入意愿应该反映问题的真实价值，而不是想要的 deadline。
参考：references/shaping-work.md
3. Betting and Cycles
3. 投注与周期
Core concept: Replace backlogs and long-term roadmaps with a betting table. Senior stakeholders review shaped pitches and bet on the ones worth building in the next six-week cycle. If work is not done in six weeks, it does not automatically continue — the circuit breaker kills it. Two-week cool-down periods between cycles give teams breathing room.
Why it works: Backlogs grow forever, create a false sense of progress, and dilute focus. The betting table forces real prioritization: with limited slots in a six-week cycle, you can only pick a handful of shaped pitches. The circuit breaker prevents zombie projects that drain morale and block fresh bets. Cool-down periods let teams fix bugs, explore ideas, and recharge — preventing the burnout that continuous sprinting creates.
Key insights:
- Backlogs are a graveyard of good intentions — abolish them; if an idea is important, it will come back
- The betting table meets at the end of each cool-down to choose work for the next cycle
- Six-week cycles are long enough for meaningful work and short enough to maintain urgency
- The circuit breaker is non-negotiable: if it is not done in six weeks, it does not ship and gets re-evaluated
- Cool-down (two weeks) is unstructured time for bugs, exploration, and small improvements
- Plan one cycle at a time — long-term roadmaps create false commitments and reduce responsiveness
- Saying no is the default — most pitches do not get bet on, and that is healthy
- Variable scope means teams cut non-essential scope to hit the fixed deadline, not the other way around
Product applications:
| Context | Application | Example |
|---|---|---|
| Roadmap replacement | Betting table each cycle | Instead of a 12-month roadmap, pick 3-4 shaped pitches every 6 weeks |
| Project scoping | Six-week maximum | Break a large initiative into independent 6-week bets rather than a multi-month project |
| Risk management | Circuit breaker kills zombies | Feature at 70% after 6 weeks? It does not ship. Re-shape and re-bet next cycle if it still matters |
| Capacity planning | Cool-down periods | Two weeks between cycles for technical debt, bug fixes, and team recovery |
| Stakeholder management | Betting creates accountability | Senior people bet their credibility on pitches — no more invisible backlog shuffling |
Ethical boundary: The circuit breaker must be applied honestly. Do not use it to kill projects that are on track but politically inconvenient. Do not use six-week limits to create unsustainable pressure. The point is focus, not speed.
See: references/betting-cycles.md
**核心理念：**用投注桌代替待办积压和长期路线图。资深 stakeholder 评审成型的提案，投注值得在下一个六周周期里做的内容。如果六周内没有做完工作，不会自动延期，断路器会终止项目。周期之间的两周冷却期给团队留出喘息空间。
**为什么有效：**待办积压会无限增长，制造虚假的进展感，稀释注意力。投注桌强制做真正的优先级排序：六周周期的名额有限，你只能选少数几个成型的提案。断路器可以避免消耗士气、阻碍新投注的僵尸项目。冷却期让团队可以修bug、探索想法、充电，避免持续 sprint 导致的 burnout。
核心观点：
- 待办积压是美好意愿的坟场——直接废掉它，如果一个想法真的重要，它会再次出现
- 投注桌在每个冷却期结束时开会，选择下一个周期的工作
- 六周周期足够完成有价值的工作，也足够短来保持紧迫感
- 断路器不可妥协：如果六周内没做完，就不发布，重新评估
- 两周冷却期是无结构化时间，用来修bug、做探索、小优化
- 一次只规划一个周期——长期路线图会制造虚假的承诺，降低响应能力
- 默认说不——大多数提案都不会被投注，这是健康的状态
- 可变范围意味着团队裁剪非核心范围来满足固定 deadline，而不是反过来
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 路线图替代 | 每个周期开投注桌 | 不用12个月路线图，每六周选3-4个成型的提案 |
| 项目范围划定 | 最长六周周期 | 把大型项目拆成独立的六周投注，而不是跨数月的大项目 |
| 风险管理 | 断路器终止僵尸项目 | 六周后功能只完成70%？不发布，如果还重要就重新塑形、下个周期再投注 |
| 容量规划 | 设置冷却期 | 周期之间留两周处理技术债务、bug修复和团队恢复 |
| 利益相关方管理 | 投注创造 accountability | 资深人员为提案投注自己的信用，再也没有看不见的待办项调整 |
**道德边界：**断路器的使用必须诚实，不要用它来砍掉进度正常但不符合政治需求的项目。不要用六周限制制造不可持续的压力，核心是聚焦，不是速度。
参考：references/betting-cycles.md
4. Small Teams and Execution
4. 小团队与执行
Core concept: Three-person teams (one designer, one or two programmers) work autonomously on shaped work. No daily standups, no project managers hovering, no status meetings. The team receives a shaped pitch with boundaries and figures out the tasks themselves. Progress is tracked with hill charts, not burndown charts or percentage-complete metrics.
Why it works: Small teams move faster because communication overhead is near zero. Three people can have a conversation; ten people need a meeting. When teams discover their own tasks from the shaped pitch, they develop real understanding of the problem rather than executing a list someone else wrote. Hill charts show the truth about where work stands — the uphill phase (figuring things out) is honest about uncertainty, and the downhill phase (executing known work) shows real progress.
Key insights:
- Three-person teams are the unit of work — one designer and one or two programmers
- The team figures out tasks by exploring the shaped pitch, not by reading a ticket list
- Hill charts have two phases: uphill (uncertainty, figuring out) and downhill (certainty, executing)
- Scopes replace tasks — group related work into named scopes that can move independently on the hill
- Meetings are toxic — use asynchronous communication by default; write it up instead of calling a meeting
- Get real: build with real HTML and real data as early as possible, not wireframes and lorem ipsum
- Launch now, iterate later — working software in users' hands beats theoretical plans in a slide deck
- Integrate design and programming from day one — no handoffs, no "design phase" followed by "dev phase"
Product applications:
| Context | Application | Example |
|---|---|---|
| Team structure | Three-person maximum | One designer + two programmers for a 6-week bet; no PM role needed |
| Progress tracking | Hill charts, not burndowns | "User Invitations" is uphill (still figuring out permissions); "Email Templates" is downhill (executing) |
| Communication | Async-first, write it up | Post a 5-minute Loom or a written update instead of scheduling a 30-minute meeting |
| Design process | Get real with HTML early | Build a working prototype in the browser on day 2, not a Figma mockup on day 5 |
| Task discovery | Team explores, not follows | Give the team the shaped pitch; they break it into scopes themselves |
Ethical boundary: Small teams must not mean overworked teams. Autonomy requires that scope is genuinely manageable. If a three-person team consistently works overtime to hit six-week deadlines, the problem is in the shaping, not the team.
See: references/small-teams-execution.md
**核心理念：**三人团队（一个设计师，一到两个程序员）自治完成已塑形的工作。没有每日站会、没有项目经理跟踪、没有进度会议。团队拿到有边界的成型提案，自己拆解任务。用hill charts跟踪进度，不用burndown charts或完成百分比指标。
**为什么有效：**小团队跑得更快，因为沟通 overhead 几乎为零。三个人可以直接对话，十个人就需要开会。当团队从成型的提案里自己拆解任务时，他们会真正理解问题，而不是执行别人写的任务列表。Hill charts能真实反映工作进度：上坡阶段（搞清楚问题）诚实展示不确定性，下坡阶段（执行已知工作）展示真实进展。
核心观点：
- 三人团队是工作单元：一个设计师加一到两个程序员
- 团队通过探索成型的提案拆解任务，不是读ticket列表
- Hill charts有两个阶段：上坡（不确定性，搞清楚问题）和下坡（确定性，执行）
- 用范围代替任务：把相关工作分组为命名范围，可以在hill上独立移动
- 会议有害：默认用异步沟通，写下来而不是开会
- 务实落地：尽早用真实HTML和真实数据开发，不用线框图和占位文本
- 现在发布，后续迭代：用户手上能运行的软件好过幻灯片里的理论方案
- 从第一天起就整合设计和开发：没有交接，没有「设计阶段」之后接「开发阶段」的流程
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 团队结构 | 最多三个人 | 一个设计师+两个程序员做六周投注，不需要PM角色 |
| 进度跟踪 | 用hill charts，不用burndown charts | 「用户邀请」处于上坡阶段（还在搞清楚权限问题），「邮件模板」处于下坡阶段（执行中） |
| 沟通 | 异步优先，写下来 | 发5分钟的Loom或文字更新，而不是安排30分钟的会议 |
| 设计流程 | 尽早用HTML落地 | 第2天就在浏览器里做可运行原型，而不是第5天做Figma mockup |
| 任务拆解 | 团队自主探索，不被动跟随 | 把成型的提案交给团队，他们自己拆成范围 |
**道德边界：**小团队不意味着团队要超负荷工作。自治的前提是范围确实可控，如果三人团队经常加班才能完成六周 deadline，问题出在塑形环节，不是团队。
参考：references/small-teams-execution.md
5. Opinionated Software and Clear Communication
5. 有主张的软件与清晰沟通
Core concept: Great software makes choices for the user instead of burying them in preferences. Every preference is a decision the team could not make — or would not make. Clear, honest copywriting reflects the same philosophy: say what you mean, skip the buzzwords, and respect the user's time. Teach everything you know openly.
Why it works: Software with too many preferences is software with no opinion. Users do not want 47 settings; they want software that works well out of the box. When you make decisions for users (pick the sensible default), you reduce cognitive load and create a more cohesive experience. The same applies to communication: clear copy builds trust, marketing-speak erodes it. And teaching your methods openly (like 37signals does with their books and blog) attracts customers who share your values.
Key insights:
- Every preference is a decision you are pushing to the user — pick the best default and ship it
- If it sounds like marketing, rewrite it — clear, honest language outperforms buzzwords
- Epicycles (adding feature on feature to fix problems created by earlier features) compound complexity
- Say no to most feature requests, even good ones — "not now" is a valid and healthy answer
- Focus on what will not change: speed, simplicity, reliability, and ease of use
- Out-teach the competition — share your philosophy, process, and knowledge openly
- Sell your by-products — the things you learn while building are valuable to others (books, blog posts, tools)
- Your app's interface copy is your best marketing — every label, error message, and confirmation is a chance to build trust
Product applications:
| Context | Application | Example |
|---|---|---|
| Feature requests | Default answer is no | "Thanks for the suggestion. We're not planning this right now." — no apology, no promise |
| UI copy | Plain language, no buzzwords | "Your file is saved" instead of "Your asset has been successfully persisted to the cloud" |
| Preferences | Eliminate, choose defaults | Remove the timezone selector; detect it from the browser. Remove the theme picker; ship one good theme |
| Error messages | Honest and helpful | "We couldn't send that email. Check the address and try again." — not "An unexpected error occurred" |
| Documentation | Teach openly | Blog about how you build, what you decided, and why — even if competitors read it |
| Marketing | Be honest, share your philosophy | "Basecamp is not for everyone. Here's who it's for and who it's not for." |
Ethical boundary: Being opinionated must not mean being dismissive of user needs. Listen carefully to what users struggle with, then curate thoughtfully. Opinionated means you have a point of view — not that you ignore feedback.
See: references/opinionated-software.md, references/ux-ui-copy.md
**核心理念：**好的软件会替用户做选择，而不是扔一堆偏好设置给用户。每一个偏好设置都是团队不想或者不敢做的决策。清晰诚实的文案也体现了同样的理念：说你真正想表达的，不用行话，尊重用户的时间。公开分享你知道的所有内容。
**为什么有效：**偏好设置太多的软件就是没有自己主张的软件。用户不想要47个设置，他们想要开箱即用的好产品。当你替用户做决策（选合理的默认值），你降低了认知负荷，创造了更统一的体验。沟通也是一样：清晰的文案建立信任，营销话术消耗信任。公开分享你的方法（就像37signals在书和博客里做的那样）会吸引和你价值观一致的客户。
核心观点：
- 每一个偏好设置都是你推给用户的决策——选最好的默认值然后发布
- 如果听起来像营销话术，重写——清晰诚实的语言比行话效果好
- 叠buff（为了修复之前功能带来的问题不断加新功能）会让复杂度指数级增长
- 对大多数功能需求说不，哪怕是好需求——「现在不做」是合理且健康的回复
- 聚焦不会变化的东西：速度、简洁、可靠性、易用性
- 比竞争对手输出更多教学内容——公开分享你的理念、流程、知识
- 售卖副产品：你做产品过程中学到的东西对其他人也有价值（书、博客、工具）
- 你产品的界面文案是最好的营销——每个标签、错误提示、确认文案都是建立信任的机会
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 功能需求处理 | 默认回复拒绝 | 「感谢你的建议，我们目前没有相关计划」——不用道歉，不用承诺 |
| UI文案 | 直白语言，不用行话 | 用「你的文件已保存」代替「你的资产已成功持久化到云端」 |
| 偏好设置 | 精简，选默认值 | 去掉时区选择器，从浏览器自动检测；去掉主题选择器，只发布一个优质主题 |
| 错误提示 | 诚实且有帮助 | 用「我们没能发送邮件，请检查地址再试」代替「发生了未知错误」 |
| 文档 | 公开教学 | 写博客分享你怎么做产品、做了什么决策、为什么这么做——哪怕竞争对手也会读 |
| 营销 | 诚实，分享你的理念 | 「Basecamp不是适合所有人的产品，这里说明它适合谁、不适合谁」 |
**道德边界：**有主张不意味着忽略用户需求。认真倾听用户的痛点，然后谨慎取舍。有主张意味着你有明确的立场，而不是你无视反馈。
参考：references/opinionated-software.md, references/ux-ui-copy.md
Common Mistakes
常见错误
| Mistake | Why It Fails | Fix |
|---|---|---|
| Maintaining a backlog | Backlogs grow forever, create false sense of progress, and dilute focus | Abolish the backlog; bet on shaped pitches each cycle |
| Estimating instead of setting appetite | Estimates grow to fill available time and invite negotiation over hours | Start with appetite: "How much time is this problem worth?" |
| Pixel-perfect mockups before shaping | Too concrete too early; invites bikeshedding and kills creative exploration | Use breadboards and fat marker sketches at the right level of abstraction |
| Extending a six-week cycle | Zombie projects drain morale, block new bets, and teach teams that deadlines are fake | Apply the circuit breaker: if it is not done in six weeks, it does not ship |
| Adding preferences instead of deciding | Every preference adds complexity for all users to serve a few; compounds over time | Pick the best default and ship it; revisit only if data shows the default fails most users |
| Daily standups and status meetings | Interrupt maker flow, create reporting overhead, and slow teams down | Use hill charts for visibility and async updates for communication |
| Saying yes to good feature requests | Good features still add complexity; most are not essential for the core job | Default to no; only bet on what matters most this cycle |
| Planning more than one cycle ahead | Long-term plans become stale commitments that reduce responsiveness to what you learn | Plan one cycle at a time; stay responsive to new information |
| 错误 | 失败原因 | 修复方案 |
|---|---|---|
| 维护待办积压 | 待办会无限增长，制造虚假进展感，稀释注意力 | 废掉待办积压，每个周期对成型的提案投注 |
| 做评估而不是设定投入意愿 | 评估会膨胀到填满可用时间，还会引发工时谈判 | 从投入意愿出发：「这个问题值得花多少时间？」 |
| 塑形之前就做像素级mockup | 太早变得太具体，会引发无意义的细节争论，扼杀创造性探索 | 在合适的抽象阶段用breadboarding和fat marker sketches |
| 延长六周周期 | 僵尸项目消耗士气，阻碍新投注，让团队觉得 deadline 是假的 | 执行断路器：六周没做完就不发布 |
| 加偏好设置而不是做决策 | 每个偏好设置都会为了少数用户给所有用户增加复杂度，长期会累积 | 选最好的默认值发布，只有数据证明默认值对大多数用户无效时再调整 |
| 每日站会和进度会议 | 打断创作者的工作流，制造汇报 overhead，拖慢团队 | 用hill charts做进度可视化，用异步更新做沟通 |
| 对好的功能需求说yes | 好功能也会增加复杂度，大多数对核心价值来说不是必需的 | 默认说不，只投注当前周期最重要的内容 |
| 提前规划超过一个周期的内容 | 长期计划会变成过时的承诺，降低对新信息的响应能力 | 一次只规划一个周期，对新信息保持响应 |
Quick Diagnostic
快速诊断
| Question | If No | Action |
|---|---|---|
| Is there a fixed time constraint on this work? | Scope will expand indefinitely | Set a six-week appetite before starting |
| Has the work been shaped (rough, solved, bounded)? | Team will discover scope problems mid-build | Shape the pitch: define problem, appetite, solution, rabbit holes, no-gos |
| Can a team of 2-3 people do this? | Too big; needs decomposing | Break into independent scoped pieces that each fit a small team |
| Have you said no to at least 5 things this cycle? | Probably building too much | Review the betting table and cut ruthlessly |
| Is the team figuring out their own tasks? | Micromanaging; team is not empowered | Hand off shaped pitches, not task lists |
| Are you tracking progress with hill charts? | False precision masking real uncertainty | Switch to hill charts: uphill (figuring out) vs. downhill (executing) |
| Is there a cool-down after this cycle? | Teams will burn out; no time for cleanup | Schedule two weeks of unstructured time between cycles |
| Does your software have a clear opinion on this feature? | Deferring decisions to users via preferences | Pick the best default and remove the setting |
| 问题 | 如果答案为否 | 行动 |
|---|---|---|
| 这项工作有固定的时间约束吗？ | 范围会无限膨胀 | 开始之前设定六周的投入意愿 |
| 工作已经完成塑形（粗略、可落地、有边界）吗？ | 团队会在开发中途发现范围问题 | 完成提案塑形：定义问题、投入意愿、解决方案、风险坑、明确不做的内容 |
| 2-3人的团队可以完成这项工作吗？ | 太大，需要拆分 | 拆成独立的、适合小团队的范围块 |
| 这个周期你已经对至少5件事说不了吗？ | 可能做得太多了 | 评审投注桌，无情裁剪 |
| 团队自己拆解任务吗？ | 微观管理，团队没有被授权 | 交付成型的提案，不是任务列表 |
| 你用hill charts跟踪进度吗？ | 虚假的精确性掩盖了真实的不确定性 | 改用hill charts：上坡（搞清楚问题）vs 下坡（执行） |
| 这个周期之后有冷却期吗？ | 团队会 burnout，没有时间做清理 | 周期之间安排两周的无结构化时间 |
| 你的软件对这个功能有明确的主张吗？ | 通过偏好设置把决策推给用户 | 选最好的默认值，去掉设置项 |
Reference Files
参考文件
- references/build-less.md — The philosophy of less: underdoing the competition, embracing constraints, curation over accumulation, and the art of cutting scope
- references/shaping-work.md — The shaping process: breadboarding, fat marker sketches, appetite setting, the pitch format, and identifying rabbit holes
- references/betting-cycles.md — Six-week cycles, the betting table, the circuit breaker, cool-down periods, and why backlogs must die
- references/small-teams-execution.md — Three-person teams, hill charts, async communication, getting real with HTML, and launch-first thinking
- references/opinionated-software.md — Defaults over preferences, clear copywriting, saying no to feature requests, and teaching openly
- references/ux-ui-copy.md — The 37signals approach to UX, UI design, and interface copywriting: browser-first design, visual hierarchy, clear copy rules, empty states, error messages, and anti-patterns
- references/case-studies.md — Three scenarios applying 37signals principles: adopting Shape Up, resisting feature creep, and replacing status meetings with hill charts
- references/build-less.md — 少做的哲学：反向竞争、拥抱约束、精选而非囤积、裁剪范围的艺术
- references/shaping-work.md — 塑形流程：breadboarding、fat marker sketches、投入意愿设定、提案格式、风险坑识别
- references/betting-cycles.md — 六周周期、投注桌、断路器、冷却期、为什么要废掉待办积压
- references/small-teams-execution.md — 三人团队、hill charts、异步沟通、HTML优先落地、先发布思维
- references/opinionated-software.md — 默认值优先于偏好设置、清晰文案、对功能需求说不、公开教学
- references/ux-ui-copy.md — 37signals的UX、UI设计、界面文案方法：浏览器优先设计、视觉层级、清晰文案规则、空状态、错误提示、反模式
- references/case-studies.md — 三个应用37signals原则的场景：落地Shape Up、抵抗功能蔓延、用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
- "Getting Real" 作者：Jason Fried & David Heinemeier Hansson
- "Rework" 作者：Jason Fried & David Heinemeier Hansson
- "Shape Up: Stop Running in Circles and Ship Work that Matters" 作者：Ryan Singer
- "It Doesn't Have to Be Crazy at Work" 作者：Jason Fried & David Heinemeier Hansson
- "Remote: Office Not Required" 作者：Jason Fried & David Heinemeier Hansson
About the Authors
关于作者
Jason Fried is the co-founder and CEO of 37signals, the company behind Basecamp and HEY. He has been building web-based software since the mid-1990s and is a prominent advocate for calm companies, remote work, and product simplicity. Fried co-authored Getting Real, Rework, Remote, and It Doesn't Have to Be Crazy at Work. He is known for his contrarian stance against venture capital, growth-at-all-costs culture, and unnecessary complexity in both software and business.
David Heinemeier Hansson (DHH) is the co-founder and CTO of 37signals and the creator of Ruby on Rails, one of the most influential web application frameworks ever built. Rails was extracted directly from Basecamp's codebase — a textbook example of the 37signals philosophy of building real software first and extracting reusable tools second. DHH co-authored Getting Real, Rework, Remote, and It Doesn't Have to Be Crazy at Work. He is known for challenging industry orthodoxies around microservices, TypeScript, cloud computing, and startup culture.
Ryan Singer is the former Head of Strategy at 37signals, where he spent over fifteen years shaping products and refining the development process that became Shape Up. His experience leading product work at Basecamp gave him unique insight into what makes small teams effective and how to structure work for maximum autonomy. Singer wrote Shape Up as a free online book (basecamp.com/shapeup), later published in print, codifying the methodology that 37signals had practiced for years.
Jason Fried是37signals的联合创始人兼CEO，37signals是Basecamp和HEY的母公司。他从90年代中期就开始开发web软件，是冷静公司、远程工作、产品简洁理念的知名倡导者。Fried联合创作了《Getting Real》、《Rework》、《Remote》和《It Doesn't Have to Be Crazy at Work》。他以反对风险投资、不惜一切代价增长的文化、软件和商业领域不必要的复杂性的逆向立场闻名。
**David Heinemeier Hansson (DHH)**是37signals的联合创始人兼CTO，也是史上最有影响力的web应用框架之一Ruby on Rails的创造者。Rails是直接从Basecamp的代码库中提取出来的，是37signals「先做真实软件，再提取可复用工具」理念的典型案例。DHH联合创作了《Getting Real》、《Rework》、《Remote》和《It Doesn't Have to Be Crazy at Work》。他以挑战微服务、TypeScript、云计算、创业文化等行业正统观念闻名。
Ryan Singer是37signals的前策略负责人，他在那里花了超过十五年的时间塑形产品、打磨后来成为Shape Up的开发流程。他在Basecamp领导产品工作的经验让他对小团队如何高效、如何搭建工作流程最大化自治有独特的洞见。Singer先是在basecamp.com/shapeup发布了免费在线版《Shape Up》，后来出版了纸质版，将37signals实践了多年的方法论系统化。