Getting Real [Book Summary]

37Signals (now called Basecamp) is a Chicago-based web application company, famous for having amongst other things invented the Ruby on Rails web application framework, and the "Getting Real" philosophy.  37Signals is one of the most highly respected authorities on web usability, web design, and web application development. The book is available for free download at Getting Real.

GETTING REAL - The smarter, faster, easier way to build a successful web application, by 37signals

Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics etc) and actually building the real thing.  Getting Real is less.  Less mass, less software, less features, less paperwork, less of everything that's not essential.  Getting Real is staying small and being agile. Getting Real delivers just what the customers need and eliminates anything they don't.

Getting Real forces you to deal with the actual problems you're trying to solve instead of your ideas about those problems.  It forces you to deal with reality.  Getting Real forgoes functional specs and other transitory documentation in favor of building real screens.  That's what your customers are going to see and use.  That's what matters.

The Starting Line

  • Build Less. Underdo your competition.  The one-upping Cold War mentality is a dead end; it's an expensive, defensive, paranoid way of building products.  Instead of outdoing, try underdoing.  Less features, less options/preferences, less people and corporate structure, less meetings and abstractions, less promises.

  • What's Your Problem?  Build software for yourself.  A great way to build software is to start by solving your own problems.  You be the target audience.  Scratch your own itch.

  • Fund Yourself.  Instead of looking for investors, use your own money.  Run on limited resources and you'll be forced to reckon with constraints earlier and more intensely.

  • Fix Time and Budget, Flex Scope.  Here's an easy way to launch on time and on budget: keep them fixed;  just scale the scope.  Scope down.  It's better to make half a product than a half-assed product.

  • Have an Enemy.  Figure out your app's enemy and you'll shine a light on where you want to go.  As a bonus, it will give you a very clear marketing message.

  • It Shouldn't be a Chore.  Your passion - or lack of - will shine through.  Keep your app small and manageable so you can actually enjoy the process.

Stay Lean

  • Less Mass.  The leaner you are, the easier it is to change.  The more massive an object, the more energy is required to change its direction.  Mass is reduced by just-in-time thinking, multi-tasking team members, embracing constraints, less software and code, less features, small team size, simplicity, open data formats, etc.

  • Lower Your Cost of Change. Stay flexible by reducing obstacles to change.  Change is your best friend.  If your competitors change faster than you, you're at a huge disadvantage.  Stay small and lean.  Remember, all the cash, all the marketing, all the people in the world can't buy the agility you get from being small.

  • The Three Musketeers.  For the first version of your app, start with only three people.  It's 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.

  • Embrace Constraints.  Let limitations guide you to creative solutions.  There's never enough time, money, people.  That's a good thing.  Instead of freaking out about these constraints, embrace them.  Let them guide you.

  • Be Yourself.  Differentiate yourself from bigger companies by being personal and friendly.  A lot of small companies make the mistake of trying to act big.

Priorities

  • What's the Big Idea?  Explicitly define the one-point vision for your app.  What does your app stand for?  Just one sentence.

  • Ignore Details Early On. Work from large to small.  There's plenty of time to be a perfectionish - just do it later.

  • It's a Problem When It's a Problem.  Don't waste time on problems you don't have yet.  E.g. don't worry about scaling to 100,000 users.  Just wing it.  Don't sweat stuff until you actually must.  Don't overbuild.  Make decisions just in time.

  • Hire the Right Customers.  Find the core market for your application and focus solely on them.  If you try to please everyone, you won't please anyone.

  • Scale Later.  Will my app scale when millions of people start using it?  Ya know what?  Wait until that actually happens.  It'll be a swell problem to have!

  • Make Opinionated Software.  Your app should take sides.  Limit features and ignore feature requests - don't try to be all things to all people.

Feature Selection

  • Half, not half-assed.  Take whatever you think your product should be and cut it in half.  Pare features down until you're left with only the most essential ones.  Then, do it again.

  • It Just Doesn't Matter. Why time stamps only every five minutes?  Why not time stamp every chat line?  Answer: it just doesn't matter.

  • Start with No.  Each time you say yes to a feature, you're adopting a child.  You have to take your baby through a whole chain of events (design, implementation, testing, etc).  Don't be a yes-man.  Start with no.  Every new feature request that comes to us should meet a no.  If a request keeps coming back, that's when you know it's time to take a deeper look.

  • Hidden Costs.  Expose the price of new features: think of all you'll need to do, such as design, implementation, coding, testing, tweaking, updating the product tour, the marketing copy, the terms of service, etc.

  • Can You Handle It?  Build something you can manage.  If you launch an affiliate programme, do you have the systems in place to handle the accounting and payouts?

  • Human Solutions.  Build software for general concepts and encourage people to create their own solutions.  Don't force conventions on people.  Make your software general, so everyone can find their own solution.

  • Forget Feature Requests.  Customers want everything under the sun.  But your first response should be a no.  Read the feature requests then throw them away.  No need to store them!  The important ones will keep bubbling up anyway.

  • Hold the Mayo.  Ask people what they don't want.  "If you could remove one feature, what would it be?"  "What don't you use?"  "What gets in your way the most?"

Process

  • Race to Running Software. Get something real up and running quickly.

  • Rinse and Repeat.  Work in iterations.  Don't expect to get it right the first time - let the app grow and speak to you.  Let it morph and evolve.  The iterative process lets you continue to make informed decisions as you go along.

  • From Idea to Implementation: go from brainstorm to sketches to HTML to coding.

  • Avoid Preferences.  Decide the little details so your customers don't have to.  Preferences are a way to avoid making tough decisions - make the call yourself.

  • "Done!"  Value the importance of moving on and moving forward.  Make the call and move on.

  • Test it in the Wild.  Test your app via real-world usage.  Formal usability testing is too stiff.  Lab settings don't reflect reality.  Release beta features to a select few inside the real app itself.

  • Shrink Your Time.  Estimates that stretch into weeks or months are fantasies.  You can't know what's going to happen that far out.  So shrink your time.  Break down timeframes into more realistic 6-10 hour chunks, and proceed one step at a time.

The Organisation

  • Unity.  Don't split into silos.  Too many companies separate design, development, copywriting, support, marketing into different silos.  Integrate your team.

  • Alone Time.  People need uninterrupted time to get things done.  It allows you to get into the zone.

  • Seek and Celebrate Small Victories.  The most important thing in software development is motivation.  Long, drawn-out release cycles are motivation killers.  They insert too much time between celebrations.

Staffing

  • Hire Less and Hire Later. Add slow to go fast.  Don't hire people.  Look for another way.

  • Kick the Tires.  Work with prospective employees on a test-basis first.

  • Actions, Not Words.  Judge potential hires on open source contributions.

  • Get Well Rounded Individuals.  Go for quick learning generalists over ingrained specialists.

  • You Can't Fake Enthusiasm.  Go for happy and average over frustrated and great.  Go for enthusiasm.

  • Wordsmiths.  Hire good writers.  Effective, concise writing and editing leads to effective, concise code, design, emails, and more.

Interface Design

  • Interface First. Design the interface before you start programming.  The interface is your product: it is what people see.

  • Epicentre Design.  Start from the core of the page and build outward.  At the start, ignore the extremities:  the navigation/tabs, footer, colours, sidebar, logo etc.  What the page absolutely cannot live without is the epicentre.  For example, if you're designing a page that displays a blog post, the blog post itself is the epicentre.

  • Three State Solution.  Design for Regular (the screen people see when everything's working fine), Blank (the screen people see when using the app for the first time), and Error (the screen people see when something goes wrong).

  • The Blank State.  Ignoring the blank state is one of the biggest mistakes you can make.  The blank state is your app's first impression and you never get a second... well, you know.

  • Get Defensive.  Design for when things go wrong.

  • Context over Consistency.  What makes sense here may not make sense there.  Do you need the exact same footer on each page?  The answer: "It depends".

  • Copywriting is Interface Design.  Every letter matters.  Do you label a button Submit or Save or Update?  Good writing is good design.

  • One Interface.  Incorporate admin functions into the public interface.  Don't build a separate "backoffice" (they have a tendency to look like crap, and they increase the amount of coding to do).

Code

  • Less Software. Keep your code as simple as possible.

  • Optimise for Happiness.  Choose tools that keep your team excited and motivated.  This is especially important for choosing a programming language.

  • Code Speaks.  Listen when your code pushes back.  Does a new feature require weeks of time and thousands of lines of code?  That's your code telling you there's probably a better way.

  • Manage Debt.  Pay off your code and design "bills".  Hack together some bad code that's functional but still a bit hairy and you're building up debt.  You need to clean it up, or you'll have to pay it off later with significant interest!

  • Open Doors.  Get data out into the world via RSS, APIs, etc.  Give up the idea of sealing in data.  Instead, let it run wild.

Words

  • There's Nothing Functional about a Functional Spec. Don't write them.  These blueprint docs usually wind up having almost nothing to do with the finished product.  Instead, write a one-page story about what the app needs to do, then begin building the interface - the interface will be the alternative to the functional spec.

  • Don't Do Dead Documents.  Eliminate unnecessary paperwork.  No One's Going to Read It.  Build, don't write.  If you need to explain something, try mocking it up.

  • Tell Me a Quick Story.  Write stories, not details.  Don't get into the technical or design details, just tell a quick story.

  • Use Real Words.  Insert actual text instead of "Lorem upsum dolor..."

  • Personify Your Product.  What is your product's personality type?  Polite?  Stern?  Forgiving?  Strict?  Funny?  Deadpan?  Serious?  Loose?

Pricing and Singup

  • Free Samples.  Give something away for free.  Giving away freebies is a great way to lure in customers.

  • Easy On, Easy Off.  Make signup and cancellation a painless process.  Keep the signup form as short as possible.  Same for the cancellation process: never "trap" people inside your product.  Make it easy to cancel/close the account.

  • Silly Rabbit, Tricks are for Kids.  Avoid long-term contracts, sign-up fees, etc.  Don't try to find "tricky" ways to get more cash.  Earn it.

  • A Softer Bullet.  Soften the blow of bad news with advance notice and grandfather clauses.  Need to deliver bad news like a price increase?  Give folks plenty of notice, and consider a grandfather clause that exempts existing customers for a period of time.

Promotion

  • Hollywood Launch. Go from teaser to preview to launch.  Teaser: a few months ahead of time, start dropping hints.  Preview:  a few weeks ahead of launch, start previewing features.  Launch:  spread the gospel by email, blogs, posts etc.

  • A Powerful Promo Site.  Build an ace promotional site that introduces people to your product, and include: an overview, tour, screen captures and videos, manifesto, case studies, buzz and testimonials, forum, pricing and signup, weblog.

  • Ride the Blog Wave. Blogging can be more effective than advertising (and cheaper!)

  • Solicit Early.  Get advance buzz and signups going ASAP:  get some sort of site up and start collecting emails as soon as possible.

  • Promote Through Education.  Share your knowledge with the world.  You can give something back to the community that supports you and score some nice promotional exposure at the same time.

  • Feature Food.  New or interesting features are a great way to generate buzz for your application.

  • Track Your Logs.  Study your logs to track buzz.

  • Inline Upsell.  Promote upgrade opportunities inside the app.

  • Name Hook.  Give your app a name that's easy to remember.

Support

  • Feel the Pain. Tear down the walls between support and development.

  • Zero Training.  Use inline help and FAQs so your product doesn't require a manual or training.  You don't need a manual to use Yahoo or Google or Amazon.

  • Answer Quick.  Quick turnaround time on support queries should be a top priority.

  • Tough Love.  Be willing to say no to your customers (when it comes to feature requests).

  • In Fine Forum.  Use forums or chat to let customers help each other.

  • Publicise Your Screwups.  Get bad news out there and out of the way.  Be as open, honest, and transparent as possible.  An informed customer is your best customer.  Plus, you'll realise that most of your screwups aren't even that bad in the minds of your customers.  A side note:  when bad news comes, get it all out in the open at once; good news, on the other hand, should be trickled out slowly.

Post-Launch

  • One Month Tuneup. Issue a major update 30 days after launch.  It shows momentum.  It shows you're listening.  It shows you've got more tricks up your sleeve.

  • Keep the Posts Coming.  Show your product is alive by keeping an ongoing product development blog post-launch.

  • Better, not Beta.  Don't use "beta" as a scapegoat.  An interminable beta stage tells customers you're not really committed to rolling out a finished product.  Take responsibility for what you're releasing.  Put it out and call it a release.

  • All Bugs are Not Created Equal.  Prioritise your bugs (and even ignore some of them).

  • Ride Out the Storm.  Wait until knee-jerk reactions to changes die down before taking action.  After you introduce a new feature/change, knee-jerk reactions (often negative) will pour in.  Resist the urge to panic or rapidly change things in response.  Ride out this initial 24-48 hour period, and you'll be able to offer a more reasoned response.

  • Keep up with the Joneses.  Subscribe to news feeds about your competitors.

  • Beware the Bloat Monster.  More mature doesn't have to mean more complicated.  Resist the temptation to scale up and bloat your app.

  • Go With the Flow.  Be open to new paths and changes in direction.  Look at Flickr:  it started as a multiplayer online game, but its creators soon realised the photo-sharing aspect of the game was a more plausible product.