Getting Real - What I Learned from 37signals

Start out by solving your own problems, by scratching your own itch.

I read Getting Real while thinking through a few business ideas. The book is short and blunt - it doesn’t hedge. What follows is my distillation, with the questions I asked myself as I worked through each section.

The Idea

Build something you personally need. If you’re solving your own problem, you already understand it better than any market research will tell you. You’ll know when the solution feels right.

• Define a one-line vision. It forces clarity and becomes the filter for every decision after.
• Find your enemy. Who are you building against? What does the obvious solution get wrong? That gap is your positioning.
• Bootstrap if you can. Outside money changes the relationship to the work. You’re no longer building to solve the problem - you’re building to hit returns on someone else’s timeline. Constraints, including financial ones, tend to produce better decisions than abundance does.

Questions to ask:

• What is the problem? Do you have personal experience with it?
• Why does your product exist, and what makes it different?
• Who are the customers who share your vision of it?
• Who is your enemy, and why would you pick a fight with them?
• Can this be bootstrapped, or does it require outside money? If the latter - why?

The MVP

Ship the smallest thing that works. Then cut it further.

The longer a product takes to build, the less likely it is to launch. Scope creep isn’t just a project management problem - it’s a motivation problem. Every feature you add before launch is a reason to delay.

• Set a deadline and a budget. Never extend either - cut scope instead.
• Write less code. Every line you write has to be read, maintained, and eventually changed.
• Do less than your competitors. A focused product beats a bloated one.
• A team of three is enough for a first version: a designer, a programmer, and someone who handles everything else. If you need more than three, you’re either building too much or have the wrong people.

Questions to ask:

• What are the minimum features the first version needs to work?
• Can you cut any of them and still have something worth shipping?

The Product

Simple products are easier to change. And you will need to change - your first assumptions will be wrong in ways you can’t predict.

• Less code means fewer bugs, less maintenance, and more time. This is arithmetic, not philosophy.
• Build for the problem you have now, not the scale you hope to have later. Premature optimization is how you end up rebuilding everything before you have users.
• Every configuration option is a decision you’re pushing onto the user. Make the decision yourself.

The Process

Work in short cycles. Ship something real regularly - it keeps the work honest and the feedback loop short.

• Break large tasks into small ones. Work on one at a time.
• Prioritize as you go. You’ll have better information later than you do now, so make decisions late.
• Meetings are expensive. A one-hour meeting with five people costs five hours of work.
• Don’t be precious about the first version. You’re going to revisit it. Ship it, learn from it, improve it.
• When the deadline arrives, cut features - never cut the deadline.

The Features

Every feature has a cost beyond the initial build. It has to be designed, developed, tested, documented, supported, and maintained. That cost compounds.

• Make features earn their place. The default answer to a feature request is no.
• Don’t add features because your competitors have them. Build what your vision requires.
• When users request something, read it, then wait. If it’s genuinely important, it comes up again. If it doesn’t, it probably wasn’t.

Questions to ask:

• Does this feature directly serve the vision?
• Does it change how users behave, or how you operate? If neither, skip it.

The Users

Find a niche and serve it well rather than trying to build for everyone. A product that does one thing exceptionally for a specific group of people is more valuable than one that does many things adequately for nobody in particular.

• Err in favour of your users when there’s doubt.
• Communicate regularly and personally. Users who feel heard stay.

The Team

A good team member knows what matters without being told. They can distinguish between the urgent and the important, make decisions independently, and aren’t waiting for permission to solve problems.

If you have to micromanage someone, that’s a hiring problem, not a management one.

Questions to ask:

• Will the vision motivate the team to keep coming back?
• Are people making decisions on their own, or waiting to be told what to do?

---

The through-line across all of it: build less, ship sooner, stay close to the problem. The book is available to read free at gettingreal.37signals.com.