Getting Real [Review]
Dec 04, 2013
Table of contents:
Getting Real: The smarter, faster, easier way to build a successful web application is a guide to creating better, more successful web applications from the people behind 37Signals.
The philosophy behind Getting Real is how to make your project as simple, clear and concise as possible. By reducing scope and complexity, you end up with a better product that is more in tune with the needs of the user and more flexible to the changing needs of your business.
Much like the philosophy, each chapter is short and to the point. Each chapter is further broken down into sections that have one clear message. Quotes and excerpts are sprinkled throughout each chapter from notable people who share the Getting Real thesis.
The Starting Line
One of the defining principles of Getting Real is, you should aim to build less than your competition. Integrating less features makes for a clear, more focused product and less overhead in terms of design, code and maintenance.
Feature creep is like a cancer of web applications and so Getting Real advocates that your should have a fixed time and fixed budget, but a flexible scope. This means, if you can’t ship the product within the time and the budget constraints, reduce the scope.
One of the beautiful things about developing for the web is you can constantly iterate on your work or add features at a later date. By reducing the scope, you end up with a more focused product that is delivered to meet the needs of the business.
Stay Lean
When you reduce the scope, you can also greatly reduce the mass of the project as a whole. Projects that have less mass are more flexible to the needs and requirements of the market. This gives you a big advantage over your well-funded competitors who require months or even years to respond to customer feedback.
Ideally you should be able to create a product with 3 or less people. Metcalfe’s Law states, communication increases in complexity exponentially as more people are added. By embracing the constraints of working as a small team and on a focused feature set, you will produce a product that is easier to maintain and better prepared to react to the market.
Priorities
In order to ship software quickly, you need get your priorities right. During the initial stages of building the product, you need to ignore the finer details. If you concentrate on the details too early, you will never get to finish the product.
Instead of worrying about every little detail, get rough working prototypes into as many hands as possible. Refine the big ideas before you concentrate on the details.
It can be difficult to focus on today’s work because you are thinking about the potential future problems you might face. Scaling isn’t an issue until you need to scale and adding that “nice to have” feature isn’t something you should think about until it is actually hurting you not to have it.
Whilst you should listen to your customer’s feedback, you can’t allow it to dictate your plans. You should build the best solution to the problem that you are trying to solve rather than caving to every feature request that a potential customer requires in order to use your software.
Feature Selection
Your customers will naturally have a wide selection of feature requests that they want to see in your product. Sometimes it will be making existing features more comprehensive, but sometimes it will be adding a whole new set of functionality to achieve an adjacent goal.
You should always say no to feature requests. Getting Real even advocates not recording feature requests at all. Instead, allow your customers to constantly ask you for a feature they want. If enough people ask for a particular feature, you don’t need a list to remind you.
Adding new features adds complexity to a product and overhead to maintain. Adding something new is not just about the code that needs to be written, but also about the design of the interface, documentation, support materials, marketing materials as well as a whole set of other hidden costs.
Instead of building features for every specific request, try to build general tools that allow your customers to solve their problems in their own way. People want to use a tool that fits their workflow. You will never be able to build specific tools for each customer’s unique workflow.
Process
The longer the you delay putting your product out there for the world to see, the longer you are delaying finding out the truth about whether the market wants it or not. By hiding your product behind closed doors or in complicated specification documents, the costlier this realisation will become.
Don’t try to build perfect software, build something that you can ship and get into the wild. Once you have real world usage you can begin to iterate on customer feedback and real data.
Don’t create superfluous features, customisation options or preference tools, just ship the basic product so you can start the learning feedback loop as quickly as possible.
Conclusion
Getting Real is like the bible of developing web applications. It is broken down into 14 sections that guide you from conception through execution and launch. Each chapter is short and to the point which makes consuming the entire book in one sitting enjoyable and refreshing. I’ve read Getting Real multiple times now and I keep going back if I feel that a project I’m working on is straying from these guiding principles.
If you are involved with creating web applications as a developer, designer or product manager, you owe it to yourself to read Getting Real and use it as your guiding light for creating high quality, successful products.
Buy Getting Real on Amazon (Affiliate link)
