Getting Real

• chapitre 1 Introduction (traduction en cours : Rémi)
• chapitre 2 Ligne de départ(traduction en cours : Nick)
• chapitre 3 Rester léger(Traduit)
• chapitre 4 Priorités(Traduit)
• chapitre 5 Choisir sa richesse fonctionnelle
• chapitre 6 Processus(traduction en cours : Mehdi)
• chapitre 7 L'organisation(traduction en cours : Mehdi)
• chapitre 8 Recruter
• chapitre 9 Design d'interface (traduction en cours : Frédéric)
• chapitre 10 Code(Traduction en cours : Emmanuel)
• chapitre 11 Mots (en cours: Fred)
• chapitre 12 Prix et inscription(Traduit)
• chapitre 13 Promotion (Traduit)
• chapitre 14 Service et support aux clients(Traduit)
• chapitre 15 Après-lancement(Traduit)
• chapitre 16 Conclusion(Traduit)

---

Introduction chapitre 1

Qu'est-ce que Getting Real ?

Vous voulez construire une application web réussie ? Alors il est temps de Get Real. Getting Real est une manière de construire plus simplement, plus rapidement et mieux un logiciel.

• Getting Real consiste à éviter tout ce qui représente la réalité (diagrammes, graphiques, cases, flèches, schémas, tableaux de bord, etc.) pour construire réellement le produit.
• Getting real, c'est moins. Moins de masse, moins de logiciel, moins de fonctionnalités, mois de paperasse, mois de tout ce qui n'est pas essentiel (et la majorité de ce que vous estimez essentiel ne l'est pas).
• Getting real, c'est rester souple et agile.
• Getting real, ça commence par l'interface, par les écrans que les gens vont réellement utiliser. Ca commence par ce que ressent le client et ce qu'il construit à partir de ça. Ca permet d'avoir interface valide plutôt que de construire le mauvais logiciel.
• Getting real, c'est réitérer et réduire le coût du changement. Getting Real, c'est mettre en ligne, ajuster et améliorer en permanence, ce qui est parfaitement adapté pour du logiciel en ligne.
• Getting real propose uniquement ce dont les clients ont besoin et supprime le reste.

Les avantages de Getting Real

Getting Real débouche sur des meilleurs résultats parce que cela vous force à régler les problèmes réels et non les idées que vous vous faites de ces problèmes. Ca vous force à vous confronter à la réalité.

Getting Real renonce aux cahiers des charges fonctionnels et à toute documentation éphémère, au profit de la réalisation de vrais écrans. Les cahiers des charges fonctionnels sont un miroir aux alouettes, une illusion d'accord, alors qu'une page web est réelle. Voilà ce que vos clients vont voir et utiliser. Voilà ce qui est important. Getting real vous y amène plus rapidement. Et vous prenez ainsi des décisions basées sur votre projet plutôt que sur des notions abstraites.

Enfin, Getting Real est une approche idéale pour le logiciel diffusé via le web. L'ancien modèle consistant à envoyer le logiciel dans une boîte et attendre un an ou deux pour fournir une mise à jour est entrain de disparaître. Contrairement aux logiciels installés, les applications en ligne peuvent évoluer en permanence, à un rythme quotidien. Getting real optimise cet avantage.

Halte aux applications boursoufflées

L'ancienne méthode : un processus long, bureaucratique, on-va-faire-comme-ça-pour-assurer-nos-arrières. Le résultat : un logiciel boursoufflé, dégoulinant de médiocrité, très vite oublié. Beurk.

Getting Real vous débarrasse...

• Des plannings sur plusieurs mois voire années
• Des spécifications fonctionnelles qui promettent la lune
• Des débats sur la montée en charge
• Des interminables réunions d'équipe
• Du "besoin" d'embaucher une dizaine de salariés
• Des insignifiants numéros de versions
• Des feuilles de route cristallines qui prédisent un avenir radieux
• Des options de préférence sans fin
• Du support externalisé
• Des test d'utilisateus irréalistes
• De la paperasse inutile
• De la hiérarchie verticale

Vous n'avez pas besoin de tonnes d'argent ou d'une équipe pléthorique ou d'un long cycle de développement pour créer de très bons logiciels. Ces éléments sont pour des applicatins lentes, nébuleuses et immuables. Getting real propose une approche opposée.

Dans ce livre, nous vous expliquerons...

• L'importance d'avoir une philosophie
• Pourquoi rester petit est une bonne chose
• Comment construire moins
• Comment passer rapidement d'une idée à la réalité
• Comment recruter votre équipe
• Pourquoi vous devriez concevoir en partant de l'intérieur
• Pourquoi l'écriture est si importante
• Pourquoi vous devriez en faire moins que vos compétiteurs
• Comment promouvoir votre application et la faire connapitre
• Les secrets d'un support performant
• Des astuces pour garder la dynamique après le lancement
• ...et bien plus

Nous nous concentrerons sur les idées générales. Nous ne vous assènerons pas des bouts de code détaillés ou des trucs et astuces sur les CSS. Nous nous en tiendrons aux idées et à la philosophie principales qui gouvernent le processus Geting Real.

Est-ce que ce livre est pour vous ?

Vous êtes commerçant, dessinateur, programmeur ou charge de marketing qui fait naître une idée neuve.

Vous vous rendez compte du fait que les règles du passé ne sont plus d'usage. Est-ce que vous distribuez toujours vos logiciels sur du CD-ROM tous les ans ? Un acte dépassé depuis 2002. Des versions numérotées ? Jetez-les par la fenêtre. Il faut bâtir, déployez, puis faire des ajustements, encore et encore.

Ou peut-être que vous hésitez au sujet du développement agile, mais vous en avez hâte d'en apprendre plus.

Si ces phrases vous décrivent, alors ce livre est écrit pour vous.

Note : Ce livre traite du processus de construction d'une application web, mais un bon nombre des idées qui y sont exprimées sont applicables à d'autres domaines d'activités. Les suggestions concernant les équipes réduites, la conception rapide des prototypes, les itérations anticipées, et toutes les autres présentées ici peuvent servir de manuel, et ce que vous créiez une entreprise, écriviez un livre, designiez un site internet, enregistriez un album ou soyez à l'origine d'autres initiatives. Une fois que vous appliquerez Getting real à un domaine particulier de votre vie, vous verrez comment ces concepts s'appliquent à un large éventail de vos activités.

---

A propos de 37signals

Notre activité

37signals est une petite équipe qui crée des logiciels simples et ciblés. Nos produits vous aide à collaborer et à vous organiser. Plus de 350 000 personnes et petites entreprises utilisent nos applications en ligne pour *get things done*. Jeremy Wagstaff, du Wall Street Journal, a écrit : "Les produits de 37signals sont des outils incroyablement simples, élégants et intuitifs, qui font passer l'interface d'Outlook pour une chambre de torture." *Our apps never put you on the rack.*

Notre modus operandi

Nous pensons que les logiciels sont trop compliqués. Trop de fonctionnalités, trop de boutons, trop à apprendre. Nos produits font moins que la concurrence — volontairement. Nous construisons des produits qui fonctionnent intelligement, vous autorisent à faire les choses à votre manière et sont simples et agréables à utiliser.

Nos produits

Au moment où nous publions ce livre, nous avons cinq produits commerciaux et un framework de développement web.

Basecamp remet d'aplomb le management de projet. A la place des diagrammes de Gantt, des graphiques fantaisistes et des bilans remplis de statistiques, Basecamp propose de quoi échanger des messages, listes les choses à faire, planifier simplement, écrire à plusieurs et partager des fichiers. A ce jour, des centaines de milliers de personnes confirment que c'est la bonne méthode. Farhad Manjoo de Salon.com a dit "Basecamp symbolyse le futur du logiciel en ligne."

Campfire introduit la discussion de groupe en ligne dans l'environnement professionnel. Les entreprises averties connaissent l'importance que peut avoir *real-time persistent group chat*. La messagerie instatannées traditionnelle est bien pour des rapides chats en tête-à-tête, mais elle est peu pratique pour 3 personnes ou plus en même temps. Campfire résout ce problème et bien d'autres.

Backpack est l'aternative à ces *personal information managers* "organisez votre vie en 25 étapes simples" confus et complexes. L'approche simple de Backpack vis-à-vis des pages, notes, listes de choses à faire et alertes par téléphone/e-mail est une idée innovante dans une catégorie de produits qui souffrent de status-quo-ite. Thomas Weber du Wall Street Journal a dit qu'il s'agit du meilleur produit de sa catégorie et David Pogue du New York Times l'a qualifié d'outil d'organisation "très cool".

Writeboard vous permet d'écrire, de partager, de corriger et de comparer des textes, seul ou avec d'autres. C'est l'alternative idéale aux énormes logiciels de traitement de texte qui sont surpuissants 95% du temps. John Gruber de Daring Fireball a dit : "Writeboard est peut-être l'application en ligne la plus claire et la plus simple que je n'ai jamais vu." Le gourou du Web Jeffrey Zeldman a dit : "Les brillants cerveaux de 37signals ont récidivé."

Ta-da List rassemble en ligne vos listes de choses à faire. Gardez ces listes pour vous ou partagez-les avec d'autres pour une collaboration simplifiée. Il n'y a pas plus simple pour *get things done*. Plus de 100 000 listes avec près de 1 000 000 éléments ont été créées à ce jour.

Ruby on Rails, pour les développeurs, est framework open source de développement web *full-stack* en Ruby pour écrire simplement et rapidement de vraies applications. Rails s'occupe du sale boulot pour que vous vous focalisiez sur votre idée. Nathan Torkington du O'Reilly publishing empire a dit : "Ruby on Rails is incroyable. L'utiliser est comme regarder un film de kung-fu, où une douzaine de méchants frameworks qui s'apprêtaient à écraser le petit nouveau se font éclater de mille manières différentes." On adore cette citation.

Vous pouvez en découvrir plus sur nos produits et notre entreprise sur notre site web www.37signals.com.

---

Avertissements, démentis, et autres frappes préventives

Histoire de s'en débarasser, voici nos réponses aux reproches que nous entendons de temps en temps :

"Ces techniques ne marchent pas pour moi."

Getting real est une méthode qui a terriblement bien marché pour nous. Ceci étant dit, les idées de ce livre ne s'appliquent pas forcément à tous les projets de la Terre. Si vous construisez un système d'armement, une usine nucléaire, un système bancaire pour des millions de clients, ou d'autres systèmes critiques liés à la santé ou à la finance, vous allez rechigner à adopter notre *laissez-faire attitude*. Allez-y et prenez des précautions supplémentaires.

Et il ne s'agit pas de prendre tout ou rien. Même si vous ne pouvez pas adopter toute notre approche, il y a probablement au moins quelques idées que vous pouvez discrètement mettre en place.

"Vous n'avez rien inventé."

Nous ne prétendons pas avoir inventé ces techniques. Nombre de ces concepts sont dans l'air d'une manière ou d'une autre depuis longtemps. Ne soyez pas susceptibles si vous lisez un conseil et qu'il vous rappelle quelque chose que vous avez déjà lu sur tel blog and dans tel livre publié il y a longtemps. C'est très possible. Ces techniques ne sont pas exclusives à 37signals. Nous vous expliquons juste comment nous travaillons et ce qui a marché pour nous.

"Tout est ou noir ou blanc pour vous."

Si notre ton vous semble un peu "je-sais-tout", soyez indulgent. Nous pensons qu'il est préférable de présenter des idées *in bold strokes than to be wishy-washy about it*. Si cela sonne arrogant ou prétentieux, c'est comme ça. A choisir, nous préferions provoquer plutôt que tout relativiser en rajoutant systématiquement "Ca dépend...". Bien sûr qu'il faut parfois assouplir ou casser ces règles. Et certaines de ces tactiques ne s'appliquent peut-être pas à votre situation. Utilisez votre bon sens et votre imagination.

"Ca ne marchera pas dans mon entreprise."

Vous pensez être trop gros pour affronter la réalité ? Même Microsoft affronte la réalité (et nous doutons que vous êtes plus gros qu'eux).

Même si, classiquement, votre entreprise se base sur des plannings à long terme avec des grosses équipes, il reste des moyens d'affronter la réalité. La première étape est de se diviser en petites unités. Quand trop de gens sont impliqués, rien n'est fait. *The leaner you are, the faster — and better — things get done.*

C'est vrai, cela peut demander des talents de commercial. salesmanship. Parlez du processus d'Affronter la réalité dans votre entreprise. Montrz-leur ce livre. Montrez-leur les résultats que vous pouvez obtenir en moins de temps et avec une plus petite équipe.

Expliquez qu'Affronter la réalité est une manière peu coûteuse et peu risquée de tester de nouveaux concepts. Essayez de voir si vous pouvez * split off from the mothership on a smaller project as a proof of concept. Demonstrate results.*

Ou alors, si vous voulez vraiment y aller au culot, soyez discret. Agissez sans vous faire remarquer et montrez les vrais résultats. C'est l'approche que l'équipe de Start.com a choisi pour Affronter la réalité chez Microsoft. "J'ai vu les gars de Start.com travailler. Ils ne demandent pas la permission", dit Robert Scoble, *Technical Evangelist* chez Microsoft. "Ils ont un chef qui *provides air cover*. *And they bite off a little bit at a time and do that and respond to feedback*."

---

Ligne de départ chapter 2

En batir moins

En faire moins que la compétition

Selon la pensée traditionnelle, il faut en faire plus pour faire concurrence aux compétiteurs. Si chez eux, leur logiciel fait quatre taches, naturellement il faut que le votre en fassiez cinq (sinon 15 ou bien 25). S’ils dépensent x dollars il faut en doubler ça. S’ils on 20, il faut avoir 30.

Ce genre de mentalité guerre-froide est une véritable voie sans issue. Pour fabriquer un produit, c’est une méthode défensive et paranoiaque. Une entreprise défensive et paranoiaque ne peut penser en avant ; elle ne peut que penser en arrière. Elle ne conduit pas ; elle suit.

Si vous envisagez batir une entreprise qui ne fait que suivre, il vaudrait mieux poser ce pamphlet tout de suite.

Alors, que faire ? La réponse est tout simplement moins. En faire moins que vos concurrents afin de les battre. Résolvez les problèmes simples, et laissez les autres—les problemes minables et complexes—pour quelqu’un d’autre. Au lieu d’en faire un truc de plus, faites un truc de moins. Au lieu de faire une solution complexe, en faites une de simple.

Nous allons découvrir ce qui veut dire moins à longeur du livre, mais pour débuter, moins veut dire :

• Moins de richesse fonctionnelle
• Moins de préférences
• Moins de personnes, moins de bureaucratie
• Moins de réunions, moins d’idées abstaites
• Moins de promesses

---

C’est quoi ton problème ?

Se batir une solution logicelle

Une méthode sympa pour batir un logicel, c’est de résoudre ses propres défis. Vous en serez l’audience que vous visez, donc vous saurez ce qui a de l’importance et ce qui ne l’a pas. Comme ça vous pourrez partir en avant pour livrez un produit reussi.

La clé c’est de comprendre que vous n’êtes pas seul. Si vous, vous avez ce problème, il est vraisemblable que des centaines de milliers de gens sont là avec vous. Votre marché, il est là ! N’était-ce pas facile ?

Basecamp a eu son origine en réponse à un problème. En tant qu’entreprise en infographie, nous avions besoins d’une méthode simple pour communiquer avec nos clients au sujet de leur projets. Nous avons d’abord accompli cela au moyen des extranets que l’on mettait à date à main. Mais changer le langage HTML à main tout le temps ne marchait pas trop. Ces sites avait tendance à dévolver progressivement pour se faire abandonner. C’était frustrant : ça nous laissait décousus, et nos clients dans le noir.

Alors nous avons commencé a regarder d’autres options. Mais chaque outil qu’on a trouvé 1) ne faisait pas ce dont on avait besoin ; ou 2) était boursoufflé de richesse dont on avait pas du tout besoin, par example la facturation, les diagrammes, etc. Nous avons su qu’il devait y avoir quelque chose de meilleur—donc nous avons décidé de nous le batir.

Quand vous résolvez votre propre problème, vous crééez un outil pour lequel vous sentez de la passion. Cette passion est la clé. Cette passion veut dire que vous vous en servirez et que vous le soignerez. Et ça, c’est la meilleure façon de la reproduire chez les autres.

---

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.

---

Restez léger chapter 3

Moins de poids

Plus vous êtes léger, plus le changement est facile

Plus un objet est lourd, plus il faut d'énergie pour changer sa direction. C'est aussi vrai dans le monde des affaires.

En matière de technologie internet, les changements doivent être faciles et bon marché. Si vous ne pouvez pas apporter de changements à la volée, vous serez dépassés par ceux qui le peuvent. C'est pourquoi vous devez éliminer la surcharge pondérale.

La masse est accrue par...

• Les contrats à long terme
• Les équipes pléthoriques
• Les décisions irrévocables
• Les réunions qui débouchent sur d'autres réunions
• Les processus interminables
• Les inventaires (physiques ou mentaux)
• Le matériel, le logiciel, les verrous technologiques
• Les formats de données propriétaires
• Le passé gouvernant le futur
• Les feuilles de route à long terme
• Les politiques de couloir

La masse est réduite par...

• La réflexion juste à temps
• Une équipe multi-tâches
• Accepter les contraintes, et ne pas essayer de les contourner
• Moins de logiciel, moins de code
• Moins de fonctionnalités
• Une équipe de petite taille
• Simplicité
• Des interfaces utilisateurs dépouillées
• Open-source products
• Des formats de données ouverts
• Une ouverture d'esprit qui permet de reconnaître ses erreurs

Avec moins de poids vous pouvez changer de direction rapidement. Vous pouvez réagir et évoluer. Vous pouvez vous concentrer sur les bonnes idées et laisser tomber les mauvaises. Vous pouvez écouter et apporter des réponses à vos clients.Vous pouvez intégrer de nouvelles technologies sans attendre. Vous conduisez un canot au lieu d'un porte-avions. Savourez !

Imaginez par exemple une entreprise plus légère, moins lourde qui a conçu un produit avec moins de code et moins de fonctionnalités. En face, une société plus grosse qui possède un produit avec un nombre significatif de fonctionnalités supplémentaires et plus de lignes de code. Et maintenant, arrive une nouvelle technologie comme Ajax, ou un nouveau concept comme les mots-clés (tags). Qui va pouvoir mettre à jour son produit en premier ? L'équipe avec plus de code, plus de fonctionnalités et une feuille de route à 12 mois, ou l'équipe avec moins de code et de fonctionnalités, et des processus centrés sur "faisons maintenant ce que nous devons faire maintenant" ?

Il est évident que l'entreprise plus légère est en meilleure position pour s'adapter aux véritables exigences du marché. Les entreprises plus grosses seront probablement encore en train de discuter des changements ou de les faire passer dans des processus bureaucratiques bien après que l'entreprise légère aura franchi le pas. L'entreprise légère aura deux métros d'avance alors que l'entreprise plus lourde en sera encore à s'interroger sur la ligne à emprunter.

Les entreprises agiles et légères peuvent à tout moment modifier radicalement leur modèle économique, leur produit, la liste des fonctionalités et leur message marketing. Elles peuvent faire des erreurs et les corriger rapidement. Elles peuvent changer leurs priorités, leur combinaison de produits et leurs centres d'intérêt. Et encore plus important, elles peuvent changer d'avis.

---

Réduisez le coût du changement

Restez flexibles en réduisant les freins au changement

Le changement est votre meilleur ami. Plus les changements sont coûteux, moins vous aurez envie d'en faire. Si vos compétiteurs peuvent changer plus vite que vous, vous partez avec un sacré handicap. Et si le changement devient trop cher, vous êtes mort.

Voilà pourquoi rester léger est une aide précieuse. Pouvoir changer pour quelques centimes, est l'un des attributs des petites équipes que les grosses n'auront jamais. Là, les gros poissons envient les petits. Ce qui prendre à une équipe nombreuse dans une grande entreprise des semaines à modifier ne prendra peut-être qu'une journée dans une équipe petite et légère. Cet avantage n'a pas de prix. Changer vite et pour pas cher est l'arme secrète des petits.

Souvenez-vous en : tout l'argent, tout le marketing, toutes les équipes du monde ne vous achèteront pas la souplesse d'être petit.

En matière de technologie du web, les changeents doivent être simple et bon marché. Si vous ne pouvez changer à la volée, vous perdrez du terrain sur ceux qui en sont capables. C'est pourquoi vous devez vous astreindre à rester léger.

---

Les trois mousquetaires

Une équipe de trois personnes pour votre version 1.0

Pour la première version de votre application, commencez avec une équipe de trois personnes. Ce nombre magique vous permettra d'avoir suffisamment de ressources tout en vous gardant léger et agile. Commencez avec un développeur, un designer et touche à tout (quelqu'un qui puisse passer d'un métier à l'autre).

Bien sûr bâtir une application avec si peu de monde est un challenge. Mais si vous avez la bonne équipe, ça en vaut la peine. Des individus talentueux n'ont pas besoin de ressources infinies. Ils s'astreignent à travailler avec des contraintes et à utiliser leur créativité pour résoudre les problèmes. Votre manque de personnel vous obligera à faire des compromis plus tôt dans le processus, et c'est une bonne chose. Cela vous forcera à choisir vos priorités au démarrage, et pas quand il sera trop tard. Vous pourrez communiquer sans vous demander constamment qui n'est pas dans la boucle.

Si vous ne pouvez pas construire votre version avec trois personnes, vous devez changer les individus ou réduire vos ambitions. Souvenez-vous que rester simple et petit pour votre première version ne pose pas de problème. Vous verrez rapidement si votre idée tient la route, et si c'est le cas, vos fondations seront simples et solides.

---

Acceptez les contraintes

Les limitations doivent vous mener vers des solutions créatives

Vous n'avez jamais assez pour avancer. Pas assez de temps. Pas assez d'argent. Pas assez de monde.

C'est une bonne chose.

Au lieu de vous angoisser à l'idée de ces contraintes, acceptez les. Qu'elles soient votre guide. Les contraintes sont le moteur de l'innovation, et vous obligent à rester concentrés. Plutôt que d'essauer de les éliminer, utilisez-les à votre avantage.

Lorsque 37signals bâtissait Basecamp, nous avions de nombreuses limitations. Nous devions :

• Faire tourner notre studio de création graphique
• Nous occuper de nos clients existants
• Gérer une décalage horaire de 7 heures (David programmait au Danemark, et le reste de l'équipe se trouvait aux Etats-Unis)
• Faire avec une petite équipe
• Travailler sur nos fonds propres

Nous avions le blues du "pas assez". Alors nous avons réduit la taille de notre assiette. De cette façon, nous ne pouvions pas en mettre trop dessus. Nous avons divisé des tâches complexes en petits bouts que nous prenions l'un après l'autre. Nous avons avancé pas à pas et hiérarchisé en marchant.

Cela nous a forcé à trouver des solutions créatives. Nous avons abaissé le coût des changements en écrivant toujours moins de code. Nous avons écrit juste ce qu'il fallait de fonctionnalités pour que nos clients puissent résoudre leurs problèmes à leur manière, et nous en sommes restés là. Le décalage horaire et la distance a rendu notre communication plus efficace. Plutôt que de se réunir, nous avons privilégié le courrier électronique, ce qui nous a forcé à rester concis.

Les contraintes sont souvent des avantages qui ne disent pas leur nom. Oubliez le capital-risque, les cycles de mise sur le marché interminables, et les embauches rapides. Travaillez plutôt avec ce que vous avez.

---

Soyez vous-même

Différentiez-vous des engtreprises plus importantes en étant amical et personnel

De nombreuses petites entreprises font l'erreur d'essayer de paraître grosses. Comme si elle voyaient leur petite taille comme une faiblesse à cacher. Dommage. Etre petit présente des avantages majeurs, particulièrement en terme de communication

Les petites entreprises génèrent moins de formalités, moins de bureaucratie, et plus de liberté. Les petites entreprises sont par nature plus proches de leurs clients. Cela signifie qu'elles communiquent de façon plus directe et plus personnalisée avec leurs clients. Si vous êtes petit, vous pouvez employer des mots de tous les jours plutôt que du jargon. Votre site et votre produit peuvent avoir figure humaine, plutôt que de ressembler à un drone de la Worldwide Company. Etre petit vous permet de parler à vos clients sans condescendance.

Il y a également des avantages en ce qui concerne la communication interne. Vous pouvez oublier les formalités. Pas de processus compliqués et de signatures multiples à chaque étape. Tous les perticipants à l'aventure peuvent parler ouvertement et honnêtement. Ce flux d'idées non censuré est l'un des gros avantages à rester petit.

---

Priorités chapitre 4

Quelle est la grande idée

Distingue-toi des grandes compagnies en étant personnel et amical

Définir explicitement une vision de votre application en un point Que représente votre application ? De quoi s’agit-il ? Avant de commencer à concevoir ou à coder vous avez besoin de savoir le but de votre produit — la vision. Pensez-grand. Pourquoi existe-elle? Que ce qui la distingue des autres produits similaires?

La vision guidera vos décisions et vous permettra de rester consistent. Chaque fois que vous avez un nouveau morceau à coller, dites, « Sommes-nous fidèles à la vision ? »

Votre vision doit aussi être brève. Une phrase doit être assez suffisante pour résumer l’idée derrière. En voila la vision derrière chacun de nos produits :

• Basecamp: La gestion de projets est communication
• Backpack: Regrouper les bouts de la vie
• Campfire: Le clavardage en groupe à la place de l’IM
• Ta-da List: Concurrencer avec les post-It
• Writeboard: Un mot qui veut tout dire

Par exemple, avec Basecamp la vision était “La gestion de projets est communication.” Nous avons fortement resenti que dans un projet une vraie communication conduit à l’appartenance globale, l’implication, l investissement, et l’élan. Elle ramène tout le monde à la même page pour travailler pour la réalisation d’un objectif commun. Nous savions que si Basecamp va pouvoir accomplir cette tache, tout le reste suivra.

Cette vision nous a conduit à garder Basecamp aussi ouverte et transparente que possible. Au lieu de limiter la communication à l’intérieur d’une société, nous y procurant l’accès aux clients. Nous avons pensé moins aux permissions et plus à encourager tous les participants à prendre part. Cette vision est la raison pour laquelle nous avons mis de côté les diagrammes, les graphes, les tables, les rapports, les statistiques, et les feuilles de bilan et en contre partie nous avons mis l’accent sur les priorités de communication tel que les messages, les commentaires, les to-do listes, et le partage de fichiers. Faites la bonne décision sur votre vision en amont et toutes vos futures décisions seront plus faciles.

---

Au début ignorez les détails

Travaillez du plus grand au plus petit

Nous sommes fous au sujet des détails

• Les espaces entre les objets
• Le type parfait à utiliser
• La couleur parfaite
• Le mot parfait
• Quatre lignes de code au lieu de sept
• 90% vs 89%
• 760px vs 750px
• $39/mois vs. $49/mois

La réussite et la satisfaction sont dans les détails

Cependant, la réussite n’est pas la seule chose que vous allez retrouver dans les détails. Vous allez aussi retrouver la stagnation, le mécontentement, les réunions, et les délais. Ses choses peuvent saper le moral et diminuer vos chances de réussite.

Combien de fois vous vous êtes retrouvé collé toute une journée avec un seul élément de conception graphique ou de code? Combien de fois vous avez réalisé que votre avancement que vous avez réalisé aujourd’hui n’est pas un avancement réel ? Ceci arrive lorsque vous vous concentrez sur les détails trop tôt dans le processus. Il y a beaucoup de temps pour être perfectionniste. Juste le faire plus tard.

Ne vous souciez pas des la taille de la fonte des entêtes la première semaine. Vous n’avez pas besoin de fixer cette nuance de vert la deuxième semaine. Vous n’avez pas besoin de déplacer ce bouton « submit » à droite de trois pixels la troisième semaine. Pour l’instant, juste ayez les choses affichées dans la page. Puis, utilisez-la. Assurez-vous qu’elle fonctionne. Plus tard, vous aller pouvoir l’ajuster et la perfectionner.

Les détails se révèlent par l’utilisation de ce que vous construisez. Vous allez vous apercevoir de ce qui a besoin de plus d’attention. Vous allez sentir ce qui manque. Vous allez savoir quels nids de poule rembler avant parce que vous allez les détester. C’est à ce moment la que vous avez besoin de faire attention, pas avant.

---

C’est un problème lorsque c’est un problème

Ne perdez pas votre temps dans les problèmes vous n’en avez pas encore

Avez-vous réellement besoin de vous soucier de la mise en échelle à 100,000 utilisateurs aujourd’hui si ça va vous prendre deux ans à y arriver à ce chiffre ?

Devez-vous réellement recruter huit programmeurs si vous avez seulement besoin de trois ?

Avez-vous réellement besoin de 12 serveurs derniers cri maintenant si vous pouvez tourner sur deux pour un an ?

Met lui juste les ailles

Les gens souvent passent beaucoup de temps à essayer de résoudre des problèmes qu’ils n’ont pas encore. Ne le faites pas. Bordel, nous avons lancé Basecamp sans la possibilité de facturer les clients ! Du moment le produit est facturé mensuellement, nous savons que nous avons 30-jours de marge pour le faire. Nous avons utilisé ce temps pour résoudre des problèmes plus urgents et ensuite, après le lancement, nous avons abordé la facturation. Ça a bien marché (et ça nous a forcé à utiliser une solution simple sans les cloches et les sifflements inutiles).

Ne suez que lorsque vous le devez. Ne sur-construisez pas. N’augmenter pas le matériel et les logiciels plus que nécessaire. Si vous ralentissez pour une semaine ou deux ce n’est pas la fin du monde. Juste soyez honnête : expliquez à vos clients que vous éprouvez quelques difficultés. Ils ne devront pas s’affoler mais ils vont apprécier la franchise.

En résumé : Prenez les décisions juste à temps, quand vous avez accès aux vrais informations dont vous avez besoin. Entre temps, vous allez être capable de prodiguer l’attention aux choses qui exigent une prise en charge immédiate.

---

Contractez les bons clients

Trouvez le bon marché pour votre application et concentrez-vous seulement sur eux

Le client n’a pas toujours raison. La vérité est que vous avez à sélectionner ceux qui ont raison et ceux qui ont tord pour votre application. La bonne nouvelle est que l’internet rend la tâche de trouver les bonnes personnes plus facile que jamais.

Si vous essayez de plaire à tout le monde, vous n’allez plaire à personne

Lorsque nous avons construit Basecamp nous avons concentré notre marketing sur les sociétés de conception. Mais en rétrécissant notre marché de cette manière, nous l’avons rendu plus probable d’attirer des clients passionnés qui, en retour, vont évangéliser le produit. Reconnaissez pour qui votre application est réellement faite et concentrer vous à leur plaire.

---

Agrandissez plustard

Vous n’avez pas encore de problème de mise en échelle

« Est ce que mon application va tenir bon lorsque des millions de personnes commenceront à l’utiliser ? »

Vous savez quoi ? Attendez jusqu’à ce que cette situation arrive. Si vous avez un très grand nombre de personnes qui surchargent votre système alors Aïe! Ça c’est un bon problème à avoir. La vérité est que la plupart des applications Web ne vont jamais atteindre ce niveau. Et même si vous commencez à l’avoir surchargée ce n’est souvent pas une question de tout-ou-rien. Vous allez avoir le temps d’ajuster et fixer le problème. De plus, vous allez avoir des données plus réelles et des benchmarks après le lancement que vous allez pouvoir utiliser pour retrouver les parties qui ont besoins d’être adressées.

Par exemple, nous avons lancé Basecamp sur un seul serveur la première année. Bascamp on s’y est pris avec une simple mise en place, ça a seulement pris une semaine pour l’implémentation. Nous n’avons pas commencé avec un cluster de 15 boites ou passer des mois à se soucier de la mise en échelle.

Avons-nous eu des problèmes ? Quelques-uns. Mais nous avons réalisé que la plupart des problèmes que nous avons redoutés, comme un court ralentissement, n’étaient pas vraiment de grande importance pour les clients. Aussi longtemps que vous gardez les clients dans la boucle, et que vous êtes honnêtes concernant la situation, ils vont comprendre. En prenant du recul, nous somme tout à fait heureux de ne pas avoir retardé le lancement pendant des moins en attendant de créer « l’installation parfaite ».

Au début, rendez la construction d’un noyau solide votre priorité au lieu d’être obsédé par la mise en échelle et les parcs de serveurs. Créez une très bonne application ensuite souciez vous de ce qui doit être fait une fois qu’elle devient un grand succès. Si non, vous allez perdre votre énergie, votre temps, votre argent à fixer quelque chose qui ne sait jamais produite.

Croyez-le ou pas, le plus grand problème n’est pas la mise en échelle, mais d’arriver au point où vous allez avoir besoin d’élargir. Sans le premier problème vous n’allez pas avoir le deuxième.

---

Faire des logiciels opiniés

Votre application doit prendre des facettes

Quelques personnes pensent que le logiciel devrait être agnostique. Ils disent que c’est arrogant de la part des développeurs de limiter les fonctionnalités ou ignorer les demandes de fonctionnalités. Ils disent le logiciel doit toujours être aussi flexible que possible.

Nous pensons que c’est une connerie. Le meilleur logiciel a une vision. Le meilleur logiciel a des facettes. Quand quelqu’un utilise un logiciel, il ne cherche pas seulement les fonctionnalités, il cherche une approche. Ils cherchent une vision. Décidez quelle est votre vision et exécutez-la.

Et souvenez vous, s’ils n’aiment pas votre vision il a beaucoup d’autres visions ailleurs pour les gens. Ne courtisez jamais du monde qui ne sera jamais heureux.

Un bon exemple est la conception originale du wiki. Ward Cunningham et des amis ont délibérément dépouillé le wiki de plusieurs fonctionnalités qui ont été considérées dans le passé comme partie intégrante de la documentation de la collaboration. Au lieu d’attribuer chaque changement dans le document à une certaine personne, ils ont supprimé beaucoup de la représentation visuelle de l’appartenance. Ils ont rendu le contenu moins personnel et avec moins d’informations sur la chronologie des modifications. Ils ont décidé qu’il n’était pas important qui a écrit le contenu ou quand il a été écrit. Et ça a fait toute la différence. Cette décision à stimulé le sens de partage communautaire et était l’ingrédient principal dans le succès de Wikipedia.

Nos applications ont suivie un parcours similaire. Elles n’essaient pas d’être tout pour tout le monde. Elles ont une attitude. Elles recherchent des clients qui sont présentement des partenaires. Elles parlent aux gens qui partagent notre vision. Vous êtes soit à l’intérieur du bus ou à l’extérieur.

---

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

Trop de projects commencent par la phase de développement. C'est une mauvaise idée. Le développement est la phase la plus lourde lors d'un projet, en d'autres mots c'est la plus chère et la plus difficile à remettre en cause. Au lieu de cela, commencez par la phase de conception.

La phase de conception est plutôt légère. Un brouillon papier ne coûte pas cher et se retouche facilement. Les pages html sont encore relativement simple à modifier (ou à jeter). Ce n'est pas vrai pour le développement. Commencer par la phase de conception vous permet de rester fléxible. Commencer par le développement limite votre marge de manoeuvre et vous garantie des coûts additionnels.

Une autre raison de commencer par la phase de conception est que l'interface utilisateur est votre produit. Ce que vous vendez c'est ce que les gens voient. Si vous contentez de pondre une interface à la fin du projet, les lacunes apparaitront.

We start with the interface so we can see how the app looks and feels from the beginning. It's con