Chapter 4
Start With No: The Art of Feature Selection
One of Getting Real's most counterintuitive principles is that your default answer to feature requests should be "no." This stance directly challenges the customer-is-always-right mentality that dominates many businesses. Instead, 37signals argues that the best products come from having strong opinions about what should and shouldn't be included.
Every feature you add is like adopting a child-you'll need to nurture it through design and development, then support it indefinitely once it's released. And once you've added a feature, removing it later becomes nearly impossible without upsetting users who've come to rely on it. This creates a one-way ratchet effect where products inevitably grow more complex over time.
To combat feature creep, Getting Real introduces the concept of "hidden costs"-the cascading implications of seemingly simple additions. Adding a meetings feature to Basecamp might seem straightforward until you consider all the elements it requires: scheduling, reminders, room booking, invitations, calendar integration, plus updating help documentation, marketing materials, and more. What started as a simple request quickly balloons into weeks of work.
Instead of trying to please everyone with endless options and preferences, make opinionated software that takes a stand. Ward Cunningham's original wiki is cited as a prime example-it deliberately omitted many features considered essential to document collaboration, creating something with a strong perspective rather than a bland tool trying to be all things to all people.
When customers ask for features, listen to their underlying problems but don't necessarily implement their suggested solutions. Often, the best approach is to solve general problems and let users create their own specific solutions. When 37signals built Ta-da List, they intentionally omitted task assignment and due dates. Users adapted by creating their own conventions like adding "(due: April 7)" to items. This approach kept the tool simple while making it infinitely flexible.
Remember: it's better to make half a product than a half-assed product. By saying no to most features and focusing intensely on the core experience, you create something that excels at its primary purpose rather than being mediocre at many things.
Chapter 5
Interface First: Design Before You Program
Getting Real flips the traditional development process on its head by starting with the interface rather than technical specifications. This approach recognizes a fundamental truth: to users, the interface is your product. No matter how elegant your code or architecture might be, people experience your application through its interface.
Begin by sketching interfaces on paper-quick, dirty, and cheap. This allows you to experiment with multiple approaches without investing significant time. Once you have promising sketches, move directly to HTML prototypes that look and feel like the real thing. These clickable prototypes provide a tangible experience that everyone can understand, unlike abstract wireframes or specifications that are open to interpretation.
This interface-first approach provides several advantages. First, it keeps you focused on the user experience rather than technical implementation details. Second, it allows you to test ideas with real users before writing a single line of backend code. Third, it creates a shared understanding among team members about what you're actually building.
When designing interfaces, start from the epicenter-the core element that the screen absolutely cannot live without-and work outward. For a blog post page, the post itself is the epicenter, not the header, sidebar, or comment form. This ensures you focus on what truly matters rather than getting distracted by peripheral elements.
Don't forget to design for all three states of your interface: the regular state (when everything's working with data present), the blank slate (what new users see before entering data), and error states. The blank slate deserves special attention as it's a crucial first impression that determines whether new users will stick around. A good blank slate should include tutorials, examples, and clear next steps.
Words matter as much as pixels in interface design. Every button label, error message, and instruction is part of your interface. Use clear, human language rather than technical jargon. Consider your product's personality-should it be formal or casual, serious or playful?-and ensure the copy reflects this consistently.
By starting with the interface and working backward to the code, you ensure that what you build actually solves real user problems in an intuitive way.
Chapter 6
From Idea to Implementation: The Getting Real Process
The Getting Real process replaces traditional waterfall development with a rapid, iterative approach focused on getting to working software as quickly as possible. This process isn't about skipping planning-it's about planning through action rather than through documentation.
Begin by brainstorming high-level ideas about what your product should do. For Basecamp, this meant focusing on their own needs: posting project updates, enabling client participation, tracking milestones, and centralizing project archives. Keep this stage focused on big questions rather than nitty-gritty details.
Next, sketch rough interface ideas on paper. These aren't meant to be pretty-they're thinking tools that help you explore possibilities cheaply before committing to code. Once you have promising sketches, immediately create HTML versions of key screens. This gives everyone something real to react to, avoiding abstract discussions about features.
Only after you have working HTML mockups should you begin writing the actual programming code. This approach ensures you're building the right thing before investing in backend development. Throughout this process, stay flexible and expect multiple iterations. Don't be afraid to throw away work that isn't meeting your goals.
Work in small batches, focusing on one feature at a time rather than trying to build the entire application at once. This creates a rhythm of regular victories that maintains momentum and morale. Even during lengthy development cycles, dedicate time for small wins-things you can complete in just a few hours like improved help text or streamlined forms.
Avoid creating "dead documents" that don't transform into something real. Every artifact you produce should evolve directly into the final product. If a wireframe won't become the actual design, don't bother creating it. Similarly, don't write functional specifications-they create only an illusion of agreement while forcing decisions to be made when you have the least information.
Instead of detailed specs, write brief stories in conversational language that explain features from a human perspective. For example: "When a customer signs up, they'll receive a welcome email with their login information and links to getting started guides." These stories initiate conversation without locking you into specific implementations.
The key to this process is maintaining momentum by constantly producing working software rather than documentation. As the authors put it: "Running software builds momentum, rallies your team, and flushes out ideas that don't work."
Chapter 7
The Right People: Building Your Team
The Getting Real approach demands a different kind of team than traditional software development. Instead of specialists with narrowly defined roles, you need versatile generalists who can wear multiple hats. In a small team, everyone must be able to step outside their comfort zone and contribute wherever needed.
Start by hiring less and hiring later. Before bringing on new people, question whether the work is truly necessary-can you solve the problem with software or process changes instead? When you do hire, look for well-rounded individuals rather than specialists. You need designers who can write, programmers who understand design, and everyone should grasp information architecture.
Writing ability is particularly crucial. Regardless of position-designer, programmer, marketer-always hire the better writer. Good writers communicate effectively, make complex concepts easy to understand, think clearly, and can put themselves in others' shoes. These qualities translate to better code, design, emails, and documentation.
Before hiring anyone permanently, test-drive them with a small project. Even 20-40 hours of collaboration will quickly reveal if there's a good fit in terms of work quality, communication style, and team chemistry. For technical roles, judge candidates by their open source contributions rather than degrees or resumes. Open source participation reveals what truly matters: quality of work, cultural perspective, passion level, and social skills.
Perhaps most importantly, you can't fake enthusiasm. Look for people who are genuinely excited about your project and ask thoughtful questions. A happy but average employee will consistently outperform a disgruntled expert. Find people who have suffered at bigger, slower companies and are eager for a new environment where they can make a real impact.
The team structure should remain flat and integrated rather than siloed. Don't separate your organization into design, development, copywriting, and support departments. While specialization has advantages, it creates a situation where staff only see their small world instead of the entire context. Instead, ensure everyone understands the big picture and can contribute across traditional boundaries.
Remember that people need uninterrupted time to get work done. Create "alone time" where team members can work without interruptions. Getting into a productive flow state takes time, like reaching REM sleep, and interruptions force you to start over. Set up rules: make half the day interruption-free with no meetings, phone calls, or instant messages.
Chapter 8
Less Code, More Happiness: The Technical Approach
Getting Real's technical philosophy centers on a counterintuitive idea: the best code is code you don't write. More code creates exponentially more complexity, not just linearly more. Each addition, change, interdependency, and preference has cascading effects that can create what programmers call a "Big Ball of Mud."
The solution is less software-fewer features, less code, less waste. Instead of solving hard problems that require extensive software, restate them as simpler problems requiring much less code. Solving 80% of the original problem for 20% of the effort is a major win. This approach brings substantial benefits: easier management, less maintenance, lower costs of change, fewer bugs, and reduced support needs.
When choosing programming tools, optimize for developer happiness rather than just technical performance. Happy programmers are productive programmers. Languages and frameworks aren't created equal-the right ones make daily work enjoyable rather than just bearable. For 37signals, this meant embracing Ruby and Rails, both designed with developer happiness in mind.
Listen to your code when it pushes back. If implementing a feature requires weeks of time and thousands of lines of code, that's a signal to reconsider your approach. Conversely, when an easy implementation path emerges, even if it's not exactly what you originally envisioned, it's worth considering. Your code can guide you toward solutions that are cheap and light if you're willing to listen.
Recognize that you'll occasionally take on technical debt-quick-and-dirty solutions implemented for speed. This is acceptable and sometimes necessary, but you must acknowledge it as debt and plan to pay it off. Regularly allocate time to clean up problematic code, just as you would set aside money for taxes.
Don't lock in your customers-let their information flow freely. Provide RSS feeds so users can access their data without repeatedly logging in. Offer APIs that allow third-party developers to build on your platform, expanding its possibilities. When Backpack offered an API, a third-party developer created a valuable Mac OS X Dashboard widget that some customers cited as their reason for using the product.
Finally, avoid premature optimization for scale. Most web applications never reach massive scale, so wait until you actually have scaling problems before investing significant resources in solving them. Basecamp ran on a single server for its first year, implementing more robust infrastructure only when needed based on real-world usage patterns.
Chapter 9
After Launch: Keeping the Momentum
Launching your application isn't the finish line-it's just the beginning. The post-launch period is crucial for establishing momentum, building customer loyalty, and refining your product based on real-world usage.
Plan a major update approximately 30 days after launch. This creates a second wave of buzz, reaffirms initial good feelings, and shows customers you're actively improving the product. This approach lets you focus on perfecting core features before launch, then address customer priorities afterward. When Backpack launched, the team focused on the base product first, then added requested features like mobile access and tagging a few weeks later.
Maintain a dedicated product blog that you update at least weekly with FAQs, how-tos, tips, new features, and fixes. A frequently updated blog shows your app is alive and makes your company seem more human. Don't be afraid to sound small and friendly-customers appreciate the personal touch rather than corporate-speak.
When you introduce changes, expect initial resistance. After new features or policy changes, negative feedback will pour in immediately. Resist the urge to panic or make rapid changes in response. Wait 24-48 hours for things to settle, as most early reactions come before people have fully explored the changes. Remember that negative reactions are almost always louder than positive ones, even when most users are happy.
Be transparent about mistakes. When something goes wrong, tell people-even if they never noticed the problem. Most customers give you breathing room when you're honest. Get bad news out all at once, but trickle good news out slowly to maintain a steady stream of positive developments.
Don't hide behind the "beta" label indefinitely. An interminable beta stage tells customers you're not committed to a finished product. Take ownership of your release-put it out and call it a release. Don't wait for perfection; it will never happen.
Prioritize bugs rather than panicking about every one. All software has bugs-it's a fact of life. Assess how many people are affected and how severe the problem is. Some annoyances can wait while you focus on critical issues or even new features that would benefit more users.
Most importantly, resist the temptation to add complexity as your product matures. Don't inflate features just for the sake of growth-that's how applications get bloated. Be willing to admit mistakes and change course when necessary. Like a surfer, watch where the big waves are breaking and adjust accordingly.
Chapter 10
Beyond Software: A Business Philosophy
While Getting Real is ostensibly about software development, it ultimately presents a comprehensive business philosophy that extends far beyond coding. At its heart is a rejection of conventional business wisdom in favor of a more authentic, human-centered approach.
This philosophy starts with how you fund your business. Seeking outside investment should be plan B, not your first priority. When you fund yourself, you maintain control and focus on building quality rather than cashing out quickly. Today's low hardware costs and free open source software mean you can start with minimal capital. If your idea works, you'll become self-sustainable; if not, you can pivot easily without investor complications.
Marketing follows similar principles-focus on education rather than promotion. Share knowledge freely through blog posts, speaking engagements, and even books. This creates goodwill while simultaneously generating exposure. When 37signals published articles about their design techniques or open-sourced Ruby on Rails, they weren't just being generous-they were building their reputation and attracting customers who shared their values.
Customer relationships should be straightforward and honest. Make signup and cancellation equally painless. Provide prominent signup buttons and keep forms short. Allow customers to export their data easily-this builds trust by giving them control over their information. Avoid manipulative business practices like long-term contracts or early termination fees. Opt for straightforward month-to-month billing that customers can cancel anytime.
Support should come directly from the people who build the product. Don't outsource customer service-have developers personally handle support emails. This provides better customer experience and keeps developers connected to real user needs. At 37signals, developers answer support queries themselves, allowing them to truly empathize with customer pain points.
Pricing should include a free option to let people experience your product's value. Once they're hooked, they're more likely to upgrade to paid plans. When delivering news like price increases, soften the blow by giving plenty of advance notice and considering grandfather clauses for existing customers.
Throughout all aspects of business, maintain a human voice. Think of your product as a person with specific personality traits-polite or stern, forgiving or strict, funny or deadpan. Use these traits consistently to guide copywriting, interface design, and feature development. Your product has a voice that speaks to customers 24 hours a day, so make deliberate choices about what kind of personality it projects.
This business philosophy-focused on independence, honesty, education, and human connection-creates sustainable companies that customers genuinely love rather than merely tolerate.
Chapter 11
The Real Revolution: Changing How We Work
The most profound impact of Getting Real isn't just in the products it helps create, but in how it transforms the work experience itself. By rejecting bloated processes and unnecessary complexity, it offers a more fulfilling way to build software and run businesses.
Traditional software development often feels like a chore-endless meetings, documentation no one reads, features no one uses, and frustration at every turn. Getting Real proposes a radical alternative: work should be enjoyable. If building your app feels like drudgery, something's wrong. Your passion-or lack thereof-will inevitably show in the final product.
This philosophy challenges the notion that professional software development must be formal and bureaucratic. Instead, it celebrates the craftsmanship aspect of building digital products. When you strip away unnecessary meetings, documentation, and features, you create space for people to do their best work and take pride in what they create.
The approach also democratizes software development. By emphasizing small teams, bootstrap funding, and focused products, Getting Real makes building successful web applications accessible to more people. You don't need venture capital or a large team-you just need a real problem to solve and the discipline to focus on what matters.
Perhaps most importantly, Getting Real reconnects developers with the purpose of their work: solving real problems for real people. By building software that addresses your own needs first, you maintain a direct connection to the value you're creating rather than becoming disconnected through layers of requirements and specifications.
The revolution isn't just about building better software-it's about building a better way to work. One where passion, craftsmanship, and purpose replace bureaucracy, bloat, and burnout. One where small teams can compete with industry giants by focusing on what truly matters. One where work feels less like a chore and more like a creative expression.
As the authors conclude: "The key to success is execution. Anyone can have ideas, but the difference is how well you implement them." By embracing the Getting Real philosophy, you're not just changing how you build software-you're changing how you experience work itself.
