Getting Real by 37 Signals

These are the notes I took while reading Getting Real by 37 Signals. This isn’t meant to be a Cliff Notes version or a substitute for reading the book.

Additional notes I’ve taken while reading other books can be found here.

March 27, 2015 update: This book is now available for free download.

The Starting Line

Build Less

Conventional wisdom says that you need to one up your competitors. If they have four features, you need 5 (or 15 or 25, etc.). If they spend X, you need to spend XX.

This is a dead end, Cold War mentality that is expensive, defensive and paranoid.

Try doing less and one-downing your competitors (instead of one-upping). For starters that means:

Fund Yourself

Do what you can with the cash on hand. What’s essential? And what can you do without? What can you do with three people instead of ten? $20k instead of $100k? These constraints force creativity.

Constraints also force you to get your idea out in the wild sooner rather than later (and thus the quicker you can figure out if you’re onto something or not).

Fix Time and Budget, Flex Scope

Want to launch on time and on budget? Keep them fixed. Don’t throw more time or money at a problem - just scale back the scope.

Launching something great that’s a littler smaller in scope than planned is better than launching something mediocre and full of holes just so you could hit some magical time / budget / scope window.

Have an Enemy

Project management isn’t about charts, graphs, reports, statistics, etc. It’s about communication. Project management isn’t about sitting up high and broadcasting a project plan. Project management is everyone taking responsibility together to make the project work.

Projects turn out better when everyone takes a part of the collective ownership of the process.

Having an enemy also gives you a very clear marketing message. People are stoked by conflict and understand a product by comparing it to others.

Don’t overanalyze other products since it will start to limit the way you think.

Stay focused by asking yourself “what is the key problem you are trying to solve?” and “how can we solve it?”

It Shouldn’t Be a Chore

If you’re not excited or passionate about your app, it will show in the final product.

Stay Lean

Less Mass

The more massive an object, the more energy it requires to change its direction. It’s just as true in business as it is in physics.

When it comes to web technology, change must be easy and cheap. If you can’t change on the fly, you’ll lose ground to someone who can.

Mass is increased by:

Mass is reduced by:

Nimble, agile, less mass businesses can quickly change their business model, product, feature set, and marketing message. They are able to make mistakes and fix them quickly. They can change their priorities, product mix, and focus. Most importantly, they can change their minds.

Lower Your Cost of Change

The more expensive it is to make a change, the less likely you will do it.

The Three Musketeers

For the first version, start with only three team members: it’s enough manpower yet allows you to stay streamlined and agile. Ideally, a developer, a designer, and a sweeper (someone who can roam between both worlds).

This lack of manpower forces you to make tradeoffs earlier (and thus force you to figure out your priorities earlier).

If you can’t build a version one with there people, you need different people or to adjust the scope of the initial version one.

As you increase the number of people on a project, the number of communications paths increases (by the square of the number of people).

Embrace Constraints

There’s never enough time, money or people to go around. That’s a good thing. Embrace these constraints.

Examples from 37 Signals:

Be Yourself

Small companies are closer to the customer (which allows them to communicate in a more direct and personal way).

Priorities

What’s the Big Idea

Before you start designing, wire framing or writing code, you need to know the purpose of your product. What do you stand for? Why do you exist? What makes you different?

This vision guides your decisions - “are we staying true to the vision?”

Ignore Details Early On

Always work from large to small. There’s plenty of time to be a perfectionist and optimize. Just do it later.

Examples: font sizing, shading of colors, button placement.

It’s a Problem When It’s a Problem

Don’t waste time on trying to solve problems you don’t have yet. Don’t sweat stuff until you actually must. Don’t overbuild. Increase hardware and software as necessary.

Example: 37 Signals launched Basecamp without the ability to bill customers. Since it was billed monthly, they had a 30 day gap to figure it out.

Hire the Right Customer

Find the core market for your application and focus solely on them. Sort out who’s right and who’s wrong for your app. If you try to please everyone, you won’t please anyone.

You can easily identify which features will be genuinely useful and (more importantly) which features to leave out.

Scale Later

Will my app scale when millions of people are using it? Don’t worry about this until you actually have this problem. Making a solid core product should be your priority. Create a great app first and then worry about what to do when it’s wildly successful later.

Make Opinionated Software

The best software has a vision. When someone uses your software, they don’t just want features. They want an approach. They want a vision. Don’t try to be all things to all people.

Feature Selection

Half, Not Half-Assed

Build half a product, not a half-ass product. Stick to what’s truly essential. Take whatever you think your product should be and cut it in half. Pare features down until you only have the most essential ones left. Then do it again.

It Just Doesn’t matter

Q: Why didn’t you do this? Why didn’t you do that? A: Because it doesn’t matter.

^ This embodies what makes a product great. Figure out what matters. Leave out the rest.

Example from 37 Signals:

Would these features be nice to have? Sure. Are they essential? Nope. Do they really matter? Nope.

If you cut out the work and thinking about things that just don’t matter, you’ll achieve productivity you’ve never imagined.

Start with No

The secret to building a half a product instead of a half-ass product is saying no.

Every time you say yes to a feature, you’re adopting a child. You now have to take your baby through a whole chain of events (design, implementation, testing, etc.). Once a feature has been released and is out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get.

Make each feature work hard to be implemented. That’s why you should start with “no.” Listen but don’t act. If a feature request keeps coming back, that’s when you should take a deeper look.

Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features. -Steve Jobs

Hidden Costs

Be on the lookout of feature loops (features that lead to more features).

Can You Handle It?

It’s easy to make promises but much harder to keep them. Build what you can actually sustain organizationally, strategically, and financially.

Human Solution

Build software for general concepts and encourage people to create their own solutions. Give users enough features to solve their own problems their own way (using your software) and then get out of their way.

Forget Feature Requests

Don’t worry about tracking and saving every single feature request that comes in. If a feature is important, it will keep coming up.

Hold the Mayo

Ask users what they don’t want

Process

Race to Running Software

Running software is the best way to build momentum. Running software is real. Once your’e there, you’ll have a much more accurate perspective on how to move forward.

Rinse and Repeat

Don’t expect to get it right the first time. There’s no need to ship perfection. You can get to real feedback and real guidance faster (which is what should get your attention).

It’s tough to imagine something you can’t see, feel, and touch. However, human beings are really good at responding to things in the environment. No one is as smart as all of us.

Avoid Preferences

Decide the little details, so your customers don’t have to. Preferences are a way to avoid making tough decisions. Use your expertise to make the best decision and choose the best path instead of leaving it in the hands of customers. You may think you’re doing them a favor, but in reality, you’re just creating busy work for them.

Preference screens with endless amounts of options are a headache, not a blessing. Customers shouldn’t have to think about every nitty gritty detail. Don’t put that burden on them when it should be your responsibility.

Preferences create more software —> Requiring more code —> Extra Testing and Designing (and preference permutations and interface screens you’ll never see —> bugs you won’t know about such as broken layouts, busted tables, pagination issues).

Make the simple decisions on behalf of your customers.

Examples from Basecamp:

These aren’t options. It’s just the way it is.

”Done!”

Decisions are temporary. Mistakes will happen. It’s not a big deal if you can correct them quickly. Make the call and move on. If you screw up and make the wrong call? It’s ok, This isn’t brain surgery.

Test in the Wild

There’s no substitute for real people using your app in real ways. Get real data. Get real feedback.

Formal usability testing is too stiff. When someone else is watching, people are especially careful not to make mistakes (yet mistakes are exactly what you’re looking for).

Release beta features to a select few users inside of the application itself. Have them use the beta features alongside the released features. This exposes the beta features to people’s real data and real workflow.

Don’t have a special beta release version. Just sprinkle your beta features into the real version.

Shrink Your Time

Break timeframes into smaller chunks. Instead of a 12 week project, view it as twelve weeklong projects. Break a 30+ hour task into 6-10 hour chunks. Smaller pieces are easier to digest.

Smaller tasks and smaller timelines are more manageable, hide fewer possible requirement misunderstandings, cost less to change your mind about, and cost less to re-do.

Smaller timelines keep developers engaged and give them more opportunities to enjoy a sense of accomplishment and less reason to think, “I’ve got plenty of time to do that… [and do something else unrelated]”

The Organization

Unity

Don’t split into silos. Specialization has its advantages, but you want staffers to see the entire context of the web app.

Alone Time

People need uninterrupted time to get things done,

Set up a rule: make half of the day along time.

Meetings are Toxic

Do you really need a meeting? Can you simplify the concept so that it can be discussed quickly via email or IM? Every minute spent in a meeting is a minute you could be getting real work done instead.

If you absolutely must have a meeting:

Seek and Celebrate Small Victories

The most important thing in software development is motivation. If you aren’t motivated by what you’re working on, the chances are that it won’t be as good as it should be.

Long drawn out release cycles are motivation killers. Quick wins you can celebrate are great motivators.

Can you build something to ship today? In four hours?

Staffing

Hire Less and Hire Later

Don’t hire people. Look for another way.

Whenever Jack Welch would fire someone, he wouldn’t immediately hire a replacement. Can you get along without that person and without that position?

The lesson? You don’t need as many people as you think.

Kick the Tires

Whenever possible, take potential new team members for a “test drive” (e.g.a test-basis first). Give them a small project first. See how they handle it, how they communicate, how they work, etc. You can figure out pretty quickly if the vibe is right or not.

Actions, Not Words

Judge potential hires based on their open source contributions. This gives you into their quality of work, cultural perspective, level of passion, completion percentage, and social match.

Get Well Rounded Individuals

Go for quick learning generalists over ingrained specialists. Small teams need people who can wear different hats.

You Can’t Fake Enthusiasm

Happy and Average > Frustrated and Great.

Wordsmiths

Hire good writers. Effective and concise writing leads to effective, concise code, design, email, etc.

Good writers know how to communicate and make things easy to understand. Clear writing is a sign of clear thinking.

Interface Design

Interface First

Programming is the most expensive and hardest part to change about building an app. Start with design first.

= Designing keeps you flexible.

Epicenter Design

Focus on the true essence of the page (the epicenter) and then build outward (e.g. ignore the extremities like navigation, footer, colors, etc. when starting out).

Start with the most critical element of the page, then the second most critical element, third, etc. That’s epicenter design. It forces you to focus on what really matters starting out.

Three State Solution

For each screen, you need to consider three possible states

The Blank Slate

The blank slate is user’s first impression of your app. The natural state of an app is one that is devoid of data. Users sign up with a blank slate.

(Potential) customers often make their decisions if an app is worthwhile using at this blank stage. Users don’t know what they are missing because everything is missing.

What’s helpful in a blank state?

Get Defensive

Defensive design is like defensive driving. Just like drivers are always on the lookout for slick roads, reckless drivers, and dangerous scenarios, you must constantly be searching for trouble spots that cause confusion and frustration.

Context Over Consistency

It’s alright to be inconsistent if your design makes more sense that way.

Copywriting is Interface Design

What does your users need to know? How can you explain it succinctly and clearly?

One Interface

Incorporate admin functions (edit, add, delete) into the public interface. It helps avoid the “crappy-admin-screen syndrome.” The fewer screens you have to worry about, the better.

Code

Less Software

Twice the code doesn’t make the software twice as complex. It makes it exponentially more complex since each change, interdependency, and preference has a cascading effect.

Less software => Less features, less code, less waste.

Solving 80% of the original problem for 20% of the effort is a win.

Encourage programmers to make counteroffers: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do X but it will do Y.”

For every feature that makes it into your app, ask yourself: “Is there a way this can be added that won’t require as much software?”

Optimize for Happiness

A happy programmer is a productive programmer. You should choose the tools that keep your team excited and motivated

Code Speaks

Listen when your code pushes back. Is a new feature requiring weeks and thousands of lines of code? Your code is telling you there’s a better way to do it.

Manage Debt

Regularly put aside some time to pay off your code and design debt.

Open Doors

Let your customers get their information when they want it and how they want it. That means giving up the idea of sealing in data. Instead, let it run wild (RSS, API’s, etc.).

This makes life more convenient for your customers and expands the possibilities of what your app can do.

RSS (while popular with blogs) is a great way for users to stay up to date on the changing contents of an app without having to log in repeatedly.

Words

There’s Nothing Functional about a Functional Spec

Don’t write a functional specifications document since it has almost nothing to do with the final product.

You make important decisions when you have the least amount of information (e.g. the more you build, the more you know and that’s when you should be making decisions).

Functional spec leads to feature overload.

Functional spec doesn’t let you evolve, change or reassess.

Don’t Do Dead Documents

Prevent excess paperwork everywhere. Build, don’t write. Documents that live separately from your application are worthless. Everything you do should evolve into the real thing.

Tell Me a Quick Story

If you do need to explain a new feature or concept, write a brief story about it (instead of the technical details). Do it in a human way. Stick to the experience (and don’t get hung up on the details).

Use Real Words

Use actual text instead of lorem ipsum.

You need real copy to know what your app truly looks like. Don’t take a shortcut when your users are forced to take the long road? Know what it truly feels like to fill out forms and input text in fields. Do as your customers do and you’ll understand them better.

Personify Your Product

Your product has a voice and is talking to users 24 hours per day. What kind of person do you want it to be? Polite? Funny? Serious? Keep these personality traits in mind as you build the product (from copywriting to interface to feature set).

Pricing and Signup

Free Samples

Giving away freebies is a great way to lure in customers. For example, Apple gives away iTunes for free to build demand for the iPod and iTunes store.

For 37 Signals, Writeboard and Ta-da list are completely free apps that are given away in hopes of getting people to use their other products. All of their other apps have some sort of free version as well.

Once users are hooked, they are much more likely to upgrade to a paying plan.

Easy On, Easy Off

Make signup and cancellation a painless process. There should always be a free option so customers can demo the app without entering credit card information. Keep the signup form as short as possible.

The same is true for canceling. You never want to trap people inside your product. Make it easy for users to get their data out if the decide to leave. It’s their data and they should be able to do with it what they want.

Giving people control over their information builds trust. It’s the right thing to do and builds goodwill.

Silly Rabbit, Tricks are for Kids

Avoid long term contracts, sign up fees, early termination fees, or one time set up fees. Don’t try to find “tricky” ways to get more cash. Earn it.

A Softer Bullet

Soften the blow of bad news with plenty of advance notice and grandfather clauses. These people are your bread and butter. Make them feel valued, not gouged.

Promotion

A Powerful Promo Site

The best promotion is a great product. What should be included on your site though?

Solicit Early

Get some sort of site up and start collecting emails as soon as possible.

Promote Through Education

Companies that share their intellectual property and business processes with customers and partners are more likely to have their knowledge (or products) passed along to prospective customers.

Those who teach stand the best chance of getting people to become passionate. Who needs an ad campaign when you’ve got user evangelists doing what evangelists do… talking about their passion.

Track Your Logs

You need to know who’s talking about you. Who’s linking to you? Who’s bitching about you?

Thank people for posting links. Leave comments on other blogs. Collect testimonials.

Inline Upsell

Call out upgrade opportunities from within the product. Show users which barriers will be removed if they upgrade.

Name Hook

Don’t worry about picking a name that vividly describes your tool’s purpose. This usually just leads to generic and forgettable names. Pick a name that’s short catchy, and memorable then just run with it.

Support

Feel The Pain

Chefs rarely hear what customers are actually saying. That’s a problem because listening to customers is the best way to get in tune with your product’s strengths and weaknesses.

Don’t outsource customer support to a call center or third party. You need to hear when your customers are annoyed and need to hear their complaints. At 37 Signals, all support emails are personally answered by the people who built the product.

This keeps development in touch with the people who use your product and helps understand the context of your users.

Zero Training

You don’t need a manual to use Yahoo or Google or Amazon. Why can’t you build a product that doesn’t required a manual?

Use inline help and FAQ’s at potential points of confusion.

Answer Quick

You can differentiate yourself from competitors by offering a thoughtful response right away. Even if you don’t have a perfect answer, say something. You can buy goodwill with a response that is quick, open and honest.

Tough Love

When it comes to feature requests, the customer is not always right.

In Fine Forum

Forums are great to let customers ask questions and help each other out.

Publicize Your Screwups

If something goes wrong, tell people (even if they never saw it in the first place).

Post-Launch

One Month Tuneup

A quick update 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. A blog shows your app is alive and your company seems more human.

Better, Not Beta

Beta passes the buck to your customers. If you’re not confident enough about your release then how can you expect the public to be? Private betas are fine, public betas are BS.

All Bugs Are Not Created Equal

Most bugs are annoying, not destroying. Prioritize your bugs. How many people are affected? How bad is the problem? Can it wait?

Ride Out the Storm

Wait until knee-jerk reactions to changes die down (usually 24-48 hours) before taking action or responding.

Keep Up With the Joneses

Subscribe to news feeds about both your product and your com- petters

Beware the Bloat Monster

New doesn’t always mean improved. Sometimes there’s a point where you should just let a product be. Desktop software (Adobe, Intuit, Microsoft, etc.) need to sell new versions every year (and have to justify the expense by adding new features). This is how software gets bloated.

Web-based software (with a subscription model), customers pay a monthly fee. You don’t need to upwell with more and more. Just provide a valuable, ongoing service.

Go With the Flow

Web apps are fluid. You can tweak and change things as you go along.

Start Your Engines

Anyone can read a book. The difference between you and everyone else will be how well you execute. Success is all about great execution.