Getting Real: the smarter, faster, easier way to build a successful web application

As part of my New Year resolutions in 2018 I set myself the goal of reading one book, every month. One of the thirteen that I read, in the end, was “Getting Real – The smarter, faster, easier way to build a successful web application” by the team at 37 Signals (and for those that don’t know they are the people behind Basecamp). For any young professional or entrepreneur out there who wants to succeed in a tech company or build their own then this is your “Bible”. Keep this by your bedside at all times. If you put just half of this into practice then you will not go far wrong.
The clue is in the title as to why I like it so much. “Getting Real” is about building the real thing and bypassing all of the stuff that gets in the way to doing this quickly. It is based on doing less, staying small and agile. It begins with what the customer actually experiences and then building, iterating, tweaking and improving from there. Ultimately it will help you “to deliver just what customers need and eliminate anything they don’t”.
I have pulled out some of the golden nuggets of wisdom below that resonated with me and that we are trying to follow at HeadBox.

1. The Starting Line

Build less.  Do less than your competitors to beat them. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow.
Launch on time and on budget. An easy way to launch on time and on budget is to keep them fixed. Never throw more time or money at a problem just scale back the scope. Figure out what’s really important and set realistic expectations.

2. Stay Lean

Embrace constraints.  There’s never enough to go around. Not enough time. Not enough money. Not enough people. That’s a good thing. Constraints force focus, innovation and creativity and help you to prioritise.
Lower your cost of change. Change is your best friend. The more expensive it is to make a change, the less likely you’ll make it.

3. Priorities

Have a clear product vision. Set measurable product goals. Personify your product and give it a tone of voice.

4. Feature selection

Build half a product, not a half-assed product. Take whatever you think your product should be and cut it in half.
It just doesn’t matter. The answer to the “why didn’t you do this or why didn’t you do that” question is because it just doesn’t matter.

5. Process

Idea to implementation.  Follow four easy steps to go from idea to implementation: Brainstorm, Paper sketches, Create HTML screens, Code it, and be prepared to go through this cycle multiple times:
Decisions are temporary so make a call and move on. Value the importance of moving on and moving forward. Get into a rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.

6. Staffing

Hire less, hire later. Don’t hire if you don’t have to.
Actions, not words. Judge people by what they do not what they say. Look at their contributions with Open Source over a period of time. Look for the zeal to get things done and ship product.
You can’t fake enthusiasm. Find someone who’s enthusiastic. Someone you can trust to get things done when left alone.

7. Interface Design

Design the interface before you start programming. Design is relatively light. A paper sketch is cheap and easy to change. Another reason to design first is that the interface is your product.
Context over consistency. It is better to be right than to be consistent. Give your customers what they need when they need it and get rid of what they don’t. Context over consistency.

8. Code

Write just the code you need.  There’s no code that is more flexible than no code.
Listen when your code pushes back. Is a new feature requiring weeks of time and thousands of lines of code? That’s your code telling you there’s probably a better way.

9. Words

There’s nothing fictional about a functional spec.  Don’t write a functional specs document. Write a one-page story about what the product needs to do.
Build don’t write. Don’t do dead documents, avoid the blockers who want to slow the process down. Build an interface that everyone can start looking at, using, clicking through and feeling before you start worrying about back end code.

 10. Support

Feel the pain.  From the very beginning make it very easy for your customers to get in touch with you. You and your whole team should know what your customers are saying. When your customers are annoyed, you need to know about it. You need to hear their complaints. You need to get annoyed too.
 
Finally, the reason why “Getting Real” matters so much is aptly summed up at the end of the book: “The difference between you and everyone else will be how well you execute. Success is all about great execution”.