My takeways form 37Signals’s books


I was really engaged by 37signal company philosophy in the last month, I definitely love their model and what they built in this last 10 years!

I just finished both their two books, Getting Real and Rework. I would have discovered them before! It is really amazing how a book from 2003 is still so actual! Both are really effective, synthetic collection of suggestions and insight about how to develop a web apps in a smarter, effective and easier way, while demystifying many assumption about the best practice, as supposed to be.

Actually, Rework is using most of the ideas from Getting Real, adding some more inspiration. It also include many principles of the Agile movements, such as releasing frequently and early on top of all.

I imagine it worked for me as a boost since I believed some of these things prior to reading the book who, now reaffirmed, can point others to it as an external and respected source.

There are several good reviews and summaries of the book online. I prefer to copy here highlight form the kindle edition, which catch the most meaningful phrased from each chapter and i think they get to overall idea quite well.

Kindle highlights

The answer is less. do less than your competitor to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.
A great way to build software is to start out by solving your own problems. You’ll be he target audience and you’ll know what’s important and what’s not. That gives you a great head start on delivering a breakout product.
Do what you can with the cash on hand. Think hard and determinate what’s really essential and what you can do without.
Run on limited resources and you’ll be forced to reckon with constraints earlier and more intensely. And that’s a good thing. Constraints drive innovation.
Here’s an easy way to lunch on time on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope.
  • You have to figure out what’s really important
  • Setting expectations is key
  • Injecting scope flexibility will introduce options based on you real experience building the product.
Sometimes the best way to know what your app should be is to know what is shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.
Overanalyze other products and you’ll start to limit the way you think. Take a look and then move on to your own vision and your own ideas.
Instead, you must tell a different story and persuade listeners that your story’s more important that the story they currently believe.
If your app doesn’t excite you, something’s wrong. If you’re only working on it in order to cash out, it will show. Likewise, if you feel passionately about your app, it will come through in the final product. People can read between the lines.
American business at this point it really about developing an idea, making it profitable, selling it while it’s profitable and then getting out or diversifying.
Mass is reduced by:
  • Just-in-time thinking
  • Multi-tasking team members
  • Embracing constraints, not trying to lift them
  • Les software, less code
  • Less features
  • Small team size
  • Simplicity
  • Pared-down interfaces
  • Open-source products
  • Open data formats
  • An ope culture that makes it easy to admit mistakes
Less mass let you change direction quickly. You can react and evolve. You can focus n the good ideas and drop the bad ones.
Change is your best friend. the more expensive is it to make change, the less likely you’ll make it. Ad if your competitors can change faster than you, you’re at a huge disadvantage. If change get too expensive, you’re dead.
Keep it small. Keep it simple. Let it happen.
Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).
Remember, i is OK to keep your first version small and tight. You’ll quickly get to see if your idea has wings and, if it does, you’ll have a clean, simple base to build on.
The efficiency of the team is approximately the inverse of the square of the number of members in the team.
Let limitations guide you to creative solutions.
A lot of small companies make the mistake of trying to act big.. I’s as if they perceive their size as a weakness that need to be covered up. Too bad. Being small can actually be a huge advantage, especially when it comes to communication.
The better course would have been to be proudly, defiantly truthful about the exact size and breadth of the company.
No matter what business you are in, good customer service has got to be the biggest request that any client will ever make.
Don’t worry about the size of your headline font in week one. You don’t need to nail that perfect shade of green in week two. You don’t need to move the “submit” button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
Don’t waste time on problems you don’t have yet.
Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention to the things that require immediate care.
Find the core market for your application and focus solely on them.
The customer is not Always right. The truth is you have to sort out who’s right and who’s wrong for your app. The good news is that the internet makes finding the right people easier than ever.
If you try to please everyone, you won’t please anyone.
Create a great app and then worry about what to do once it’s wildly successful.
Throw in every decent idea that comes along and you’ll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.
Take whatever you think your product should be and cut it in half.
Our favorite answer to the “why didn’t you do this or why didn’t you do that?” question is always: “Because it just doesn’t matter”. That statement embodies what makes a product great. Figuring out what mattes and leaving out the rest.
Each time you say yes to a feature, you’re adopting a child. You have to take you baby through a Whole chain of events.
Innovation is not about saying yes to everything. It’s about saying NO to all the must crucial features.
Do the best job you can with the root of the problem then step aside. People will find their own solution and conventions within you general framework.
We are Always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important.
It is OK to do less, skip details, and take shortcuts in you process if it’ll lead to running software faster. Once you’re there, you’ll be rewarded eith a significantly more accurate perspective on how to proceed.
When a group of different people set out to try and find on what is harmonious… their opinions about it will tend to converge if they are mocking up a full-scale, real stuff.
Don’t’ expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there’s no need to ship perfection.
Preferences are a way to avoid making tough decision.
Get real data. Get real feedback. Then improve based on that info.
Break it down. Keep dividing problems int a smaller and small pieces until you’re are able to digest them.
Smaller task and smaller timelines are more manageable, hide fewer possible requirement misunderstanding, and cost less to change your mind about or redo.
To many companies separate design, development, copywriting, support and marketing into different silos. While specialization has its advantages, it also create a situation where staffers see just their own little world instead of the entire context of the web app.
Set up a rule at work: Make half the day alone time. From 10am-2pm, on one can talk to one another (expect during lunch). or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid Productivity.killing interruptions.
Have fewer meeting. There are too many meetings. Push back on meetings that do not make sense or are unproductive. Only book a meeting when you have an important business issue to discuss and you want or need input, approval, or agreement.
The solution is clear: break items into smaller autonomous and independent unites to reduce these communication links. Find a way to partition the program to eliminate – or minimize – the dependencies between units.
Brooks’ law: Adding people to a late software project makes it later.
Whenever possible, take potential new team member out for a “test drive”.
Judge potential hires on open source contributions. The amount of open source involvement often shows how much a candidate truly care about programming.
If you want something done ask to the busiest person you know.
Small team need people who can wear different hats.
A happy yest average employee is better than a disgruntled expert.
If you are trying to decide between a few people to fill a position, Always hire the better writer.
Clear writing leads to clear thinking.
Design the interface before you start programming. The interface is your product.
Epicenter design focuses on the true essence of the page – the epicenter – and then builds outward.
For each screen, you need to consider three possible states:
  • Regular: the screen people see when everything’s working fine and your app is flush with data.
  • Blank: the screen people see when using the app for the first time, before data is entered.
  • Error: the screen people see when something goes wrong.
What should you include in a helpful blank state?
  • Use it as an opportunity to insert quick tutorials and help blurbs
  • Give a sample screenshot of the page populated with data so people know what to expect
  • Explain how to get started, what the screen will eventually look like
  • Answer key questions that first-time viewers will ask: What is this page? What do I do now? How will this screen look one its’ full?
  • Set expectations and help reduce frustration, intimidation, and overall confusion.
Design for when the things go wrong: defensive design (Ref.
Context is more important than consistency. It is OK to be inconsistent if your design makes more sense that way. Give people just what matters.
What matters on the Web is whether, on each individual page, the user can quickly and easily advance the next step in the process.

You need to speak the same Language as your audience too.
Good writing is good design. It is a rare exception where words don’t accompany design. Icons with names, form fields with examples, buttons with labels, step by step instructions in a process, a clear explanation of your refund policy. These are all interface design.

Don’t build separate screens to deal with admin functions. Instead, build these functions in to the regular interface.

Keep your code as simple as possible. Less software means less features, less code, less waste.
Solving 80% of the original problem for 20% of the effort is a major win.
Do less:
  • Kess software is easier to manage
  • Less software reduces tour codebase and that means
  • less maintenance busywork
  • Less software lowers your cost of change so you can adapt quickly. OYOu can change your mind without having to change boatloads of code
  • Less software results in fewer bugs
  • Less software means less support
Encourage programmers to make counteroffers.
Happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.
In programmers got paid to remove code from software instead of writing new code, software should be a Whole lot better.
Don’t write a functional specification document. These blueprint docs usually wind up having almost nothing to do with the finished product. Functional specs are just words on paper.
A bunch of people agreeing on a paragraph of text isn’t a true agreement. Everyone may be reading the same thing but they’re thinking something different. This inevitably comes out later on.
Functional specs force you to make the most important decision when you have the least information.
Functional specs lead to feature overload.
Specs don’t deal with the reality that once you start building something, everything changes.
Write a one page story about what the app needs to do. Use plain Language and make it quick. If it takes more than a page to explain it, then it’s too complex.
Eliminate unnecessary paperwork. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document.
Documents that live separately from your application are worthless. They don’t get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it’s dead.
Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.
Write stories, not details. If you do find yourself requiring words to explain a new feature or concept, write a brief story about it, Don’t get into the technical or design details, just tell a quick story.
Dummy text means you won’t see the inevitable variations that show up once real information is entered. Dummy text is a veil between you and reality.
Do as your customer do and you’ll understand hem better.
Whenever you make a change, ask yourself if the change fits your apps’ personality.
It’s a noisy world out there. In order to get people to notice you amid the din, give something away for free.
Provide a big, clear, signup button that pops and put it on each page of your marketing site. Tell folks how easy it is: “from sign-up yo login in just 1 minute!”.
Also, make sure people can get their data out if they decide to leave. Don’t hold users against their will.
Avoid long-term contracts, sign-up fees, etc..
  • Overview: explain your app and its benefits
  • Tour: guide people through various features
  • Screen captures and videos: show people what the app actually looks like and how to use it
  • Manifesto: explain the philosophy and ideas behind it
  • Case studies: provide real life examples that show what’s possible
  • Buzz: testimonial quotes from customers, reviews, press, etc..
  • Forum: offer a place for member of the community yo help one another
  • Pricing & Sign-up: get people into your app as quickly as possible
  • Weblog: blogs keep your site fresh with news, tips, etc..
Blogging can be more effective than advertising (and it’s a hell of a lot cheaper)
Share your knowledge with the world.
And when the subject you’re teaching is your app, it serves a dual purpose: you can give something back to the community that supports you and score some nice promotional exposure at the same time.
Freely sharing our knowledge has also helped position us as experts in the industry and strengthened our relationship with existing customers.
Don’t sweat it if you can’t get the exact domain name you want. You can Always be creating get close with a couple of extra letter (e.g. or
Avoiding building walls between your customers and the development/design team. Don’t outsource customer support to a call center or third party.
Use inline help and FAQs so your product does not require a manual or training.
If something goes wrong, tell people. Even if they never saw it in the first place.
Don’t stop blogging once you lunch. Show your product is a living creature by keeping a dedicated blog that you update frequently. Things to include: FAQ, how-tos, Tips & tricks, News features, updates& fixes,¬†Buzz/press
Keep the conversation going with your users on your product blog, and be transparent and generous with the information you share.
Prioritize your bugs (and even ignore some of them)
Just because something gets older and more mature, doesn’t mean it need to get more complicated.
Be open to the fact that your original idea may not be your best one.