Getting Real

• Kapitel 1 Einleitung
• Kapitel 2 Die Startlinie
• Kapitel 3 Bleib schlank
• Kapitel 4 Prioritäten
• Kapitel 5 Feature-Auswahl
• Kapitel 6 Arbeitsablauf
• Kapitel 7 Organisation
• Kapitel 8 Personalmanagement
• Kapitel 9 Interface Design
• Kapitel 10 Code
• Kapitel 11 Words
• Kapitel 12 Pricing and Signup
• Kapitel 13 Promotion
• Kapitel 14 Support
• Kapitel 15 Post-Launch
• Kapitel 16 Schlussfolgerung

---

Einleitung Kapitel 1

Was ist mach es wahr?

Du möchtest eine erfolgreiche Webanwendung entwickeln? Dann ist es jetzt an der Zeit es wahr zu machen. Mach es wahr ist ein leichterer, schnellerer und besserer Weg Software zu entwickeln.

• Mach es wahr handelt davon, all die Dinge zu überspringen die nur die Realität repräsentieren (Tabellen, Grafiken, Quadrate, Pfeile, Schemata, Drahtmodellen, usw. ) und stattdessen wirklich etwas Reales zu entwickeln.
• Mach es wahr heißt weniger. Weniger Masse, weniger Software, weniger Funktionen, weniger Papierkram, weniger von allem, das nicht wirklich wichtig ist. (Und das Meiste, was du im Moment für wichtig hältst, ist in Wirklichkeit unwichtig.)
• Mach es wahr heißt klein zu bleiben und beweglich zu sein.
• Mach es wahr beginnt mit der Oberfläche, den wirklichen Bildschirmen, die die Anwender benutzen werden. Es baut auf den ersten Anwender-Erfahrungen auf und leitet alles andere davon ab. Das sorgt dafür, dass du zuerst die Oberfläche richtig machst, bevor du die Software falsch machen kannst.
• Mach es wahr handelt von Iterationen und Senkung der Kosten für Änderungen. Mach es wahr sagt alles über Markteinführung, Optimierung und konstante Verbesserung, was es zu einem Perfekten Ansatz für Webbasierte Software macht.
• Mach es wahr liefert nur was die Anwender brauchen und schliesst alles andere aus.

Die Vorteile von Mach es wahr

Mach es wahr liefert bessere Resultate weil es dich dazu zwingt dich mit den aktuellen Problemen auseinanderzusetzen die du lösen sollst, anstatt mit deinen Ideen über diese Probleme. Es zwingt dich dazu dich mit der Wirklichkeit auseinanderzusetzen.

Mach es wahr übergeht Funktionsspezifikationen und andere vergängliche Dokumentation um stattdessen die wirkliche Anwendung zu entwickeln. Eine Funktionsspezifikation ist eine Phantasie, eine Illusion einer Vereinbarung, während eine aktuelle Webseite real ist. Das ist es was unsere Kunden sehen und benutzen wollen. Das ist es was zählt. Mach es wahr bringt dich schneller dort hin. Und das heisst du triffst Entwicklungsentscheidungen anhand der Wirklichkeit anstatt anhand abstrakter Notationen.

Letztendlich, ist mach es wahr eine ideale Herangehensweise für Webbasierte Software. Das alte Modell Software in Schachteln zu verkaufen und dann ein oder zwei Jahre mit einem Update zu warten verschwindet zusehends. Im gegensatz zu installierter Software, können Webanwendungen konstant auf einer täglichen Basis weiterentwickelt werden. Mach es wahr sorgt dafür das dieser Vorteil voll zur Geltung kommt.

No more bloat

Der alte Weg: Ein langatmiger, bürokratischer, wir-tun-das-um-unseren-Arsch-zu-schützen Prozess. Das typische Resultat: aufgeblasene zum vergessen schlechte Software, triefend vor Mittelmässigkeit. Blech.

Mach es wahr mach Schluss mit...

• Zeitplänen die sich über Monate oder sogar Jahre erstrecken
• Pie-in-the-sky functional specs
• Skalierbarkeitsdebatten
• Langwierige Mitarbeiterbesprechungen
• Der "Zwang" dutzende Mitarbeiter einstellen zu müssen
• Nichtssagende Versionsnummern
• Makellose Zeitpläne die eine Perfekte Zukunft vorraussagen
• Endless preference options
• Ausgelagerter Support
• Unrealistische Anwendertests
• Nutzlose Dokumentation
• Top-down Hierarchien

Du benötigst weder massenweise Geld noch ein großes Team oder einen langsamen Enwicklungszyklus um großartige Software zu Entwicklen. Diese Dinge sind die Zutaten für langsame, düstere, unveränderliche Anwendungen. Mach es wahr verwendet den umgekehrten Ansatz.

In diesem Buch werden wir dir zeigen...

• Das es wichtig ist eine Philosopie zu haben
• Warum klein zu bleiben eine gute Sache ist
• How to build less
• How to get from idea to reality quickly
• How to staff your team
• Warum du von innen nach aussen Entwickeln solltest
• Why writing is so crucial
• Why you should underdo your competition
• How to promote your app and spread the word
• Geheimnisse für Erfolgreichen support
• Tips on keeping momentum going after launch
• ...und vieles mehr

The focus is on big-picture ideas. We won't bog you down with detailed code snippets or css tricks. We'll stick to the major ideas and philosophies that drive the Getting Real process.

Is this book for you?

You're an entrepreneur, designer, programmer, or marketer working on a big idea.

You realize the old rules don't apply anymore. Distribute your software on cd-roms every year? How 2002. Version numbers? Out the window. You need to build, launch, and tweak. Then rinse and repeat.

Or maybe you're not yet on board with agile development and business structures, but you're eager to learn more.

If this sounds like you, then this book is for you.

Note: While this book's emphasis is on building a web app, a lot of these ideas are applicable to non-software activities too. The suggestions about small teams, rapid prototyping, expecting iterations, and many others presented here can serve as a guide whether you're starting a business, writing a book, designing a web site, recording an album, or doing a variety of other endeavors. Once you start Getting Real in one area of your life, you'll see how these concepts can apply to a wide range of activities.

---

Über 37signals

Was wir machen

Die Firma 37signals ist ein kleines Team, dass einfache, zweckmäßige Software entwickelt. Unsere Produkte helfen dir mit anderen Menschen zusammen zu arbeiten und dich selbst zu organisieren. Mehr als 350.000 Menschen und kleine Unternehmen nutzen unsere Web-Anwendungen um Dinge du erledigen. Jeremy Wagstaff vom Wall Street Journal schreibt, „die Produkte von 37signals sind wunderschön einfache, elegante und intuitive Werkzeuge, die Outlook als das Software-Ebenbild einer Folterkammer erscheinen lassen.“ Unsere Anwendungen lassen dich nie die Wände hochgehen.

Unsere Arbeitsweise

Wir glauben Software ist zu komplex. Zu viele Features, zu viele Buttons, zu viel zu lernen. Unsere Produkte machen weniger als die Konkurrenz - und das mit gutem Grund. Wir bauen Produkte die intelligenter arbeiten, sich besser anfühlen, die es dir erlauben, so zu arbeiten wie du willst und einfacher zu benutzen sind.

Unsere Produkte

Zum Zeitpunkt der Veröffentlichung dieses Buches haben wir fünf kommerzielle Produkte und ein Open-Source-Framework.

Basecamp stellt Projektmanagement auf den Kopf. Anstelle von Gantt-Diagrammen, extravaganten Kurven und mit Statistiken vollgepackten Tabellen bietet Basecamp ein -- Message Board -- Aufgabenlisten, einfache Terminplanung, gemeinsames Schreiben an Dokumenten und Dateiaustausch. Bis heute sind mehrere Hunderttausend der Meinung, dass das ein besserer Weg ist. Farhad Manjoo von Salon.com sagte „Basecamp stellt die Zukunft der Software im Web dar.“

Campfire ermöglicht einen einfachen Gruppen-Chat in der Geschäftswelt. Erfolgreiche Firmen wissen wie wertvoll nachvollziehbarer Gruppen-Chat sein kann. Gewöhnliches Instant Messaging is großartig für 1-zu-1 Chats, aber miserabel für 3 oder mehr Menschen gleichzeitig. Campfire löst dieses und viele weitere Probleme.

Backpack ist die Alternative zu den verwirrenden, komplexen, „organisiere dein Leben in 25 einfachen Schritten“ persönlichen Informationsmanagement-Softwarelösungen. Backpack‘s einfacher Ansatz mit Seiten, Notizen, To-Do-Listen, und Erinnerungen an das Mobiltelefon oder an die Email-Adresse ist eine neuartige Idee in einer Produktkategorie, die unter dem Status-Quo-Syndrom leidet. Thomas Weber vom Wall Street Journal sagt es sei das beste Produkte in seiner Klasse und David Pogue von der New York Times bezeichnet es als „sehr cooles“ Organisationswerkzeug.

Writeboard ermöglicht dir alleine oder mit anderen zusammen das verfassen, verteilen, überprüfen und vergleichen von Texten. Es ist eine erfrischende Alternative zu den aufgeblähten Word-Anwendungen, die für 95% dessen, was du schreibt, übertrieben sind. John Gruber von Daring Fireball sagte, „Writeboard ist womöglich die eindeutigste, einfachste Web-Anwendungen, die ich je gesehen habe.“ Web-Guru Jeffrey Zeldman sagt, „die genialen Köpfe von 37signals haben es wieder geschafft.“

Ta-da List behält alle deine Aufgabenlisten online zusammen und organisiert. Behalte die Listen für dich oder biete sie anderen zur einfachen Zusammenarbeit an. Es gibt keinen einfacheren Weg etwas fertig zu stellen. Mehr als 100.000 Listen mit fast 1.000.000 Listeneinträgen sind bis heute erstellt worden.

Für Entwickler ist Ruby on Rails ein vollständiges Open-Source-Web-Framework in der Programmiersprache Ruby um echte Anwendungen schnell und einfach zu schreiben. Rails übernimmt die Routinearbeit damit du dich auf deine Idee konzentrieren kannst. Nathan Torkington vom O‘Reilly Verlagshaus sagt „Ruby on Rails ist erstaunlich. Es ist wie bei einem Kung-Fu Film, in dem sich ein Duzend schlechter Frameworks vorbereiten den kleinen Neuling zu schlagen um dann ihre Hintern in vielen erdenklichen Arten versohlt zu bekommen. Dieses Zitat muss man lieben. asses in a variety of imaginative ways." Gotta love that quote.

Du kannst mehr über unsere Produkte und unsere Firman auf unserem Webauftritt www.37signals.com herausfinden.

---

Caveats, disclaimers, and other preemptive strikes

Just to get it out of the way, here are our responses to some complaints we hear every now and again:

"These techniques won't work for me."

Getting real is a system that's worked terrifically for us. That said, the ideas in this book won't apply to every project under the sun. If you are building a weapons system, a nuclear control plant, a banking system for millions of customers, or some other life/finance-critical system, you're going to balk at some of our laissez-faire attitude. Go ahead and take additional precautions.

And it doesn't have to be an all or nothing proposition. Even if you can't embrace Getting Real fully, there are bound to be at least a few ideas in here you can sneak past the powers that be.

"You didn't invent that idea."

We're not claiming to have invented these techniques. Many of these concepts have been around in one form or another for a long time. Don't get huffy if you read some of our advice and it reminds you of something you read about already on so and so's weblog or in some book published 20 years ago. It's definitely possible. These techniques are not at all exclusive to 37signals. We're just telling you how we work and what's been successful for us.

"You take too much of a black and white view."

If our tone seems too know-it-allish, bear with us. We think it's better to present ideas in bold strokes than to be wishy-washy about it. If that comes off as cocky or arrogant, so be it. We'd rather be provocative than water everything down with "it depends..." Of course there will be times when these rules need to be stretched or broken. And some of these tactics may not apply to your situation. Use your judgement and imagination.

"This won't work inside my company."

Think you're too big to Get Real? Even Microsoft is Getting Real (and we doubt you're bigger than them).

Even if your company typically runs on long-term schedules with big teams, there are still ways to get real.The first step is to break up into smaller units. When there's too many people involved, nothing gets done. The leaner you are, the faster — and better — things get done.

Granted, it may take some salesmanship. Pitch your company on the Getting Real process. Show them this book. Show them the real results you can achieve in less time and with a smaller team.

Explain that Getting Real is a low-risk, low-investment way to test new concepts. See if you can split off from the mothership on a smaller project as a proof of concept. Demonstrate results.

Or, if you really want to be ballsy, go stealth. Fly under the radar and demonstrate real results. That's the approach the Start.com team has used while Getting Real at Microsoft. "I've watched the Start.com team work. They don't ask permission," says Robert Scoble, Technical Evangelist at Microsoft. "They have a boss that provides air cover. And they bite off a little bit at a time and do that and respond to feedback."

---

Die Startliniechapter 2

Build Less

Underdo your competition

Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they're spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It's an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can't think ahead, they can only think behind. They don't lead, they follow.

If you want to build a company that follows, you might as well put down this book now.

So what to do then? The answer is less. Do less than your competitors 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.

We'll cover the concept of less throughout this book, but for starters, less means:

• 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 out by solving your own problems. You'll be the 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.

The key here is understanding that you're not alone. If you're having this problem, it's likely hundreds of thousands of others are in the same boat. There's your market. Wasn't that easy?

Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn't working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.

So we started looking at other options. Yet every tool we found either 1) didn't do what we needed or 2) was bloated with features we didn't need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.

When you solve your own problem, you create a tool that you're passionate about. And passion is key. Passion means you'll truly use it and care about it. And that's the best way to get others to feel passionate about it too.

---

Fund Yourself

Outside money is plan B

The first priority of many startups is acquiring funding from investors. But remember, if you turn to outsiders for funding, you'll have to answer to them too. Expectations are raised. Investors want their money back — and quickly. The sad fact is cashing in often begins to trump building a quality product.

These days it doesn't take much to get rolling. Hardware is cheap and plenty of great infrastructure software is open source and free. And passion doesn't come with a price tag.

So do what you can with the cash on hand. Think hard and determine what's really essential and what you can do without. What can you do with three people instead of ten? What can you do with $20k instead of $100k? What can you do in three months instead of six? What can you do if you keep your day job and build your app on the side?

Constraints force creativity

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.

Constraints also force you to get your idea out in the wild sooner rather than later — another good thing. A month or two out of the gates you should have a pretty good idea of whether you're onto something or not. If you are, you'll be self-sustainable shortly and won't need external cash. If your idea's a lemon, it's time to go back to the drawing board. At least you know now as opposed to months (or years) down the road. And at least you can back out easily. Exit plans get a lot trickier once investors are involved.

If you're creating software just to make a quick buck, it will show. Truth is a quick payout is pretty unlikely. So focus on building a quality tool that you and your customers can live with for a long time.

---

Fix Time and Budget, Flex Scope

Launch on time and on budget

Here's an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope.

There's a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happens and when it does quality often suffers.

If you can't fit everything in within the time and budget allotted then don't expand the time and budget. Instead, pull back the scope. There's always time to add stuff later — later is eternal, now is fleeting.

Launching something great that's a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, and scope window. Leave the magic to Houdini. You've got a real business to run and a real product to deliver.

Here are the benefits of fixing time and budget, and keeping scope flexible:

• Prioritization

  You have to figure out what's really important. What's going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.

• Reality

  Setting expectations is key. If you try to fix time, budget, and scope, you won't be able to deliver at a high level of quality. Sure, you can probably deliver something, but is "something" what you really want to deliver?

• Flexibility

  The ability to change is key. Having everything fixed makes it tough to change. Injecting scope flexibility will introduce options based on your real experience building the product. Flexibility is your friend.

Our recommendation: Scope down. It's better to make half a product than a half-assed product (more on this later).

---

Have an Enemy

Pick a fight

Sometimes the best way to know what your app should be is to know what it shouldn't be. Figure out your app's enemy and you'll shine a light on where you need to go.

When we decided to create project management software, we knew Microsoft Project was the gorilla in the room. Instead of fearing the gorilla, we used it as a motivator. We decided Basecamp would be something completely different, the anti-Project.

We realized project management isn't about charts, graphs, reports and statistics — it's about communication. It also isn't about a project manager sitting up high and broadcasting a project plan. It's about everyone taking responsibility together to make the project work.

Our enemy was the Project Management Dictators and the tools they used to crack the whip. We wanted to democratize project management — make it something everyone was a part of (including the client). Projects turn out better when everyone takes collective ownership of the process.

When it came to Writeboard, we knew there were competitors out there with lots of whizbang features. So we decided to emphasize a "no fuss" angle instead. We created an app that let people share and collaborate on ideas simply, without bogging them down with non-essential features. If it wasn't essential, we left it out. And in just three months after launch, over 100,000 Writeboards have been created.

When we started on Backpack our enemy was structure and rigid rules. People should be able to organize their information their own way — not based on a series of preformatted screens or a plethora of required form fields.

One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.

Now with all that said, it's also important to not get too obsessed with the competition. 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.

---

It Shouldn't be a Chore

Your passion — or lack of — will shine through

The less your app is a chore to build, the better it will be. Keep it small and managable so you can actually enjoy the process.

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.

---

Stay Lean chapter 3

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. It's as true in the business world as it is in the physical world.

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. That's why you need to shoot for less mass.

Mass is increased by...

• Long term contracts
• Excess staff
• Permanent decisions
• Meetings about other meetings
• Thick process
• Inventory (physical or mental)
• Hardware, software, technology lock-ins
• Proprietary data formats
• The past ruling the future
• Long-term roadmaps
• Office politics

Mass is reduced by...

• Just-in-time thinking
• Multi-tasking team members
• Embracing constraints, not trying to lift them
• Less software, less code
• Less features
• Small team size
• Simplicity
• Pared-down interfaces
• Open-source products
• Open data formats
• An open culture that makes it easy to admit mistakes

Less mass lets you change direction quickly. You can react and evolve. You can focus on the good ideas and drop the bad ones. You can listen and respond to your customers. You can integrate new technologies now instead of later. Instead of an aircraft carrier, you steer a cigarette boat. Revel in that fact.

For example, let's imagine a lean, less mass company that has built a product with less software and less features. On the other side is a more mass company that's got a product with significantly more software and more features. Then let's say a new technology like Ajax or a new concept like tagging comes around. Who is going to be able to adapt their product quicker? The team with more software and more features and a 12-month roadmap or the team with less software and less features and a more organic "let's focus on what we need to focus on right now" process?

Obviously the less-mass company is in a better position to adjust to the real demands of the marketplace. The more-mass company will likely still be discussing changes or pushing them through its bureaucratic process long after the less-mass company has made the switch. The less mass company will be two steps ahead while the more mass company is still figuring out how to walk.

Nimble, agile, less-mass businesses can quickly change their entire business model, product, feature set, and marketing message. They can make mistakes and fix them quickly. They can change their priorities, product mix, and focus. And, most importantly, they can change their minds.

---

Lower Your Cost of Change

Stay flexible by reducing obstacles to change

Change is your best friend. The more expensive it is to make a change, the less likely you'll make it. And if your competitors can change faster than you, you're at a huge disadvantage. If change gets too expensive, you're dead.

Here's where staying lean really helps you out. The ability to change on a dime is one thing small teams have by default that big teams can never have. This is where the big guys envy the little guys. What might take a big team in a huge organization weeks to change may only take a day in a small, lean organization. That advantage is priceless. Cheap and fast changes are small's secret weapon.

And remember: All the cash, all the marketing, all the people in the world can't buy the agility you get from being small.

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. That's why you need to shoot for less mass.

---

The Three Musketeers

Use a team of three for version 1.0

For the first version of your app, start with only three people. That's the magic number that will give you enough manpower yet allow you to stay streamlined and agile. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).

Now sure, it's a challenge to build an app with only a few people. But if you've got the right team, it's worth it. Talented people don't need endless resources. They thrive on the challenge of working within restraints and using their creativity to solve problems. Your lack of manpower means you'll be forced to deal with tradeoffs earlier in the process — and that's alright. It will make you figure out your priorities earlier rather than later. And you'll be able to communicate without constantly having to worry about leaving people out of the loop.

If you can't build your version one with three people, then you either need different people or need to slim down your initial version. Remember, 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 to go around. Not enough time. Not enough money. Not enough people.

That's a good thing.

Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.

When 37signals was building Basecamp, we had plenty of limitations. We had:

• A design firm to run
• Existing client work
• A 7-hour time difference (David was doing the programming in Denmark, the rest of us were in the States)
• A small team
• No outside funding

We felt the "not enough" blues. So we kept our plate small. That way we could only put so much on it. We took big tasks and broke them up into small bits that we tackled one at a time. We moved step by step and prioritized as we went along.

That forced us to come up with creative solutions. We lowered our cost of change by always building less software. We gave people just enough features to solve their own problems their own way — and then we got out of the way. The time difference and distance between us made us more efficient in our communication. Instead of meeting in person, we communicated almost exclusively via im and email which forced us to get to the point quickly.

Constraints are often advantages in disguise. Forget about venture capital, long release cycles, and quick hires. Instead, work with what you have.

---

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. It's as if they perceive their size as a weakness that needs to be covered up. Too bad. Being small can actually be a huge advantage, especially when it comes to communication.

Small companies enjoy fewer formalities, less bureaucracy, and more freedom. Smaller companies are closer to the customer by default. That means they can communicate in a more direct and personal way with customers. If you're small, you can use familiar language instead of jargon. Your site and your product can have a human voice instead of sounding like a corporate drone. Being small means you can talk with your customers, not down to them.

There are also advantages to internal communications at small companies too. You can ditch formalities. There's no need for arduous processes and multiple sign-offs on everything. Everyone in the process can speak openly and honestly. This unfettered flow of ideas is one of the big advantages of staying small.

---

Priorities chapter 4

What's the Big Idea

Differentiate yourself from bigger companies by being personal and friendly

Explicitly define the one-point vision for your app What does your app stand for? What's it really all about? Before you start designing or coding anything you need to know the purpose of your product — the vision. Think big. Why does it exist? What makes it different than other similar products?

This vision will guide your decisions and keep you on a consistent path. Whenever there's a sticking point, ask, "Are we staying true to the vision?"

Your vision should be brief too. A sentence should be enough to get the idea across. Here's the vision for each of our products:

• Basecamp: Project management is communication
• Backpack: Bring life's loose ends together
• Campfire: Group chat over IM sucks
• Ta-da List: Competing with a post-it note
• Writeboard: Word is overkill

With Basecamp, for example, the vision was "Project management is communication." We felt strongly that effective communication on a project leads to collective ownership, involvement, investment, and momentum. It gets everyone on the same page working toward a common goal. We knew if Basecamp could accomplish this, everything else would fall in line.

This vision led us to keep Basecamp as open and transparent as possible. Instead of limiting communication to within a firm, we gave clients access too. We thought less about permissions and more about encouraging all participants to take part. The vision is why we skipped charts, graphs, tables, reports, stats, and spreadsheets and instead focused on communication priorities like messages, comments, to-do lists, and sharing files. Make the big decision about your vision upfront and all your future little decisions become much easier.

---

Ignore Details Early On

Work from large to small

We're crazy about details.

• The space between objects
• The perfect type leading
• The perfect color
• The perfect words
• Four lines of code instead of seven
• 90% vs 89%
• 760px vs 750px
• $39/month vs. $49/month

Success and satisfaction is in the details.

However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.

How often have you found yourself stuck on a single design or code element for a whole day? How often have you realized that the progress you made today wasn't real progress? This happens when you focus on details too early in the process. There's plenty of time to be a perfectionist. Just do it later.

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 that "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.

Details reveal themselves as you use what you're building. You'll see what needs more attention. You'll feel what's missing. You'll know which potholes to pave over because you'll keep hitting them. That's when you need to pay attention, not sooner.

---

It's a Problem When It's a Problem

Don't waste time on problems you don't have yet

Do you really need to worry about scaling to 100,000 users today if it will take you two years to get there?

Do you really have to hire eight programmers if you only need three today?

Do you really need 12 top-of-the-line servers now if you can run on two for a year?

Just Wing It

People often spend too much time up front trying to solve problems they don't even have yet. Don't. Heck, we launched Basecamp without the ability to bill customers! Since the product billed in monthly cycles, we knew we had a 30-day gap to figure it out. We used that time to solve more urgent problems and then, after launch, we tackled billing. It worked out fine (and it forced us into a simple solution without unnecessary bells and whistles).

Don't sweat stuff until you actually must. Don't overbuild. Increase hardware and system software as necessary. If you're slow for a week or two it's not the end of the world. Just be honest: explain to your customers you're experiencing some growing pains. They may not be thrilled but they'll appreciate the candor.

Bottom Line: 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 on the things that require immediate care.

---

Hire the Right Customers

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

When we built Basecamp we focused our marketing on design firms. By narrowing our market this way, we made it more likely to attract passionate customers who, in turn, would evan gelize the product. Know who your app is really intended for and focus on pleasing them.

---

Scale Later

You don't have a scaling problem yet

"Will my app scale when millions of people start using it?"

Ya know what? Wait until that actually happens. If you've got a huge number of people overloading your system then huzzah! That's one swell problem to have. The truth is the overwhelming majority of web apps are never going to reach that stage. And even if you do start to get overloaded it's usually not an allor-nothing issue. You'll have time to adjust and respond to the problem. Plus, you'll have more real-world data and benchmarks after you launch which you can use to figure out the areas that need to be addressed.

For example, we ran Basecamp on a single server for the first year. Because we went with such a simple setup, it only took a week to implement. We didn't start with a cluster of 15 boxes or spend months worrying about scaling.

Did we experience any problems? A few. But we also realized that most of the problems we feared, like a brief slowdown, really weren't that big of a deal to customers. As long as you keep people in the loop, and are honest about the situation, they'll understand. In retrospect, we're quite glad we didn't delay launch for months in order to create "the perfect setup."

In the beginning, make building a solid core product your priority instead of obsessing over scalability and server farms. Create a great app and then worry about what to do once it's wildly successful. Otherwise you may waste energy, time, and money fixating on something that never even happens.

Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second.

---

Make Opinionated Software

Your app should take sides

Some people argue software should be agnostic. They say it's arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible.

We think that's bullshit. The best software has a vision. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision. Decide what your vision is and run with it.

And remember, if they don't like your vision there are plenty of other visions out there for people. Don't go chasing people you'll never make happy.

A great example is the original wiki design. Ward Cunningham and friends deliberately stripped the wiki of many features that were considered integral to document collaboration in the past. Instead of attributing each change of the document to a certain person, they removed much of the visual representation of ownership. They made the content ego-less and time-less. They decided it wasn't important who wrote the content or when it was written. And that has made all the difference. This decision fostered a shared sense of community and was a key ingredient in the success of Wikipedia.

Our apps have followed a similar path. They don't try to be all things to all people. They have an attitude. They seek out customers who are actually partners. They speak to people who share our vision. You're either on the bus or off the bus.

---

Feature Selection chapter 5

Half, Not Half-Assed

Build half a product, not a half-ass product

Beware of the "everything but the kitchen sink" approach to web app development. 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.

Stick to what's truly essential. Good ideas can be tabled. 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.

With Basecamp, we started with just the messages section. We knew that was the heart of the app so we ignored milestones, to-do lists, and other items for the time being. That let us base future decisions on real world usage instead of hunches.

Start off with a lean, smart app and let it gain traction. Then you can start to add to the solid foundation you've built.

---

It Just Doesn't Matter

Essentials only

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 matters and leaving out the rest.

When we launched Campfire we heard some of these questions from people checking out the product for the first time:

"Why time stamps only every 5 minutes? Why not time stamp every chat line?" Answer: It just doesn't matter. How often do you need to track a conversation by the second or even the minute? Certainly not 95% of the time. 5 minute stamps are sufficient because anything more specific just doesn't matter.

"Why don't you allow bold or italic or colored formatting in the chats?" Answer: It just doesn't matter. If you need to emphasize something use the trusty caps lock key or toss a few *'s around the word or phrase. Those solutions don't require additional software, tech support, processing power, or have a learning curve. Besides, heavy formatting in a simple text-based chat just doesn't matter.

"Why don't you show the total number of people in the room at a given time?" Answer: It just doesn't matter. Everyone's name is listed so you know who's there, but what difference does it make if there's 12 or 16 people? If it doesn't change your behavior, then it just doesn't matter.

Would these things be nice to have? Sure. But are they essential? Do they really matter? Nope. And that's why we left them out. The best designers and the best programmers aren't the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn't matter. That's where the real gains are made.

Most of the time you spend is wasted on things that just don't matter. If you can cut out the work and thinking that just don't matter, you'll achieve productivity you've never imagined.

---

Start With No

Make features work hard to be implemented

The secret to building half a product instead of a half-ass product is saying 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 (e.g. design, implementation, testing, etc.). And once that feature's out there, you're stuck with it. Just try to take a released feature away from customers and see how pissed off they get.

Don't be a yes-man

Make each feature work hard to be implemented. Make each feature prove itself and show that it's a survivor. It's like "Fight Club." You should only consider features if they're willing to stand on the porch for three days waiting to be let in.

That's why you start with no. Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is "not now." If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.

And what do you say to people who complain when you won't adopt their feature idea? Remind them why they like the app in the first place. "You like it because we say no. You like it because it doesn't do 100 other things. You like it because it doesn't try to please everyone all the time."

---

Hidden Costs

Expose the price of new features

Even if a feature makes it past the "no" stage, you still need to expose its hidden costs.

For example, be on the lookout for feature loops (i.e. features that lead to more features). We've had requests to add a meetings tab to Basecamp. Seems simple enough until you examine it closely. Think of all the different items a meetings tab might require: location, time, room, people, email invites, calendar integration, support documentation, etc. That's not to mention that we'd have to change promotional screenshots, tour pages, faq/help pages, the terms of service, and more. Before you know it, a simple idea can snowball into a major headache.

For every new feature you need to...

• 1. Say no.
• 2. Force the feature to prove its value.
• 3. If "no" again, end here. If "yes," continue...
• 4. Sketch the screen(s)/ui.
• 5. Design the screen(s)/ui.
• 6. Code it.
• 7-15. Test, tweak, test, tweak, test, tweak, test, tweak...
• 16. Check to see if help text needs to be modified.
• 17. Update the product tour (if necessary).
• 18. Update the marketing copy (if necessary).
• 19. Update the terms of service (if necessary).
• 20. Check to see if any promises were broken.
• 21. Check to see if pricing structure is affected.
• 22. Launch.
• 23. Hold breath.

---

Can You Handle It?

Build something you can manage

If you launch an affiliate program do you have the systems in place to handle the accounting and payouts? Maybe you should just let people earn credit against their membership fees instead of writing, signing, and mailing a check each month.

Can you afford to give away 1 gb of space for free just because Google does? Maybe you should start small at 100 mb, or only provide space on paying accounts.

Bottom line: Build products and offer services you can manage. It's easy to make promises. It's much harder to keep them. Make sure whatever it is that you're doing is something you can actually sustain — organizationally, strategically, and financially.

---

Human Solutions

Build software for general concepts and encourage people to create their own solutions

Don't force conventions on people. Instead make your software general so everyone can find their own solution. Give people just enough to solve their own problems their own way. And then get out of the way.

When we built Ta-da List we intentionally omitted a lot of stuff. There's no way to assign a to-do to someone, there's no way to mark a date due, there's no way to categorize items, etc.

We kept the tool clean and uncluttered by letting people get creative. People figured out how to solve issues on their own. If they wanted to add a date to a to-do item they could just add (due: April 7, 2006) to the front of the item. If they wanted to add a category, they could just add [Books] to the front of the item. Ideal? No. Infinitely flexible? Yes.

If we tried to build software to specifically handle these scenarios, we'd be making it less useful for all the cases when those concerns don't apply.

Do the best job you can with the root of the problem then step aside. People will find their own solutions and conventions within your general framework.

---

Forget Feature Requests

Let your customers remind you what's important

Customers want everything under the sun. They'll avalanche you with feature requests. Just check out our product forums; The feature request category always trumps the others by a wide margin.

We'll hear about "this little extra feature" or "this can't be hard" or "wouldn't it be easy to add this" or "it should take just a few seconds to put it in" or "if you added this I'd pay twice as much" and so on.

Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.

How did we come to this conclusion? When we first launched Basecamp we tracked every major feature request on a Basecamp to-do list. When a request was repeated by someone else we'd update the list with an extra hash mark (II or III or IIII, etc). We figured that one day we'd review this list and start working from the most requested features on down.

But the truth is we never looked at it again. We already knew what needed to be done next because our customers constantly reminded us by making the same requests over and over again. There was no need for a list or lots of analysis because it was all happening in real time. You can't forget what's important when you are reminded of it every day.

And one more thing: Just because x number of people request something, doesn't mean you have to include it. Sometimes it's better to just say no and maintain your vision for the product.

---

Hold the Mayo

Ask people what they don't want

Most software surveys and research questions are centered around what people want in a product. "What feature do you think is missing?" "If you could add just one thing, what would it be?" "What would make this product more useful for you?"

What about the other side of the coin? Why not 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?"

More isn't the answer. Sometimes the biggest favor you can do for customers is to leave something out.

---

Process chapter 6

Race to Running Software

Get something real up and running quickly

Running software is the best way to build momentum, rally your team, and flush out ideas that don't work. It should be your number one priority from day one.

It's ok to do less, skip details, and take shortcuts in your process if it'll lead to running software faster. Once you're there, you'll be rewarded with a significantly more accurate perspective on how to proceed. Stories, wireframes, even html mockups, are just approximations. Running software is real.

With real, running software everyone gets closer to true understanding and agreement. You avoid heated arguments over sketches and paragraphs that wind up turning out not to matter anyway. You realize that parts you thought were trivial are actually quite crucial.

Real things lead to real reactions. And that's how you get to the truth.

---

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. With web-based software there's no need to ship perfection. Design screens, use them, analyze them, and then start over again.

Instead of banking on getting everything right upfront, the iterative process lets you continue to make informed decisions as you go along. Plus, you'll get an active app up and running quicker since you're not striving for perfection right out the gate. The result is real feedback and real guidance on what requires your attention.

Iterations lead to liberation

You don't need to aim for perfection on the first try if you know it's just going to be done again later anyway. Knowing that you're going to revisit issues is a great motivator to just get ideas out there to see if they'll fly.

---

From Idea to Implementation

Go from brainstorm to sketches to HTML to coding

Here's the process we use to Get Real:

Brainstorm

Come up with ideas. What is this product going to do? For Basecamp, we looked at our own needs. We wanted to post project updates. We wanted clients to participate. We knew that projects had milestones. We wanted to centralize archives so people could easily review old stuff. We wanted to have a big-picture, bird's-eye view of what's going on with all our projects. Together, those assumptions, and a few others, served as our foundation.

This stage is not about nitty gritty details. This is about big questions. What does the app need to do? How will we know when it's useful? What exactly are we going to make? This is about high level ideas, not pixel-level discussions. At this stage, those kinds of details just aren't meaningful.

Paper sketches

Sketches are quick, dirty, and cheap and that's exactly how you want to start out. Draw stuff. Scrawl stuff. Boxes, circles, lines. Get your ideas out of your head and onto paper. The goal at this point should be to convert concepts into rough interface designs. This step is all about experimentation. There are no wrong answers.

Create HTML screens

Make an html version of that feature (or section or flow, if it's more appropriate). Get something real posted so everyone can see what it looks like on screen.

For Basecamp, we first did the "post a message" screen, then the "edit a message" screen, and it went on from there.

Don't write any programming code yet. Just build a mock-up in html and css. Implementation comes later.

Code it

When the mock-up looks good and demonstrates enough of the necessary functionality, go ahead and plug in the programming code.

During this whole process remember to stay flexible and expect multiple iterations. You should feel free to throw away the deliverable of any particular step and start again if it turns out crappy. It's natural to go through this cycle multiple times.

---

Avoid Preferences

Decide the little details so your customers don't have to

You're faced with a tough decision: how many messages do we include on each page? Your first inclination may be to say, "Let's just make it a preference where people can choose 25, 50, or 100." That's the easy way out though. Just make a decision.

Preferences are a way to avoid making tough decisions

Instead of using your expertise to choose the best path, you're leaving it in the hands of customers. It may seem like you're doing them a favor but you're just making busy work for them (and it's likely they're busy enough). For customers, preference screens with an endless amount 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 are also evil because they create more software. More options require more code. And there's all the extra testing and designing you need to do too. You'll also wind up with preference permutations and interface screens that you never even see. That means bugs that you don't know about: broken layouts, busted tables, strange pagination issues, etc.

Make the call

Make simple decisions on behalf of your customers. That's what we did in Basecamp. The number of messages per page is 25. On the overview page, the last 25 items are shown. Messages are sorted in reverse chronological order. The five most recent projects are shown in the dashboard. There aren't any options. That's just the way it is.

Yes, you might make a bad call. But so what. If you do, people will complain and tell you about it. As always, you can adjust. Getting Real is all about being able to change on the fly.

---

"Done!"

Decisions are temporary so make the call and move on

Done. Start to think of it as a magical word. When you get to done it means something's been accomplished. A decision has been made and you can move on. Done means you're building momentum.

But wait, what if you screw up and make the wrong call? It's ok. This isn't brain surgery, it's a web app. As we keep saying, you'll likely have to revisit features and ideas multiple times during the process anyway. No matter how much you plan you're likely to get half wrong anyway. So don't do the "paralyis through analysis" thing. That only slows progress and saps morale.

Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn't work out.

Accept that decisions are temporary. Accept that mistakes will happen and realize it's no big deal as long as you can correct them quickly. Execute, build momentum, and move on.

---

Test in the Wild

Test your app via real world usage

There's no substitute for real people using your app in real ways. Get real data. Get real feedback. Then improve based on that info.

Formal usability testing is too stiff. Lab settings don't reflect reality. If you stand over someone's shoulder, you'll get some idea of what's working or not but people generally don't perform well in front of a camera. When someone else is watching, people are especially careful not to make mistakes — yet mistakes are exactly what you're looking for.

Instead, release beta features to a select few inside the real application itself. Have them use the beta features alongside the released features. This will expose these features to people's real data and real workflow. And that's where you'll get real results.

Further, don't have a release version and a beta version. They should always be the same thing. A separate beta version will only get a superficial walk through. The real version, with some beta features sprinkled in, will get the full workout.

---

Shrink Your Time

Break it down

Estimates that stretch into weeks or months are fantasies. The truth is you just don't know what's going to happen that far in advance.

So shrink your time. Keep breaking down timeframes into smaller chunks. Instead of a 12 week project, think of it as 12 weeklong projects. Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time.

The same theory applies to other problems too. Are you facing an issue that's too big to wrap your mind around? Break it down. Keep dividing problems into smaller and smaller pieces until you're able to digest them.

---

The Organization chapter 7

Unity

Don't split into silos

Too many companies separate design, development, copywriting, support, and marketing into different silos. While specialization has its advantages, it also creates a situation where staffers see just their own little world instead of the entire context of the web app.

As much as possible, integrate your team so there's a healthy back-and-forth dialogue throughout the process. Set up a system of checks and balances. Don't let things get lost in translation. Have copywriters work with designers. Make sure support queries are seen by developers.

Even better, hire people with multiple talents who can wear different hats during development. The end result will be a more harmonious product.

---

Alone Time

People need uninterrupted time to get things done

37signals is spread out over four cities and eight time zones. From Provo, Utah to Copenhagen, Denmark, the five of us are eight hours apart. One positive side effect of this eight hour difference is alone time.

There are only about 4-5 hours during the day that we're all up and working together. At other times, the us team is sleeping while David, who's in Denmark, is working. The rest of the time, we're working while David is sleeping. This gives us about half of the day together and the other half alone.

Guess which part of the day we get the most work done? The alone part. It's not that surprising really. Many people prefer to work either early in the morning or late at night — times when they're not being bothered.

When you have a long stretch when you aren't bothered, you can get in the zone. The zone is when you are most productive. It's when you don't have to mindshift between various tasks. It's when you aren't interrupted to answer a question or look up something or send an email or answer an im. The alone zone is where real progress is made.

Getting in the zone takes time. And that's why interruption is your enemy. It's like rem sleep — you don't just go to rem sleep, you go to sleep first and you make your way to rem. Any interruptions force you to start over. rem is where the real sleep magic happens. The alone time zone is where the real development magic happens.

Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except 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.

A successful alone time period means letting go of communication addiction. During alone time, give up instant messenging, phone calls, and meetings. Avoid any email thread that's going to require an immediate response. Just shut up and get to work.

---

Meetings Are Toxic

Don't have meetings

Do you really need a meeting? Meetings usually arise when a concept isn't clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire. The goal is to avoid meetings. Every minute you avoid spending in a meeting is a minute you can get real work done instead.

There's nothing more toxic to productivity than a meeting. Here's a few reasons why:

• They break your work day into small, incoherent pieces that disrupt your natural workflow
• They're usually about words and abstract concepts, not real things (like a piece of code or some interface design)
• They usually convey an abysmally small amount of information per minute
• They often contain at least one moron that inevitably gets his turn to waste everyone's time with nonsense
• They drift off-subject easier than a Chicago cab in heavy snow
• They frequently have agendas so vague nobody is really sure what they are about
• They require thorough preparation that people rarely do anyway

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:

• Set a 30 minute timer. When it rings, meeting's over. Period.
• Invite as few people as possible.
• Never have a meeting without a clear agenda.

---

Seek and Celebrate Small Victories

Release something today

The most important thing in software development is motivation. Motivation is local — if you aren't motivated by what you are working on right now, then chances are it won't be as good as it should be. In fact, it's probably going to suck.

Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators. If you let lengthy release cycles quash quick wins, you kill the motivation. And that can kill your product.

So, if you're in the middle of a months-long release cycle, dedicate a day a week (or every two weeks) for some small victories. Ask yourself "What can we do and release in 4 hours?" And then do it. It could be...

• A new simple feature
• A small enhancement to an existing feature
• Rewriting some help text to reduce the support burden
• Removing some form fields that you really don't need

When you find those 4-hour quick wins, you'll find celebration. That builds morale, increases motivation, and reaffirms that the team is headed in the right direction.

---

Staffing chapter 8

Hire Less and Hire Later

Add slow to go fast

There's no need to get big early — or later. Even if you have access to 100 of the very best people, it's still a bad idea to try and hire them all at once. There's no way that you can immediately assimilate that many people into a coherent culture. You'll have training headaches, personality clashes, communication lapses, people going in different directions, and more.

So don't hire. Really. Don't hire people. Look for another way. Is the work that's burdening you really necessary? What if you just don't do it? Can you solve the problem with a slice of software or a change of practice instead?

Whenever Jack Welch, former ceo of ge, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long ge could get along without that person and that position. We're certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don't need as many people as you think.

If there's no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.

---

Kick the Tires

Work with prospective employees on a test-basis first

It's one thing to look at a portfolio, resume, code example, or previous work. It's another thing to actually work with someone. Whenever possible, take potential new team members out for a "test drive."

Before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. Working with someone as they design or code a few screens will give you a ton of insight. You'll learn pretty quickly whether or not the right vibe is there.

Scheduling can be tough for this sort of thing but even if it's for just 20 or 40 hours, it's better than nothing. If it's a good or bad fit, it will be obvious. And if not, both sides save themselves a lot of trouble and risk by testing out the situation first.

---

Actions, Not Words

Judge potential tech hires on open source contributions

The typical method of hiring for technical positions — based on degrees, resumés, etc. — is silly in a lot of ways. Does it really matter where someone's degree is from or their gpa? Can you really trust a resumé or a reference?

Open source is a gift to those who need to hire technical people. With open source, you can track someone's work and contributions — good and bad — over a lengthy period of time.

That means you can judge people by their actions instead of just their words. You can make a decision based on the things that really matter:

• Quality of work
  Many programmers can talk the talk but trip when it comes time to walk the walk. With open source, you get the nitty gritty specifics of a person's programming skills and practices.
• Cultural perspective
  Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point, values, and ideals. Look at the specific decisions made by a candidate in coding, testing, and community arguments to see whether you've got a cultural match. If there's no fit here, each decision will be a struggle.
• Level of passion
  By definition, involvement in open source requires at least some passion. Otherwise why would this person spend free time sitting in front of a screen? The amount of open source involvement often shows how much a candidate truly cares about programming.
• Completion percentage
  All the smarts, proper cultural leanings, and passion don't amount to valuable software if a person can't get stuff done. Unfortunately, lots of programmers can't. So look for that zeal to ship. Hire someone who needs to get it out the door and is willing to make the pragmatic trade-offs this may require.
• Social match
  Working with someone over a long period of time, during both stress/relaxation and highs/lows, will show you their real personality. If someone's lacking in manners or social skills, filter them out.

When it comes to programmers, we only hire people we know through open source. We think doing anything else is irresponsible. We hired Jamis because we followed his releases and participation in the Ruby community. He excelled in all the areas mentioned above. It wasn't necessary to rely on secondary factors since we could judge him based on what really matters: the quality of his work.

And don't worry that extra-curricular activities will take focus and passion away from a staffer's day job. It's like the old cliché says: If you want something done, ask the busiest person you know. Jamis and David are two of the heaviest contributors to Rails and still manage to drive 37signals technically. People who love to program and get things done are exactly the kind of people you want on your team.

---

Get Well Rounded Individuals

Go for quick learning generalists over ingrained specialists

We'll never hire someone who's an information architect. It's just too overly specific. With a small team like ours, it doesn't make sense to hire people with such a narrowly defined skill-set.

Small teams need people who can wear different hats. You need designers who can write. You need programmers who understand design. Everyone should have an idea about how to architect information (whatever that may mean). Everyone needs to have an organized mind. Everyone needs to be able to communicate with customers.

And everyone needs to be willing and able to shift gears down the road. Keep in mind that small teams often need to change direction and do it quickly. You want someone who can adjust and learn and flow as opposed to a stick-in-the-mud who can do only one thing.

---

You Can't Fake Enthusiasm

Go for happy and average over frustrated and great

Enthusiasm. It's one attribute you just can't fake. When it comes time to hire, don't think you need a guru or a tech-celebrity. Often, they're just primadonnas anyway. A happy yet average employee is better than a disgruntled expert.

Find someone who's enthusiastic. Someone you can trust to get things done when left alone. Someone who's suffered at a bigger, slower company and longs for a new environment. Someone who's excited to build what you're building. Someone who hates the same things you hate. Someone who's thrilled to climb aboard your train.

---

Wordsmiths

Hire good writers

If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.

That's because 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.

---

Interface Design chapter 9

Interface First

Design the interface before you start programming

Too many apps start with a program-first mentality. That's a bad idea. Programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change. Instead, start by designing first.

Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.

Another reason to design first is that the interface is your product. What people see is what you're selling. If you just slap an interface on at the end, the gaps will show.

We start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you're dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.

---

Epicenter Design

Start from the core of the page and build outward

Epicenter design focuses on the true essence of the page — the epicenter — and then builds outward. This means that, at the start, you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.

Whatever the page absolutely can't live without is the epicenter. For example, if you're designing a page that displays a blog post, the blog post itself is the epicenter. Not the categories in the sidebar, not the header at the top, not the comment form at the bottom, but the actual blog post unit. Without the blog post unit, the page isn't a blog post.

Only when that unit is complete would you begin to think about the second most critical element on the page. Then after the second most critical element, you'd move on to the third, and so on. That's epicenter design.

Epicenter design eschews the traditional "let's build the frame then drop the content in" model. In that process, the page shape is built, then the nav is included, then the marketing "stuff" is inserted, and then, finally, the core functionality, the actual purpose of the page, is poured in to whatever space remains. It's a backwards process that takes what should be the top priority and saves it for the end.

Epicenter design flips that process and allows you to focus on what really matters on day one. Essentials first, extras second. The result is a more friendly, focused, usable screen for customers. Plus, it allows you to start the dialogue between designer and developer right away instead of waiting for all aspects of the page to fall in line first.

---

Three State Solution

Design for regular, blank, and error states

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.

The regular state is a no-brainer. This is the screen where you'll spend most of your time. But don't forget to invest time on the other states too (see the following essays for more on this).

---

The Blank Slate

Set expectations with a thoughtful first-run experience

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

The problem is that when designing a ui, it's usually flush with data. Designers always fill templates with data. Every list, every post, every field, every nook and cranny has stuff in it. And that means the screen looks and works great.

However, the natural state of the app is one that's devoid of data. When someone signs up, they start with a blank slate. Much like a weblog, it's up to them to populate it — the overall look and feel doesn't take shape until people enter their data: posts, links, comments, hours, sidebar info, or whatever.

Unfortunately, the customer decides if an application is worthy at this blank slate stage — the stage when there's the least amount of information, design, and content on which to judge the overall usefulness of the application. When you fail to design an adequate blank slate, people don't know what they are missing because everything is missing.

Yet most designers and developers still take this stage for granted. They fail to spend a lot of time designing for the blank slate because when they develop/use the app, it's full of data that they've entered for testing purposes. They don't even encounter the blank slate. Sure, they may log-in as a new person a few times, but the majority of their time is spent swimming in an app that is full of data.

What should you include in a helpful blank slate?

• 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 (and why they should stick around).
• Explain how to get started, what the screen will eventually look like, etc.
• Answer key questions that first-time viewers will ask: What is this page? What do I do now? How will this screen look once it's full?
• Set expectations and help reduce frustration, intimidation, and overall confusion.

First impressions are crucial. If you fail to design a thoughtful blank slate, you'll create a negative (and false) impression of your application or service.

---

Get Defensive

Design for when things go wrong

Let's admit it: Things will go wrong online. No matter how carefully you design your app, no matter how much testing you do, customers will still encounter problems. So how do you handle these inevitable breakdowns? With defensive design.

Defensive design is like defensive driving. The same way drivers must always be on the lookout for slick roads, reckless drivers, and other dangerous scenarios, site builders must constantly search for trouble spots that cause visitors confusion and frustration. Good site defense can make or break the customer experience.

We could fill a separate book with all the things we have to say about defensive design. In fact, we already have. "Defensive Design for the Web" is the title and it's a great resource for anyone who wants to learn how to improve error screens and other crisis points.

Remember: Your app may work great 90% of the time. But if you abandon customers in their time of need, they're unlikely to forget it.

---

Context Over Consistency

What makes sense here may not make sense there

Should actions be buttons or links? It depends on the action. Should a calendar view be in list-form or grid-form? It depends where it's being shown and how long the time period is. Does every global navigation link need to be on every page? Do you need a global search bar everywhere? Do you need the same exact footer on each page? The answer: "It depends."

That's why context is more important than consistency. It's ok to be inconsistent if your design makes more sense that way. Give people just what matters. Give them what they need when they need it and get rid of what they don't. It's better to be right than to be consistent.