Book Review: Getting Real

Getting Real1 is a great guide by the team at 37Signals on building software faster and smarter. With 14 chapters and 171 pages, it’s a quick read—thankfully 😇 short and to the point. Here’s a breakdown of the core ideas:

1. Starting Line

Defensive companies can’t think ahead; they can only think behind. They don’t lead; they follow.

  • Build for yourself
  • Fund yourself
  • Constraints force creativity
  • Fix time and budget; flex scope
  • Pull back scope to stay focused
  • Prioritize, stay flexible, and be realistic
  • Have an enemy
  • Microsoft Project 👹 vs Basecamp 🧗
  • Godin’s advice: – ‘Be a better liar
  • It shouldn’t be a chore

2. Stay Lean

  • Less is more
    • Mass is created ↑ by thick process, lock-ins, closed data formats, office politics etc.
    • Mass is reduced ↓ by simplicity: fewer features, pared-down interface, OSS, and an open culture
  • Startups are cool because can change their minds 🧠 quickly
  • Lower your cost of change
  • Emergence: Complex properties arise naturally within a system
  • The 3 Musketeers: A team of 3 for version 1 is often ideal
  • Embrace constraints
  • Be yourself

3. Priorities

  • Focus on the big idea
  • Ignore details early on
  • Tackle problems only when they arise (it’s a problem when it’s a problem)
  • Hire the right customers
  • Scale later

4. Feature Selection

  • Build half a product
  • It just doesn’t matter – start small
  • Start with no
  • Hidden costs are often overlooked
  • Forget feature requests: read them and then discard them
  • Hold the mayo – keep it simple

5. Process

  • Race to running software
  • Get something up quickly and iterate
  • Work in iterations
  • Don’t expect to get it perfect the first time; let it morph + evolve 🦎
  • From idea to implementation
    • Brainstorm 🧠⛈️ → sketches → HTML → coding
  • Avoid preferences
    • Preferences are evil as they create more software
  • Done!
    • Decisions are temporary so make the call and move on
    • Ideas are just multipliers (max double digits) times execution (worth millions)
    • Test in the wild
  • Shrink your time
    • Are you facing a Big problem?
    • Break it down into smaller pieces

6. The Organization

  • Unity over silos
  • Alone time = productivity
  • Meetings are toxic – keep them small and purposeful
    • Set a timer
    • Invite as few people as possible
    • Have a clear agenda
  • Seek and celebrate small victories
    • The most important thing in software development is motivation
    • 4-hour quick wins (builds morale, ↑ motivation, reaffirms team is → right direction)

7. Staffing

  • Hire less, hire later
  • Brooks’ Law: Adding people to a late project makes it later
  • Kick the tires 🚗 (take potential new team members on a test drive)
  • Look for actions, not words
  • Judge hires on OSS contributions
  • Some qualities to look out for include
    • Quality of work
    • Cultural perspective
    • Level of passion
    • Completion percentage
    • Social match

If you want something done, ask the busiest person you know

  • Get well rounded individuals
  • You can’t fake enthusiasm
  • Happy + average > frustrated + great
  • Wordsmiths
    • Hire good writers (when deciding over a designer, programmer, marketer, salesperson, etc.)
    • Good writers know how to communicate

8. Interface Design

  • Interface first: Design it before you start coding
  • The interface is your product
  • Epicenter design: start from the core + build outward
  • Three-state solution: regular 💚, blank 🤍, error 🔴
  • Context is more important than consistency
  • Good copywrighting is key to effective interface design

9. Code

  • Keep code simple
  • Avoid unnecessary software
  • Optimize for happiness – simplify your codebase
  • Solving 80% of the problem for 20% of the effort is a major win
  • Look for ways around writing more software
  • Complexity doesn’t scale linearly with size2
  • Don’t seal in data – let it run wild with APIs and RSS feeds

10. Words

  • Skip the functional spec

A “spec” is close to useless. I have never seen a spec that was both big enough to be useful and accurate. – Linus Torvalds (from Linux: Linus On Specifications3)

  • Use real words, not lorem ipsum
  • Personify your product to make it relatable

11. Pricing and signup

  • Free samples to encourage singups
  • Make signups and cancellations easy

12. Promotion

  • Hollywood Launch ⭐: Teaser → Preview → Launch
  • Ride the blog wave to generate buzz (can be more effective than advertising, and it’s cheaper)
  • Track your logs and engage with your community
    • Leave comments on blogs
    • Thank people for posting links
  • Create ‘buzz’ page to hype your product

13. Support

  • Feel the pain and respond quickly
  • DIY support – let users help each other
  • Tough love: Sometimes. the customer is not always right
    • Decided not to support IE5 (7% of market)
  • Publicize your mistakes – transparency builds trust

14. Post-Launch

  • One-month tune-up: Release a major update 30 days after launch
  • Blog regularly to show your app is alive ⛹️‍♀️
  • Focus on important bugs and avoid bloat 👻
  • some bugs are more important
  • Go with the flow – be open to change

Conclusion

This is the third book I’ve read from team 37signals (after Remote, and Rework), and I continue to appreciate their minimalist philosophy.

Like Amazon’s “Day 1″ mentality, it encourages simplicity, speed and constant iteration.

Overall I’d give Getting Real ★★★★☆.


Extra Reading

  • The Pragmatic Programmer – Andrew Hunt, David Thomas
  • The Dip: A Little Book That Teaches You When to Quit (and When to Stick) – Seth Godin
  1. https://basecamp.com/gettingreal ↩︎
  2. Embedded Systems Programming, September and October, 1998https://www.ganssle.com/articles/keepsmall.htm ↩︎
  3. https://yarchive.net/comp/linux/specs.html ↩︎

Leave a Reply

Your email address will not be published. Required fields are marked *