Getting Real

Getting Real Plot Summary

Introduction

Creating web applications today often means drowning in bloated processes, unnecessary features, and overly complex designs. Many teams find themselves caught in a cycle of planning paralysis, feature creep, and delayed launches that ultimately produce mediocre products. Traditional development approaches focus on lengthy specifications, perfect mockups, and grandiose plans that rarely translate to what users actually need. What if there was a more direct path to building successful web applications? A methodology that emphasizes simplicity, embraces constraints, and focuses on what truly matters. This approach isn't about cutting corners—it's about making deliberate choices that lead to better products, happier teams, and satisfied customers. By stripping away the unnecessary and concentrating on what's essential, you can create applications that solve real problems elegantly and efficiently.

Chapter 1: Embrace Constraints and Stay Lean

Constraints aren't limitations—they're opportunities for creativity. When resources are limited, you're forced to focus on what truly matters. Instead of viewing boundaries as obstacles, successful teams use them as catalysts for innovation. 37signals, the creators of Basecamp, embraced significant constraints during their development process. They had a design firm to run, existing client work to manage, and a small team separated by a 7-hour time difference between Denmark and the United States. Rather than fighting these limitations, they turned them into advantages. The time difference made communication more efficient—instead of lengthy meetings, team members communicated via instant messaging and email, forcing them to be clear and direct. The small team size eliminated bureaucracy and streamlined decision-making. These constraints guided 37signals toward creative solutions. They built less software by giving users just enough features to solve their problems their own way. Rather than trying to address every possible use case, they focused on core functionality that delivered real value. This approach resulted in a leaner, more focused product that resonated with users. To embrace constraints in your own projects, start by identifying your boundaries. How much time do you realistically have? What's your budget? How many people are on your team? Instead of lamenting these limitations, ask how they can guide you toward simplicity. Break large tasks into smaller ones that you can tackle one at a time. Prioritize ruthlessly, focusing on what will deliver the most value with the least effort. The key insight is that constraints force you to make tough decisions early. When you can't do everything, you must decide what's truly important. This leads to more focused, intentional products that solve specific problems well rather than attempting to be all things to all people. By working within your constraints rather than fighting them, you'll create more innovative solutions and avoid the bloat that plagues so many web applications. Remember that some of the most successful products in history emerged from significant constraints. Your limitations aren't holding you back—they're showing you the way forward.

Chapter 2: Focus on the Epicenter of Your Design

Epicenter design means starting with the core of your application—the essential element without which your product would be meaningless—and building outward from there. Unlike traditional approaches that begin with frames, navigation, and marketing elements before addressing core functionality, epicenter design puts the most important elements first. When 37signals designed Basecamp, they identified the core essence of the product: project communication. Instead of starting with navigation schemes or sidebar features, they focused on the message posting interface—the epicenter of the application. They recognized that without effective communication tools, their project management software would fail at its primary purpose. By starting with this essential element, they ensured that the heart of the application received the attention it deserved. This approach continued throughout development. Only after perfecting the central communication tools did they expand to related functionality like to-do lists and file sharing. Each new feature was evaluated based on how it supported the epicenter rather than being added simply because competitors offered it. This focus resulted in a product that excelled at its core purpose rather than being mediocre at many things. To implement epicenter design in your projects, begin by asking what your page or application absolutely cannot function without. For a blog post page, it's the actual post content—not the categories, comments, or navigation. For an e-commerce product page, it's the product information and purchase option. Identify this critical element and make it your starting point. The beauty of epicenter design is that it forces you to confront the most important design and development challenges immediately. Instead of postponing difficult decisions by working on peripheral elements, you tackle the heart of the matter first. This approach not only produces better designs but also allows you to get meaningful feedback earlier in the process. By focusing on the epicenter, you create an application that maintains clarity of purpose throughout development. Additional features serve to enhance the core experience rather than distracting from it.

Chapter 3: Build Less, But Build Better

Building less isn't about cutting corners—it's about being deliberate and focused. The "half, not half-assed" philosophy emphasizes creating a focused product that does a few things extremely well rather than many things poorly. When 37signals launched Basecamp, they started with just the messages section—the heart of the app. They deliberately left out features like milestones and to-do lists initially, even though they planned to add them later. This approach allowed them to perfect the core functionality first and base subsequent decisions on real-world usage rather than assumptions. By starting with a smaller, more focused product, they created a solid foundation they could build upon. This approach stands in stark contrast to the "everything but the kitchen sink" mentality prevalent in software development. Many products fail because they try to please everyone by including every conceivable feature. The result is a bloated, confusing application that does many things poorly rather than a few things well. To apply this principle to your projects, start by identifying the essential elements of your application. What's the 20% of functionality that will satisfy 80% of user needs? Build that first, and do it exceptionally well. Don't worry about feature parity with competitors—focus on creating a superior experience with fewer features. This philosophy extends to every aspect of development. When faced with a complex problem, look for ways to simplify it. Can you solve 80% of the issue with 20% of the effort? That's usually a win, as the original problem is rarely important enough to justify five times the effort. The benefits of building less extend beyond the initial development phase. Less code means fewer bugs, easier maintenance, and greater flexibility to evolve your product over time. It means less support burden and happier customers who aren't overwhelmed by unnecessary complexity. Remember that you can always add features later based on actual user feedback rather than speculation. Starting small and focused gives you the agility to respond to real user needs rather than imagined ones. This approach isn't about permanent minimalism—it's about intentional growth based on genuine requirements.

Chapter 4: Choose the Right Tools for Happiness

The tools you use have a profound impact on your team's productivity, creativity, and overall happiness. Choosing technologies based solely on industry standards or performance metrics misses a crucial component: the human element. When developers work with tools they love, they produce better code and better products. 37signals discovered their programming "bliss" in Ruby, a language designed with developer happiness in mind, and later created Rails, a framework that shares this philosophy. They recognized that happy programmers do the right thing—they write cleaner, more elegant code and approach problems with enthusiasm rather than drudgery. This focus on developer happiness isn't just feel-good philosophy; it directly impacts the quality of the final product. The concept of optimizing for happiness extends beyond just programming languages. It applies to all the tools and processes your team uses daily. When team members genuinely enjoy their tools, they invest more of themselves in their work. They care about craftsmanship and take pride in what they create. This leads to better attention to detail and more thoughtful solutions. To implement this principle, start by evaluating your current toolset. Are team members fighting with their tools or flowing with them? Don't be afraid to try new technologies that might better match your team's working style and preferences. Sometimes switching to a more enjoyable stack can revitalize a struggling project. However, optimizing for happiness doesn't mean choosing the newest or trendiest tools. It means finding technologies that align with your team's values and working style. For some teams, that might mean embracing cutting-edge tools; for others, it could mean sticking with proven technologies that allow them to work efficiently. Remember that different projects may require different tools. Be flexible and willing to adapt your toolset based on the specific needs of each project. The goal isn't to standardize on a single approach but to create an environment where your team can do their best work. By prioritizing tools that your team genuinely enjoys using, you'll foster an atmosphere of craftsmanship and care that translates directly to the quality of your product.

Chapter 5: Listen to Customers, Not Just Features

Building successful web applications requires a delicate balance: you must listen to customers without becoming a slave to their feature requests. The key is understanding the problems behind the requests rather than implementing every suggestion that comes your way. 37signals takes an unusual approach to feature requests: they read them, consider them, and then throw them away. Rather than maintaining an extensive tracking system, they rely on frequently recurring requests to bubble up naturally. If something is truly important, customers will keep asking for it. This organic filtering helps identify which features actually matter versus those that sound good but aren't essential. The company also practices what they call "tough love"—being willing to say no to customers. When building Basecamp, they received numerous requests for comprehensive time tracking, billing, meeting scheduling, and other features. Yet, their surveys consistently showed that what customers valued most was Basecamp's simplicity. By resisting the temptation to add every requested feature, they preserved what made their product special. To implement this approach in your own projects, start by creating direct channels for customer feedback. Make it easy for users to share their thoughts, but don't automatically commit to implementing every suggestion. Instead, look for patterns and recurring themes. What problems keep coming up? What workarounds are customers creating? When evaluating feedback, focus on understanding the underlying problem rather than the proposed solution. Customers are experts at identifying what's frustrating them but may not always suggest the best solution. Your job is to dig deeper and solve the core issue, which might require a different approach than what was requested. It's also crucial to maintain a clear vision for your product. Not every suggestion will align with that vision, and that's okay. Being strategic about which feedback you act on helps keep your application focused and coherent rather than becoming a jumble of disconnected features. Remember that listening to customers isn't about implementing every request—it's about understanding their needs and solving their problems in the most elegant way possible.

Chapter 6: Launch Fast and Iterate Continuously

The traditional approach to software development involves lengthy planning phases followed by a big, high-stakes launch. The Getting Real methodology flips this on its head: launch quickly with a solid core, then improve through rapid iteration based on real-world feedback. 37signals demonstrates this principle with their approach to Basecamp's initial launch. Instead of waiting until every planned feature was perfect, they launched with just the essential messaging functionality. They even launched without a billing system, knowing they had a 30-day window before the first payment cycle to implement it. This approach allowed them to get real user feedback quickly and focus on solving actual problems rather than anticipated ones. After launching Basecamp, they continued to iterate based on user feedback and their own experience using the product. This iterative approach extended to their other products as well. When they launched Backpack, they followed up with a significant update 30 days later, adding features like mobile support and tagging based on customer requests. This "one-month tuneup" showed momentum, demonstrated responsiveness to customer needs, and generated a second wave of buzz. To apply this principle to your projects, start by identifying the absolute minimum viable product—what's the smallest version of your app that delivers real value? Launch with that core functionality, even if it feels incomplete. Then commit to a schedule of regular updates based on actual usage patterns and feedback. Working in iterations offers several advantages. First, it gets your product in front of real users quickly, providing invaluable feedback you can't get from internal testing. Second, it reduces risk by allowing you to adjust course based on real-world data rather than speculation. Finally, it creates a rhythm of continuous improvement that keeps both your team and your customers engaged. Remember that each iteration should be small and focused. Don't try to overhaul everything at once. Instead, make targeted improvements that address specific issues or opportunities. This approach maintains momentum and prevents the paralysis that can come from attempting too much at once. The key insight is that real-world usage will always reveal things you couldn't have anticipated during planning. Embracing this reality and building your process around it leads to better products and happier customers.

Chapter 7: Maintain Simplicity As You Grow

As applications mature, they face a constant threat: the bloat monster. There's a natural tendency to add features, increase complexity, and drift from the original vision that made the product successful. Resisting this tendency is crucial for long-term success. 37signals advocates for maintaining simplicity even as products mature. They emphasize that growth doesn't have to mean complexity—you can add value without adding confusion. Their approach contrasts sharply with traditional software companies that need to justify annual upgrades by adding new features, often leading to bloated products that become increasingly difficult to use. Basecamp exemplifies this philosophy of sustainable simplicity. While it has evolved significantly since its launch, each addition has been carefully considered against the product's core purpose: making project communication simple and effective. Features that would complicate the user experience or dilute the product's focus have been consistently rejected, even when competitors offered them. To maintain simplicity as your application grows, start by establishing clear criteria for evaluating new features. Each addition should be judged not just on its individual merit but on how it affects the overall experience. Will it make the product more coherent or more confusing? Does it support the core purpose or distract from it? It's also important to regularly reassess existing features. Just because something made sense in the past doesn't mean it belongs in the future. Be willing to remove elements that no longer serve your users or align with your vision. This pruning process keeps your application focused and prevents the gradual accumulation of unnecessary complexity. Remember that simplicity isn't just about features—it extends to your entire approach. Keep your team small and agile. Maintain clear, direct communication with users. Resist the urge to add process and bureaucracy as you grow. Each of these decisions helps preserve the essence of what makes your product valuable. The challenge of maintaining simplicity never ends—it requires constant vigilance and sometimes difficult decisions. But the reward is a product that remains true to its purpose and continues to delight users year after year.

Summary

Getting Real represents a fundamental shift in how we approach web application development. It's about embracing constraints rather than fighting them, focusing on what truly matters rather than trying to please everyone, and building products that solve real problems with elegant simplicity. As the authors remind us, "The best designers and the best programmers aren't the ones with the best skills, or the nimblest fingers—they are the ones that can determine what just doesn't matter." Take your first step toward Getting Real today. Choose one project where you can apply these principles—start small, focus on the epicenter, embrace constraints, and launch quickly. You don't need to transform everything at once. Begin with a single application of these ideas and experience firsthand how this approach can transform not just your products but your entire development process. The journey toward simpler, more focused, and more effective web applications starts with that first deliberate choice to do less, but do it better.

About Author

Loading...

Jason Fried

Jason Fried is the co-founder and President of 37signals. Jason believes there’s real value and beauty in the basics. Jason co-wrote all of 37signals books, and is invited to speak around the world on entrepreneurship, design, management, and software.

Read more

Related Books by Jason Fried

Loading...

ReWork

Jason Fried

Unorthodox advice for growing companies

★★★½☆4.0

Loading...

It Doesn’t Have to Be Crazy at Work

Jason Fried

Reclaim your work-life balance

★★★★☆4.0

Loading...

Remote

Jason Fried

Office Not Required

★★★½☆3.8