It’s been raining for WEEKS here in Boston.  As many of you know we are all remote here at BSA and I am still running BSA “HQ” from a home office (well, our empty bedroom), and, with only the dog to talk to during the day, I was really starting to feel like the world was going to end.  SO, I was in need of some inspiration.  Lucky for me I stumbled across 37signals book, Getting Real: Discover the smarter, faster, easier way to build a successful web-based application.  And, despite the fact that we already have our web app built, I had a feeling that this would be a nice read to spark some inspiration and get me out of my funk.  It’s a quick read, I was able to get through it in a few hours or so (and I’m a slow reader).

Here are 10 Key Takeaways that stuck with me after reading the book:

(book image taken from 37signals website)

1. Constraints force creativity / Stay lean.

Surely, you’ve heard this before, and that’s because it’s true.  Having naturally imposed constraints, whether it be monetary, bandwidth (people), or time related can be a really good thing.  It forces you to be efficient, creative and find ways to make things work with what you’ve got.  When I first launched BSA I was working another full-time job.  And, being the honest chap that I am I could only work on BSA before 9am and after 7pm (I was at another startup that I was truly passionate about too, so it wasn’t the standard 9-5).  That meant waking up at 5 or 5:30 and answering support emails, all of them, and then working on the site late at night.  Having those time and bandwidth constraints forced me to be really good at solving problems quickly.  Which, in turn, helped set the pace for quality support here at BSA.

2. Lower your cost of change.

One of the most frustrating aspects for me while working at other companies was that to get something DONE it really took a lot of effort.  That might sound lazy, but what I’m saying is that I just like to get sh*t done and move on.  There’s no reason why changes to web apps should become big monolithic projects.  Small teams have a much lower cost of change because there are fewer cooks in the kitchen.  I really like this quote from Andrew Hunt in The Pragmatic Programmers (that’s quoted in Getting Real):

“The harder we tighten things down, the less room there is for a creative, emergent solution.  Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.  Keep it small.  Keep it simple.  Let it happen.”

3. Don’t sweat the small stuff at first, just get something live.

More than anything, your app just needs to *work* and it needs to be *out there*.  When I first launched BSA it looked OK, but it was actually pretty awful looing back now.  The first version of the app worked, it was solving a problem, and that’s why people liked it.  Sure, there were issues here and there, but for the most part things just worked.  It’s a web app, you can iterate, change, and improve something every day.

Who cares if it’s NOT going to scale – worry about that when you get there.  Surely, if you need to scale your app because it’s growing quickly and bursting at the seams, you will figure it out.  Do you think we planned to serve billions of impressions per month when we first launched BSA?  No way, but it became a possibility very quickly and we then figured out how to scale (and we’re still figuring out how to scale it beyond that now).

4. Be open, share ideas.

If you can’t pull it off, your “idea” isn’t worth much.  This one is courtesy of Derek Sivers (president and programmer, CD Baby and HostBaby):

“It’s so funny when I hear people being so protective of ideas [like when someone asks you to sign an NDA].  To me, ideas are worth nothing unless executed.  They [ideas] are just a multiplier. Execution is worth millions… The most brilliant idea, with no execution, is worth $20.  The most brilliant idea takes great execution to be worth $20,000,000.”

LOL, while writing this post I received a call from someone who told me they wanted to use BSA, and were asking for advice, but couldn’t tell me what their site or idea was because I hadn’t signed an NDA.  Boy did I get a nice chuckle ;)

5. Communication in your app is key.

Having a really good writer on your team is important.  The ability to provide clear, concise communication in your web app is vital.

“… being a good writer is about more than words.  Good writers know how to communicate.  They make things easy to understand.  They can put themselves in someone else’s shoes.  They know what to omit.  They think clearly.  And those are the qualities you need.”

6. Spend less time in Photoshop, work on the interface before you begin coding (server-side stuff).

I like to call this “designing in code”.  And, I don’t know about you, but I love Photoshop… however, I prefer to spend as little time in Photoshop as possible.  Whenever I’m working on a comp, I get so anxious to actually start coding that I tend to abandon Photoshop as soon as I have a clear vision in my mind of where I’m going with things.  There are many advantages to this approach in my mind:

• You will tend to end up using less images in your layouts, which is a good thing.
• You’re working on something that’s actually working, people won’t need to use their imagination to figure out what it’s going to look like once converted to HTML/CSS/JS.
• You can spend less time worrying about pixels and more time worrying about how things work, because you can easily tweak the pixels later.

If you are a programmer, I hope you will agree with me (and 37signals) on the second part of this takeaway: work on the interface before you begin coding (server-side stuff).  If your web app is some amazing patentable algorithm you will need to have that first, but we’re not talking about stuff like this.  Imagine yourself as a programmer and I hand you an HTML file for a screen and say “this is what I want it to look like, and this is how I want it to work”.  Chances are, having that visual piece in front of you will clear up many questions you may have had and speed up the development process.

7. Give your app a personality.

On page 123, “Your product has a voice – and it’s talking to your customers 24 hours a day.”  This doesn’t mean that it needs to be witty or anything like that, it just means that it needs to have tone and some sort of personality.

8. Pay it forward.

I’m a big believer in having “good karma” (if you don’t believe me, take a look at our footer).  In other words, don’t be a jerk.  Help people out, be kind when you reply to support tickets.  Even if someone isn’t a customer or isn’t your biggest customer you should still treat them like they are.  Even if they don’t become a customer (ever) maybe they will say something nice about you (or NOT say something bad about you) if you are kind, helpful, and respectful.

9. Don’t outsource support, get in the trenches and feel your users pain.

I was very happy to see this in the book, because I’m very very active in support at BSA.  I really enjoy interacting with our users, and it’s the best way for me to keep “tabs” on the overall vibe of the business.  I can’t remember exactly where I saw this a few months ago, but someone once said something like this about BSA, “the guy who owns it still answers all of the support questions, that’s crazy, they must not be a real company”.  I was blown away… I thought to myself “I would be PSYCHED if I called or emailed a company and the owner of that company was the one to respond”.  Surely, there may come a time when I can’t answer the majority of the support cases like I do now, and we’ve had awesome help from @mkammerer and @scorpiono for months in support, but it’s not something I plan to let go of anytime soon.  In addition, the book says that programmers (and the whole team in general) should be involved in support.  This is an *awesome* idea, and pretty soon BSA users will see our lead developer, Nathan, answering some support emails.

“Do it yourself.  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.”

They go on to say that at 37signals all of the support emails are answered personally by the people who actually built the product.  I tested this real quick, and it’s true.  That is super cool.

10. Beta is “bullshit”.

I will have to confess, for about a year we said that BSA was in “beta”.  In reality, it’s because we didn’t have the guts to tell people we didn’t want to have their site listed in our inventory.  It was our way of “protecting” ourselves from people having a bad experience (i.e. us not listing their site in inventory since we didn’t think we could sell ads on it).  We meant well, we really did, but this wasn’t a good way to go about it.  What we should have done (and something we still need to do more of) is educate people about why it is easy for us to sell ads on some sites and hard on others.  Gmail and a bunch of other Google products recently came out of beta, maybe they just finished reading Getting Real too ;)  The point is that “beta” is a scapegoat…

“Beta passes the buck to your customers… Private betas are fine, public betas are bullshit… Don’t wait for your product to reach perfection.  It’s not gonna happen.  Take responsibility for what you’re releasing.”

Conclusion

The book is AWESOME.  Really, if you are building, have built, or work on ANY product (web-based or not) you must read this book.  I could have titled this “50 Takeaways” and gone on much longer, there is just so much good content in this book.  It’s short, to the point, and is a great way to find some inspiration and new ideas to give you a little extra hop in your step.  Please, go read it now: Getting Real.