# Betting and Cycles

## Table of Contents

- [Why Not Backlogs](#why-not-backlogs)
- [The Betting Table](#the-betting-table)
- [Six-Week Cycles](#six-week-cycles)
- [The Circuit Breaker](#the-circuit-breaker)
- [Cool-Down Periods](#cool-down-periods)
- [Fixed Time, Variable Scope](#fixed-time-variable-scope)
- [Cycle Planning in Practice](#cycle-planning-in-practice)
- [When to Use Small Batches](#when-to-use-small-batches)

## Why Not Backlogs

A backlog is a growing list of ideas, requests, and tasks that theoretically represent future work. In practice, backlogs create more problems than they solve.

**The problems with backlogs:**

1. **Backlogs grow forever.** Items are added faster than they are completed. A 200-item backlog is not a plan — it is an anxiety list.

2. **Backlogs create false obligations.** Once an idea is in the backlog, it feels like a commitment. Teams spend time grooming, prioritizing, and re-prioritizing items that may never be built.

3. **Backlogs dilute focus.** When everything is in the backlog, nothing stands out. The important is buried alongside the trivial.

4. **Backlogs discourage fresh thinking.** Instead of evaluating each cycle on its own merits, teams default to pulling from the backlog — recycling old ideas instead of responding to current reality.

5. **Backlogs are emotionally draining.** Team members see hundreds of items and feel perpetually behind. The list never gets shorter. Morale suffers.

**The 37signals alternative:** No backlogs. Ideas are either shaped into pitches and bet on for the next cycle, or they are let go. If an idea is truly important, it will come back — someone will bring it up again, or the problem will resurface. If it does not come back, it was not important enough to build.

**But what about good ideas we might forget?** Some ideas do deserve to be saved. The key is who saves them and how. Individual team members can keep their own informal lists. A senior person can maintain a short list of potential pitches to shape. But there is no shared, groomed backlog that creates obligations for the team.

## The Betting Table

The betting table is a meeting that happens at the end of each cool-down period, before the next cycle begins. A small group of senior stakeholders reviews shaped pitches and decides which ones to bet on.

**Who attends the betting table:**

- The CEO or product owner (final decision authority)
- A senior technical person (can assess feasibility)
- A senior designer or product strategist (can assess solution quality)
- Optionally, one or two other senior people with relevant context

This is not a democratic process. The betting table is small by design — 2-4 people, never more. Too many voices leads to compromise, and compromise produces mediocre bets.

**How the betting table works:**

1. **Review pitches.** The group reads the shaped pitches (written documents, not presentations). Each pitch takes 5-10 minutes to review.

2. **Discuss trade-offs.** For each pitch, discuss: Is this the right problem? Is the appetite appropriate? Does the solution address the problem well enough? Are the rabbit holes handled?

3. **Place bets.** Decide which pitches get a team for the next cycle. A bet means committing a team for 6 weeks. This is real commitment — once a bet is placed, the team is protected from interruption.

4. **Say no to the rest.** Most pitches do not get bet on. This is healthy and expected. The rejected pitches are not added to a backlog — they are simply not bet on this cycle.

**What makes a good bet:**

| Factor | Strong Bet | Weak Bet |
|--------|-----------|----------|
| Problem clarity | Specific, concrete user scenario | Vague goal ("improve engagement") |
| Solution quality | Shaped, with breadboards and no-gos | Half-baked idea or unshaped request |
| Appetite match | Solution clearly fits the time budget | Solution seems too big or too uncertain |
| Strategic fit | Aligns with current business priorities | Nice-to-have with no urgency |
| Risk level | Rabbit holes identified and addressed | Major unknowns unresolved |

## Six-Week Cycles

Six weeks is the standard cycle length at 37signals. It is long enough for a small team to build something meaningful, and short enough to maintain urgency and limit the damage of a wrong bet.

**Why six weeks, not two-week sprints:**

- **Two weeks is too short** for meaningful work. Teams spend a disproportionate amount of time on planning, estimating, and ceremony relative to actual building.
- **Six weeks is long enough** for a designer and one or two programmers to build a significant feature from start to finish, including design, code, testing, and polish.
- **Six weeks creates natural urgency.** In the first week or two, the team explores the problem and discovers tasks. By week three, they should be executing. By week five, they should be cutting scope and converging. Week six is finish and polish.

**Why not longer than six weeks:**

- **Projects longer than six weeks lose urgency.** The deadline feels distant, and teams defer hard decisions.
- **Longer timelines increase risk.** The more time you invest before shipping, the more you lose if the bet was wrong.
- **Large projects should be broken into independent six-week bets.** If a feature genuinely needs 12 weeks, shape it into two independent six-week pieces, each of which delivers value on its own.

**The rhythm of a six-week cycle:**

| Week | Phase | Activity |
|------|-------|----------|
| 1 | Exploration | Team reads the pitch, explores the problem, discovers scopes |
| 2 | Exploration → Building | Scopes take shape, first code and design emerge |
| 3 | Building | Core functionality coming together, biggest uncertainties resolved |
| 4 | Building | Integration, edge cases, testing begins |
| 5 | Convergence | Scope cutting begins — what is not essential gets cut |
| 6 | Convergence → Ship | Polish, final testing, deployment |

## The Circuit Breaker

The circuit breaker is the most important and most controversial element of the 37signals methodology. It is simple: if a project is not done at the end of its six-week cycle, it does not automatically continue. It stops.

**How the circuit breaker works:**

1. A team is given a six-week bet.
2. At the end of six weeks, the work is either done or it is not.
3. If it is done, it ships.
4. If it is not done, it does not get an automatic extension. The project is paused and returned to the shaping table.
5. If the problem is still important, a new pitch is shaped (possibly re-scoped) and brought to the next betting table. It competes with other pitches on its merits.

**Why the circuit breaker exists:**

- **Prevents zombie projects.** Without a circuit breaker, projects in trouble get extensions, then more extensions, consuming resources while delivering diminishing returns.
- **Forces honest shaping.** If you know the circuit breaker is real, you shape more carefully. You cut scope more aggressively. You identify rabbit holes more diligently.
- **Protects team morale.** Struggling teams are freed from death marches. A fresh start with better shaping is more humane and more effective than grinding through.
- **Keeps the betting table honest.** When bets that do not pay off are stopped, stakeholders take the betting process more seriously.

**When to invoke the circuit breaker:**

- The team has significant unfinished work that cannot be completed with a few extra days
- The core approach turned out to be wrong and needs re-thinking
- New information has changed the value of the project
- The team is demoralized and grinding rather than building with momentum

**When not to invoke it:**

- The work is 90%+ complete and needs only a few days of polish — some flexibility is reasonable
- External dependencies (not the team's fault) caused delays — address the dependency issue separately

**Common objections and responses:**

| Objection | Response |
|-----------|----------|
| "We'll lose all the work we did" | The code and knowledge remain. The next pitch can build on what was learned. |
| "It will demoralize the team" | Extending a struggling project is more demoralizing. A fresh start is a gift. |
| "We're so close, just one more week" | If one more week would fix it, the team would have found that scope cut during week 5. |
| "The customer is waiting" | Better to re-shape and deliver something good than to ship something half-finished. |

## Cool-Down Periods

Between every six-week cycle, there is a two-week cool-down period. This is not vacation time, but it is unstructured time — no assigned projects, no obligations, no pressure.

**What happens during cool-down:**

- **Bug fixes.** Small bugs that accumulated during the cycle get addressed.
- **Exploration.** Team members pursue ideas that interest them — potential future pitches, new technology experiments, side projects.
- **Technical maintenance.** Dependency updates, infrastructure improvements, small refactors.
- **Recovery.** After six weeks of focused building, people need time to decompress and reset.

**Why cool-down matters:**

- **Prevents burnout.** Back-to-back cycles with no breaks create unsustainable pace.
- **Creates slack for emergencies.** If something urgent arises, the cool-down absorbs it without disrupting a cycle.
- **Generates fresh ideas.** Unstructured time produces the insights and experiments that become future pitches.
- **Maintains quality.** Technical debt accumulates during focused cycles; cool-down is when it gets addressed.

**Cool-down is also when the betting table meets.** Senior people use the cool-down to review shaped pitches, discuss priorities, and decide what to bet on for the next cycle.

## Fixed Time, Variable Scope

This is the fundamental inversion that makes the 37signals methodology work. Traditional projects fix the scope and let the timeline flex. Shape Up fixes the timeline and lets the scope flex.

**How scope flexing works:**

1. A team receives a shaped pitch with a six-week appetite.
2. During weeks 1-2, they explore the pitch and discover scopes (named chunks of work).
3. During weeks 3-4, they build the core scopes.
4. During weeks 5-6, they evaluate remaining scopes. Nice-to-haves that do not fit are cut. Must-haves get the remaining time.
5. At the end of week 6, whatever is done ships. Whatever was cut was either not essential or can be addressed in a future bet.

**What makes scope cutting work:**

- **The pitch defines what is essential.** The shaped solution identifies the core problem and the core flow. Everything else is negotiable.
- **No-gos set explicit boundaries.** Things that are already excluded in the pitch cannot creep back in.
- **The team has autonomy.** Because the team discovered their own scopes, they understand which ones are essential and which are nice-to-have. They can make intelligent cut decisions.

**The beauty of variable scope:** When you fix the time and flex the scope, every bet has a bounded downside. The worst case is six weeks of work with a reduced scope shipped. The best case is the full solution in six weeks. Either way, the team moves on to the next cycle with a fresh start.

## Cycle Planning in Practice

**Before the cycle (cool-down period):**

1. Shapers prepare pitches for problems worth solving
2. Pitches are shared as written documents for asynchronous review
3. The betting table meets to review pitches and place bets
4. Bets are communicated to teams with the full shaped pitch

**During the cycle (six weeks):**

1. Week 1: Team reads the pitch, explores the territory, identifies scopes
2. Week 2: Scopes solidify, uphill work on biggest unknowns begins
3. Weeks 3-4: Core building, scopes move downhill, integration happens
4. Week 5: Scope cutting decisions, convergence begins
5. Week 6: Polish, testing, deployment

**After the cycle:**

1. Work ships (or the circuit breaker fires)
2. Cool-down begins — two weeks of unstructured time
3. The cycle repeats

## When to Use Small Batches

Not everything needs a six-week cycle. Small batches (1-2 week projects) are appropriate for:

- Bug fixes that need more than a quick patch
- Small improvements that users have been requesting
- Experiments or proofs of concept
- Internal tooling improvements

**How small batches fit the cycle:**

- Small batches are also bet on at the betting table
- Multiple small batches can run in a single cycle (one team does 3-4 small projects in six weeks)
- Small batches still have a fixed time constraint — 1-2 weeks per project
- The circuit breaker still applies — if a "1-week project" is not done in 1 week, stop and re-evaluate

**The key distinction:** Small batches are for work that is already well-understood and does not need extensive shaping. If a small project keeps growing, it probably needs to be shaped as a full six-week bet instead.

# Build Less: The Philosophy of Deliberate Omission

## Table of Contents

- [The Core Argument](#the-core-argument)
- [Underdo the Competition](#underdo-the-competition)
- [Solve Your Own Problem](#solve-your-own-problem)
- [Embrace Constraints](#embrace-constraints)
- [Be a Curator](#be-a-curator)
- [Half a Product, Not a Half-Assed Product](#half-a-product-not-a-half-assed-product)
- [Focus on What Won't Change](#focus-on-what-wont-change)
- [The Feature Audit](#the-feature-audit)
- [Practical Application](#practical-application)

## The Core Argument

Most software fails not because it does too little, but because it does too much. Every feature added to a product carries hidden costs: maintenance burden, cognitive load for users, increased testing surface, documentation overhead, and opportunity cost. The 37signals philosophy inverts the default: instead of asking "What should we add?", ask "What can we leave out?"

This is not minimalism for its own sake. It is a strategic choice rooted in the reality of building products with small teams and limited resources. When you build less, you can build better. When you maintain less, you can move faster. When users have fewer choices, they make decisions more confidently.

Getting Real calls this "less software." Rework calls it "underdoing the competition." Both mean the same thing: the constraint of less is not a limitation — it is the competitive advantage.

## Underdo the Competition

The instinct when facing a competitor with more features is to match them. This is a trap. Feature parity is an arms race that favors incumbents with bigger teams and deeper pockets. The 37signals alternative: do less, but do it so well that the simplicity itself becomes the selling point.

**How underdoing works:**

- Competitor has 50 integrations? You ship 3 that work flawlessly and require zero configuration.
- Competitor has a full project management suite? You ship task lists with clear deadlines and nothing else.
- Competitor has 20 report types? You ship one report that answers the question 80% of users actually have.

Underdoing is not laziness. It requires harder decisions than overdoing. You must understand which 20% of functionality delivers 80% of the value, and have the discipline to ship only that.

**The psychology of underdoing:** Users experience feature overload as anxiety. A product with fewer, better features feels more trustworthy than one with dozens of half-implemented ones. Simplicity signals confidence — it says "we know what matters."

**When underdoing fails:** Underdoing fails when you cut core functionality, not peripheral features. The key is understanding the essential job your product does. A project management tool can skip Gantt charts but cannot skip task assignment. Know the job, then strip everything that does not directly serve it.

## Solve Your Own Problem

The surest way to build something valuable is to build something you need yourself. When you are your own user, you understand the problem intimately. You do not need extensive user research to know if a feature works — you use it every day. You do not need a PM to prioritize — your own frustration tells you what matters.

**Why self-use matters:**

- **Faster feedback loops.** You notice problems immediately because you experience them.
- **Authentic understanding.** You know the difference between nice-to-have and must-have because you feel it.
- **Reduced research overhead.** User interviews supplement your understanding rather than being your only source.
- **Better taste.** You develop strong opinions about how things should work because you live with the consequences.

Basecamp was built because 37signals needed a project management tool for their own client work. Ruby on Rails was extracted from Basecamp's codebase. HEY was built because they were frustrated with existing email clients. In each case, the product existed to solve a real problem the team experienced daily.

**The limitation:** Solving your own problem works best when your problem is shared by many others. It fails when your use case is too niche or idiosyncratic. The check: would at least a few thousand other people recognize this problem as their own?

## Embrace Constraints

Constraints — limited time, limited budget, limited people — are typically viewed as obstacles. The 37signals philosophy treats them as creative fuel. When you cannot do everything, you must find the essential version. When you have three people instead of thirty, you cannot afford unnecessary complexity. When you have six weeks instead of six months, you must cut to what matters.

**Types of constraints and their creative benefits:**

| Constraint | What It Forces | Creative Benefit |
|-----------|----------------|-----------------|
| Small team (2-3 people) | No specialization overhead, direct communication | Every person understands the whole; decisions happen fast |
| Fixed time (6 weeks) | Cannot build everything | Must find the simplest version that delivers value |
| No outside funding | Must be profitable early | Forces focus on features users will pay for, not vanity metrics |
| No dedicated PM role | Team owns decisions | No telephone game between decision-makers and builders |
| Simple technology stack | Cannot over-engineer | Solutions are maintainable and debuggable by the whole team |

**The paradox of constraints:** Teams with unlimited resources often ship slower and worse than teams with tight constraints. Abundance breeds indecision — when you can do anything, you debate endlessly about what to do. Scarcity breeds action — when you can only do one thing, you pick it and move.

## Be a Curator

Building software requires a curator — someone who decides what stays and what goes. Like a museum curator who selects which pieces belong in an exhibit, a product curator decides which features belong in the product. The curator's most important tool is the word "no."

**What curators do:**

- **Say no by default.** The default response to any feature request, any idea, any suggestion is no. Only the ideas that keep coming back, that solve real problems, that fit the product's opinion get through.
- **Remove, not just add.** Curators periodically audit the product and remove features that no longer earn their place. If a feature is rarely used and adds maintenance cost, it goes.
- **Maintain coherence.** A product with 100 well-curated features feels simple. A product with 20 random features feels complex. Coherence comes from having a clear opinion about what the product is for.
- **Resist epicycles.** An epicycle is a feature added to fix a problem caused by an earlier feature. Epicycles compound complexity. When you notice an epicycle forming, remove the root cause rather than adding another layer.

**The feature request trap:** Users request features that solve their immediate problem without considering the systemic cost. "Just add an option for X" sounds simple but adds one more preference, one more test path, one more thing to document. The curator's job is to understand the underlying need and find a solution that serves it without adding complexity.

## Half a Product, Not a Half-Assed Product

This is the most frequently quoted 37signals principle, and the most frequently misunderstood. It does not mean "ship something broken." It means: deliberately choose to build a complete, polished version of half the features rather than a half-finished version of all the features.

**What "half a product" looks like:**

- Every feature that ships works correctly, is well-designed, and is properly documented
- The product does fewer things but does each one with care and attention
- Users can accomplish the core job without workarounds or missing pieces
- The product feels finished, not like a beta

**What "half-assed" looks like:**

- Many features exist but most are partially implemented or buggy
- The product technically has a feature checklist but users hit walls constantly
- Edge cases are unhandled, error states are unhelpful, and flows are inconsistent
- The product feels unfinished despite being feature-rich on paper

**The decision framework:** Before adding a feature, ask: "If we add this, can we do it completely and well within our constraints?" If the answer is no, do not add it. A missing feature is invisible. A broken feature is visible and damaging.

## Focus on What Won't Change

Rework makes a sharp distinction between what changes (trends, technologies, competitors' features) and what does not change (speed, simplicity, reliability, ease of use, quality). The 37signals bet: invest in what will not change, because those investments compound forever.

**What does not change:**

- Users want software that is fast
- Users want software that is simple to understand
- Users want software that works reliably
- Users want clear communication (no jargon, no hidden surprises)
- Users want to accomplish their task with minimum friction

**What changes constantly:**

- Technology stacks and frameworks
- Design trends and visual styles
- Competitor feature sets
- Market narratives and buzzwords

Building on what does not change means your investment appreciates. Building on what changes means your investment depreciates.

## The Feature Audit

Periodically audit your product to identify features that no longer earn their place. Use this decision matrix:

| Feature State | Usage | Maintenance Cost | Action |
|--------------|-------|-----------------|--------|
| Core — defines the product | High | Any | Keep and invest |
| Useful — supports the core job | Moderate | Low | Keep |
| Useful — supports the core job | Moderate | High | Simplify or rebuild |
| Marginal — nice-to-have | Low | Low | Keep for now, monitor |
| Marginal — nice-to-have | Low | High | Remove |
| Legacy — served a past need | Minimal | Any | Remove |
| Epicycle — fixes problems from other features | Any | Any | Remove root cause instead |

**How to run the audit:**

1. List every feature in the product
2. Classify each by usage level and maintenance cost
3. Identify epicycles — features that exist only because of other features
4. Propose removals and simplifications
5. Ship the leaner version and measure impact

## Practical Application

**For product managers:** When prioritizing, start by asking "What can we remove?" before "What should we add?" Every removal simplifies the product for all users. Every addition complicates it for all users.

**For designers:** Design the simplest possible version first. Add elements only when their absence causes a real problem, not a theoretical one. If you are designing preferences, stop and ask which default would work for 80% of users.

**For engineers:** Resist the urge to build for hypothetical future requirements. Build what is needed now, build it well, and trust that you can extend it later if the need materializes. The best code is code you do not write.

**For founders:** Your competitive advantage is not features — it is focus. The company with fewer features and a clearer opinion will always out-execute the company trying to be everything to everyone.

# Case Studies: 37signals Principles in Practice

## Table of Contents

- [Case Study 1: From Scrum to Shape Up](#case-study-1-from-scrum-to-shape-up)
- [Case Study 2: Resisting Feature Creep](#case-study-2-resisting-feature-creep)
- [Case Study 3: Replacing Status Meetings with Hill Charts](#case-study-3-replacing-status-meetings-with-hill-charts)
- [Key Takeaways](#key-takeaways)

## Case Study 1: From Scrum to Shape Up

### Context

A 25-person B2B SaaS company builds project management software for construction firms. They have been running two-week Scrum sprints for three years. The team consists of 4 product managers, 12 engineers, 3 designers, and 6 people in other roles (QA, DevOps, support).

### The Problems

**Sprint planning consumed 20% of productive time.** Every two weeks, the team spent a full day on sprint planning: grooming the backlog, estimating story points, debating priorities, assigning tasks. With two-week sprints, this meant one day out of every ten was spent on ceremony rather than building.

**The backlog had 847 items.** Over three years, the backlog had grown from a focused list to an unmanageable graveyard. The team spent hours each month grooming items they would never build. The backlog created a constant sense of being behind — there was always more to do than could ever be done.

**Teams did not feel ownership.** Engineers received assigned tasks with detailed acceptance criteria. They executed the tasks but did not feel connected to the problems they were solving. Designer mockups were handed off to engineers who implemented them without understanding the design decisions. The result: technically correct but uninspired work.

**Projects regularly overran.** Despite careful estimation with story points, projects consistently took 1.5x to 3x longer than estimated. Extensions were the norm. "One more sprint" became a running joke.

### The Transition

**Phase 1: Abolish the backlog (Week 1)**

The product team exported the backlog to a spreadsheet (for reference, not obligation) and deleted it from the project management tool. The emotional reaction was mixed: some team members felt liberated, others felt anxious about losing their "to-do list." The leadership communicated clearly: "If something is important, it will come back. If it doesn't come back, we didn't need it."

**Phase 2: Learn to shape (Weeks 2-6)**

The two most senior product people (a PM and a designer) spent four weeks learning to shape. They read Shape Up, practiced breadboarding, and shaped three pitches as exercises. Key learnings:
- Shaping is harder than it looks — it requires holding business context, user needs, and technical reality simultaneously
- The appetite concept was the biggest mental shift: "How much is this worth?" instead of "How long will this take?"
- Breadboarding felt awkward at first but proved effective at clarifying flows without getting stuck on visual details

**Phase 3: First six-week cycle (Weeks 7-12)**

Three teams of three (one designer + two engineers) were formed. Each team received one shaped pitch. The remaining engineers handled small batch work (bug fixes, minor improvements) during the same cycle.

Results of the first cycle:
- Two of three teams shipped successfully within six weeks
- One team hit the circuit breaker — their project was not done and was paused
- The team that hit the circuit breaker initially resisted, but after reflecting, agreed the pitch needed reshaping (the rabbit holes were larger than anticipated)
- Total ceremony time dropped from 20% to approximately 3% (one betting table meeting every 8 weeks)

**Phase 4: Iterate and stabilize (Cycles 2-4)**

Over the next three cycles (18 weeks), the company refined their approach:
- Shaping improved — rabbit holes were caught earlier, appetites were more realistic
- Teams learned to cut scope proactively rather than requesting extensions
- Hill charts replaced standup meetings — the team posted updates twice per week
- The circuit breaker fired once more, and the team handled it without drama

### Results After 6 Months

| Metric | Before (Scrum) | After (Shape Up) |
|--------|---------------|-----------------|
| Planning overhead | ~20% of time | ~3% of time |
| Backlog size | 847 items | None (abolished) |
| Projects completed on time | ~40% | ~75% (within fixed cycles) |
| Team satisfaction (survey) | 6.2/10 | 8.1/10 |
| Features shipped per quarter | ~8 | ~10 (with better quality) |
| Time spent in meetings | ~8 hrs/week/person | ~2 hrs/week/person |

### Lessons Learned

1. **The backlog deletion was the hardest step emotionally but the most impactful practically.** Once the list was gone, the team stopped feeling perpetually behind.
2. **Shaping is a skill that takes practice.** The first shaped pitches were too vague. By cycle 3, they were consistently high quality.
3. **The circuit breaker must be applied consistently.** When the team first hit it, there was pressure to extend. Holding the line established credibility.
4. **Not every team adapts at the same speed.** Some engineers thrived with autonomy immediately; others needed a cycle or two to adjust to discovering their own tasks.

## Case Study 2: Resisting Feature Creep

### Context

A 10-person startup builds an email marketing tool for small businesses. After two years, the product has grown from a simple "create and send newsletters" tool to a complex platform with automation workflows, A/B testing, landing page builder, CRM, and advanced analytics. The team is struggling to maintain everything and shipping new features has slowed to a crawl.

### The Problems

**Every customer conversation added features.** Sales calls ended with "They'd sign up if we had X." Support tickets became feature requests. The team treated every request as a mandate, adding features without removing anything.

**Complexity was compounding.** The automation workflow builder interacted with the CRM which interacted with the landing page builder which interacted with the analytics. Changing anything required understanding everything. Bug fixes in one area caused regressions in another.

**New users were overwhelmed.** The onboarding flow required 12 steps. New users had to configure their CRM fields, set up automation rules, and connect their landing pages before they could send a single email. Activation rate had dropped from 60% to 28%.

**The core product was neglected.** The email editor — the thing every user needed — had not been improved in 8 months. All engineering time went to maintaining peripheral features or building new ones.

### The Intervention

The founders read Getting Real and Rework and decided to apply the "build less" philosophy retroactively.

**Step 1: Identify the core job**

They surveyed users with one question: "What is the one thing you use our product for?" 73% of responses mentioned some variation of "send emails to my list." Not automation, not CRM, not landing pages — sending emails.

**Step 2: Audit every feature**

They categorized every feature using the feature audit framework:

| Feature | Usage | Maintenance Cost | Decision |
|---------|-------|-----------------|----------|
| Email editor | High | Medium | Invest heavily |
| Subscriber management | High | Low | Keep, improve |
| Campaign scheduling | High | Low | Keep |
| Basic analytics (open/click) | High | Low | Keep |
| Automation workflows | Low (8% of users) | Very high | Remove |
| A/B testing | Low (5% of users) | Medium | Remove |
| Landing page builder | Low (3% of users) | High | Remove |
| CRM | Low (6% of users) | Very high | Remove |
| Advanced analytics | Low (4% of users) | Medium | Remove |

**Step 3: Cut**

They removed the automation workflow builder, the A/B testing feature, the landing page builder, the CRM module, and advanced analytics. This was painful — these features had taken months to build. But each one was used by fewer than 10% of customers and cost disproportionate engineering time to maintain.

They communicated the changes to affected users with honesty: "We're focusing on making the core email experience excellent. These features are being retired. Here are alternatives that specialize in [automation/CRM/landing pages]. We'll help you export your data."

**Step 4: Reinvest in the core**

With 60% of their codebase removed, the team spent two six-week cycles rebuilding the email editor, simplifying the onboarding (from 12 steps to 3), and making the core sending workflow faster and more reliable.

### Results After 4 Months

| Metric | Before | After |
|--------|--------|-------|
| Codebase size | ~180K lines | ~75K lines |
| Feature count | 14 | 5 |
| Onboarding steps | 12 | 3 |
| Activation rate | 28% | 64% |
| Customer churn | 6.2%/month | 3.8%/month |
| Bug reports per week | ~22 | ~5 |
| Time to ship a new improvement | 4-6 weeks | 1-2 weeks |
| Engineering time on maintenance | ~55% | ~20% |

### Lessons Learned

1. **Removing features is harder socially than technically.** The code deletion was easy; explaining it to affected customers was hard but necessary.
2. **A small percentage of vocal users drove most feature requests.** The 8% who used automation were the loudest, but the 92% who just wanted good email tools were the majority.
3. **Simplification improved everything.** Fewer features meant fewer bugs, faster development, easier onboarding, and lower churn. The product was better in every measurable way.
4. **You can always add later.** The fear was that removing features was permanent. In reality, the team retained the option to re-add features as independent, well-shaped bets if demand justified it. So far, demand has not.

## Case Study 3: Replacing Status Meetings with Hill Charts

### Context

A 15-person design and engineering team at a mid-size company builds internal tools. They have weekly one-hour status meetings where each of the 5 project leads presents their progress. In addition, there are daily 15-minute standups per team (3 teams, 15 minutes each).

### The Problems

**Status meetings were theater.** Project leads spent 30 minutes preparing slides for the weekly meeting. During the meeting, most attendees listened passively while one person presented. The information was stale by the time it was shared — things had changed since the slides were prepared.

**"Percentage complete" was meaningless.** Project leads reported progress as percentages: "We're 70% done." But 70% done could mean "the easy 70% is done and the hard 30% remains" or "we're 70% through the timeline but only 40% through the complexity." Percentages created a false sense of precision.

**Daily standups were ritualistic.** Team members recited "what I did yesterday, what I'll do today, any blockers" without genuine engagement. The standup ran on autopilot — it was a habit, not a tool. Real problems were discussed after the standup, in smaller groups.

**Problems were hidden until late.** Because percentage-complete tracked tasks (not understanding), a scope that was "on track" could suddenly be "in trouble" when the team hit an unexpected complexity. The status meeting format did not surface this risk early enough.

### The Transition

**Week 1: Introduce hill charts**

The team adopted hill charts for all active projects. Each project identified 4-8 scopes and placed them on the hill. Initial positions:

- Most scopes started on the left side of the hill (uphill — still figuring things out)
- A few scopes started near the summit or on the downhill side (approach was clear)

**Week 2: Replace standup with async updates**

Daily standups were replaced with twice-weekly hill chart updates. Each team updated their hill chart positions and optionally wrote a one-paragraph note for any scope that moved significantly or got stuck.

**Week 3: Replace weekly status meeting with hill chart review**

The one-hour weekly status meeting was replaced with a 20-minute hill chart review. Instead of presentations, the group looked at the hill charts and focused only on scopes that were:
- Stuck uphill for more than a week (risk signal)
- Moving backward (the team discovered something harder than expected)
- Missing from the chart (a scope the team had not started yet)

### How Hill Charts Changed the Conversation

**Before (percentage-complete):**

> "The reporting feature is about 60% complete. We're on track."
> "Great, any blockers?"
> "No blockers right now."
> (Two weeks later: "Actually, the reporting feature is going to need another sprint. We hit some complexity with the data aggregation layer.")

**After (hill charts):**

> "The 'Report Templates' scope is moving downhill — we know what to build and we're executing. But 'Data Aggregation' has been uphill for a week. We're still figuring out how to handle cross-timezone calculations."
> "That's a risk. Is the appetite still right for this, or does 'Data Aggregation' need to be re-scoped?"
> "Let's simplify — what if we only support one timezone per report for v1?"
> "That works. Move it to the summit."

The hill chart made the risk visible two weeks earlier and prompted a scope-cutting conversation that kept the project on track.

### Results After 3 Months

| Metric | Before | After |
|--------|--------|-------|
| Time in status meetings per week | 3.25 hrs/person (1hr weekly + 0.75hr standups) | 0.5 hrs/person (20min review + 10min async updates) |
| Time to surface a stuck scope | 1-2 weeks (at next status meeting) | 2-3 days (next hill chart update) |
| "Surprise" project problems per quarter | 4-5 | 0-1 |
| Meeting preparation time per week | 30 min (slides) | 2 min (drag dots) |
| Sense of progress (team survey) | "We report progress" | "We see progress" |

### What Made It Work

1. **Hill charts separate uncertainty from execution.** The uphill/downhill distinction gives an honest view of where the real risk is, which percentage-complete cannot.
2. **Async updates respect focus time.** Writing a one-paragraph update takes 2 minutes and does not interrupt anyone's flow. A standup interrupts everyone's morning.
3. **Short meetings focus on risk, not reports.** The 20-minute review only discusses scopes that are stuck or moving backward. Good news is visible on the chart — it does not need to be presented.
4. **Visual progress is motivating.** Seeing scopes move across the hill provides a tangible sense of progress that task lists and percentages do not.

## Key Takeaways

Across all three case studies, several themes emerge:

**1. Simplification improves outcomes.** In every case, removing process, removing features, or removing meetings led to better results. The instinct to add more is almost always wrong.

**2. Honesty enables speed.** Hill charts show real risk. Appetite forces honest scoping. The circuit breaker forces honest assessment of progress. When the team is honest about where things stand, problems are caught early and addressed quickly.

**3. Autonomy produces better work.** Teams that discover their own tasks, cut their own scope, and manage their own progress do better work than teams that follow instructions. Autonomy requires trust, and trust requires boundaries (shaped pitches, appetites, hill charts).

**4. Transitions are uncomfortable.** Every team experienced discomfort when changing their process. The backlog deletion felt risky. The first circuit breaker felt harsh. Removing status meetings felt like losing control. In every case, the discomfort faded within one or two cycles as the new approach proved itself.

**5. The framework adapts to context.** No team implemented Shape Up exactly as described in the book. Each adapted the principles to their size, domain, and culture. The six-week cycle is not sacred — the principles behind it (fixed time, variable scope, shaped work, small teams) are what matter.

# Opinionated Software and Clear Communication

## Table of Contents

- [What Opinionated Software Means](#what-opinionated-software-means)
- [Defaults Over Preferences](#defaults-over-preferences)
- [The Epicycle Trap](#the-epicycle-trap)
- [The Art of Saying No](#the-art-of-saying-no)
- [Clear Copywriting Principles](#clear-copywriting-principles)
- [Focus on What Won't Change](#focus-on-what-wont-change)
- [Out-Teach the Competition](#out-teach-the-competition)
- [Sell Your By-Products](#sell-your-by-products)

## What Opinionated Software Means

Opinionated software makes choices on behalf of the user. Instead of offering 15 configuration options, it picks the best one and ships it as the default — or the only option. Instead of supporting every possible workflow, it supports one workflow well and says "this is how we think it should be done."

This is the opposite of the "platform" mindset, where the goal is maximum flexibility. The 37signals mindset is: flexibility is complexity. Every option you add is a decision the user must make. Every configuration is a potential source of confusion. Opinionated software trades flexibility for clarity.

**Examples of opinionated decisions in Basecamp:**

| Area | Opinionated Choice | What They Did Not Build |
|------|-------------------|----------------------|
| Project structure | All projects have a message board, to-do lists, schedule, docs, and campfire chat | Custom project templates, configurable modules |
| Notifications | Sensible defaults with one toggle (on/off) per project | Per-event notification rules, notification schedules, do-not-disturb windows |
| Permissions | Simple owner/member model | Role-based access control, custom permission levels |
| File organization | Flat list with search | Folder hierarchies, tagging systems, metadata |
| Reporting | Built-in views that answer the most common questions | Custom report builder, query language, data export scheduler |

**The cost of having no opinion:** Software without opinions becomes a configuration puzzle. Users spend more time setting up the tool than using it. Support teams answer the same questions about which settings to use. And the product loses its identity — it becomes a generic platform rather than a tool that stands for something.

## Defaults Over Preferences

Every preference in your software represents a decision your team did not make. Some of these are legitimate — users genuinely have different needs. But most preferences exist because the team could not decide, or because one vocal user requested an option, or because "we'll just make it configurable" felt easier than choosing.

**The preference audit:**

For each preference or setting in your product, ask:

1. **What percentage of users change this from the default?** If it is less than 5%, remove the preference and keep the default.
2. **Is there a single best answer?** If yes, pick it and remove the option. Users do not want to choose — they want it to work.
3. **Does this preference exist because of a vocal minority?** One customer's request is not a mandate. Solve their specific problem differently.
4. **Does this preference create downstream complexity?** If a setting changes behavior in ways that affect other features, the complexity cost is high. Remove it.
5. **Would removing this break a significant use case?** If yes, keep it. If no, remove it.

**How to pick good defaults:**

- **Observe real behavior.** If you already have the preference, look at what most users choose. Make that the default.
- **Choose the safe option.** When in doubt, default to the option that is least likely to cause problems.
- **Choose the simple option.** When both options are safe, choose the one that requires less explanation.
- **Match user expectations.** What would a new user expect this to do without reading documentation? Do that.

**Example: Timezone settings.** Most software asks users to set their timezone. 37signals approach: detect the timezone from the browser. If you are wrong, the user can change it — but you should not make every user manually configure something that can be detected automatically.

## The Epicycle Trap

An epicycle is a feature added to fix a problem caused by an earlier feature. The term comes from Ptolemaic astronomy, where epicycles (circles upon circles) were added to explain planetary motion within a flawed model. In software, epicycles look like this:

1. You add a feature (bulk notifications)
2. Users complain it is noisy (because bulk notifications create too many alerts)
3. You add a preference to control notification frequency (epicycle 1)
4. Some users set it wrong and miss important notifications
5. You add a "priority notification" override (epicycle 2)
6. Users are now confused about the interaction between frequency settings and priority overrides
7. You add a documentation page explaining the notification system (epicycle 3)

Each epicycle makes the original problem worse by adding complexity. The 37signals solution: remove the root cause. If bulk notifications are noisy, fix the notification logic — do not add settings to let users manage the noise themselves.

**How to spot epicycles:**

- You are adding a feature whose primary purpose is to manage or configure another feature
- You are writing documentation to explain feature interactions
- Users need a "getting started guide" for a single feature
- You are adding an "advanced settings" panel
- A feature has more than two preferences

**How to break the cycle:**

1. Identify the root feature that caused the downstream complexity
2. Ask: "Is there a simpler version of this root feature that would not need the epicycles?"
3. Replace the complex version with the simple one
4. Remove all the epicycles

## The Art of Saying No

Saying no is the most important skill in product development. Every feature request, no matter how reasonable, competes with simplicity. The default answer to any request must be no — not because the idea is bad, but because the cost of yes is always higher than it appears.

**The hidden costs of yes:**

| Visible Cost | Hidden Cost |
|-------------|------------|
| Development time | Maintenance forever |
| Design work | Cognitive load for all users |
| Testing effort | Documentation and support burden |
| One-time feature | Ongoing compatibility with future features |
| Satisfying one user | Complicating the product for everyone |

**How to say no effectively:**

- **Be direct.** "We're not going to build this" is clearer and kinder than "We'll add it to the backlog" (which is a lie).
- **Do not apologize.** You are making a product decision, not committing a wrong. "Thanks for the suggestion. We've decided not to include this." is sufficient.
- **Explain your reasoning (briefly).** "We want to keep the notification system simple, and this would add a level of complexity we're not comfortable with." One sentence, not a paragraph.
- **Do not promise a future.** "Not now" implies "later." If you mean no, say no.
- **Acknowledge the need.** "I understand this would be useful for your workflow" shows empathy without creating commitment.

**When to say yes:** Say yes when a request solves a problem that many users share, aligns with the product's opinion, can be built simply, and fits within a cycle's appetite. That combination is rare — which is why no is the default.

**The "few vocal users" problem:** A small number of power users generate a disproportionate amount of feature requests. Their needs are real but not representative. Building for vocal power users at the expense of the quiet majority is a common product mistake. The check: how many users does this actually affect?

## Clear Copywriting Principles

The 37signals approach to copy is an extension of their product philosophy: simple, honest, and opinionated. Every word in the interface is a product decision.

**The rules:**

**1. Write for humans, not for marketers.** If a sentence would sound weird spoken aloud in a conversation, rewrite it. "Your file has been saved" is human. "Your asset has been successfully persisted to our cloud infrastructure" is not.

**2. No buzzwords.** Remove every instance of: "leverage," "synergy," "seamless," "robust," "cutting-edge," "next-generation," "holistic," "ecosystem," and any word that means nothing specific. Replace with plain language.

**3. Be specific.** "Fast" is vague. "Loads in under 2 seconds" is specific. "Easy to use" is vague. "Set up in 3 steps" is specific. Specificity builds trust; vagueness erodes it.

**4. Be honest about limitations.** If your product does not do something, say so. "Basecamp is not for everyone. Here's who it's for." This honesty attracts the right customers and repels the wrong ones — both good outcomes.

**5. Error messages are a product.** Every error message is a conversation with a frustrated user. "An unexpected error occurred" is abandoning that user. "We couldn't send that email. Check the address and try again." is helping them.

**6. Labels matter.** The name you give a feature shapes how users understand it. "Campfire" (Basecamp's chat feature) evokes warmth and informality. "Team Communication Module" does not.

**Copy before/after examples:**

| Before (Generic) | After (37signals Style) |
|------------------|----------------------|
| "Welcome to our platform! Let's get you set up with a seamless onboarding experience." | "Welcome to Basecamp. Let's get your first project started." |
| "An error has occurred. Please contact support." | "That didn't work. Here's what happened and how to fix it:" |
| "Upgrade to our premium tier for enhanced functionality." | "Need more storage? Upgrade for $99/month." |
| "Your notification preferences have been updated successfully." | "Saved." |
| "Leverage our robust integration ecosystem." | "Works with the tools you already use." |

## Focus on What Won't Change

Technology trends come and go. User preferences shift. Competitors add and remove features. But some things never change: people want software that is fast, simple, reliable, and respectful of their time. The 37signals bet is to invest disproportionately in these permanent qualities.

**Permanent qualities worth investing in:**

- **Speed.** A faster product is always better. This will never change.
- **Simplicity.** Easier to understand is always better. This will never change.
- **Reliability.** Always working is always better. This will never change.
- **Clarity.** Clear communication is always better. This will never change.
- **Respect for user time.** Fewer steps, fewer clicks, fewer distractions. Always better.

**Transient qualities to be cautious about:**

- Latest JavaScript framework (will be replaced in 3 years)
- AI features (valuable, but the landscape changes monthly)
- Social features (user expectations shift frequently)
- Integration with trending platforms (platforms rise and fall)

This does not mean ignoring new technology. It means building on a stable foundation and adopting new technology selectively, when it clearly serves a permanent quality. Use a new framework if it makes the product faster. Do not use it because it is trendy.

## Out-Teach the Competition

37signals publishes books, blog posts, conference talks, and free resources about how they work. This is not charity — it is strategy. Teaching your methods openly attracts customers who share your values, establishes authority in your space, and creates a relationship with potential customers long before they buy.

**What teaching looks like:**

- **Books.** Getting Real, Rework, Remote, It Doesn't Have to Be Crazy at Work, Shape Up — all share 37signals' methods openly.
- **Blog posts.** Signal v. Noise (now HEY World) publishes opinions about product development, business, and technology regularly.
- **Open source.** Ruby on Rails is the ultimate "sell your by-products" example — a tool built for internal use, released to the world, creating a massive community that feeds back into 37signals' reputation.
- **Transparent practices.** Open salaries, public positions on remote work, published decision frameworks — transparency builds trust.

**Why teaching works as marketing:**

- People buy from people they trust. Teaching builds trust.
- Your best customers are people who already agree with your philosophy. Teaching finds them.
- Teaching is durable. A blog post generates leads for years. An ad generates leads for a day.
- Teaching differentiates. Competitors can copy your features. They cannot copy your thinking.

## Sell Your By-Products

Every business produces by-products — knowledge, processes, tools, and methods created along the way to the main product. Most companies ignore these. 37signals sells them.

**37signals by-products:**

| Main Product | By-Product | Outcome |
|-------------|-----------|---------|
| Basecamp (project management) | Ruby on Rails (web framework) | World's most popular Ruby framework; massive community |
| Building Basecamp | Getting Real, Rework, Shape Up (books) | Millions of copies; established thought leadership |
| Running a remote company | Remote (book) | Influenced the global remote work movement |
| Product development process | Shape Up methodology | Adopted by thousands of companies |
| Building HEY | Blog posts about email philosophy | Generated massive launch buzz |

**How to identify your by-products:**

1. What processes did you create that others might find useful?
2. What tools did you build internally that could stand alone?
3. What lessons did you learn that others in your industry would value?
4. What opinions do you hold that are different from the mainstream?

**How to sell by-products:**

- Open source internal tools (Rails, Turbo, Stimulus, Hotwire)
- Write about your process (blog posts, books, newsletters)
- Speak about your decisions (conferences, podcasts, interviews)
- Share your templates (pitch templates, hiring processes, team structures)

By-products are already paid for — the cost of creating them was absorbed by the main product. Selling them is nearly pure upside.

# Shaping the Work

## Table of Contents

- [What Shaping Is](#what-shaping-is)
- [Properties of Shaped Work](#properties-of-shaped-work)
- [Setting the Appetite](#setting-the-appetite)
- [Breadboarding](#breadboarding)
- [Fat Marker Sketches](#fat-marker-sketches)
- [The Pitch Format](#the-pitch-format)
- [Identifying Rabbit Holes](#identifying-rabbit-holes)
- [Defining No-Gos](#defining-no-gos)
- [Who Does the Shaping](#who-does-the-shaping)
- [Shaping in Practice](#shaping-in-practice)

## What Shaping Is

Shaping is the work you do before the work. It happens at the intersection of product strategy, design thinking, and technical reality. The goal is to take a raw idea — a customer request, a business opportunity, a nagging problem — and transform it into something a small team can build in a fixed amount of time.

Shaping is not writing a spec. Specs are too detailed — they remove the team's ability to make creative decisions. Shaping is not writing a user story. User stories are too vague — they leave too many open questions for the team to resolve under time pressure. Shaping sits in between: detailed enough that the main approach is clear, rough enough that the team has room to work out the specifics.

**What shaping replaces:**

| Traditional Approach | Problem | Shaping Alternative |
|---------------------|---------|-------------------|
| Detailed specification | Too rigid; team becomes ticket-takers | Shaped pitch with room to maneuver |
| User story ("As a user I want...") | Too vague; team discovers scope problems mid-sprint | Shaped pitch with solution sketched out |
| Wireframes and mockups | Too concrete; invites pixel-level debate too early | Breadboards and fat marker sketches |
| Story point estimation | Focuses on how long, not how much it is worth | Appetite: "This is worth 2 weeks of work" |
| Sprint planning with a backlog | Picks from an ever-growing list of undifferentiated items | Betting table selects from freshly shaped pitches |

## Properties of Shaped Work

Shaped work has three essential properties. If any one is missing, the work is not ready to bet on.

**1. Rough.** The solution is sketched at the right level of abstraction. There are no wireframes, no pixel-level designs, no detailed task lists. The team has room to interpret the solution and make their own design and technical decisions. Roughness is intentional — it signals to the team that they own the details.

**2. Solved.** Despite being rough, the main elements of the solution are worked out. The shaper has thought through the core flow, identified the key interactions, and resolved the biggest design questions. The team should not have to figure out the fundamental approach — that is the shaper's job. They should figure out the details within that approach.

**3. Bounded.** The scope is explicitly limited. The appetite sets a time boundary. No-gos set feature boundaries. Rabbit holes are identified and addressed. The team knows what they are building and — just as importantly — what they are not building.

**How to tell if work is properly shaped:**

- Can you explain the solution in under 5 minutes using only words and rough sketches?
- Does the solution address the customer's core problem without unnecessary extras?
- Could a small team start building on day one without asking "but what about...?"
- Are the known risks called out and addressed?
- Is it clear what is out of scope?

If the answer to any of these is no, the work needs more shaping.

## Setting the Appetite

The appetite is a time budget that reflects how much the problem is worth. This is fundamentally different from estimation.

**Estimation asks:** "How long will this take?" The answer depends on the solution, which depends on scope, which depends on what the team discovers, which means the answer is a guess that grows under pressure.

**Appetite asks:** "How much time is this problem worth to us?" The answer is a strategic decision made before a solution exists. It constrains the solution rather than the solution dictating the timeline.

**Appetite sizes:**

| Size | Duration | Team | Typical Use |
|------|----------|------|-------------|
| Small batch | 1-2 weeks | 1-2 people | Bug fixes, small improvements, experiments |
| Large batch | 6 weeks | 2-3 people | New features, significant improvements, redesigns |

There is no "3-week appetite" or "4-month appetite." The constraint of fixed sizes forces honest classification: either this is small enough for a quick batch, or it is worth a full cycle. If it seems like it is in between, it needs more shaping to fit one size or the other.

**How appetite changes the conversation:**

- Without appetite: "How long will the reporting feature take?" "6-8 weeks." "Can you do it in 4?" (negotiation over fiction)
- With appetite: "We think a basic reporting feature is worth a 6-week bet. Can you shape something that solves the core need within that appetite?" (creative problem-solving within constraints)

## Breadboarding

A breadboard is an interaction design sketch that uses only words and arrows. No layout, no visual design, no color, no images. Just three elements:

**Places** — screens, dialogs, or pages the user can navigate to. Written as nouns.

**Affordances** — things the user can interact with at each place. Written as verbs or interactive elements (buttons, fields, links).

**Connection lines** — arrows showing how affordances lead to other places.

**Example breadboard: "User invites a teammate"**

```
[Project Settings]
  - "Invite" button
      ↓
[Invite Form]
  - Email field
  - Role selector (Admin / Member)
  - "Send Invite" button
      ↓
[Confirmation]
  - "Invitation sent to {email}" message
  - "Send another" link → [Invite Form]
  - "Done" link → [Project Settings]
```

**Why breadboards work:**

- They force you to think about flow before layout
- They are fast to create and easy to change
- They prevent premature conversations about visual design
- They reveal missing steps and edge cases in the interaction
- Anyone can read them — no design tools required

**When not to use breadboards:** When the challenge is primarily visual (a new data visualization, a complex responsive layout), a fat marker sketch is more appropriate.

## Fat Marker Sketches

A fat marker sketch is a visual sketch drawn at low fidelity — as if you were using a thick marker on a whiteboard. The thick line prevents you from drawing details like specific fonts, exact spacing, or precise button sizes. It forces you to think about arrangement and emphasis rather than polish.

**Rules for fat marker sketches:**

1. Draw on paper or a tablet with a thick brush — never in a design tool
2. No text labels (or very few) — use blocks and shapes to represent content areas
3. No color — grayscale only
4. No precise alignment — rough positioning is the point
5. Show the most important element prominently; let everything else recede

**What fat marker sketches communicate:**

- The relative priority of elements on a page (what is big, what is small)
- The general layout approach (sidebar? stacked? tabbed?)
- Which elements exist and which do not
- The relationship between content areas

**What they intentionally do not communicate:**

- Exact spacing, sizing, or alignment
- Typography choices
- Color or visual styling
- Responsive behavior
- Interaction states

This intentional vagueness is a feature. It gives the building team freedom to design the details while keeping the strategic layout decisions intact.

## The Pitch Format

A pitch is the shaped work packaged for the betting table. It is a written document — not a slide deck, not a verbal presentation — because writing forces clarity and allows asynchronous review.

**Five elements of a pitch:**

**1. Problem.** What is the problem or opportunity? Describe it from the user's perspective. Include a specific story or scenario that makes the problem concrete. Avoid abstract descriptions.

**2. Appetite.** How much time is this worth? Small batch (1-2 weeks) or large batch (6 weeks). This is a strategic decision, not a technical estimate.

**3. Solution.** The shaped solution, presented with breadboards and/or fat marker sketches. Show the core flow and key interactions. Keep it rough — enough to understand the approach, not enough to copy pixel-by-pixel.

**4. Rabbit holes.** Known risks and complexities that could blow up the scope. For each rabbit hole, explain how the solution addresses it or avoids it. If a rabbit hole cannot be mitigated, it may mean the pitch is not ready.

**5. No-gos.** Explicit statements about what the solution will not include. These prevent scope creep by making boundaries visible and non-negotiable. "We will not support bulk invitations in this version" is a no-go.

**Pitch length:** A pitch should take 5-10 minutes to read. If it takes longer, the solution is probably not shaped well enough — it is either too detailed or too complex.

## Identifying Rabbit Holes

Rabbit holes are the parts of a project that look simple on the surface but contain hidden complexity that can consume weeks of work. The shaper's job is to identify them before the team encounters them.

**Common rabbit hole patterns:**

| Pattern | Example | How to Address |
|---------|---------|---------------|
| Permissions complexity | "Who can see what when a user is shared across projects?" | Simplify the permission model; define only 2 roles for v1 |
| Data migration | "Existing users have data in the old format" | Define a simple migration path or make new feature new-only |
| Edge case explosion | "What if the user has 10,000 items?" | Set a practical limit and document it as a no-go |
| Integration dependency | "This needs the payment provider to support X" | Verify support exists before betting; if not, it is a no-go |
| Performance cliff | "This query will be slow at scale" | Shape the solution to avoid the expensive query (pagination, caching) |

**How to spot rabbit holes during shaping:**

1. Walk through the solution step by step and ask "What could go wrong here?"
2. For each interaction, ask "Is there a simpler version that achieves 80% of the value?"
3. Look for words like "just," "simply," or "obviously" in your own thinking — they often mask complexity
4. Ask an engineer to review the pitch for technical rabbit holes
5. Ask a designer to review for interaction rabbit holes

## Defining No-Gos

No-gos are explicit boundaries that prevent scope creep during the build. They state what the solution will not include, even if those exclusions seem like obvious additions.

**Why no-gos matter:**

- They prevent the building team from expanding scope based on their own good judgment
- They make trade-offs visible to the betting table
- They give teams permission to not build something without feeling like they are cutting corners
- They make the appetite honest — the solution fits the time budget because these things are excluded

**Good no-go examples:**

- "No bulk operations in v1 — users invite one person at a time"
- "No custom notification schedules — we pick a sensible default"
- "No mobile-responsive version for this feature — desktop only"
- "No CSV import — users enter data manually or use the API"
- "No undo — actions are confirmed before execution"

**Bad no-go examples (too vague):**

- "No over-engineering"
- "Keep it simple"
- "Don't spend too much time on edge cases"

No-gos must be specific and concrete. A team member should be able to look at a no-go and immediately know whether their current work violates it.

## Who Does the Shaping

Shaping is a senior role. The shaper needs to understand the business context (which problems are worth solving), the user perspective (what workflows look like), and the technical landscape (what is easy and what is hard to build). This rare combination usually means shaping is done by a founder, a senior product person, or a senior designer who is technically fluent.

**Shaping is not a committee activity.** One or two people shape a pitch. They may consult others — an engineer for technical feasibility, a support person for common complaints — but the shaping itself is done by a small number of people who can hold the whole picture in their head.

**Shaping is not the building team's job.** If the team doing the building also does the shaping, they end up shaping during the build, which defeats the purpose. The building team's job is to take a shaped pitch and figure out the implementation details. The shaper's job is to make sure the pitch is ready for that.

## Shaping in Practice

**Step 1: Set the appetite.** Before exploring solutions, decide how much time the problem is worth. This prevents the shaper from accidentally designing a 3-month solution for a 2-week problem.

**Step 2: Narrow the problem.** Move from a broad problem ("reporting is bad") to a specific scenario ("managers need to know which projects are behind schedule this week"). The narrower the problem, the easier it is to shape a bounded solution.

**Step 3: Sketch the solution.** Use breadboards for flow-heavy problems and fat marker sketches for layout-heavy problems. Work quickly — if the sketch takes more than 30 minutes, the problem might need more narrowing.

**Step 4: Identify rabbit holes.** Walk through the solution and flag anything that could blow up. Address each one: simplify, exclude, or find a workaround.

**Step 5: Define no-gos.** Write down what the solution will not include. Be specific.

**Step 6: Write the pitch.** Package everything into the five-element pitch format. Share it for review before bringing it to the betting table.

**Time investment:** Shaping a single pitch typically takes 1-3 days of focused work, spread over a week or two. This is a fraction of the time the building team will spend, but it dramatically reduces the risk of building the wrong thing.

# Small Teams and Execution

## Table of Contents

- [The Three-Person Team](#the-three-person-team)
- [Team Autonomy](#team-autonomy)
- [Discovering Scopes](#discovering-scopes)
- [Hill Charts](#hill-charts)
- [Getting Real](#getting-real)
- [Async Communication](#async-communication)
- [Launch Now, Iterate Later](#launch-now-iterate-later)
- [Integrating Design and Programming](#integrating-design-and-programming)

## The Three-Person Team

The fundamental unit of work at 37signals is a team of three: one designer and two programmers, or one designer and one programmer for smaller bets. No project manager. No dedicated QA person. No scrum master. Three people who build the entire thing together.

**Why three:**

- **Communication overhead scales quadratically.** With 3 people, there are 3 communication paths. With 6 people, there are 15. With 10, there are 45. Small teams communicate naturally — in conversations, not meetings.
- **Shared context comes automatically.** Three people working on the same shaped pitch can hold the entire project in their heads. They do not need status documents to stay aligned.
- **Accountability is clear.** When three people own a bet, there is nowhere to hide. Everyone contributes, everyone is responsible.
- **Decision-making is fast.** Three people can make a decision in a five-minute conversation. Ten people need a meeting with an agenda and follow-up action items.

**What the three-person team does not have:**

| Role | Why It Is Absent | What Replaces It |
|------|-----------------|-----------------|
| Project manager | Shaped pitches eliminate ambiguity; small teams self-organize | The team manages itself using hill charts |
| Product manager (during the cycle) | Shaping happens before the cycle; the PM shapes, not manages | The shaper hands off the pitch; the team builds |
| QA engineer | Three people test as they build; scope is small enough to verify | Integrated testing by the building team |
| Scrum master | No sprints, no ceremonies, no process to facilitate | No process overhead — the team just builds |
| Tech lead (separate from the team) | The senior programmer on the team makes technical decisions | Technical leadership comes from within the team |

**What happens when a bet needs more than three people:** It does not get more people. It gets re-shaped. If a shaped pitch requires more than three people, the pitch is too big or too vague. Break it into smaller, independent bets that each fit a three-person team.

## Team Autonomy

Once a team receives a shaped pitch and the cycle begins, they are autonomous. No one assigns them tasks, checks their progress daily, or tells them how to build. They own the entire bet from start to finish.

**What autonomy means in practice:**

- The team decides the technical approach (which frameworks, which database schema, which architecture)
- The team decides the design details (layout, typography, interaction patterns)
- The team decides the build order (which scopes to tackle first, which to defer)
- The team decides when to cut scope (within the boundaries of the pitch's no-gos)
- The team decides when to ship (within the six-week constraint)

**What autonomy does not mean:**

- Ignoring the shaped pitch — the pitch defines the boundaries; the team fills in the details
- Skipping communication — the team posts hill chart updates and writes up decisions for transparency
- Expanding scope — autonomy is freedom within constraints, not freedom to redefine the bet
- Working in isolation — team members collaborate closely with each other; they just do not need external direction

**Why autonomy works:** When people own their work, they bring better judgment, more energy, and more creativity than when they are executing someone else's task list. Autonomy also attracts and retains talented people who want to do meaningful work, not follow instructions.

## Discovering Scopes

When a team receives a shaped pitch, their first job is to discover scopes — named chunks of work that can be built and tracked somewhat independently. Scopes are not pre-defined; the team discovers them by exploring the pitch.

**What a scope is:**

- A meaningful piece of the project that can move through the hill independently
- Named with a descriptive label (e.g., "User Invitations," "Permission Checks," "Email Notifications")
- Big enough to be meaningful (not a single task) but small enough to complete in days, not weeks
- Defined by the team based on their understanding of the work, not by the shaper

**How to discover scopes:**

1. **Read the pitch thoroughly.** Understand the problem, the solution, the rabbit holes, and the no-gos.
2. **Start building.** Do not spend days planning — start with the most uncertain part of the project.
3. **Notice natural boundaries.** As you work, pieces of the project naturally group together. A set of related database changes, a UI component, an integration point — these become scopes.
4. **Name them.** Give each scope a clear, descriptive name. The name should communicate what the scope is about to someone who has not read the code.
5. **Revise as you learn.** Scopes evolve during the cycle. Some merge, some split, some turn out to be unnecessary. This is normal and expected.

**Scopes vs. tasks:**

| Scopes | Tasks |
|--------|-------|
| Named by the team based on discovered structure | Assigned by a PM or tech lead based on a spec |
| Group related work together | Individual work items |
| Track on a hill chart (figuring out → done) | Track in a list (to-do → done) |
| Evolve during the cycle | Fixed at sprint planning |
| Communicate what area is progressing | Communicate whether a checklist item is ticked |

## Hill Charts

Hill charts are the 37signals alternative to burndown charts, percentage-complete metrics, and status meetings. A hill chart shows each scope as a dot on a hill. The left side of the hill is "uphill" (figuring things out), and the right side is "downhill" (executing known work).

**The shape of the hill:**

```
          ·  ← summit (figured out, ready to execute)
         / \
        /   \
uphill /     \ downhill
      /       \
     /         \
____/           \____
figuring out    executing
(uncertainty)   (certainty)
```

**How to read a hill chart:**

- **Dot on the far left:** The team has not started this scope yet.
- **Dot climbing uphill:** The team is exploring, figuring out the approach, encountering unknowns.
- **Dot near the summit:** The core approach is figured out but implementation has not started.
- **Dot going downhill:** The approach is clear and the team is executing — this is the "boring" productive work.
- **Dot at the far right:** The scope is done.

**Why hill charts work better than other progress tracking:**

| Method | Problem | Hill Chart Advantage |
|--------|---------|---------------------|
| Percentage complete | "80% done" can mean "80% of tasks done but the hard 20% remains" | Shows whether uncertainty is resolved or not |
| Burndown chart | Treats all tasks as equal; does not distinguish exploration from execution | Uphill/downhill distinction reveals where the real risk is |
| Status meeting | "It's going well" hides problems until it is too late | A dot stuck uphill for two weeks is a visible red flag |
| Task list | Checked boxes feel like progress even if the hardest work is untouched | Scopes stuck uphill force honest conversation about risk |

**Using hill charts to manage risk:**

The most important thing a hill chart reveals is which scopes are stuck uphill. A scope that has been uphill for more than two weeks is a warning sign — the team is struggling with uncertainty. This triggers a conversation: Is the scope too big? Is there a rabbit hole that was not identified during shaping? Does the scope need to be re-shaped or cut?

**How often to update hill charts:** At least twice per week. Updates should take less than two minutes — just drag the dots to their current position. No written status reports needed.

## Getting Real

"Getting real" is the 37signals principle of working with real materials as early as possible. In software, real materials are HTML, CSS, JavaScript, and real data — not wireframes, not prototypes, not mockups with lorem ipsum.

**What "getting real" looks like:**

- Build the actual interface in the browser on day one or two, not in a design tool
- Use real data (or realistic fake data), not "lorem ipsum" and placeholder content
- Make it functional as fast as possible, even if it is ugly — then improve the design
- Test with real interactions (clicking, typing, navigating), not static screenshots

**Why getting real works:**

- **You discover problems earlier.** Wireframes and mockups hide interaction problems that become obvious when you click through real HTML.
- **You make better design decisions.** Seeing real content in a real browser reveals what works and what does not in a way that static images cannot.
- **You avoid the handoff problem.** When designers work in Figma and engineers implement separately, translation losses are inevitable. When the designer and programmer build together in the browser, the output is the real thing.
- **You ship faster.** The prototype becomes the product. There is no throwaway work.

**Getting real does not mean skipping design:** It means the design happens in the medium of the final product (HTML/CSS) rather than in an intermediate medium (Figma/Sketch). The designer and programmer collaborate in the browser from day one.

## Async Communication

Meetings are toxic at 37signals. Not because meetings are always bad, but because they are almost always overused. A one-hour meeting with six people is not a one-hour meeting — it is six hours of collective time. And most of that time is wasted by the majority who are listening rather than contributing.

**The async-first approach:**

- **Write it up.** If you have something to share, write a message, a document, or a post. People can read it on their own schedule and respond thoughtfully.
- **Record a Loom.** If you need to show something visual, record a 5-minute video walkthrough. It is faster to make than a meeting is to schedule, and everyone can watch at 2x speed.
- **Use hill chart updates.** The hill chart replaces the daily standup. Anyone can see where the project stands by looking at the chart.
- **Reserve meetings for conversations.** Meetings are appropriate when you need real-time back-and-forth to resolve a disagreement or brainstorm. They are not appropriate for status updates, announcements, or information sharing.

**The 37signals communication hierarchy:**

| Need | Method | Why |
|------|--------|-----|
| Status update | Hill chart + async post | No meeting needed; people check on their own time |
| Decision announcement | Written post | Documentation is built-in; everyone gets the same information |
| Design feedback | Loom video + written comments | Async review is more thoughtful than real-time critique |
| Complex problem-solving | Real-time conversation (2-3 people) | Keep it small, keep it focused, keep it short |
| Team alignment | Written pitch or kickoff post | The shaped pitch IS the alignment document |

## Launch Now, Iterate Later

The 37signals philosophy strongly favors shipping over perfecting. Working software in the hands of real users generates more useful feedback in one day than months of internal review.

**What "launch now" means:**

- Ship at the end of the six-week cycle, even if some nice-to-have scopes were cut
- Ship to real users, not to a staging environment for internal review
- Accept that the first version will not be perfect — it should be good, but not perfect
- Plan to iterate in future cycles based on real usage data, not hypothetical feedback

**What "launch now" does not mean:**

- Ship broken software — everything that ships should work correctly
- Skip testing — the building team tests as they build
- Ignore quality — the shipped version should be polished within its reduced scope
- Never improve — iteration is expected; "launch now" is the beginning, not the end

**The iteration cycle:**

1. Ship the first version (end of six-week cycle)
2. Observe real usage during the cool-down period
3. If improvements are needed, shape a follow-up pitch
4. Bring the follow-up pitch to the next betting table
5. If it wins the bet, build the improvement in the next cycle

## Integrating Design and Programming

Traditional product development separates design and engineering into sequential phases: design first, then build. The 37signals approach integrates them from day one. The designer and programmer(s) work together on the same scopes simultaneously.

**How integration works in practice:**

- **Day 1-2:** The designer starts building real HTML/CSS for the core interaction. The programmer sets up the data model and backend. They sync frequently.
- **Day 3-5:** The designer refines the interface while the programmer connects it to real data. They work on the same scope, in the same codebase.
- **Week 2+:** Design and engineering decisions are made together, in context. "Should this be a modal or a page?" is answered by building both and seeing which one works.

**Why integration matters:**

- No handoff problems — the designer sees the real implementation, not a screenshot
- Faster decision-making — questions are resolved in minutes, not in a review meeting next week
- Better solutions — the designer understands technical constraints; the programmer understands design intent
- Single source of truth — the codebase is the design, not a Figma file that may be out of date

**What this requires from the team:**

- Designers must be comfortable working with HTML/CSS or closely pairing with a programmer
- Programmers must care about the user experience, not just the code
- Both must be willing to change their work based on what they learn together

# The 37signals Approach to UX, UI, and Copy

## Table of Contents

- [Design Philosophy](#design-philosophy)
- [UX Principles](#ux-principles)
- [UI Design Approach](#ui-design-approach)
- [Copywriting as Product Design](#copywriting-as-product-design)
- [The Basecamp Design Process](#the-basecamp-design-process)
- [Interface Patterns](#interface-patterns)
- [Writing the Interface](#writing-the-interface)
- [Anti-Patterns](#anti-patterns)

## Design Philosophy

The 37signals design philosophy rests on a single conviction: design is not decoration. Design is how it works. Every pixel, every word, every interaction is a product decision. The goal is not to make software that looks beautiful in a screenshot — it is to make software that feels obvious in use.

This means design starts with the problem, not the screen. Before asking "What should this look like?", ask "What is the user trying to do, and what is the fastest path to doing it?" The answer shapes everything: the layout, the copy, the interactions, and — critically — what is not on the screen.

**The three design principles:**

1. **Clarity over cleverness.** A clever interface that confuses users is a failed interface. A boring interface that gets the job done is a successful one.
2. **Reduction over addition.** When a screen is not working, the first instinct should be to remove elements, not add them. Most design problems are caused by too much, not too little.
3. **Convention over innovation.** Use standard patterns (links look like links, buttons look like buttons, forms work like forms) unless there is a compelling reason not to. Innovation for its own sake is a cost, not a benefit.

## UX Principles

### Start with the Core Job

Every screen in the product should serve a clear purpose connected to the user's core job. If you cannot articulate what the user is trying to accomplish on a screen, the screen should not exist.

**The one-screen test:** Can you describe what the user does on this screen in one sentence? If you need two sentences, the screen is doing too much. Split it or simplify it.

**Examples:**
- "The user sees all their projects and opens one." (Projects list — clear purpose)
- "The user writes a message to their team." (Message composer — clear purpose)
- "The user sees their dashboard with activity feed, upcoming deadlines, team status, notifications, and quick actions." (Dashboard — doing too much; simplify)

### Reduce to the Essence

For every element on the screen, ask: "If I remove this, does the user fail at their task?" If the answer is no, remove it. Start with the minimum viable screen and add only what is proven necessary.

**The removal checklist:**

| Element | Keep If | Remove If |
|---------|---------|-----------|
| Navigation item | User needs it at least weekly | It serves < 10% of users or is accessible from another path |
| Form field | Data is required to complete the task | Data is "nice to have" or can be inferred |
| Confirmation dialog | Action is destructive and irreversible | Action is easily undone |
| Tooltip or help text | The UI element is genuinely confusing | Better solution: rename the element so it is self-explanatory |
| Loading indicator | Operation takes > 1 second | Operation is instant |
| Success notification | User needs confirmation to proceed | The result of the action is already visible on screen |

### Design for the Happy Path First

Design the screen for the most common scenario first. Get that working perfectly. Then handle edge cases, empty states, and error states. Most users will experience the happy path most of the time — invest your design energy proportionally.

**Priority order for design attention:**
1. The happy path (80% of user time)
2. Empty states (first-time experience)
3. Error states (things that go wrong)
4. Edge cases (unusual but valid scenarios)
5. Power user features (requested by few, used by fewer)

### Make Navigation Obvious

Users should always know where they are, how they got there, and how to get back. This sounds basic because it is — and yet most software fails at it. The 37signals approach: use clear breadcrumbs, descriptive page titles, and consistent navigation patterns. Never make the user guess where they are.

## UI Design Approach

### Build in the Browser

The 37signals approach to UI design is to build in the browser from day one. This means HTML and CSS, not Figma or Sketch. The browser is the final medium — designing in an intermediate tool and then translating is waste.

**Why browser-first design works:**

- **Real interactions.** You can click, scroll, and type. You discover interaction problems immediately.
- **Real constraints.** Browser rendering, responsive behavior, and performance are immediate. No surprises at implementation time.
- **Real content.** Using real data instead of lorem ipsum reveals length issues, truncation needs, and content hierarchy problems.
- **No handoff.** The "design" and the "implementation" are the same artifact. Nothing is lost in translation.

**What this does not mean:** It does not mean the designer must write production-quality code. It means the designer works in HTML/CSS (possibly with a programmer pairing) to create the real interface. The code may be rough — it gets refined during the cycle.

### Visual Hierarchy Through Weight, Not Decoration

The 37signals UI style relies on content hierarchy achieved through font weight, size, color contrast, and whitespace — not through borders, backgrounds, shadows, or decorative elements.

**Hierarchy tools (in order of preference):**

1. **Font size.** Bigger = more important. Simple and universal.
2. **Font weight.** Bold = emphasis. Use sparingly — if everything is bold, nothing is.
3. **Color contrast.** High contrast (black text) = primary. Low contrast (gray text) = secondary. One accent color for interactive elements.
4. **Whitespace.** Generous spacing groups related elements and separates unrelated ones. Whitespace is not empty space — it is a design element.
5. **Position.** Top-left is where the eye goes first (in LTR languages). Put the most important thing there.

**What to avoid:**

- Excessive borders and dividers — use whitespace to separate instead
- Background colors on every section — reserve background color for meaningful distinction
- Shadow on every card — use shadow sparingly to create meaningful depth
- Icon overuse — icons without labels are ambiguous; use text labels

### Responsive as Reduction

When designing for smaller screens, the 37signals approach is not "rearrange everything to fit" but "remove what is not essential at this size." A mobile interface is not a shrunk desktop interface — it is a simpler interface that serves the most common mobile use cases.

**Mobile reduction principles:**

- Show only the primary action, not all available actions
- Use full-screen flows instead of modals or sidebars
- Reduce navigation to essential items only
- Prioritize reading and quick actions over complex editing
- Accept that some features are desktop-only — that is okay

### Use Standard Components

Do not invent custom UI components when standard ones exist. A standard dropdown, a standard checkbox, a standard text input — users already know how these work. Custom components carry a learning cost.

**When custom components are justified:**
- The standard component genuinely cannot serve the use case (rare)
- The custom component is dramatically simpler than the standard alternative
- The custom component is used repeatedly throughout the product (worth the investment)

**When custom components are not justified:**
- "It looks cooler" — users do not care about cool; they care about familiar
- "It matches our brand" — brand is expressed through content and tone, not through reinventing checkboxes
- "The designer wanted it" — design serves users, not designers' portfolios

## Copywriting as Product Design

At 37signals, interface copy is not an afterthought — it is a core design element. The words on the screen shape user expectations, guide behavior, and build (or erode) trust. Copy is written by the people who design and build the product, not by a separate copywriting team.

### The Copy Rules

**1. Use the fewest words possible.** Every word on the screen competes for the user's attention. Remove words that do not earn their place.

| Wordy | Concise |
|-------|---------|
| "Click the button below to save your changes" | "Save" (button label) |
| "Are you sure you want to delete this item? This action cannot be undone." | "Delete this? It can't be undone." |
| "You have successfully completed the setup process." | "You're all set." |
| "In order to proceed, please enter your email address in the field below." | "Email" (field label) |

**2. Use the simplest words possible.** Write at a 6th-grade reading level. Not because users are unsophisticated, but because simple words are processed faster by everyone, including experts.

| Complex | Simple |
|---------|--------|
| "Utilize" | "Use" |
| "Terminate" | "End" |
| "Configure" | "Set up" |
| "Authenticate" | "Sign in" |
| "Facilitate" | "Help" |
| "Leverage" | "Use" |

**3. Be specific, not abstract.** Tell the user exactly what will happen, not what category of thing will happen.

| Abstract | Specific |
|----------|---------|
| "Manage your account" | "Change your name, email, or password" |
| "Enhanced collaboration features" | "Invite your team and share files" |
| "Optimize your workflow" | "Send automatic reminders when tasks are due" |

**4. Write how you talk.** Read your copy aloud. If it sounds robotic or stilted, rewrite it. Interface copy should sound like a helpful colleague, not a legal document.

**5. Be honest about what is happening.** If something will take time, say so. If there are limitations, disclose them. If something went wrong, explain what happened. Never use vague language to hide bad news.

### Error Messages as Conversations

Error messages are the most neglected and most important copy in any application. A user encountering an error is frustrated — the error message is your chance to help them or abandon them.

**The error message formula:**

1. **What happened** (in plain language)
2. **Why it happened** (if the user can understand the cause)
3. **What to do next** (specific action the user can take)

**Examples:**

| Bad | Good |
|-----|------|
| "Error 422: Unprocessable Entity" | "That email address is already in use. Try signing in instead?" |
| "An unexpected error occurred" | "Something went wrong on our end. Try again in a few minutes." |
| "Invalid input" | "Names can only contain letters and spaces." |
| "Request failed" | "We couldn't reach the server. Check your connection and try again." |

### Empty States as Onboarding

An empty state (a screen with no content yet) is not an error — it is an opportunity. It is the user's first encounter with a feature, and it should teach them what to do next.

**Good empty state pattern:**

1. A brief explanation of what this area is for (one sentence)
2. A clear call to action (one button or link)
3. Optionally, a short example of what the area looks like when populated

**Example:**
- Bad empty state: "No items found."
- Good empty state: "This is where your team's messages live. Post the first one?" [New Message button]

## The Basecamp Design Process

The design process at 37signals integrates design thinking into every phase of the Shape Up cycle.

**During shaping (before the cycle):**

- The shaper uses breadboards to map the core interaction flow
- Fat marker sketches establish the general layout approach
- Copy is drafted for key screens — labels, button text, primary messages
- No pixel-level design work happens yet

**During building (the cycle):**

- **Days 1-3:** The designer builds the core screen in HTML/CSS with real (or realistic) copy. The programmer connects it to data. The interface is ugly but functional.
- **Days 4-10:** Design and code evolve together. The designer refines layout, typography, and spacing while the programmer implements functionality. They work on the same scopes.
- **Weeks 3-5:** The interface takes its final shape. Copy is refined. Edge cases are designed as they are discovered. Scope decisions happen in real time.
- **Week 6:** Polish. The team reviews every screen for consistency, clarity, and quality. Final copy review. Final visual review.

**Design decisions are made in context:** The designer does not design all screens up front and hand them off. They design each scope as it is built, making decisions with the full context of real data, real interactions, and real constraints.

## Interface Patterns

### Progressive Disclosure

Show the minimum necessary information first. Reveal more detail on demand. This keeps screens clean while still providing depth for users who need it.

**Examples:**
- Show a list of tasks. Click a task to see its details, comments, and history.
- Show a project summary. Expand sections to see individual metrics.
- Show the primary form fields. Link to "Advanced options" for rarely-used settings.

### Confirmation Through Visibility

Instead of showing a success toast or modal ("Item saved!"), make the result of the action visible in the interface itself. The user sees the item appear in the list, the status change, the content update. The interface is its own confirmation.

**When explicit confirmation is needed:**
- Destructive actions (delete, cancel, remove)
- Actions with delayed effects (email sent, payment processed)
- Actions where the result is not immediately visible on the current screen

### One Primary Action per Screen

Every screen should have one primary action — the thing the user is most likely to do. Make it visually prominent. Secondary actions can exist but should be visually subordinate.

**How to implement:**
- One button with the primary style (colored, prominent)
- Secondary actions as text links or muted buttons
- Destructive actions in a separate area or behind a menu

## Anti-Patterns

These are common UI/UX patterns that violate the 37signals approach:

| Anti-Pattern | Why It Fails | 37signals Alternative |
|-------------|-------------|---------------------|
| Dashboard with 12 widgets | Overwhelms; users ignore most of it | Show one thing well; link to details |
| Wizard with 7 steps | Too much friction for setup | Ask the minimum; infer the rest |
| Modal upon modal | Creates navigation confusion | Use full pages for complex interactions |
| Tooltip on every element | Signals that the UI is not self-explanatory | Rename elements to be clear without help |
| "Are you sure?" for everything | Creates modal fatigue; users click through without reading | Only confirm destructive, irreversible actions |
| Custom scrollbars | Breaks platform conventions; accessibility risk | Use native scrollbars |
| Infinite configuration page | Pushes decisions to users who do not want to make them | Pick defaults; reduce options |
| Feature comparison table on pricing | Overwhelms with complexity; induces analysis paralysis | Simple plan descriptions focusing on the job each plan serves |
| Auto-playing animations | Distracts from content; accessibility concern | Static by default; animate only on interaction |
| Notification badges on everything | Creates anxiety; trains users to ignore notifications | Notify only for things that require action |