Ceiiing Real

| 7siuais
lhe smarter, faster, easier ua to
|uiio a successfui ue| appiicatiou
Copyright 2006 by 37signals
All rights reserved. No part ot this book may be reproduced in any torm
or by any electronic or mechanical means, including intormation storage
and retrieval systems, vithout permission in vriting trom 37signals,
except by a reviever vho may quote briet passages in a reviev.
lirst edition
Conienis
+ Inirouciion
: What is Getting Peal
o About 37signals
, Caveats, disclaimers, and other preemptive strikes
+: The 8iariing Line
+ Build Iess
+ What`s Your Problem
+; lund Yourselt
+, lix 1ime and Budget, llex Scope
:+ Have an Lnemy
: It Shouldn`t be a Chore
: 8iay Lean
:o Iess Mass
:, Iover Your Cost ot Change
+ 1he 1hree Musketeers
Lmbrace Constraints
Be Yourselt
; Prioriiies
: What`s the Big Idea
o Ignore Details Larly On
: It`s a Problem When It`s a Problem
Hire the Pight Customers
Scale Iater
o Make Opinionated Sottvare
; Feaiure 8eleciion
: Halt, Not Halt-Assed
, It ust Doesn`t Matter
+ Start With No
Hidden Costs
Can You Handle It
Human Solutions
o lorget leature Pequests
: Hold the Mayo
, Process
oo Pace to Punning Sottvare
o: Pinse and Pepeat
o lrom Idea to Implementation
oo Avoid Preterences
o: Done'
;o 1est in the Wild
;: Shrink Your 1ime
; The Organizaiion
;o Lnity
;; Alone 1ime
;, Meetings Are 1oxic
:+ Seek and Celebrate Small Victories
:: 8iang
: Hire Iess and Hire Iater
: Kick the 1ires
:o Actions, Not Words
:: Get Well Pounded Individuals
:, You Can`t lake Lnthusiasm
,o Wordsmiths
,+ Inierface Design
,: Intertace lirst
, Lpicenter Design
,o 1hree State Solution
,; 1he Blank Slate
,, Get Detensive
+oo Context Over Consistency
+o+ Copyvriting is Intertace Design
+o: One Intertace
+o Coe
+o Iess Sottvare
+o; Optimize tor Happiness
+o, Code Speaks
+++ Manage Debt
++: Open Doors
++ ors
++ 1here`s Nothing lunctional about a lunctional Spec
++: Don`t Do Dead Documents
+:o 1ell Me a Quick Story
+:+ Lse Peal Words
+: Personity Your Product
+: Pricing an 8ignup
+: lree Samples
+:; Lasy On, Lasy O
+:, Silly Pabbit, 1ricks are tor Kids
+o A Sotter Bullet
++ Promoiion
+: Hollyvood Iaunch
+ A Povertul Promo Site
+o Pide the Blog Wave
+; Solicit Larly
+: Promote 1hrough Lducation
++ leature lood
+ 1rack Your Iogs
+ Inline Lpsell
+ Name Hook
+o 8uppori
+; leel 1he Pain
+, Zero 1raining
+o Ansver Quick
+: 1ough Iove
+ In line lorum
+ Publicize Your Screvups
+; Posi-Launch
+: One Month 1uneup
+, Keep the Posts Coming
+o+ Better, Not Beta
+o: All Bugs Are Not Created Lqual
+o Pide Out the Storm
+o Keep Lp With the oneses
+o Bevare the Bloat Monster
+oo Go With the llov
+o; Conclusion
+o: Start Your Lngines
+;+ 37signals Pesources
Inirouciion
1hat is ettiu Peai`
|out 7siuais
Ca:eats, oisciaimers, auo other preempti:e strikes
:
hai is Ceiiing Real?
Want to build a successtul veb app 1hen it`s time to Get Peal.
Getting Peal is a smaller, taster, better vay to build sottvare.
Getting Peal is about skipping all the stu that
represeuts real (charts, graphs, boxes, arrovs, schematics,
viretrames, etc., and actuaii |uiioiu the reai thiu.
Getting real is less. Iess mass, less sottvare, less teatures,
less papervork, less ot everything that`s not essential (and
most ot vhat you think is essential actually isn`t,.
Getting Peal is staying small and being agile.
Getting Peal starts vith the intertace, the real screens that
people are going to use. It begins vith vhat the customer
actually experiences and builds backvards trom there. 1his lets
you get the intertace right betore you get the sottvare vrong.
Getting Peal is about iterations and lovering the
cost ot change. Getting Peal is all about launching,
tveaking, and constantly improving vhich makes
it a pertect approach tor veb-based sottvare.
Getting Peal delivers just vhat customers need
and eliminates anything they don`t.
1he benehts of Getting Real
Getting Peal delivers better results because it torces you to deal
vith the actual problems you`re trying to solve instead ot your
ideas about those problems. It torces you to deal vith reality.

Getting Peal toregoes tunctional specs and other transitory

documentation in tavor ot building real screens. A tunctional
spec is make-believe, an illusion ot agreement, vhile an actual
veb page is reality. 1hat`s vhat your customers are going to see
and use. 1hat`s vhat matters. Getting Peal gets you there taster.
And that means you`re making sottvare decisions based on the
real thing instead ot abstract notions.
linally, Getting Peal is an approach ideally suited to veb-based
sottvare. 1he old school model ot shipping sottvare in a box
and then vaiting a year or tvo to deliver an update is tading
avay. Lnlike installed sottvare, veb apps can constantly evolve
on a day-to-day basis. Getting Peal leverages this advantage tor
all its vorth.
Hou lo 1rite 1iorous :oftuare
Vigorous vriting is concise. A sentence should contain no unnecessary
vords, a paragraph no unnecessary sentences, tor the same reason that a
draving should have no unnecessary lines and a machine no unnecessary
parts. 1his requires not that the vriter make all sentences short or avoid
all detail and treat subjects only in outline, but that every vord tell.
From "The Elemenis of 8iyle' ly illiam 8irunk jr.
No nore bloat
1he old vay: a lengthy, bureaucratic, ve`re-doing-this-to-cover-
our-asses process. 1he typical result: bloated, torgettable sott-
vare dripping vith mediocrity. Blech.
Getting Real gets rid of...
1imelines that take months or even years
Pie-in-the-sky tunctional specs
Scalability debates

Interminable sta meetings

1he need to hire dozens ot employees
Meaningless version numbers
Pristine roadmaps that predict the pertect tuture
Lndless preterence options
Outsourced support
Lnrealistic user testing
Lseless papervork
1op-dovn hierarchy
You don`t need tons ot money or a huge team or a lengthy
development cycle to build great sottvare. 1hose things are the
ingredients tor slov, murky, changeless applications. Getting
real takes the opposite approach.
In this book vell shov you...
1he importance ot having a philosophy
Why staying small is a good thing
Hov to build less
Hov to get trom idea to reality quickly
Hov to sta your team
Why you should design trom the inside out
Why vriting is so crucial
Why you should underdo your competition

Hov to promote your app and spread the vord

Secrets to successtul support
1ips on keeping momentum going atter launch
...and lots more
1he tocus is on big-picture ideas. We von`t bog you dovn vith
detailed code snippets or css tricks. We`ll stick to the major
ideas and philosophies that drive the Getting Peal process.
Is this book for you?
You`re an entrepreneur, designer, programmer, or marketer
vorking on a big idea.
You realize the old rules don`t apply anymore. Distribute your
sottvare on ci-roxs every year Hov :oo:. Version numbers
Out the vindov. You need to build, launch, and tveak. 1hen
rinse and repeat.
Or maybe you`re not yet on board vith 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 veb app,
a lot ot these ideas are applicable to non-sottvare activities too.
1he suggestions about small teams, rapid prototyping, expect-
ing iterations, and many others presented here can serve as a
guide vhether you`re starting a business, vriting a book,
designing a veb site, recording an album, or doing a variety
ot other endeavors. Once you start Getting Peal in one area ot
your lite, you`ll see hov these concepts can apply to a vide
range ot activities.
o
Aloui 3'signals
What ve do
37signals is a small team that creates simple, tocused sottvare.
Our products help you collaborate and get organized. More
than o,ooo people and small businesses use our veb-apps to
get things done. eremy Wagsta, ot the Wall Street ournal,
vrote, 37signals products are beautitully simple, elegant and
intuitive tools that make an Outlook screen look like the sott-
vare equivalent ot a torture chamber. Our apps never put you
on the rack.
Our nodus operandi
We believe sottvare is too complex. 1oo many teatures, too
many buttons, too much to learn. Our products do less than
the competition intentionally. We build products that vork
smarter, teel better, allov you to do things your vay, and are
easier to use.
Our products
As ot the publishing date ot this book, ve have tve commercial
products and one open source veb application tramevork.
Basecanp turns project management on its head. Instead ot
Gantt charts, tancy graphs, and stats-heavy spreadsheets, Base-
camp oers message boards, to-do lists, simple scheduling, col-
laborative vriting, and tle sharing. So tar, hundreds ot thou-
sands agree it`s a better vay. larhad Manjoo ot Salon.com said
Basecamp represents the tuture ot sottvare on the Web.
;
Canphre brings simple group chat to the business setting.
Businesses in the knov understand hov valuable real-time
persistent group chat can be. Conventional instant messaging is
great tor quick 1-on-1 chats, but it`s miserable tor 3 or more
people at once. Camptre solves that problem and plenty more.
Backpack is the alternative to those contusing, complex, orga-
nize your lite in : simple steps personal intormation managers.
Backpack`s simple take on pages, notes, to-dos, and cellphone
email-based reminders is a novel idea in a product category that
suers trom status-quo-itis. 1homas Weber ot the Wall Street
ournal said it`s the best product in its class and David Pogue ot
the Nev York 1imes called it a very cool organization tool.
Writeboard lets you vrite, share, revise, and compare text
solo or vith others. It`s the retreshing alternative to bloated
vord processors that are overkill tor , ot vhat you vrite.
ohn Gruber ot Daring lireball said, Writeboard might be the
clearest, simplest veb application I`ve ever seen. Web-guru
erey Zeldman said, 1he brilliant minds at 37signals have
done it again.
1a-da List keeps all your to-do lists together and organized
online. Keep the lists to yourselt or share them vith others tor
easy collaboration. 1here`s no easier vay to get things done.
Over +oo,ooo lists vith nearly +,ooo,ooo items have been
created so tar.
Ruby on Rails, tor developers, is a tull-stack, open-source
veb tramevork in Puby tor vriting real-vorld applications
quickly and easily. Pails takes care ot the busy vork so you can
tocus on your idea. Nathan 1orkington ot the O`Peilly publish-
ing empire said Puby on Pails is astounding. Lsing it is like
vatching a kung-tu movie, vhere a dozen bad-ass tramevorks
prepare to beat up the little nevcomer only to be handed their
asses in a variety ot imaginative vays. Gotta love that quote.
:
You can tnd our more about our products and our company on
our veb site at: http:vvv.37signals.com.
,
Careais, isclaimers, an oiher
preempiire sirikes
ust to get it out ot the vay, here are our responses to some com-
plaints ve hear every nov and again:
1hese techniques vont vork for ne.
Getting real is a system that`s vorked territcally tor us. 1hat
said, the ideas in this book von`t apply to every project under
the sun. It you are building a veapons system, a nuclear control
plant, a banking system tor millions ot customers, or some other
litetnance-critical system, you`re going to balk at some ot our
laissez-taire attitude. Go ahead and take additional precautions.
And it doesn`t have to be an all or nothing proposition. Lven it
you can`t embrace Getting Peal tully, there are bound to be at
least a tev ideas in here you can sneak past the povers that be.
You didnt invent that idea.
We`re not claiming to have invented these techniques.
Many ot these concepts have been around in one torm or
another tor a long time. Don`t get huy it you read some
ot our advice and it reminds you ot something you read
about already on so and so`s veblog or in some book pub-
lished :o years ago. It`s detnitely possible. 1hese tech-
niques are not at all exclusive to 37signals. We`re just telling
you hov ve vork and vhat`s been successtul tor us.
+o
You take too nuch of a black and vhite viev.
It our tone seems too knov-it-allish, bear vith us. We think it`s
better to present ideas in bold strokes than to be vishy-vashy
about it. It that comes o as cocky or arrogant, so be it. We`d
rather be provocative than vater everything dovn vith it
depends... Ot course there vill be times vhen these rules need
to be stretched or broken. And some ot these tactics may not
apply to your situation. Lse your judgement and imagination.
1his vont vork inside ny conpany.
1hink you`re too big to Get Peal Lven Microsott is Getting
Peal (and ve doubt you`re bigger than them,.
Lven it your company typically runs on long-term schedules
vith big teams, there are still vays to get real.1he trst step is
to break up into smaller units. When there`s too many people
involved, nothing gets done. 1he leaner you are, the taster and
better things get done.
Granted, it may take some salesmanship. Pitch your company on
the Getting Peal process. Shov them this book. Shov them the
real results you can achieve in less time and vith a smaller team.
Lxplain that Getting Peal is a lov-risk, lov-investment vay to
test nev concepts. See it you can split o trom the mothership
on a smaller project as a proot ot concept. Demonstrate results.
Or, it you really vant to be ballsy, go stealth. lly under the
radar and demonstrate real results. 1hat`s the approach the
Start.com team has used vhile Getting Peal at Microsott. I`ve
vatched the Start.com team vork. 1hey don`t ask permission,
says Pobert Scoble, 1echnical Lvangelist at Microsott. 1hey
have a boss that provides air cover. And they bite o a little bit
at a time and do that and respond to teedback.
++
:hippiu Microsoft`s :tart.com
In big companies, processes and meetings are the norm. Many months are
spent on planning teatures and arguing details vith the goal ot everyone
reaching an agreement on vhat is the right thing tor the customer.
1hat may be the right approach tor shrink-vrapped sottvare, but vith the veb
ve have an incredible advantage. ust ship it' Iet the user tell you it it`s the right
thing and it it`s not, hey you can tx it and ship it to the veb the same day it
you vant' 1here is no vord stronger than the customer`s resist the urge to
engage in long-vinded meetings and arguments. ust ship it and prove a point.
Much easier said than done this implies:
Months ot planning are not necessary.
Months ot vriting specs are not necessary specs should have the toundations
nailed and details tgured out and retned during the development phase. Don`t
try to close all open issues and nail every single detail betore development starts.
Ship less teatures, but quality teatures.
You don`t need a big bang approach vith a vhole nev release and
bunch ot teatures. Give the users byte-size pieces that they can digest.
It there are minor bugs, ship it as soon you have the core scenarios
nailed and ship the bug txes to veb gradually atter that. 1he taster
you get the user teedback the better. Ideas can sound great on paper
but in practice turn out to be suboptimal. 1he sooner you tnd out
about tundamental issues that are vrong vith an idea, the better.
Once you iterate quickly and react on customer teedback, you
vill establish a customer connection. Pemember the goal is
to vin the customer by building vhat they vant.
-8anaz Ahari, Program Manager of 8iari.com, Microsofi
The 8iariing Line
Puiio Less
1hat`s Your Iro|iem`
Iuuo Yourseif
Iix lime auo Puoet, Iiex :cope
Ha:e au Luem
It :houiou`t |e a Chore
+
Buil Less
Underdo your conpetition
Conventional visdom says that to beat your competitors you
need to one-up them. It they have tour teatures, you need tve
(or +, or :,. It they`re spending x, you need to spend xx. It
they have :o, you need o.
1his sort ot one-upping Cold War mentality is a dead-end. It`s
an expensive, detensive, and paranoid vay ot building products.
Detensive, paranoid companies can`t think ahead, they can only
think behind. 1hey don`t lead, they tollov.
If ou uaut to |uiio a compau that foiious, ou miht as ueii put oouu
this |ook uou.
So vhat to do then 1he ansver is less. Do less than your com-
petitors to beat them. Solve the simple problems and leave the
hairy, dicult, nasty problems to everyone else. Instead ot one-
upping, try one-dovning. Instead ot outdoing, try underdoing.
We`ll cover the concept ot less throughout this book, but tor
starters, less means:
Iess teatures
Iess optionspreterences
Iess people and corporate structure
Iess meetings and abstractions
Iess promises
+
hai's Your Prollem?
Build softvare for yourself
A great vay to build sottvare is to start out by solving your ovn
problems. You`ll be the target audience and you`ll knov vhat`s
important and vhat`s not. 1hat gives you a great head start on
delivering a breakout product.
1he key here is understanding that you`re not alone. It you`re
having this problem, it`s likely hundreds ot thousands ot others
are in the same boat. 1here`s your market. Wasn`t that easy
Basecamp originated in a problem: As a design trm ve
needed a simple vay to communicate vith our clients
about projects. We started out doing this via client ex-
tranets vhich ve vould update manually. But changing the
n+xi by hand every time a project needed to be updated
just vasn`t vorking. 1hese project sites alvays seemed to
go stale and eventually vere abandoned. It vas trustrating
because it lett us disorganized and lett clients in the dark.
So ve started looking at other options. Yet every tool ve tound
either 1, didn`t do vhat ve needed or 2, vas bloated vith tea-
tures ve didn`t need like billing, strict access controls, charts,
graphs, etc. We knev there had to be a better vay so ve decided
to build our ovn.
When you solve your ovn 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 vay to get others to
teel passionate about it too.
+
:cratchiu our ouu itch
1he Open Source vorld embraced this mantra a long time ago
they call it scratching your ovn itch. lor the open source
developers, it means they get the tools they vant, delivered the
vay they vant them. But the benett goes much deeper.
As the designer or developer ot a nev application, you`re taced vith
hundreds ot micro-decisions each and every day: blue or green One
table or tvo Static or dynamic Abort or recover Hov do ve make
these decisions It it`s something ve recognize as being important, ve
might ask. 1he rest, ve guess. And all that guessing builds up a kind ot
debt in our applications an interconnected veb ot assumptions.
As a developer, I hate this. 1he knovledge ot all these small-scale
timebombs in the applications I vrite adds to my stress. Open Source
developers, scratching their ovn itches, don`t suer this. Because they are
their ovn users, they knov the correct ansvers to ,o ot the decisions
they have to make. I think this is one ot the reasons tolks come home
atter a hard day ot coding and then vork on open source: It`s relaxing.
Dare Thomas, The Pragmaiic Programmers
Poru out of uecessit
Campaign Monitor really vas born out ot necessity. lor years ve`d
been trustrated by the quality ot the email marketing options out
there. One tool vould do x and . but never z, the next had .
and z nailed but just couldn`t get x right. We couldn`t vin.
We decided to clear our schedule and have a go at building our
dream email marketing tool. We consciously decided not to look
at vhat everyone else vas doing and instead build something that
vould make ours and our customer`s lives a little easier.
As it turned out, ve veren`t the only ones vho vere unhappy vith
the options out there. We made a tev moditcations to the sottvare
so any design trm could use it and started spreading the vord. In
less than six months, thousands ot designers vere using Campaign
Monitor to send email nevsletters tor themselves and their clients.
Dari Creiner, founer, Campaign Moniior
+o
You ueeo to care a|out it
When you vrite a book, you need to have more than an interesting story.
You need to have a desire to tell the story. You need to be personally
invested in some vay. It you`re going to live vith something tor tvo
years, three years, the rest ot your lite, you need to care about it.
Malcolm Clauell, auihor ( from A Feu Thin 8lices of Malcolm Clauell)
+;
Fun Yourself
Outside noney is plan B
1he trst priority ot many startups is acquiring tunding trom
investors. But remember, it you turn to outsiders tor tunding,
you`ll have to ansver to them too. Lxpectations are raised.
Investors vant their money back and quickly. 1he sad tact is
cashing in otten begins to trump building a quality product.
1hese days it doesn`t take much to get rolling. Hardvare
is cheap and plenty ot great intrastructure sottvare is open
source and tree. And passion doesn`t come vith a price tag.
So do vhat you can vith the cash on hand. 1hink hard and
determine vhat`s really essential and vhat you can do vithout.
What can you do vith three people instead ot ten What can
you do vith x:ok instead ot x+ook What can you do in three
months instead ot six What can you do it you keep your day
job and build your app on the side
Constraints force creativity
Pun on limited resources and you`ll be torced to reckon vith
constraints earlier and more intensely. And that`s a good thing.
Constraints drive innovation.
+:
Constraints also torce you to get your idea out in the vild
sooner rather than later another good thing. A month or tvo
out ot the gates you should have a pretty good idea ot vhether
you`re onto something or not. It you are, you`ll be selt-sustain-
able shortly and von`t need external cash. It your idea`s a lemon,
it`s time to go back to the draving board. At least you knov
nov as opposed to months (or years, dovn the road. And at least
you can back out easily. Lxit plans get a lot trickier once inves-
tors are involved.
It you`re creating sottvare just to make a quick buck, it vill
shov. 1ruth is a quick payout is pretty unlikely. So tocus on
building a quality tool that you and your customers can live
vith tor a long time.
luo paths
[ake Walker started one company vith investor money (Disclive, and one
vithout (1he Shov,. Here he discusses the dierences betveen the tvo paths.|
1he root ot all the problems vasn`t raising money itselt, but everything that
came along vith it. 1he expectations are simply higher. People start taking salary,
and the motivation is to build it up and sell it, or tnd some other vay tor the
initial investors to make their money back. In the case ot the trst company,
ve simply started acting much bigger than ve vere out ot necessity...
[With 1he Shov| ve realized that ve could deliver a much better product
vith less costs, only vith more time. And ve gambled vith a bit ot our ovn
money that people vould be villing to vait tor quality over speed. But the
company has stayed (and vill likely continue to be, a small operation. And ever
since that trst project, ve`ve been tully selt tunded. With just a bit ot creative
terms trom our vendors, ve`ve never really need to put much ot our ovn
money into the operation at all. And the expectation isn`t to grov and sell, but
to grov tor the sake ot grovth and to continue to benett trom it tnancially.
A commeni from 8ignal rs. Noise
+,
Fix Time an Bugei, Flex 8cope
Launch on tine and on budget
Here`s an easy vay to launch on time and on budget: keep them
txed. Never throv more time or money at a problem, just scale
back the scope.
1here`s a myth that goes like this: ve can launch on time, on
budget, and on scope. It almost never happens and vhen it does
quality otten suers.
It you can`t tt everything in vithin the time and budget allot-
ted then don`t expand the time and budget. Instead, pull back
the scope. 1here`s alvays time to add stu later later is eternal,
nov is neeting.
Iaunching something great that`s a little smaller in scope than
planned is better than launching something mediocre and tull
ot holes because you had to hit some magical time, budget, and
scope vindov. Ieave the magic to Houdini. You`ve got a real
business to run and a real product to deliver.
Here are the benetts ot txing time and budget, and keeping
scope nexible:
Prioritization
You have to tgure out vhat`s really important. What`s
going to make it into this initial release 1his torces
a constraint on you vhich vill push you to make
tough decisions instead ot hemming and having.
:o
Reality
Setting expectations is key. It you try to tx time, budget,
and scope, you von`t be able to deliver at a high level
ot quality. Sure, you can probably deliver something,
but is something vhat you really vant to deliver
Fleibility
1he ability to change is key. Having everything txed
makes it tough to change. Injecting scope nexibility
vill introduce options based on your real experience
building the product. llexibility is your triend.
Our recommendation: Scope dovn. It`s better to make halt a
product than a halt-assed product (more on this later,.
Cue, tuo, three...
Hov does a project get to be a year behind schedule One day at a time.
-Fre Brooks, sofiuare engineer an compuier scieniisi
:+
Hare an Enemy
Pick a hght
Sometimes the best vay to knov vhat your app should be is
to knov vhat it shouldn`t be. ligure out your app`s enemy and
you`ll shine a light on vhere you need to go.
When ve decided to create project management sottvare, ve
knev Microsott Project vas the gorilla in the room. Instead ot
tearing the gorilla, ve used it as a motivator. We decided Base-
camp vould be something completely dierent, 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 vork.
Our enemy vas the Project Management Dictators and the tools
they used to crack the vhip. We vanted to democratize project
management make it something everyone vas a part ot (in-
cluding the client,. Projects turn out better vhen everyone takes
collective ovnership ot the process.
When it came to Writeboard, ve knev there vere competi-
tors out there vith lots ot vhizbang teatures. So ve decided to
emphasize a no tuss angle instead. We created an app that let
people share and collaborate on ideas simply, vithout bogging
them dovn vith non-essential teatures. It it vasn`t essential, ve
lett it out. And in just three months atter launch, over +oo,ooo
Writeboards have been created.
::
When ve started on Backpack our enemy vas structure and
rigid rules. People should be able to organize their intormation
their ovn vay not based on a series ot pretormatted screens or
a plethora ot required torm telds.
One bonus you get trom having an enemy is a very clear mar-
keting message. People are stoked by connict. And they also
understand a product by comparing it to others. With a chosen
enemy, you`re teeding people a story they vant to hear. Not
only vill they understand your product better and taster,
they`ll take sides. And that`s a sure-tre vay to get attention and
ignite passion.
Nov vith all that said, it`s also important to not get too ob-
sessed vith the competition. Overanalyze other products and
you`ll start to limit the vay you think. 1ake a look and then
move on to your ovn vision and your ovn ideas.
Dou`t foiiou the ieaoer
Marketers (and all human beings, are vell trained to tollov the leader. 1he
natural instinct is to tgure out vhat`s vorking tor the competition and then
try to outdo it to be cheaper than your competitor vho competes on
price, or taster than the competitor vho competes on speed. 1he problem
is that once a consumer has bought someone else`s story and believes that
lie, persuading the consumer to svitch is the same as persuading him to
admit he vas vrong. And people hate admitting that they`re vrong.
Instead, you must tell a dierent story and persuade listeners that
your story is more important than the story they currently believe.
It your competition is taster, you must be cheaper. It they sell the
story ot health, you must sell the story ot convenience. Not just the
positioning xy axis sort ot We are cheaper claim, but a real story
that is completely dierent trom the story that`s already being told.
8eih Coin, auihor/enirepreneur ( from Be a Beiier Liar)
:
1hat`s the ke pro|iem`
One ot the quickest vays to get yourselt into trouble is to look at vhat
your competitors are doing. 1his has been especially true tor us at BlinkIist.
Since ve launched there have been about +o other social bookmarking
services that have been launched. Some people have even started to generate
spreadsheets online vith a detailed teature by teature comparison.
Hovever, this can quickly lead one astray. Instead, ve stay tocused
on the big picture and keep asking ourselves, vhat is the key
problem ve are trying to solve and hov can ve solve it.
Michael Reining, co-founer, Min1alley L Blinklisi
:
Ii 8houln'i le a Chore
Your passion or lack of vill shine through
1he less your app is a chore to build, the better it vill be. Keep
it small and managable so you can actually enjoy the process.
It your app doesn`t excite you, something`s vrong. It you`re only
vorking on it in order to cash out, it vill shov. Iikevise, it you
teel passionately about your app, it vill come through in the
tnal product. People can read betveen the lines.
lhe preseuce of passiou
In design, vhere meaning is otten controversially subjective or
paintully inscrutable, tev things are more apparent and lucid than
the presence ot passion. 1his is true vhether the design ot a product
delights you or leaves you cold, in either case it`s dicult not to
detect the emotional investment ot the hands that built it.
Lnthusiasm manitests itselt readily ot course, but indierence is equally
indelible. It your commitment doesn`t encompass a genuine passion
tor the vork at hand, it becomes a void that is almost impossible to
conceal, no matter hov elaborately or attractively designed it is.
Khoi 1inh, 8uliraciion.com an co-founer of Beharior iic
lhe |aker
American business at this point is really about developing an idea,
making it prottable, selling it vhile it`s prottable and then getting
out or diversitying. It`s just about sucking everything up. My idea vas:
Lnjoy baking, sell your bread, people like it, sell more. Keep the bakery
going because you`re making good tood and people are happy.
Ian MacKaye, memler of Fugazi an co-ouner of Dischor Recors
( from 8alon.com People Ian MacKaye)
8iay Lean
Less Mass
Louer Your Cost of Chaue
lhe lhree Musketeers
Lm|race Coustraiuts
Pe Yourseif
:o
Less Mass
1he leaner you are, the easier it is to change
1he more massive an object, the more energy is required to
change its direction. It`s as true in the business vorld as it is in
the physical vorld.
When it comes to veb technology, change must be easy and
cheap. It you can`t change on the ny, you`ll lose ground to
someone vho can. 1hat`s vhy you need to shoot tor less mass.
Mass is increased by...
Iong term contracts
Lxcess sta
Permanent decisions
Meetings about other meetings
1hick process
Inventory (physical or mental,
Hardvare, sottvare, technology lock-ins
Proprietary data tormats
1he past ruling the tuture
Iong-term roadmaps
Oce politics
:;
Mass is reduced by...
ust-in-time thinking
Multi-tasking team members
Lmbracing constraints, not trying to litt them
Iess sottvare, less code
Iess teatures
Small team size
Simplicity
Pared-dovn intertaces
Open-source products
Open data tormats
An open culture that makes it easy to admit mistakes
Iess mass lets you change direction quickly. You can react and
evolve. You can tocus on the good ideas and drop the bad ones.
You can listen and respond to your customers. You can integrate
nev technologies nov instead ot later. Instead ot an aircratt
carrier, you steer a cigarette boat. Pevel in that tact.
::
lor example, let`s imagine a lean, less mass company that has
built a product vith less sottvare and less teatures. On the
other side is a more mass company that`s got a product vith
signitcantly more sottvare and more teatures. 1hen let`s say a
nev technology like Ajax or a nev concept like tagging comes
around. Who is going to be able to adapt their product quicker
1he team vith more sottvare and more teatures and a +:-month
roadmap or the team vith less sottvare and less teatures and
a more organic let`s tocus on vhat ve need to tocus on right
nov process
Obviously the less-mass company is in a better position to
adjust to the real demands ot the marketplace. 1he more-mass
company vill likely still be discussing changes or pushing
them through its bureaucratic process long atter the less-mass
company has made the svitch. 1he less mass company vill be
tvo steps ahead vhile the more mass company is still tguring
out hov to valk.
Nimble, agile, less-mass businesses can quickly change their
entire business model, product, teature set, and marketing
message. 1hey can make mistakes and tx them quickly. 1hey
can change their priorities, product mix, and tocus. And, most
importantly, they can change their ninds.
:,
Louer Your Cosi of Change
Stay eible by reducing obstacles to change
Change is your best triend. 1he more expensive it is to make a
change, the less likely you`ll make it. And it your competitors
can change taster than you, you`re at a huge disadvantage. It
change gets too expensive, you`re dead.
Here`s vhere staying lean really helps you out. 1he ability to
change on a dime is one thing small teams have by detault that
big teams can never have. 1his is vhere the big guys envy the
little guys. What might take a big team in a huge organization
veeks to change may only take a day in a small, lean organiza-
tion. 1hat advantage is priceless. Cheap and tast changes are
small`s secret veapon.
And remember: All the cash, all the marketing, all the people in
the vorld can`t buy the agility you get trom being small.
o
Lmereuce
Lmergence is one ot the tounding principles ot agility, and is the closest
one to pure magic. Lmergent properties aren`t designed or built in, they
simply happen as a dynamic result ot the rest ot the system. Lmergence
comes trom middle +;th century Iatin in the sense ot an untoreseen
occurrence. You can`t plan tor it or schedule it, but you can cultivate
an environment vhere you can let it happen and benett trom it.
A classic example ot emergence lies in the nocking behavior ot birds.
A computer simulation can use as tev as three simple rules (along the
lines ot don`t run into each other, and suddenly you get very complex
behavior as the nock vends and vatts its vay gracetully through the
sky, retorming around obstacles, and so on. None ot this advanced
behavior (such as retorming the same shape around an obstacle, is
specited by the rules, it emerges trom the dynamics ot the system.
Simple rules, as vith the birds simulation, lead to complex behavior. Complex
rules, as vith the tax lav in most countries, lead to stupid behavior.
Many common sottvare development practices have the untortunate side-
eect ot eliminating any chance tor emergent behavior. Most attempts at
optimization tying something dovn very explicitly reduces the breadth
and scope ot interactions and relationships, vhich is the very source ot
emergence. In the nocking birds example, as vith a vell-designed system,
it`s the interactions and relationships that create the interesting behavior.
1he harder ve tighten things dovn, the less room there is tor a creative,
emergent solution. Whether it`s locking dovn requirements betore
they are vell understood or prematurely optimizing code, or inventing
complex navigation and vorknov scenarios betore letting end users
play vith the system, the result is the same: an overly complicated, stupid
system instead ot a clean, elegant system that harnesses emergence.
Keep it small. Keep it simple. Iet it happen.
Anreu Huni, The Pragmaiic Programmers
+
The Three Muskeieers
Use a tean of three for version
lor the trst version ot your app, start vith only three people.
1hat`s the magic number that vill give you enough manpover
yet allov you to stay streamlined and agile. Start vith a develop-
er, a designer, and a sveeper (someone vho can roam betveen
both vorlds,.
Nov sure, it`s a challenge to build an app vith only a tev
people. But it you`ve got the right team, it`s vorth it. 1alented
people don`t need endless resources. 1hey thrive on the chal-
lenge ot vorking vithin restraints and using their creativity to
solve problems. Your lack ot manpover means you`ll be torced
to deal vith tradeos earlier in the process and that`s alright. It
vill make you tgure out your priorities earlier rather than later.
And you`ll be able to communicate vithout constantly having to
vorry about leaving people out ot the loop.
It you can`t build your version one vith three people, then you
either need dierent people or need to slim dovn your initial
version. Pemember, it`s ok to keep your trst version small and
tight. You`ll quickly get to see it your idea has vings and, it it
does, you`ll have a clean, simple base to build on.
:
Metcaife`s Lau auo project teams
Keep the team as small as possible. Metcalte`s Iav, that the value ot a
communication system grovs at approximately the square ot the number
ot users ot the system, has a corollary vhen it comes to project teams:
1he eciency ot the team is approximately the inverse ot the square ot
the number ot members in the team. I`m beginning to think three people
is optimal tor a +.o product release...Start out by reducing the number
ot people you plan to add to the team, and then reduce some more.
Marc Helun, enirepreneur-in-resience ai O'Reilly Meia
Commuuicatiou ou
Communication novs more easily on small teams than large teams. It
you`re the only person on a project, communication is simple. 1he only
communication path is betveen you and the customer. As the number ot
people on a project increases, hovever, so does the number ot communication
paths. It doesn`t increase additively, as the number ot people increases, it
increases multiplicatively, proportional to the square ot the number ot people.
8iere McConnell, Chief 8ofiuare Engineer ai Consirux 8ofiuare Builers
Inc. ( from Less is More jumpsiariing Prouciiriiy uiih 8mall Teams)

Emlrace Consirainis
Let linitations guide you to creative solutions
1here`s never enough to go around. Not enough time. Not
enough money. Not enough people.
lhat`s a ooo thiu.
Instead ot treaking out about these constraints, embrace
them. Iet them guide you. Constraints drive innovation and
torce tocus. Instead ot trying to remove them, use them to
your advantage.
When 37signals vas building Basecamp, ve had plenty ot limi-
tations. We had:
A design trm to run
Lxisting client vork
A ;-hour time dierence (David vas doing the programming
in Denmark, the rest ot us vere in the States,
A small team
No outside tunding
We telt the not enough blues. So ve kept our plate small.
1hat vay ve could only put so much on it. We took big tasks
and broke them up into small bits that ve tackled one at a time.
We moved step by step and prioritized as ve vent along.

1hat torced us to come up vith creative solutions. We lovered

our cost ot change by alvays building less sottvare. We gave
people just enough teatures to solve their ovn problems their
ovn vay and then ve got out ot the vay. 1he time dierence
and distance betveen us made us more ecient in our com-
munication. Instead ot meeting in person, ve communicated
almost exclusively via ix and email vhich torced us to get to the
point quickly.
Constraints are otten advantages in disguise. lorget about
venture capital, long release cycles, and quick hires. Instead,
vork vith vhat you have.
Iiht |iiht
What has been described as creeping elegance is probably better described
as teature blight, tor like a tungus on a plant it gradually elaborates and blurs
the true outline ot the product vhile it drains its sap. 1he antidote to teature
blight is, ot course, the constricting deadline. 1his results in teatures being
discarded in proportion to the time it vould take to implement them. It is
otten the case that the most usetul teatures take the longest to implement.
1hus the combination ot the blight and the deadline yields sottvare as ve
knov and love it, comprised ot bountitul quantities ot useless teatures.
jef Raskin, auihor ( from hy 8ofiuare Is ihe ay Ii Is)

Be Yourself
Dierentiate yourself fron bigger conpanies by being
personal and friendly
A lot ot small companies make the mistake ot trying to act big.
It`s as it they perceive their size as a veakness that needs to be
covered up. 1oo bad. Being small can actually be a huge advan-
tage, especially vhen it comes to communication.
Small companies enjoy tever tormalities, less bureaucracy, and
more treedom. Snaller conpanies are closer to the cus-
toner by default. 1hat means they can communicate in a
more direct and personal vay vith customers. It you`re small,
you can use tamiliar language instead ot jargon. Your site and
your product can have a human voice instead ot sounding like
a corporate drone. Being small means you can talk uith your
customers, not dovn to them.
1here are also advantages to internal communications at small
companies too. You can ditch tormalities. 1here`s no need tor
arduous processes and multiple sign-os on everything. Lvery-
one in the process can speak openly and honestly. 1his untet-
tered nov ot ideas is one ot the big advantages ot staying small.
o
Pe prouoi, oefauti truthfui
1hough you may think that a customer can be tooled by exaggerations on the
number ot staers in your company or the breadth ot your oerings, the smart
ones, the ones you really vant, vill alvays learn the truth vhether through
intuition or deduction. Lmbarrassingly, I`ve been a part ot vhite lies like this in
the past, and none ot those situations ever resulted in vhat matters most to a
business: meaningtul, lasting and mutually benetcial relationships vith people
vho had a real need tor the services oered. 1he better course vould have been
to be proudly, detantly truthtul about the exact size and breadth ot the company.
Khoi 1inh, 8uliraciion.com an co-founer of Beharior LLC
u time at aii
No matter vhat business you are in, good customer service has got to be the
biggest request that any client vill ever make. We demand it tor the services
ve use so vhy vould ve think our customers vould be any dierent
lrom the very beginning ve made it easy and transparent tor our
customers to get in touch vith us tor any number or questions they
might have. On our vebsite ve list a toll-tree number that torvards to
our mobile phones and on our business cards each ot us list our mobile
numbers. We emphasize to our customers that they can get in touch
vith us any time no matter vhat the problem might be. Our customers
appreciate this level ot trust and no one has ever abused this service.
Euar Kniiiel, Direcior of 8ales an Markeiing, Kennel8ource
Prioriiies
1hat`s the Pi Ioea`
Iuore Detaiis Lari Cu
It`s a Iro|iem 1heu It`s a Iro|iem
Hire the Piht Customers
:caie Later
Make Cpiuiouateo :oftuare
:
hai's ihe Big Iea
Lplicitly dehne the one-point vision for your app
What does your app stand tor What`s it really all about
Betore you start designing or coding anything you need
to knov the purpose ot your product the vision. 1hink
big. Why does it exist What makes it ditterent than other
similar products
1his vision vill guide your decisions and keep you on a con-
sistent path. Whenever there`s a sticking point, ask, Are ve
staying true to the vision
Your vision should be briet too. A sentence should be enough to
get the idea across. Here`s the vision tor each ot our products:
Basecanp: Project management is communication
Backpack: Bring lite`s loose ends together
Canphre: Group chat over IM sucks
1a-da List: Competing vith a post-it note
Writeboard: Word is overkill
With Basecamp, tor example, the vision vas Project manage-
ment is communication. We telt strongly that eective commu-
nication on a project leads to collective ovnership, involvement,
investment, and momentum. It gets everyone on the same page
vorking tovard a common goal. We knev it Basecamp could
accomplish this, everything else vould tall in line.
,
1his vision led us to keep Basecamp as open and transparent as
possible. Instead ot limiting communication to vithin a trm,
ve gave clients access too. We thought less about permissions
and more about encouraging all participants to take part. 1he
vision is vhy ve skipped charts, graphs, tables, reports, stats, and
spreadsheets and instead tocused on communication priorities
like messages, comments, to-do lists, and sharing tles.
Make the big decision about your vision uptront and all your
tuture little decisions become much easier.
1hite|oaro phiiosoph
Andy Hunt and I once vrote a debit card transaction svitch. A major
requirement vas that the user ot a debit card shouldn`t have the same
transaction applied to their account tvice. In other vords, no matter vhat
sort ot tailure mode might happen, the error should be on the side ot not
processing a transaction rather than processing a duplicate transaction.
So, ve vrote it on our shared vhiteboard in big letters: Lrr in tavor ot users.
It joined about halt-a-dozen other maxims. ointly, these guided all those tricky
decisions you make vhile building something complex. 1ogether, these lavs
gave our application strong internal coherence and great external consistency.
-Dare Thomas, The Pragmaiic Programmers
Make Mautra
Organizations need guideposts. 1hey need an outline, employees need to knov
each day vhen they vake up vhy they`re going to vork. 1his outline should
be short and sveet, and all encompassing: Why do you exist What motivates
you I call this a mantra a three- or tour-vord description ot vhy you exist.
-Cuy Kauasaki, auihor ( from Make Manira)
o
Ignore Deiails Early On
Work fron large to snall
We`re crazy about details.
1he space betveen objects
1he pertect type leading
1he pertect color
1he pertect vords
lour lines ot code instead ot seven
,o vs :,
;oopx vs ;opx
x,month vs. x,month
:uccess auo satisfactiou is iu the oetaiis.
Hovever, success isn`t the only thing you`ll tnd in the details.
You`ll also tnd stagnation, disagreement, meetings, and delays.
1hese things can kill morale and lover your chances ot success.
Hov otten have you tound yourselt stuck on a single design or
code element tor a vhole day Hov otten have you realized that
the progress you made today vasn`t real progress 1his happens
vhen you tocus on details too early in the process. 1here`s
plenty ot time to be a pertectionist. ust do it later.
Don`t vorry about the size ot your headline tont in veek one.
You don`t need to nail that pertect shade ot green in veek tvo.
You don`t need to move that submit button three pixels to the
right in veek three. ust get the stu on the page tor nov. 1hen
use it. Make sure it vorks. Iater on you can adjust and pertect it.
+
Details reveal themselves as you use vhat you`re building. You`ll
see vhat needs more attention. You`ll teel vhat`s missing. You`ll
knov vhich potholes to pave over because you`ll keep hitting
them. 1hat`s vhen you need to pay attention, not sooner.
lhe De:ii`s iu the Detaiis
I really got over the get into details right avay attitude atter I took some
draving classes...It you begin to drav the details right avay you can be sure
that the draving is going to suck. In tact, you are completely missing the point.
You should begin by getting your proportions right tor the vhole
scene. 1hen you sketch the largest objects in your scene, up to the
smallest one. 1he sketch must be very loose up to this point.
1hen you can proceed vith shading vhich consists ot bringing volume to lite.
You begin vith only three tones (light, medium, dark,. 1his gives you a tonal
sketch. 1hen tor each portion ot your draving you reevaluate three tonal shades
and apply them. Do it until the volumes are there (requires multiple iteration,...
Work trom large to small. Alvays.
-Pairick Laeur, Creaiion Oljei Inc. ( from 8ignal rs. Noise)
:
Ii's a Prollem hen Ii's a Prollem
Dont vaste tine on problens you dont have yet
Do you really need to vorry about scaling to +oo,ooo users
today it it vill take you tvo years to get there
Do you really have to hire eight programmers it you only need
three today
Do you really need +: top-ot-the-line servers nov it you can
run on tvo tor a year
)ust Wing It
People otten spend too much time up tront trying to solve
problems they don`t even have yet. Don`t. Heck, ve launched
Basecamp vithout the ability to bill customers' Since the
product billed in monthly cycles, ve knev ve had a o-day gap
to tgure it out. We used that time to solve more urgent prob-
lems and then, atter launch, ve tackled billing. It vorked out
tne (and it torced us into a simple solution vithout unnecessary
bells and vhistles,.
Don`t sveat stu until you actually must. Don`t overbuild. In-
crease hardvare and system sottvare as necessary. It you`re slov
tor a veek or tvo it`s not the end ot the vorld. ust be honest:
explain to your customers you`re experiencing some groving
pains. 1hey may not be thrilled but they`ll appreciate the candor.
Bottom Iine: Make decisions just in time, vhen you have
access to the real intormation you need. In the meanvhile,
you`ll be able to lavish attention on the things that require im-
mediate care.

Hire ihe Righi Cusiomers

Find the core narket for your application and focus
solely on then
1he customer is not alvays right. 1he truth is you have to sort
out vho`s right and vho`s vrong tor your app. 1he good nevs is
that the internet makes tnding the right people easier than ever.
If you try to please everyone, you vont please anyone
When ve built Basecamp ve tocused our marketing on design
trms. By narroving our market this vay, ve made it more
likely to attract passionate customers vho, in turn, vould evan-
gelize the product. Knov vho your app is really intended tor
and tocus on pleasing them.
lhe Pest Caii 1e L:er Maoe
1he decision to aim Campaign Monitor strictly at the veb design market
vas the best call ve ever made. It alloved us to easily identity vhich
teatures vould be genuinely usetul and, more importantly, vhich teatures
to leave out. Not only have ve attracted more customers by targeting a
smaller group ot people, these customers all have similar needs vhich
makes our job much easier. 1here are loads ot teatures in Campaign
Monitor that vould be useless to anyone but a veb designer.
locusing on a core market also makes it much easier to spread the vord
about your sottvare. Nov that ve have a tightly detned audience, ve
can advertise vhere they trequent online, publish articles they might tnd
interesting, and generally build a community around our product.
-Dari Creiner, founer, Campaign Moniior

8cale Laier
You dont have a scaling problen yet
1iii m app scaie uheu miiiious of peopie start usiu it`
Ya knov vhat Wait until that actually happens. It you`ve got a
huge number ot people overloading your system then huzzah'
1hat`s one svell problem to have. 1he truth is the overvhelm-
ing majority ot veb apps are never going to reach that stage.
And even it you do start to get overloaded it`s usually not an all-
or-nothing issue. You`ll have time to adjust and respond to the
problem. Plus, you`ll have more real-vorld data and benchmarks
atter you launch vhich you can use to tgure out the areas that
need to be addressed.
lor example, ve ran Basecamp on a single server tor the trst
year. Because ve vent vith such a simple setup, it only took a
veek to implement. We didn`t start vith a cluster ot + boxes or
spend months vorrying about scaling.
Did ve experience any problems A tev. But ve also realized
that most ot the problems ve teared, like a briet slovdovn,
really veren`t that big ot a deal to customers. As long as you
keep people in the loop, and are honest about the situation,
they`ll understand. In retrospect, ve`re quite glad ve didn`t
delay launch tor months in order to create the pertect setup.

In the beginning, make building a solid core product your

priority instead ot obsessing over scalability and server tarms.
Create a great app and then vorry about vhat to do
once its vildly successful. Othervise you may vaste energy,
time, and money txating on something that never even happens.
Believe it or not, the bigger problem isn`t scaling, it`s getting to
the point vhere you have to scale. Without the trst problem
you von`t have the second.
You ha:e to re:isit auua
1he tact is that everyone has scalability issues, no one can deal
vith their service going trom zero to a tev million users vithout
revisiting almost every aspect ot their design and architecture.
-Dare Olasanjo, Microsofi
o
Make Opinionaie 8ofiuare
Your app should take sides
Some people argue sottvare should be agnostic. 1hey say it`s ar-
rogant tor developers to limit teatures or ignore teature requests.
1hey say sottvare should alvays be as nexible as possible.
We think that`s bullshit. 1he best sottvare has a vision. 1he
best sottvare takes sides. When someone uses sottvare, they`re
not just looking tor teatures, they`re looking tor an approach.
1hey`re looking tor a vision. Decide vhat your vision is and run
vith it.
And remember, it they don`t like your vision there are plenty
ot other visions out there tor people. Don`t go chasing people
you`ll never make happy.
A great example is the original viki design. Ward Cunningham
and triends deliberately stripped the viki ot many teatures that
vere considered integral to document collaboration in the past.
Instead ot attributing each change ot the document to a certain
person, they removed much ot the visual representation ot
ovnership. 1hey made the content ego-less and time-less. 1hey
decided it vasn`t important vho vrote the content or vhen it
vas vritten. And that has made all the dierence. 1his decision
tostered a shared sense ot community and vas a key ingredient
in the success ot Wikipedia.
Our apps have tolloved a similar path. 1hey don`t try to be
all things to all people. 1hey have an attitude. 1hey seek out
customers vho are actually partners. 1hey speak to people vho
share our vision. You`re either on the bus or o the bus.
Feaiure 8eleciion
Haif, ^ot Haifsseo
It ]ust Doesu`t Matter
:tart 1ith ^o
Hiooeu Costs
Cau You Hauoie It`
Humau :oiutious
Ioret Ieature Peuests
Hoio the Mao
:
Half, Noi Half-Asse
Build half a product, not a half-ass product
Bevare ot the everything but the kitchen sink approach to
veb app development. 1hrov in every decent idea that comes
along and you`ll just vind up vith a halt-assed version ot your
product. What you really vant to do is build halt a product that
kicks ass.
Stick to vhat`s truly essential. Good ideas can be tabled. 1ake
vhatever you think your product should be and cut it in
half. Pare teatures dovn until you`re lett vith only the most es-
sential ones. 1hen do it again.
With Basecamp, ve started vith just the messages section. We
knev that vas the heart ot the app so ve ignored milestones,
to-do lists, and other items tor the time being. 1hat let us base
tuture decisions on real vorld usage instead ot hunches.
Start o vith a lean, smart app and let it gain traction. 1hen you
can start to add to the solid toundation you`ve built.
,
Ii jusi Doesn'i Maiier
Lssentials only
Our tavorite ansver to the vhy didn`t you do this or vhy
didn`t you do that question is alvays: Because it just doesn`t
matter. 1hat statement embodies vhat makes a product great.
liguring out vhat matters and leaving out the rest.
When ve launched Camptre ve heard some ot these questions
trom people checking out the product tor the trst time:
1h time stamps oui e:er miuutes` 1h uot time stamp e:er
chat iiue` Ansver: It just doesn`t matter. Hov otten do you
need to track a conversation by the second or even the minute
Certainly not , ot the time. minute stamps are sucient
because anything more specitc just doesn`t matter.
1h oou`t ou aiiou |oio or itaiic or coioreo formattiu iu the chats`
Ansver: It just doesn`t matter. It you need to emphasize some-
thing use the trusty c:rs iock key or toss a tev *`s around the
vord or phrase. 1hose solutions don`t require additional sott-
vare, tech support, processing pover, or have a learning curve.
Besides, heavy tormatting in a simple text-based chat just doesn`t
matter.
1h oou`t ou shou the totai uum|er of peopie iu the room at a i:eu
time` Ansver: It just doesn`t matter. Lveryone`s name is listed
so you knov vho`s there, but vhat dierence does it make it
there`s +: or +o people It it doesn`t change your behavior, then
it just doesn`t matter.
o
Would these things be nice to have Sure. But are they essential
Do they really matter Nope. And that`s vhy ve lett them out.
1he best designers and the best programmers aren`t the ones
vith the best skills, or the nimblest tngers, or the ones vho can
rock and roll vith Photoshop or their environment ot choice,
they are the ones that can determine vhat just doesn`t matter.
1hat`s vhere the real gains are made.
Most ot the time you spend is vasted on things that just don`t
matter. It you can cut out the vork and thinking that just don`t
matter, you`ll achieve productivity you`ve never imagined.
+
8iari iih No
Make features vork hard to be inplenented
1he secret to building halt a product instead ot a halt-ass
product is saying no.
Lach time you say yes to a teature, you`re adopting a child. You
have to take your baby through a vhole chain ot events (e.g.
design, implementation, testing, etc.,. And once that teature`s
out there, you`re stuck vith it. ust try to take a released teature
avay trom customers and see hov pissed o they get.
Dont be a yes-nan
Make each teature vork hard to be implemented. Make each
teature prove itselt and shov that it`s a survivor. It`s like light
Club. You should only consider teatures it they`re villing to
stand on the porch tor three days vaiting to be let in.
1hat`s vhy you start vith no. Lvery nev teature request that
comes to us or trom us meets a no. We listen but don`t act.
1he initial response is not nov. It a request tor a teature keeps
coming back, that`s vhen ve knov it`s time to take a deeper
look. 1hen, and only then, do ve start considering the teature
tor real.
And vhat do you say to people vho complain vhen you
von`t adopt their teature idea Pemind them vhy they like
the app in the trst place. You like it because ve say no.
You like it because it doesn`t do +oo other things. You like
it because it doesn`t try to please everyone all the time.
:
1e Dou`t 1aut a lhousauo Ieatures
Steve obs gave a small private presentation about the i1unes Music Store to
some independent record label people. My tavorite line ot the day vas vhen
people kept raising their hand saying, Does it do [x|, Do you plan to add
[y|. linally obs said, Wait vait put your hands dovn. Iisten: I knov you
have a thousand ideas tor all the cool teatures i1unes could have. So do ve. But
ve don`t vant a thousand teatures. 1hat vould be ugly. Innovation is not about
saying yes to everything. It`s about saying NO to all but the most crucial teatures.
-Derek 8irers, presieni an programmer, CD Baly
an HosiBaly ( from 8ay NO ly efauli)

Hien Cosis
Lpose the price of nev features
Lven it a teature makes it past the no stage, you still need to
expose its hidden costs.
lor example, be on the lookout tor teature loops (i.e. teatures
that lead to more teatures,. We`ve had requests to add a meet-
ings tab to Basecamp. Seems simple enough until you examine
it closely. 1hink ot all the dierent items a meetings tab might
require: location, time, room, people, email invites, calendar
integration, support documentation, etc. 1hat`s not to mention
that ve`d have to change promotional screenshots, tour pages,
r:qhelp pages, the terms ot service, and more. Betore you
knov it, a simple idea can snovball into a major headache.
For every nev feature you need to...
1. Say no.
2. lorce the teature to prove its value.
3. It no again, end here. It yes, continue...
4. Sketch the screen(s,ui.
3. Design the screen(s,ui.
6. Code it.
7-13. 1est, tveak, test, tveak, test, tveak, test, tveak...
16. Check to see it help text needs to be modited.
17. Lpdate the product tour (it necessary,.
18. Lpdate the marketing copy (it necessary,.
19. Lpdate the terms ot service (it necessary,.
20. Check to see it any promises vere broken.
21. Check to see it pricing structure is aected.
22. Iaunch.
23. Hold breath.

Can You Hanle Ii?

Build sonething you can nanage
It you launch an aliate 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 tees instead
ot vriting, signing, and mailing a check each month.
Can you aord to give avay + i ot space tor tree just because
Google does Maybe you should start small at +oo xi, or only
provide space on paying accounts.
Bottom line: Build products and oer services you can manage.
It`s easy to make promises. It`s much harder to keep them. Make
sure vhatever it is that you`re doing is something you can actu-
ally sustain organizationally, strategically, and tnancially.

Human 8oluiions
Build softvare for general concepts and encourage
people to create their ovn solutions
Don`t torce conventions on people. Instead make your sottvare
general so everyone can tnd their ovn solution. Give people
just enough to solve their ovn problems their ovn vay. And
then get out ot the vay.
When ve built 1a-da Iist ve intentionally omitted a lot ot stu.
1here`s no vay to assign a to-do to someone, there`s no vay to
mark a date due, there`s no vay to categorize items, etc.
We kept the tool clean and uncluttered by letting people get
creative. People tgured out hov to solve issues on their ovn. It
they vanted to add a date to a to-do item they could just add
(due: April ;, :ooo, to the tront ot the item. It they vanted to
add a category, they could just add [Books| to the tront ot the
item. Ideal No. Intnitely nexible Yes.
It ve tried to build sottvare to specitcally handle these sce-
narios, ve`d be making it less usetul tor all the cases vhen those
concerns don`t apply.
Do the best job you can vith the root ot the problem then step
aside. People vill tnd their ovn solutions and conventions
vithin your general tramevork.
o
Forgei Feaiure Requesis
Let your custoners renind you vhats inportant
Customers vant everything under the sun. 1hey`ll avalanche
you vith teature requests. ust check out our product torums,
1he teature request category alvays trumps the others by a
vide margin.
We`ll hear about this little extra teature or this can`t be hard
or vouldn`t it be easy to add this or it should take just a tev
seconds to put it in or it you added this I`d pay tvice as much
and so on.
Ot course ve don`t tault people tor making requests. We en-
courage it and ve vant to hear vhat they have to say. Most ev-
erything ve add to our products starts out as a customer request.
But, as ve mentioned betore, your trst response should be a no.
So vhat do you do vith all these requests that pour in Where
do you store them Hov do you nanage then? You dont.
)ust read then and then throv then avay.
Yup, read them, throv them avay, and torget them. It sounds
blasphemous but the ones that are important vill keep bubbling
up anyvay. 1hose are the only ones you need to remember.
1hose are the truly essential ones. Don`t vorry about tracking
and saving each request that comes in. Iet your customers be
your memory. It it`s really vorth remembering, they`ll remind
you until you can`t torget.
;
Hov did ve come to this conclusion When ve trst launched
Basecamp ve tracked every major teature request on a Basecamp
to-do list. When a request vas repeated by someone else ve`d
update the list vith an extra hash mark (II or III or IIII, etc,.
We tgured that one day ve`d reviev this list and start vorking
trom the most requested teatures on dovn.
But the truth is ve never looked at it again. We already knev
vhat needed to be done next because our customers constantly
reminded us by making the same requests over and over again.
1here vas no need tor a list or lots ot analysis because it vas all
happening in real time. You can`t torget vhat`s important vhen
you are reminded ot it every day.
And one more thing: ust because x number ot people request
something, doesn`t mean you ha:e to include it. Sometimes it`s
better to just say no and maintain your vision tor the product.
:
Hol ihe Mayo
Ask people vhat they on'i vant
Most sottvare surveys and research questions are centered
around vhat people vant in a product. What teature do you
think is missing It you could add just one thing, vhat vould
it be What vould make this product more usetul tor you
What about the other side ot the coin Why not ask people
vhat they don`t vant It you could remove one teature, vhat
vould it be What don`t you use What gets in your vay
the most
More isn`t the ansver. Sometimes the biggest tavor you can do
tor customers is to leave something out.
Iuuo:atiou Comes Irom :aiu ^o
[Innovation| comes trom saying no to +,ooo things to make sure ve
don`t get on the vrong track or try to do too much. We`re alvays
thinking about nev markets ve could enter, but it`s only by saying no
that you can concentrate on the things that are really important.
-8iere jols, CEO, Apple ( from The 8ee of Apple's Innoraiion)
Process
Pace to Puuuiu :oftuare
Piuse auo Pepeat
Irom Ioea to Impiemeutatiou
:oio Irefereuces
Doue:
lest iu the 1iio
:hriuk Your lime
oo
Race io Running 8ofiuare
Get sonething real up and running quickly
Punning sottvare is the best vay to build momentum, rally
your team, and nush out ideas that don`t vork. It should be your
number one priority trom day one.
It`s ok to do less, skip details, and take shortcuts in your process
it it`ll lead to running sottvare taster. Once you`re there, you`ll
be revarded vith a signitcantly more accurate perspective on
hov to proceed. Stories, viretrames, even n+xi mockups, are
just approximations. Punning sottvare is real.
With real, running sottvare everyone gets closer to true un-
derstanding and agreement. You avoid heated arguments over
sketches and paragraphs that vind up turning out not to matter
anyvay. You realize that parts you thought vere trivial are actu-
ally quite crucial.
Peal things lead to real reactions. And that`s hov you get to
the truth.
lhe Peai lhiu Leaos to reemeut
When a group ot dierent people set out to try and tnd out vhat
is harmonious...their opinions about it vill tend to converge
it they are mocking up tull-scale, real stu. Ot course, it they`re
making sketches or throving out ideas, they von`t agree. But, it
you start making the real thing, one tends to reach agreement.
-Chrisiopher Alexaner, Emeriius Professor of Archiieciure ai ihe Cnirersiiy of
California, Berkeley ( from Conirasiing Concepis of Harmony in Archiieciure)
o+
et It 1orkiu :s:r
I do not think I`ve ever been involved vith a sottvare project large or
small that vas successtul in terms ot schedule, cost, or tunctionality that
started vith a long period ot planning and discussion and no concurrent
development. It is simply too easy, and sometimes tun, to vaste valuable time
inventing teatures that turn out to be unnecessary or unimplementable.
1his applies at all levels ot development and get something real
up and running is a tractal mantra. It doesn`t just apply to the
project as a vhole, it is at least equally applicable to the smaller-scale
development ot components trom vhich the application is built.
When there is a vorking implementation ot a key component available,
developers vant to understand hov it vill or von`t vork vith their piece ot
the application and vill generally try to use it as soon as they can. Lven it the
implementation isn`t pertect or complete at trst, this early collaboration usually
leads to vell-detned intertaces and teatures that do exactly vhat they need to.
-Maii Hamer, ereloper an prouci manager, Kinja
o:
Rinse an Repeai
Work in iterations
Don`t expect to get it right the trst time. Iet the app grov and
speak to you. Iet it morph and evolve. With veb-based sott-
vare there`s no need to ship pertection. Design screens, use
them, analyze them, and then start over again.
Instead ot banking on getting everything right uptront, the
iterative process lets you continue to make intormed decisions
as you go along. Plus, you`ll get an active app up and running
quicker since you`re not striving tor pertection right out the gate.
1he result is real teedback and real guidance on vhat requires
your attention.
Iterations lead to liberation
You don`t need to aim tor pertection on the trst try it you knov
it`s just going to be done again later anyvay. Knoving that
you`re going to revisit issues is a great motivator to just get ideas
out there to see it they`ll ny.
o
Ma|e ou`re smarter thau me
Maybe you`re a IO1 smarter than me.
It`s entirely possible. In tact, it`s likely. Hovever, it you`re like most people, then
like me, you have trouble imagining vhat you can`t see and teel and touch.
Human beings are extremely good at responding to things in the environment.
We knov hov to panic vhen a tiger enters the room, and hov to clean up
atter a devastating nood. Lntortunately, ve`re terrible at planning ahead, at
understanding the ramitcations ot our actions and in prioritizing the stu that
really matters.
Perhaps you are one ot the tev individuals vho can keep it all in your head. It
doesn`t really matter.
Web :.o, the vorld vhere ve start by assuming that everyone already uses the
veb, allovs smart developers to put this human trailty to vork tor them. Hov
By alloving your users to tell you vhat they think vhile there`s still time to do
something about it.
And that last sentence explains vhy you should develop this vay and hov you
might vant to promotelaunch.
Get your story straight. Make sure the pieces vork. 1hen launch and revise.
No one is as smart as all ot us.
-8eih Coin, auihor/enirepreneur
o
From Iea io Implemeniaiion
Go fron brainstorn to sketches to (4-, to coding
Here`s the process ve use to Get Peal:
Brainstorn
Come up vith ideas. What is this product going to do lor
Basecamp, ve looked at our ovn needs. We vanted to post
project updates. We vanted clients to participate. We knev
that projects had milestones. We vanted to centralize archives
so people could easily reviev old stu. We vanted to have a
big-picture, bird`s-eye viev ot vhat`s going on vith all our
projects. 1ogether, those assumptions, and a tev others, served
as our toundation.
1his stage is not about nitty gritty details. 1his is about big
questions. What does the app need to do Hov vill ve knov
vhen it`s usetul What exactly are ve going to make 1his is
about high level ideas, not pixel-level discussions. At this stage,
those kinds ot details just aren`t meaningtul.
Paper sketches
Sketches are quick, dirty, and cheap and that`s exactly hov you
vant to start out. Drav stu. Scravl stu. Boxes, circles, lines.
Get your ideas out ot your head and onto paper. 1he goal at
this point should be to convert concepts into rough intertace
designs. 1his step is all about experimentation. 1here are no
vrong ansvers.
o
Create H1ML screens
Make an n+xi version ot that teature (or section or nov, it it`s
more appropriate,. Get something real posted so everyone can
see vhat it looks like on screen.
lor Basecamp, ve trst did the post a message screen, then the
edit a message screen, and it vent on trom there.
Don`t vrite any programming code yet. ust build a mock-up in
n+xi and css. Implementation comes later.
Code it
When the mock-up looks good and demonstrates enough ot
the necessary tunctionality, go ahead and plug in the program-
ming code.
During this vhole process remember to stay nexible and expect
multiple iterations. You should teel tree to throv avay the deliv-
erable ot any particular step and start again it it turns out crappy.
It`s natural to go through this cycle multiple times.
oo
Aroi Preferences
Decide the little details so your custoners dont have to
You`re taced vith a tough decision: hov many messages do ve
include on each page Your trst inclination may be to say, Iet`s
just make it a preterence vhere people can choose :, o, or
+oo. 1hat`s the easy vay out though. ust make a decision.
Preferences are a vay to avoid naking tough decisions
Instead ot using your expertise to choose the best path, you`re
leaving it in the hands ot customers. It may seem like you`re
doing them a tavor but you`re just making busy vork tor them
(and it`s likely they`re busy enough,. lor customers, preterence
screens vith an endless amount ot 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 vhen it should be
your responsibility.
Preterences are also evil because they create more sottvare.
More options require more code. And there`s all the extra
testing and designing you need to do too. You`ll also vind up
vith preterence permutations and intertace screens that you
never even see. 1hat means bugs that you don`t knov about:
broken layouts, busted tables, strange pagination issues, etc.
Make the call
Make simple decisions on behalt ot your customers. 1hat`s vhat
ve did in Basecamp. 1he number ot messages per page is :.
On the overviev page, the last : items are shovn. Messages
are sorted in reverse chronological order. 1he tve most recent
projects are shovn in the dashboard. 1here aren`t any options.
1hat`s just the vay it is.
o;
Yes, you might make a bad call. But so vhat. It you do, people
vill complain and tell you about it. As alvays, you can adjust.
Getting Peal is all about being able to change on the ny.
Irefereuces Ha:e a Cost
It turns out that preterences have a cost. Ot course, some preterences also
have important benetts and can be crucial intertace teatures. But each
one has a price, and you have to caretully consider its value. Many users
and developers don`t understand this, and end up vith a lot ot cost and
little value tor their preterences dollar...I tnd that it you`re hard-core
disciplined about having good detaults that ust Work instead ot lazily adding
preterences, that naturally leads the overall ui in the right direction.
-Haroc Penningion, iech lea, Re Hai ( from Free sofiuare an goo user inierfaces)
o:
"Done!'
Decisions are tenporary so nake the call and nove on
Done. Start to think ot it as a magical vord. 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 build-
ing momentum.
But vait, vhat it you screv up and make the vrong call It`s
ok. 1his isnt brain surgery, its a veb app. As ve keep
saying, you`ll likely have to revisit teatures and ideas multiple
times during the process anyvay. No matter hov much you
plan you`re likely to get halt vrong anyvay. So don`t do the
paralyis through analysis thing. 1hat only slovs progress and
saps morale.
Instead, value the importance ot moving on and moving
torvard. Get in the rhythm ot making decisions. Make a quick,
simple call and then go back and change that decision it it
doesn`t vork out.
Accept that decisions are temporary. Accept that mistakes vill
happen and realize it`s no big deal as long as you can correct
them quickly. Lxecute, build momentum, and move on.
o,
Pe u Lxecutiouer
It`s so tunny vhen I hear people being so protective ot ideas. (People vho vant
me to sign an xi: to tell me the simplest idea.,
1o me, ideas are vorth nothing unless executed. 1hey are just a multiplier.
Lxecution is vorth millions.
Lxplanation:
Avtul idea = -1
Weak idea = 1
So-so idea = 3
Good idea = 10
Great idea = 13
Brilliant idea = 20
No execution = s1
Weak execution = s1000
So-so execution = s10,000
Good execution = s100,000
Great execution = s1,000,000
Brilliant execution = s10,000,000
1o make a business, you need to multiply the tvo.
1he most brilliant idea, vith no execution, is vorth x:o. 1he most brilliant idea
takes great execution to be vorth x:o,ooo,ooo.
1hat`s vhy I don`t vant to hear people`s ideas. I`m not interested until I see
their execution.
-Derek 8irers, presieni an programmer, CD Baly an HosiBaly
;o
Tesi in ihe il
1est your app via real vorld usage
1here`s no substitute tor real people using your app in real
vays. Get real data. Get real teedback. 1hen improve based on
that into.
lormal usability testing is too sti. Iab settings don`t renect
reality. It you stand over someone`s shoulder, you`ll get some
idea ot vhat`s vorking or not but people generally don`t
pertorm vell in tront ot a camera. When someone else is vatch-
ing, people are especially caretul not to make mistakes yet
mistakes are exactly vhat you`re looking tor.
Instead, release beta teatures to a select tev inside the real ap-
plication itselt. Have them use the beta teatures alongside the
released teatures. 1his vill expose these teatures to people`s real
data and real vorknov. And that`s vhere you`ll get real results.
lurther, don`t have a release version and a beta version. 1hey
should alvays be the same thing. A separate beta version vill
only get a supertcial valk through. 1he real version, vith some
beta teatures sprinkled in, vill get the tull vorkout.
;+
lhe Peta Pook
It developers are nervous releasing code, then publishers and authors are territed
ot releasing books. Once a book gets committed to paper, it`s seen as a big hairy
deal to change it. (It really isn`t, but perception and memories ot problems
vith old technologies still linger in the industry., So, publishers go to a lot ot
trouble (and expense, to try to make books right betore they`re released.
When I vrote the book Agile Web Development With Pails, there vas
a lot ot pent up demand among developers: give us the book nov ve
vant to learn about Pails. But I`d tallen into the mindset ot a publisher. It
isn`t ready yet, I`d say. But pressure trom the community and some egging
on trom David Heinemeier Hansson changed my mind. We released the
book in rir torm about : months betore it vas complete. 1he results vere
spectacular. Not only did ve sell a lot ot books, but ve got teedback a
lot ot teedback. I set up an automated system to capture readers` comments,
and in the end got almost :o reports or typos, technical errors, and
suggestions tor nev content. Almost all made their vay into the tnal book.
It vas a vin-vin: I got to deliver a much improved paper book, and the
community got early access to something they vanted. And it you`re in a
competitive race, getting something out earlier helps tolks commit to you and
not your competition.
-Dare Thomas, The Pragmaiic Programmers
Do it uick
1. Decide it it`s vorth doing, and it so:
2. Do it quick not pertect. just do it.
3. Save it. upload it. publish it
4. See vhat people think
1hough I`m alvays reluctant to add nev teatures to things, once
I have that yeah' moment ot deciding something is vorth
doing, it`s usually up on the vebsite a tev hours later, naved but
launched, letting teedback guide tuture retnement ot it.
-Derek 8irers, presieni an programmer, CD Baly an HosiBaly
;:
8hrink Your Time
Break it dovn
Lstimates that stretch into veeks or months are tantasies. 1he
truth is you just don`t knov vhat`s going to happen that tar
in advance.
So shrink your time. Keep breaking dovn timetrames into
smaller chunks. Instead ot a +: veek project, think ot it as +:
veeklong projects. Instead ot guesstimating at tasks that take
o hours, break them dovn into more realistic o-+o hour
chunks. 1hen proceed one step at a time.
1he same theory applies to other problems too. Are you tacing
an issue that`s too big to vrap your mind around Break it dovn.
Keep dividing problems into smaller and smaller pieces until
you`re able to digest them.
;
:maiier lasks auo :maiier limeiiues
Sottvare developers are a special breed ot optimist: vhen presented vith a
programming task, they think, 1hat`ll be easy' Won`t take much time at all.
So, give a programmer three veeks to complete a large task, and she`ll spend tvo
and a halt procrastinating, and then one programming. 1he o-schedule result
vill probably meet the vrong requirements, because the task turned out to be
more complex than it seemed. Plus, vho can remember vhat the team agreed
upon three veeks ago
Give a programmer an atternoon to code a small, specitc module and she`ll
crank it out, ready to move onto the next one.
Smaller tasks and smaller timelines are more manageable, hide tever possible
requirement misunderstandings, and cost less to change your mind about or re-
do. Smaller timelines keep developers engaged and give them more opportunities
to enjoy a sense ot accomplishment and less reason to think, Oh I`ve got plenty
ot time to do that. lor nov, let me tnish rating songs in my i1unes library.
-Cina Trapani, uel ereloper an eiior of Lifehacker,
ihe prouciiriiy an sofiuare guie
lrue Iactors
Next time someone tries to pin you dovn tor an exact ansver to an
unknovable question vhether it`s tor a deadline date, a tnal project cost, or
the volume ot milk that vould tt in the Grand Canyon just start by taking the
air out ot the room: say I don`t knov.
lar trom damaging your credibility, this demonstrates the care you bring to your
decision-making. You`re not going to just say vords to sound smart. It also levels
the playing teld by retraming the question as a collaborative conversation. By
learning hov exact your estimate needs to be (and vhy,, you can vork together
to develop a shared understanding about the true tactors behind the numbers.
-Merlin Mann, creaior an eiior of 43folers.com
;
:oi:e lhe Cue Iro|iem :tariu You iu the Iace
My absolute tavorite thing to happen on the veb in recent memory is
the release and adoption ot the notollov attribute. Nobody talked
about it betorehand. 1here vere no conterences or committees vhere
a bunch ot yahoos could debate its semantic or grammatical nature.
No rrc that could turn a simple idea into a :o-line xxi snippet I`d
have to read up on just to tgure out hov to use, and then not use
because I vasn`t sure it I vas tormatting tor version . or .b.
It`s simple, it`s eective, it provided an option tor people vho vanted an
option and that is tar more important vhen dealing vith a population
ot the veb that doesn`t care about specitcations or deterence.
Sometimes solving the next tventy problems is not as usetul or as prudent as
solving the one staring us right in the tace. It vasn`t just a small victory against
spam (all victories against spam are small,, but a victory tor those ot us vho
enjoy the simple and svitt results that being a veb developer is all about.
-Anre Torrez, programmer an 1P of Engineering ai Feeraie Meia Pullishing
The Organizaiion
uit
ioue lime
Meetius re loxic
:eek auo Ceie|rate :maii 1ictories
;o
Cniiy
Dont split into silos
1oo many companies separate design, development, copyvrit-
ing, support, and marketing into dierent silos. While special-
ization has its advantages, it also creates a situation vhere staers
see just their ovn little vorld instead ot the entire context ot
the veb app.
As much as possible, integrate your team so there`s a healthy
back-and-torth dialogue throughout the process. Set up a system
ot checks and balances. Don`t let things get lost in translation.
Have copyvriters vork vith designers. Make sure support
queries are seen by developers.
Lven better, hire people vith multiple talents vho can vear
dierent hats during development. 1he end result vill be a more
harmonious product.
;;
Alone Time
People need uninterrupted tine to get things done
37signals is spread out over tour cities and eight time zones.
lrom Provo, Ltah to Copenhagen, Denmark, the tve ot us are
eight hours apart. One positi:e side eect ot this eight hour dit-
terence is alone time.
1here are only about - hours during the day that ve`re all
up and vorking together. At other times, the us team is sleep-
ing vhile David, vho`s in Denmark, is vorking. 1he rest ot the
time, ve`re vorking vhile David is sleeping. 1his gives us about
halt ot the day together and the other halt alone.
Guess vhich part ot the day ve get the most vork done 1he
alone part. It`s not that surprising really. Many people preter to
vork either early in the morning or late at night times vhen
they`re not being bothered.
When you have a long stretch vhen you aren`t bothered, you
can get in the zone. 1he zone is vhen you are most productive.
It`s vhen you don`t have to mindshitt betveen various tasks.
It`s vhen you aren`t interrupted to ansver a question or look up
something or send an email or ansver an ix. 1he alone zone is
vhere real progress is made.
Getting in the zone takes time. And that`s vhy interruption
is your enemy. It`s like rrx sleep you don`t just go to rrx
sleep, you go to sleep trst and you make your vay to rrx. Any
interruptions torce you to start over. rrx is vhere the real sleep
magic happens. 1he alone tine zone is vhere the real de-
velopnent nagic happens.
;:
Set up a rule at vork: Make halt the day alone time. lrom
+oam-:pm, no one can talk to one another (except during
lunch,. Or make the trst or the last halt ot the day the alone
time period. ust make sure this period is contiguous in order to
avoid productivity-killing interruptions.
A successtul alone time period means letting go ot communica-
tion addiction. During alone time, give up instant messenging,
phone calls, and meetings. Avoid any email thread that`s going
to require an immediate response. ust shut up and get to vork.
et Iuto the roo:e
We all knov that knovledge vorkers vork best by getting into nov, also
knovn as being in the zone, vhere they are tully concentrated on their
vork and tully tuned out ot their environment. 1hey lose track ot time and
produce great stu through absolute concentration...trouble is that it`s so easy
to get knocked out ot the zone. Noise, phone calls, going out tor lunch, having
to drive 3 minutes to Starbucks tor coee, and interruptions by covorkers
rsrrci:ii. interruptions by covorkers all knock you out ot the zone. It
you take a 1 minute interruption by a covorker asking you a question, and
this knocks out your concentration enough that it takes you halt an hour
to get productive again, your overall productivity is in serious trouble.
-joel 8polsky, sofiuare ereloper, Fog Creek 8ofiuare
( from here o These People Cei Their (Cnoriginal) Ieas?)
;,
Meeiings Are Toxic
Dont have neetings
Do you really need a meeting Meetings usually arise vhen a
concept isn`t clear enough. Instead ot resorting to a meeting, try
to simplity the concept so you can discuss it quickly via email
or ix or Camptre. 1he goal is to avoid meetings. Lvery minute
you avoid spending in a meeting is a minute you can get real
vork done instead.
1here`s nothing more toxic to productivity than a meeting.
Here`s a tev reasons vhy:
1hey break your vork day into small, incoherent
pieces that disrupt your natural vorknov
1hey`re usually about vords and abstract concepts, not real
things (like a piece ot code or some intertace design,
1hey usually convey an abysmally small
amount ot intormation per minute
1hey otten contain at least one moron that inevitably
gets his turn to vaste everyone`s time vith nonsense
1hey dritt o-subject easier than a Chicago cab in heavy snov
1hey trequently have agendas so vague nobody
is really sure vhat they are about
1hey require thorough preparation
that people rarely do anyvay
:o
lor those times vhen you a|soiutei must have a meeting (this
should be a rare event,, stick to these simple rules:
Set a o minute timer. When it rings, meeting`s over. Period.
Invite as tev people as possible.
Never have a meeting vithout a clear agenda.
Ha:e feuer meetius
1here are too many meetings. Push back on meetings that do not
make sense or are unproductive. Only book a meeting vhen you have
an important business issue to discuss and you vant or need input,
approval, or agreement. Lven then, resist the urge to invite everyone
and their brother don`t vaste people`s time unnecessarily.
-Lisa Hanelerg, auihor ( from Don'i Lei Meeiings Rule!)
Preak it Douu
As projects grov, adding people has a diminishing return. One ot the most
interesting reasons is the increased number ot communications channels. 1vo
people can only talk to each other, there`s only a single comm path. 1hree
vorkers have three communications paths, have o. In tact, the grovth ot links
is exponential...Pretty soon memos and meetings eat up the entire vork day.
1he solution is clear: break teams into smaller, autonomous and
independent units to reduce these communications links.
Similarly, cut programs into smaller units. Since a large part ot the
problem stems trom dependencies (global variables, data passed betveen
tunctions, shared hardvare, etc.,, tnd a vay to partition the program
to eliminate or minimize the dependencies betveen units.
-The Canssle Croup ( from Keep Ii 8mall)
:+
8eek an Celelraie 8mall 1iciories
Release sonething today
1he most important thing in sottvare development is motiva-
tion. Motivation is local it you aren`t motivated by vhat you
are vorking on right nov, then chances are it von`t be as good
as it should be. In tact, it`s probably going to suck.
Iong, dravn out release cycles are motivation killers. 1hey
insert too much time betveen celebrations. On the other hand,
quick vins that you can celebrate are great motivators. It you let
lengthy release cycles quash quick vins, you kill the motivation.
And that can kill your product.
So, it you`re in the middle ot a months-long release cycle, dedi-
cate a day a veek (or every tvo veeks, tor some small victories.
Ask yourselt What can ve do and release in hours And
then do it. It could be...
A nev simple teature
A small enhancement to an existing teature
Pevriting some help text to reduce the support burden
Pemoving some torm telds that you really don`t need
When you tnd those -hour quick vins, you`ll tnd celebration.
1hat builds morale, increases motivation, and rearms that the
team is headed in the right direction.
8iang
Hire Less auo Hire Later
Kick the lires
ctious, ^ot 1oros
et 1eii Pouuoeo Iuoi:iouais
You Cau`t Iake Luthusiasm
Hire ooo 1riters
:
Hire Less an Hire Laier
Add slov to go fast
1here`s no need to get big early or later. Lven it you have
access to +oo ot the very best people, it`s still a bad idea to try
and hire them all at once. 1here`s no vay that you can immedi-
ately assimilate that many people into a coherent culture. You`ll
have training headaches, personality clashes, communication
lapses, people going in dierent directions, and more.
So don`t hire. Peally. Don`t hire people. Iook tor another vay.
Is the vork that`s burdening you really necessary What it you
just don`t do it Can you solve the problem vith a slice ot sott-
vare or a change ot practice instead
Whenever ack Welch, tormer cro ot r, used to tre someone,
he didn`t immediately hire a replacement. He vanted to see hov
long r could get along uithout that persou auo that positiou. We`re
certainly not advocating tring people to test this theory, but
ve do think ack is on to something: You don`t need as many
people as you think.
It there`s no other vay, then consider a hire. But you should
knov exactly vho to get, hov to introduce them to the vork,
and the exact pain you expect them to relieve.
Prooks` iau
Adding people to a late sottvare project makes it later.
-Fre Brooks
:
Irorammiu auo Mo:art`s Peuiem
A single good programmer vorking on a single task has no coordination
or communication overhead. live programmers vorking on the same
task must coordinate and communicate. 1hat takes a lot ot time...
1he real trouble vith using a lot ot mediocre programmers instead ot a
couple ot good ones is that no matter hov long they vork, they never
produce something as good as vhat the great programmers can produce.
live Antonio Salieris von`t produce Mozart`s Pequiem.
Lver. Not it they vork tor +oo years.
-joel 8polsky, sofiuare ereloper, Fog Creek 8ofiuare
( from Hiiiing ihe High Noies)
:
Kick ihe Tires
Work vith prospective enployees on a test-basis hrst
It`s one thing to look at a porttolio, resume, code example,
or previous vork. It`s another thing to actually vork vith
someone. Whenever possible, take potential nev team members
out tor a test drive.
Betore ve hire anyone ve give them a small project to chev on
trst. We see hov they handle the project, hov they communi-
cate, hov they vork, etc. Working vith someone as they design
or code a tev screens vill give you a ton ot insight. You`ll learn
pretty quickly vhether or not the right vibe is there.
Scheduling can be tough tor this sort ot thing but even it it`s tor
just :o or o hours, it`s better than nothing. It it`s a good or bad
tt, it vill be obvious. And it not, both sides save themselves a lot
ot trouble and risk by testing out the situation trst.
:tart smaii
1ry a small test assignment to start. Don`t leap in vith all ot your vork at
once. Give your nev [virtual assistant| a test project or tvo to vork on and
see hov the chemistry develops. In the beginning, it`s too easy to gloss over
potential problems vith rose-colored glasses. Make it clear this is a test run.
-8uzanne Falier-Barns, auihor/creaiiriiy experi ( from
Hou To Fin An Keep The Perfeci 1A)
:o
Aciions, Noi ors
)udge potential tech hires on open source contributions
1he typical method ot hiring tor technical positions based on
degrees, resumes, etc. is silly in a lot ot vays. Does it really
matter vhere someone`s degree is trom or their r: Can you
really trust a resume or a reterence
Open source is a gitt to those vho need to hire technical people.
With open source, you can track someone`s vork and contribu-
tions good and bad over a lengthy period ot time.
1hat means you can judge people by their actions instead ot just
their vords. You can make a decision based on the things that
really matter:
Quality of vork
Many programmers can talk the talk but trip vhen it comes
time to valk the valk. With open source, you get the nitty-
gritty specitcs ot a person`s programming skills and practices.
Cultural perspective
Programing is all about decisions. Iots and lots ot
them. Decisions are guided by your cultural vantage
point, values, and ideals. Iook at the specitc decisions
made by a candidate in coding, testing, and community
arguments to see vhether you`ve got a cultural match.
It there`s no tt here, each decision vill be a struggle.
Level of passion
By detnition, involvement in open source requires at
least some passion. Othervise vhy vould this person
spend tree time sitting in tront ot a screen 1he amount
:;
ot open source involvement otten shovs hov much
a candidate truly cares about programming.
Conpletion percentage
All the smarts, proper cultural leanings, and passion don`t
amount to valuable sottvare it a person can`t get stu done.
Lntortunately, lots ot programmers can`t. So look tor that zeal
to ship. Hire someone vho needs to get it out the door and
is villing to make the pragmatic trade-os this may require.
Social natch
Working vith someone over a long period ot time,
during both stressrelaxation and highslovs, vill
shov you their real personality. It someone`s lacking
in manners or social skills, tlter them out.
When it comes to programmers, ve only hire people ve knov
through open source. We think doing anything else is irre-
sponsible. We hired amis because ve tolloved his releases and
participation in the Puby community. He excelled in all the
areas mentioned above. It vasn`t necessary to rely on secondary
tactors since ve could judge him based on vhat really matters:
the quality ot his vork.
And don`t vorry that extra-curricular activities vill take tocus
and passion avay trom a staer`s day job. It`s like the old cliche
says: It you vant something done, ask the busiest person you
knov. amis and David are tvo ot the heaviest contributors to
Pails and still manage to drive 37signals technically. People
vho love to program and get things done are exactly the kind ot
people you vant on your team.
Cpeu :ource Iassiou
What you vant the most trom a nev hire is passion tor vhat he does, and there`s
no better vay ot shoving it than a trace ot commitment in open source projects.
-jarkko Laine, sofiuare ereloper ( from Louihinking.com
Reuce ihe risk, hire from open source)
::
Cei ell Roune Iniriuals
Go for quick learning generalists over ingrained specialists
We`ll never hire someone vho`s an intormation architect. It`s
just too overly specitc. With a small team like ours, it doesn`t
make sense to hire people vith such a narrovly detned skill-set.
Small teams need people vho can vear dierent hats. You
need designers vho can vrite. You need programmers vho
understand design. Lveryone should have an idea about hov
to architect intormation (vhatever that may mean,. Lveryone
needs to have an organized mind. Lveryone needs to be able to
communicate vith customers.
And everyone needs to be villing and able to shitt gears dovn
the road. Keep in mind that small teams otten need to change
direction and do it quickly. You vant someone vho can adjust
and learn and nov as opposed to a stick-in-the-mud vho can do
only one thing.
:,
You Can'i Fake Enihusiasm
Go for happy and average over frustrated and great
Lnthusiasm. It`s one attribute you just can`t take. When it comes
time to hire, don`t think you need a guru or a tech-celebrity.
Otten, they`re just primadonnas anyvay. A happy yet average
employee is better than a disgruntled expert.
lind someone vho`s enthusiastic. Someone you can trust to get
things done vhen lett alone. Someone vho`s suered at a bigger,
slover company and longs tor a nev environment. Someone
vho`s excited to build vhat you`re building. Someone vho
hates the same things you hate. Someone vho`s thrilled to climb
aboard your train.
Lxtra poiuts for askiu uestious
Observe vhether a potential hire asks a lot ot questions about your
project. Passionate programmers vant to understand a problem as vell as
possible and vill quickly propose potential solutions and improvements,
vhich leads to a lot ot questions. Claritying questions also reveal an
understanding that your project could be implemented thousands ot
dierent vays and it`s essential to nail dovn as explicitly as possible exactly
hov you imagine your veb app vorking. As you dig into the details,
you`ll develop a sense ot vhether the person is a good cultural match.
-Eric 8iephens, Buil11.com
,o
orsmiihs
Hire good vriters
It you are trying to decide betveen a tev people to tll a po-
sition, alvays hire the better vriter. It doesn`t matter it that
person is a designer, programmer, marketer, salesperson, or
vhatever, the vriting skills vill pay o. Lective, concise
vriting and editing leads to eective, concise code, design,
emails, instant messages, and more.
1hat`s because being a good vriter is about more than vords.
Good vriters knov hov to communicate. 1hey make things
easy to understand. 1hey can put themselves in someone else`s
shoes. 1hey knov vhat to omit. 1hey think clearly. And those
are the qualities you need.
u Craui:eo Miuo
Good vriting skills are an indicator ot an organized mind vhich is capable ot
arranging intormation and argument in a systematic tashion and also helping
(not making, other people understand things. It spills over into code, personal
communications, instant messaging (tor those long-distance collaborations,,
and even such esoteric concepts as protessionalism and reliability.
-Dusiin j. Miichell, ereloper
Ciear 1ritiu Leaos lo Ciear lhiukiu
Clear vriting leads to clear thinking. You don`t knov vhat you knov
until you try to express it. Good vriting is partly a matter ot character.
Instead ot doing vhat`s easy tor you, do vhat`s easy tor your reader.
-Michael A. Coringion, Professor of Compuier 8cience ai The Cnirersiiy of Ceorgia
( from Hou io riie More Clearly, Think More Clearly,
an Learn Complex Maierial More Easily)
Inierface Design
Iuterface Iirst
Lpiceuter Desiu
lhree :tate :oiutiou
lhe Piauk :iate
et Defeusi:e
Coutext C:er Cousisteuc
Copuritiu is Iuterface Desiu
Cue Iuterface
,:
Inierface Firsi
Design the interface before you start progranning
1oo many apps start vith a program-trst mentality. 1hat`s a
bad idea. Programming is the heaviest component ot building
an app, meaning it`s the most expensive and hardest to change.
Instead, start by designing trst.
Design is relatively light. A paper sketch is cheap and easy to
change. n+xi designs are still relatively simple to modity (or
throv out,. 1hat`s not true ot programming. Designing trst
keeps you nexible. Programming trst tences you in and sets you
up tor additional costs.
Another reason to design trst is that the interface is your
product. What people see is vhat you`re selling. It you just slap
an intertace on at the end, the gaps vill shov.
We start vith the intertace so ve can see hov the app looks and
teels trom the beginning. It`s constantly being revised through-
out the process. Does it make sense Is it easy to use Does it
solve the problem at hand 1hese are questions you can only
truly ansver vhen you`re dealing vith real screens. Designing
trst keeps you nexible and gets you to those ansvers sooner in
the process rather than later.
,
lhe Craue Ieu lhat :tarteo Piiuksaie
As soon as I realized my trustration vith o-the-shelt invoicing sottvare, I
decided to drav out hov I vould preter my invoicing solution to vork. I
pulled out an orange pen, because it vas the only thing handy that evening,
and had about ; percent ot the ui dravn out vithin a tev hours. I shoved
it to my vite, Pachel, vho vas ironing at the time, and asked, What do
you think And she replied vith a smile, You need to do this. lor real.
Over the next tvo veeks I retned the designs, and completely mocked-
up static n+xi pages tor almost the entire trst version ot vhat vould
become Blinksale. We never did any viretrames beyond those orange-
pen sketches, and getting straight into the n+xi design helped us stay
excited about hov real the project vas becoming, even though
at the time ve really didn`t knov vhat ve vere getting into.
Once the n+xi mockups vere completed, ve approached our developer,
Scott, vith the idea tor Blinksale. Having most ot the ui designed up tront
vas extremely benetcial on several levels. lirst, it gave Scott a real vision and
excitement tor vhere ve vere going. It vas much more than just an idea,
it vas real. Second, it helped us accurately gauge hov much ot Scott`s eort
and time it vould require to turn the design into a tunctioning application.
When you`re tnancially bootstrapping a project, the earlier you can predict
budget requirements, the better. 1he ui design became our benchmark tor
the initial project scope. linally, the ui design served as a guide to remind us
vhat the application vas about as ve progressed turther into development.
As ve vere tempted to add nev teatures, ve couldn`t simply say, Sure, let`s
add that' We had to go back to the design and ask ourselves vhere that
nev teature vould go, and it it didn`t have a place, it vouldn`t get added.
-josh illiams, founer, Blinksale
,
Epicenier Design
Start fron the core of the page and build outvard
Lpicenter design tocuses on the true essence ot the page the
epicenter and then builds outvard. 1his means that, at the
start, you ignore the extremities: the navigationtabs, tooter,
colors, sidebar, logo, etc. Instead, you start at the epicenter and
design the most important piece ot content trst.
Whatever the page absolutely can`t live vithout is the epicen-
ter. lor example, it you`re designing a page that displays a blog
post, the blog post itselt is the epicenter. Not the categories in
the sidebar, not the header at the top, not the comment torm at
the bottom, but the actual blog post unit. Without the blog post
unit, the page isn`t a blog post.
Only vhen that unit is complete vould you begin to think
about the second most critical element on the page. 1hen atter
the second most critical element, you`d move on to the third,
and so on. 1hat`s epicenter design.
Lpicenter design eschevs the tradtional let`s build the trame
then drop the content in model. In that process, the page shape
is built, then the nav is included, then the marketing stu
is inserted, and then, tnally, the core tunctionality, the actual
purpose ot the page, is poured in to vhatever space remains. It`s
a backvards process that takes vhat should be the top priority
and saves it tor the end.
,
Lpicenter design nips that process and allovs you to tocus on
vhat really matters on day one. Lssentials trst, extras second.
1he result is a more triendly, tocused, usable screen tor custom-
ers. Plus, it allovs you to start the dialogue betveen designer
and developer right avay instead ot vaiting tor all aspects ot the
page to tall in line trst.
,o
Three 8iaie 8oluiion
Design for regular, blank, and error states
lor each screen, you need to consider three possible states:
Regular
1he screen people see vhen everything`s vorking
tne and your app is nush vith data.
Blank
1he screen people see vhen using the app tor
the trst time, betore data is entered.
Lrror
1he screen people see vhen something goes vrong.
1he regular state is a no-brainer. 1his is the screen vhere you`ll
spend most ot your time. But don`t torget to invest time on the
other states too (see the tolloving essays tor more on this,.
,;
The Blank 8laie
Set epectations vith a thoughtful hrst-run eperience
Ignoring the blank slate stage is one ot the biggest mistakes you
can make. 1he blank slate is your app`s trst impression and you
never get a second...vell, you knov.
1he problem is that vhen designing a ui, it`s usually nush vith
data. Designers alvays tll templates vith data. Lvery list, every
post, every teld, every nook and cranny has stu in it. And that
means the screen looks and vorks great.
Hovever, the natural state ot the app is one that`s devoid ot data.
When someone signs up, they start vith a blank slate. Much like
a veblog, it`s up to them to populate it the overall look and
teel doesn`t take shape until people enter their data: posts, links,
comments, hours, sidebar into, or vhatever.
Lntortunately, the customer decides it an application is vorthy
at this blank slate stage the stage vhen there`s the least
amount ot intormation, design, and content on vhich to judge
the overall usetulness ot the application. When you tail to
design an adequate blank slate, people don`t knov vhat they are
missing because everything is missing.
Yet most designers and developers still take this stage tor
granted. 1hey tail to spend a lot ot time designing tor the blank
slate because vhen they developuse the app, it`s tull ot data that
they`ve entered tor testing purposes. 1hey don`t even encoun-
ter the blank slate. Sure, they may log-in as a nev person a tev
times, but the majority ot their time is spent svimming in an
app that is tull ot data.
,:
What should you include in a helptul blank slate
Lse it as an opportunity to insert quick
tutorials and help blurbs.
Give a sample screenshot ot the page populated
vith data so people knov vhat to expect
(and vhy they should stick around,.
Lxplain hov to get started, vhat the screen
vill eventually look like, etc.
Ansver key questions that trst-time vievers
vill ask: What is this page What do I do nov
Hov vill this screen look once it`s tull
Set expectations and help reduce trustration,
intimidation, and overall contusion.
lirst impressions are crucial. It you tail to design a thoughttul
blank slate, you`ll create a negative (and talse, impression ot your
application or service.
You ^e:er et :ecouo Chauce...
Another aspect ot the Mac OS x ui that I think has been tremendously
innuenced by [Steve| obs is the setup and trst-run experience. I think obs
is keenly avare ot the importance ot trst impressions...I think obs looks at
the trst-run experience and thinks, it may only be one-thousandth ot a
user`s overall experience vith the machine, but it`s the most important one-
thousandth, because it`s the trst one-thousandth, and it sets their expectations
and initial impression.
-john Cruler, auihor an uel ereloper ( from Inierrieu uiih john Cruler)
,,
Cei Defensire
Design for vhen things go vrong
Iet`s admit it: 1hings vill go vrong online. No matter hov
caretully you design your app, no matter hov much testing you
do, customers vill still encounter problems. So hov do you
handle these inevitable breakdovns With detensive design.
Detensive design is like detensive driving. 1he same vay
drivers must alvays be on the lookout tor slick roads, reck-
less drivers, and other dangerous scenarios, site builders must
constantly search tor trouble spots that cause visitors contu-
sion and trustration. Good site detense can make or break the
customer experience.
We could tll a separate book vith all the things ve have to
say about detensive design. In tact, ve already have. Deten-
sive Design tor the Web is the title and it`s a great resource tor
anyone vho vants to learn hov to improve error screens and
other crisis points.
Pemember: Your app may vork great ,o ot the time. But it
you abandon customers in their time ot need, they`re unlikely to
torget it.
+oo
Coniexi Orer Consisiency
What nakes sense here nay not nake sense there
Should actions be buttons or links It depends on the action.
Should a calendar viev be in list-torm or grid-torm It depends
vhere it`s being shovn and hov long the time period is. Does
every global navigation link need to be on every page Do you
need a global search bar everyvhere Do you need the same
exact tooter on each page 1he ansver: It depends.
1hat`s vhy context is more important than consistency. It`s ok
to be inconsistent it your design makes more sense that vay.
Give people just vhat matters. Give them vhat they need vhen
they need it and get rid ot vhat they don`t. It`s better to be right
than to be consistent.
Iuteiiieut Iucousisteuc
Consistency is xo+ necessary. lor years, students ot ui and ux have been
taught that consistency in the intertace is one ot the cardinal rules ot
intertace design. Perhaps that holds in sottvare, but on the Web, it`s just
not true. What matters on the Web is vhether, on each individual page,
the user can quickly and easily advance the next step in the process.
At Creative Good, ve call it intelligent inconsistency: making
sure that each page in the process gives users exactly vhat they need
at that point in the process. Adding supernuous nav elements, just
because they`re consistent vith the rest ot the site, is just silly.
-Mark Hursi, founer of Creaiire Coo an creaior of
Cooriie.com ( from The Page Paraigm)
+o+
Copyuriiing is Inierface Design
Lvery letter natters
Copyvriting is intertace design. Great intertaces are vritten.
It you think every pixel, every icon, every typetace matters,
then you also need to believe every letter matters. When you`re
vriting your intertace, alvays put yourselt in the shoes ot the
person vho`s reading your intertace. What do they need to
knov Hov you can explain it succinctly and clearly
Do you label a button Submit or Save or Update or New or
Create 1hat`s copyvriting. Do you vrite three sentences or
tve Do you explain vith general examples or vith details Do
you label content New or Updated or Recently Updated or Modi-
ed Is it There are new messages: 5 or There are 5 new messages
or is it 5 or ve or messages or posts All ot this matters.
You need to speak the same language as your audience too.
ust because you`re vriting a veb app doesn`t mean you can
get avay vith technical jargon. 1hink about your customers
and think about vhat those buttons and vords mean to them.
Don`t use acronyms or vords that most people don`t understand.
Don`t use internal lingo. Don`t sound like an engineer talking to
another engineer. Keep it short and sveet. Say vhat you need to
and no more.
Good vriting is good design. It`s a rare exception vhere vords
don`t accompany design. Icons vith names, torm telds vith
examples, buttons vith labels, step by step instructions in a
process, a clear explanation ot your retund policy. 1hese are all
intertace design.
+o:
One Inierface
Incorporate adnin functions into the public interface
Admin screens the screens used to manage preterences, people,
etc. have a tendency to look like crap. 1hat`s because the ma-
jority ot development time is spent on the public-tacing inter-
tace instead.
1o avoid crappy-admin-screen syndrome, don`t build separate
screens to deal vith admin tunctions. Instead, build these tunc-
tions (i.e. edit, add, delete, into the regular application intertace.
It you have to maintain tvo separate intertaces (i.e. one tor
regular tolks and one tor admins,, both vill suer. In eect,
you vind up paying the same tax tvice. You`re torced to repeat
yourselt and that means you increase the odds ot getting sloppy.
1he tever screens you have to vorry about, the better they`ll
turn out.
^o :eparate Iuterface
1he application is everything. Anything that can be changed, added, or
adjusted can be done directly through the management area ot the application.
1his allovs us to see exactly vhat our customers see to help them through
any problems or questions that they have. And our customers don`t have
to vorry about logging into a separate intertace to do dierent tasks. One
minute they might be dealing vith appointments tor their clients and
the next minute they might have to add a nev employee. 1hey can`t be
bothered vith jumping betveen dierent applications and maintaining a
consistent intertace they`re able to adapt to the application even quicker.
-Euar Kniiiel, Direcior of 8ales an Markeiing, Kennel8ource
Coe
Less :oftuare
Cptimi:e for Happiuess
Cooe :peaks
Mauae De|t
Cpeu Doors
+o
Less 8ofiuare
Keep your code as sinple as possible
You`d think that tvice as much code vould make your sottvare
only tvice as complex. But actually, each tine you increase
the anount of code, your softvare grovs exponeniially
nore conplicated. Lach minor addition, each change, each
interdependency, and each preterence has a cascading eect.
Keep adding code recklessly and, betore you knov it, you`ll
have created the dreaded Big Ball ot Mud.
1he vay you tght this complexity is vith less sottvare. Iess
sottvare means less teatures, less code, less vaste.
1he key is to restate any hard problem that requires a lot ot sott-
vare into a simple problem that requires much less. You may not
be solving exactly the same problem but that`s alright. Solving
:o ot the original problem tor :o ot the eort is a major vin.
1he original problem is almost never so bad that it`s vorth tve
times the eort to solve it.
Iess sottvare means you put avay the crystal ball. Instead ot
trying to predict tuture problems, you deal only vith the prob-
lems ot today. Why lears you have about tomorrov otten never
come to truition. Don`t bog yourselt dovn trying to solve these
phantom issues.
+o
lrom the beginning, ve`ve designed our products around the
concept ot less sottvare. Whenever possible, ve chop up hard
problems into easy ones. We`ve tound solutions to easy problems
are not only easier to implement and support, they`re easier to
understand and easier to use. It`s all part ot hov ve dierentiate
ourselves trom competitors, Instead ot trying to build products
that do more, ve build products that do less.
Iess sottvare is easier to manage.
Iess sottvare reduces your codebase and that means
less maintenance busyvork (and a happier sta,.
Iess sottvare lovers your cost ot change so you
can adapt quickly. You can change your mind
vithout having to change boatloads ot code.
Iess sottvare results in tever bugs.
Iess sottvare means less support.
Which teatures you choose to include or omit have a lot to
do vith less sottvare too. Don`t be atraid to say no to teature
requests that are hard to do. Lnless they`re absolutely essential,
save timeeortcontusion by leaving them out.
Slov dovn too. Don`t take action on an idea tor a veek and see
it it still seems like a great idea atter the initial buzz vears o.
1he extra marinading time vill otten help your brain come up
vith an easier solution.
Lncourage progranners to nake counteroers.You vant
to hear: 1he vay you suggested vill take +: hours. But there`s
a vay I can do it that vill only take one hour. It von`t do x but
it vill do .. Iet the sottvare push back. 1ell programmers to
tght tor vhat they think is the best vay.
+oo
Also, search tor detours around vriting more sottvare. Can you
change the copy on the screen so that it suggests an alternate
route to customers that doesn`t require a change in the sottvare
model lor example, can you suggest that people upload images
ot a specitc size instead ot doing the image manipulation on the
server side
lor every teature that makes it into your app, ask yourselt: Is
there a vay this can be added that von`t require as much sott-
vare Write just the code you need and no more. Your app vill
be leaner and healthier as a result.
lhere is ^o CCDL lhat is More Iiexi|ie lhau ^C Cooe:
1he secret to good sottvare design vasn`t in knoving vhat to put into
the code, it vas in knoving vhat to leave OL1' It vas in recognizing
vhere the hard-spots and sott-spots vere, and knoving vhere to
leave spaceroom rather than trying to cram in more design.
-Bra Appleion, sofiuare engineer ( from There is No
CODE ihai is more exille ihan NO Coe!)
Compiexit Does ^ot :caie Liueari 1ith :i:e
1he most important rule ot sottvare engineering is also the least knovn:
Complexity does not scale linearly vith size...A :ooo line program requires
more than tvice as much development time as one halt the size.
-The Canssle Croup ( from Keep Ii 8mall)
+o;
Opiimize for Happiness
Choose tools that keep your tean ecited and notivated
A happy programmer is a productive programmer. 1hat`s vhy
ve optimize tor happiness and you should too. Don`t just pick
tools and practices based on industry standards or pertormance
metrics. Iook at the intangibles: Is there passion, pride, and
crattmanship here Would you truly be happy vorking in this
environment eight hours a day
1his is especially important tor choosing a programming lan-
guage. Despite public perception to the contrary, they are not
created equal. While just about any language can create just
about any application, the right one makes the eort not merely
possible or bearable, but pleasant and invigorating. It`s all about
making the little details ot daily vork enjoyable.
Happiness has a cascading eect. Happy programmers do the
right thing. 1hey vrite simple, readable code. 1hey take clean,
expressive, readable, elegant approaches. 1hey have tun.
We tound programming bliss in the language Puby and passed
it on to other developers vith our tramevork Pails. Both share
a mission statement to optimize tor humans and their happiness.
We encourage you to give that combination a spin.
In summary, your team needs to vork vith tools they love.
We`ve talked here in terms ot programming languages, but the
concept holds true tor applications, plattorms, and anything else.
Choose the tuse that gets people excited. You`ll generate excite-
ment and motivation and a better product as a result.
+o:
lhe kiuos of euiueers ou uaut
1he number one reason I vanted to build our app using Puby on Pails is
that it is so elegant, productive, and beautitully designed. It tends to attract the
kind ot engineers vho care about just those sort ot things...those are exactly
the kinds ot engineers you vant on your team because they create the kind
ot beautitul, elegant and productive sottvare you need to vin the market.
-Charles jolley, Managing Direcior ai Nisus 8ofiuare ( from 8ignal rs. Noise)
+o,
Coe 8peaks
Listen vhen your code pushes back
Iisten to your code. It vill oer suggestions. It vill push back. It
vill tell you vhere the pittalls reside. It vill suggest nev vays to
do things. It vill help you stick to a model ot less sottvare.
Is a nev teature requiring veeks ot time and thousands ot lines
ot code 1hat`s your code telling you there`s probably a better
vay. Is there a simple vay to code something in one hour
instead ot a complicated vay that vill take ten hours Again,
that`s your code guiding you. Iisten.
Your code can guide you to txes that are cheap and light. Pay
attention vhen an easy path emerges. Sure, the teature that`s
easy to make might not be exactly the same as the teature you
originally had in mind but so vhat It it vorks vell enough and
gives you more time to vork on something else, it`s a keeper.
Listeu up
Don`t vorry about design, it you listen to your code a good
design vill appear...Iisten to the technical people. It they are
complaining about the diculty ot making changes, then take
such complaints seriously and give them time to tx things.
-Mariin Fouler, Chief 8cieniisi, Thoughiorks ( from Is Design Dea?)
++o
If Irorammers ot Iaio lo Pemo:e Cooe...
It programmers got paid to remove code trom sotvare instead ot
vriting nev code, sottvare vould be a vhole lot better.
-Nicholas Negroponie, iesner Professor of Meia Technology ai ihe
Massachuseiis Insiiiuie of Technology an founing chairman of MIT's
Meia Laloraiory ( from An, ihe resi of ihe (AICA Conference) siory)
+++
Manage Deli
Pay o your code and design bills
We usually think ot debt in terms ot money but it comes in
other torms too. You can easily build up code and design debt.
Hack together some bad code that`s tunctional but still a bit
hairy and you`re building up debt. 1hrov together a design
that`s good enough but not really good and you`ve done it again.
It`s ok to do this trom time to time. In tact, it`s otten a
needed technique that helps you do the vhole Get-Peal-:s:r-
thing. But you still need to recognize it as debt and pay it o at
some point by cleaning up the hairy code or redesigning that
so-so page.
1he same vay you should regularly put aside some ot your
income tor taxes, regularly put aside some time to pay o your
code and design debt. It you don`t, you`ll just be paying inter-
est (txing hacks, instead ot paying dovn the principal (and
moving torvard,.
++:
Open Doors
Get data out into the vorld via RSS, APIs, etc.
Don`t try to lock-in your customers. Iet them get their intorma-
tion vhen they vant it and hov they vant it.
1o do that, you`ve got to give up the idea of sealing in data.
Instead, let it run vild. Give people access to their intorma-
tion via rss teeds. Oer :ris that let third-party developers
build on to your tool. When you do, you make lite more conve-
nient tor customers and expand the possibilities ot vhat your
app can do.
People used to think ot rss teeds as merely a good vay to keep
track ot blogs or nevs sites. leeds have more pover than that
though. 1hey also provide a great vay tor customers to stay up
to date on the changing content ot an app vithout having to
log in repeatedly. With Basecamp teeds, customers can pop the
uri into a nevsreader and keep an eye on project messages, to-
do lists, and milestones vithout having to constantly check in at
the site.
:ris let developers build add-on products tor your app that can
turn out to be invaluable. lor example, Backpack supplies an :ri
vhich Chipt Productions used to build a Mac os x Dashboard
vidget. 1he vidget lets people add and edit reminders, list
items, and more trom the desktop. Customers have raved to us
about this vidget and some have even said it vas the key tactor
in getting them to use Backpack.
Other good examples ot companies letting data run tree in order
to get a boomerang eect:
++
1he Google Maps API has spavned interesting mash-
ups that let people cull intormation trom another source
(e.g. apartment listings, and plot that data on a map.
Linkrolls oer a vay tor people to get their latest
del.icio.us bookmarks displayed on their ovn sites.
Flickr allovs other businesses access to commercial :ris
so customers can buy photo books, posters, ivi backups,
and stamps. 1he goal is to open it up completely and give
you the biggest variety ot choices vhen it comes to doing
things vith your photos, says Stevart Butterteld ot llickr.
1ioet Makes the Diereuce
When 37signals released Backpack a vhile back, my trst impression vas...eh.
So it vas around the time that Chipt Productions released a Backpack
vidget tor 1iger vhich vas too cool not to dovnload and try that
I gave Backpack a second look. 1he result Quite a dierence.
Nov vhenever an idea hits, I pop up the vidget, type, and submit done.
Lmail arrives vith something I vant to check out Pop up the vidget,
type, and submit done. 1he vidget is an immediate brain dump readily
available on each Mac I use. And because everything is veb based, there isn`t
any version control or syncing just the nuid input ot content vithout
having to be concerned about vhere it`s going or hov I`ll access it later.
-To Dominey, founer, Dominey Design ( from Trying on Backpack)
ors
lhere`s ^othiu Iuuctiouai a|out a Iuuctiouai :pec
Dou`t Do Deao Documeuts
leii Me a uick :tor
se Peai 1oros
Iersouif Your Iroouct
++
There's Noihing Funciional aloui a
Funciional 8pec
Dont vrite a functional specihcations docunent
1hese blueprint docs usually vind up having almost nothing to
do vith the tnished product. Here`s vhy:
Functional specs are fantasies
1hey don`t renect reality. An app is not real until builders are
building it, designers are designing it, and people are using it.
lunctional specs are just vords on paper.
Functional specs are about appeasenent
1hey`re about making everyone teel involved and happy vhich,
vhile varm and tuzzy, isn`t all that helptul. 1hey`re never about
making tough choices and exposing costs, things that need to
happen to build a great app.
Functional specs only lead to an illusion of agreenent
A bunch ot people agreeing on paragraphs ot text isn`t a true
agreement. Lveryone may be reading the same thing but they`re
thinking something dierent. 1his inevitably comes out later
on: Wait, that`s not vhat I had in mind. Huh 1hat`s not
hov ve described it. Yes it vas and ve all agreed on it you
even signed o on it. You knov the drill.
++o
Functional specs force you to nake the nost inportant
decisions vhen you have the least infornation
You knov the least about something vhen you begin to build it.
1he more you build it, the more you use it, the more you knov
it. 1hat`s vhen you should be making decisions vhen you
have more intormation, not less.
Functional specs lead to feature overload
1here`s no pushback during spec phase. 1here`s no cost to
vriting something dovn and adding another bullet point. You
can please someone vho`s a pain by adding their pet teature.
And then you vind up designing to those bullet points, not to
humans. And that`s hov you vind up vith an overloaded site
that`s got o tabs across the top ot the screen.
Functional specs dont let you evolve, change,and reassess
A teature is signed o and agreed on. Lven it you realize during
development that it`s a bad idea, you`re stuck vith it. Specs don`t
deal vith the reality that once you start building something,
everything changes.
So vhat should you do in place ot a spec Go vith a brieter
alternative that moves you tovard something real.
Write a one page story about vhat the app needs to do. Lse
plain language and make it quick. It it takes more than a page
to explain it, then it`s too complex. 1his process shouldn`t take
more than one day.
1hen begin building the intertace the intertace vill be the
alternative to the tunctional spec. Drav some quick and simple
paper sketches. 1hen start coding it into n+xi. Lnlike para-
graphs ot text that are open to alternate interpretations, intertace
designs are common ground that everyone can agree on.
++;
Contusion disappears vhen everyone starts using the same
screens. Build an intertace everyone can start looking at, using,
clicking through, and teeling betore you start vorrying about
back-end code. Get yourselt in tront ot the customer experience
as much as possible.
lorget about locked-in specs. 1hey torce you to make big, key
decisions too early in the process. Bypass the spec phase and
you`ll keep change cheap and stay nexible.
seiess :pecs
A spec is close to useless. I have never seen a spec that
vas both big enough to be usetul and accurate.
And I have seen lots ot total crap vork that vas based on specs.
It`s the single vorst vay to vrite sottvare, because it by detnition
means that the sottvare vas vritten to match theory, not reality.
-Linus Torrals, creaior of Linux ( from Linux Linus On 8pecicaiions)
Iiht the |iockers
I tound the people insisting on extensive requirements documents betore starting
any design vere really blockers` just trying to slov the process dovn (and
usually people vith nothing to contribute on design or innovative thinking,.
All our best vork vas done vith a tev concepts in our heads about
improving a site, doing a quick prototype (static,, changing the design a bit
and then building a live prototype vith real data. Atter kicking the tires on
this prototype, ve usually had a real project in motion and good result.
-Mark Callagher, corporaie iniranei ereloper ( from 8ignal rs. Noise)
++:
Don'i Do Dea Documenis
Llininate unnecessary papervork
Avoiding tunctional specs is a good start but don`t stop there,
Prevent excess papervork everyvhere. Lnless a document is
actually going to morph into something real, don`t produce it.
Build, don`t vrite. It you need to explain something, try
mocking it up and prototyping it rather than vriting a long-
vinded document. An actual intertace or prototype is on its vay
to becoming a real product. A piece ot paper, on the other hand,
is only on its vay to the garbage can.
Here`s an example: It a viretrame document is destined to stop
and never directly become the actual design, don`t bother doing
it. It the viretrame starts as a viretrame and then morphs into
the actual design, go tor it.
Documents that live separately trom your application are vorth-
less. 1hey don`t get you anyvhere. Lverything you do should
evolve into the real thing. It a document stops betore it turns
real, it`s dead.
++,
^o Cue`s oiu to Peao It
I can`t even count hov many multi-page product specitcations or business
requirement documents that have languished, unread, gathering dust nearby my
dev team vhile ve coded avay, discussing problems, asking questions and user-
testing as ve vent. I`ve even vorked vith developers vho`ve spent hours vriting
long, descriptive emails or coding standards documents that also vent unread.
Webapps don`t move torvard vith copious documentation. Sottvare
development is a constantly shitting, iterative process that involves
interaction, snap decisions, and impossible-to-predict issues that crop
up along the vay. None ot this can or should be captured on paper.
Don`t vaste your time typing up that long visionary tome, no one`s going to
read it. 1ake consolation in the tact that it you give your product enough room
to grov itselt, in the end it von`t resemble anything you vrote about anyvay.
-Cina Trapani, uel ereloper an eiior of Lifehacker,
ihe prouciiriiy an sofiuare guie
+:o
Tell Me a Quick 8iory
Write stories, not details
It you do tnd yourselt requiring vords to explain a nev teature
or concept, vrite a briet story about it. Don`t get into the tech-
nical or design details, just tell a quick story. Do it in a human
vay, like you vould in normal conversation.
It doesn`t need to be an essay. ust give the nov ot vhat happens.
And it you can include the briet story in context vith screens
you are developing, all the better.
Stick to the experience instead ot getting hung up on the details.
1hink strategy, not tactics. 1he tactics vill tall into place once
you begin building that part ot your app. Pight nov you just
vant to get a story going that vill initiate conversation and get
you on the right track.
+:+
Cse Real ors
Insert actual tet instead of loren ipsun
Iorem ipsum dolor is a trusted triend ot designers. Dummy text
helps people get vhat the design vill look like once it`s neshed
out. But dummy text can be dangerous too.
Iorem ipsum changes the vay copy is vieved. It reduces
text-based content to a visual design element a shape ot text
instead ot vhat it should be: valuable intormation someone
is going to have to enter andor read. Dummy text means you
von`t see the inevitable variations that shov up once real intor-
mation is entered. It means you von`t knov vhat it`s like to
tll out torms on your site. Dummy text is a veil betveen you
and reality.
You need real copy to knov hov long certain telds should be.
You need real copy to see hov tables vill expand or contract.
You need real copy to knov vhat your app truly looks like.
As soon as you can, use real and relevant vords. It your site or
application requires data input, enter the real deal. And actually
type in the text don`t just paste it in trom another source. It
it`s a name, type a real name. It it`s a city, type a real city. It it`s a
passvord, and it`s repeated tvice, type it tvice.
+::
Sure, it`s easier to just run dovn the torms and tll the telds vith
garbage (asdsadklja 123usadtjasld snaxn2q9e7, in order to
plov through them quickly. But that`s not real. 1hat`s not vhat
your customers are going to do. Is it really smart to take a short-
cut vhen customers are torced to take the long road When you
just enter take copy in rapid-tre tashion, you don`t knov vhat it
really teels like to tll out that torm.
Do as your customers do and you`ll understand them better.
When you understand them better, and teel vhat they teel,
you`ll build a better intertace.
Lorem Ipsum ar|ae
By not having the imagination to imagine vhat the content might be, a
design consideration is lost. Meaning becomes obtuscated because it`s just
text, understandability gets compromised because nobody realized that this
text stu vas actually meant to be read. Opportunities get lost because the
lorem ipsum garbage that you used instead ot real content didn`t suggest
opportunities. 1he text then gets made really small, because, it`s not meant
to be used, ve might as vell create loads ot that lovely vhite space.
-Tom 8miih, esigner an ereloper ( from I haie Lorem Ipsum an Lorem Ipsum Csers)
+:
Personify Your Prouci
What is your products personality type?
1hink ot your product as a person. What type ot person do you
vant it to be Polite Stern lorgiving Strict lunny Deadpan
Serious Ioose Do you vant to come o as paranoid or trust-
ing As a knov-it-all Or modest and likable
Once you decide, alvays keep those personality traits in mind
as the product is built. Lse them to guide the copyvriting, the
intertace, and the teature set. Whenever you make a change, ask
yourselt it that change tts your app`s personality.
Your product has a voice and it`s talking to your customers :
hours a day.
Pricing an 8ignup
Iree :ampies
Las Cu, Las C
:iii Pa||it, lricks are for Kios
:ofter Puiiet
+:
Free 8amples
Give sonething avay for free
It`s a noisy vorld out there. In order to get people to notice you
amid the din, give something avay tor tree.
Smart companies knov giving avay treebies is a great vay to
lure in customers. Iook at Apple. 1hey oer i1unes sottvare tor
tree in order to build demand tor the iPod and the i1unes music
store. In the oine vorld, retail outlets do the same. Starbucks
says a nev purchase is stimulated tor every tve beverage samples
they give avay to customers. Not too shabby.
lor us, Writeboard and 1a-da list are completely tree apps that
ve use to get people on the path to using our other products.
Also, ve alvays oer some sort ot tree version ot all our apps.
We vant people to experience the product, the intertace, the
usetulness ot vhat ve`ve built. Once they`re hooked, they`re
much more likely to upgrade to one ot the paying plans (vhich
allov more projects or pages and gives people access to addition-
al teatures like tle uploading and ssi data encryption,.
Pitesi:e chuuks
Make bite-size chunks: Devise specialized, smaller oerings to get
customers to bite. Pesolve to sub-divide at least one product or
service into bite-size chunks that are inexpensive, easy or tun.
-Ben McConnell an jackie Hula, auihors of Church of ihe Cusiomer Blog
( from hai is cusiomer erangelism?)
+:o
i:e ua Your Hit :iuie
Consider giving one ot your songs (per-album, as a tree promotional
dovnload to the vorld to be like the movie trailer like the hit single
sent to radio the song that makes people vant to go buy your music.
Don`t vorry about piracy tor this song. Iet people play it, copy it, share it, give
it avay. Have the contdence that it the vorld heard it, they vill pay tor more.
-Derek 8irers, presieni an programmer, CD Baly
an HosiBaly ( from Free Promo Track)
+:;
Easy On, Easy Op
Make signup and cancellation a painless process
Make it as easy as possible to get in and get out ot your app.
It I`m a customer that vants to use your app, it should be a pain-
less, no-brainer process. Provide a big, clear, signup button that
pops and put it on each page ot your marketing site. 1ell tolks
hov easy it is: lrom sign-up to login in just 1 minute'
1here should alvays be a tree option so customers can demo the
app vithout entering credit card intormation. Some ot our com-
petitors require a call back, an appointment, or a special pass-
vord in order to try their product. What`s the deal vith that
We let anyone try our apps tor tree at any time.
Keep the signup torm as short as possible. Don`t ask tor stu you
don`t need and don`t throv a long daunting torm at people.
1he same principles hold true tor the cancellation process. You
never vant to trap people inside your product. While ve`re
sorry vhen people decide to cancel their Basecamp account, ve
never make that process intimidating or contusing. Cancel my
account is a link that`s clear as day on a person`s account page.
1here shouldn`t be any email to send, special torm to tll out, or
questions to ansver.
Also, make sure people can get their data out it they decide to
leave. We make sure customers can easily export all messages
and comments in xxi tormat at any time. It`s their data and they
should be able to do vith it vhat they vant.
+::
1his is crucial because giving people control over their
intormation builds trust. You`re giving them a bridge to their
data island. You`re alloving them to leave vithout penalty
it they tnd a better oer. It`s the right thing to do and it
builds goodvill.
Lxit uith Lase
Don`t hold users against their vill. It they vant to leave, let them pick up vith
all ot the content they created vhile they vere on your site and leave...tor tree...
You have to let the barn door open and tocus on keeping your customers ted,
so they vant to come back, instead ot coming back because they`re stuck.
-Charlie O'Donnell, analysi, Cnion 8quare 1eniures
( from 1o 8ieps io a Hugely 8uccessful el 2.o Company)
+:,
8illy Rallii, Tricks are for Kis
Avoid long-tern contracts, sign-up fees, etc.
No one likes long term contracts, early termination tees, or one-
time set-up tees. So avoid them. Our products bill on a month-
to-month basis. 1here`s no contract to sign and you can cancel
at any time vithout penalty. And there are never any set-up tees.
Don`t try to tnd tricky vays to get more cash. Larn it.
+o
A 8ofier Bullei
Soften the blov of bad nevs vith advance notice and
grandfather clauses
Need to deliver bad nevs like a price increase Make it as pain-
less as possible by giving tolks plenty ot advance notice. Also,
consider a grandtather period that exempts existing custom-
ers tor a certain period ot time. 1hese tolks are your bread and
butter and you vant to make them teel valued, not gouged.
Promoiion
Hoiiuooo Lauuch
Iouerfui Iromo :ite
Pioe the Pio 1a:e
:oiicit Lari
Iromote lhrouh Loucatiou
Ieature Iooo
lrack Your Los
Iuiiue pseii
^ame Hook
+:
Hollyuoo Launch
Go fron teaser to previev to launch
It an app launches in a torest and there`s no one there to use it,
does it make a noise 1he point here is that it you launch your
app vithout any pre-hype, people aren`t going to knov about it.
1o build up buzz and anticipation, go vith a Hollyvood-style
launch: 1, 1easer, 2, Previev, and 3, Iaunch.
1easer
A tev months ahead ot time, start dropping hints. Iet people
knov vhat you`re vorking on. Post a logo. Post to your blog
about the development. Stay vague but plant the seed. Also,
get a site up vhere you can collect emails trom tolks vho
are interested.
At this stage, you should also start seducing mavens and in-
siders. 1hese are the tolks on the cutting edge. 1hey`re
the tastemakers. Appeal to their vanity and status as
ahead-ot-the-curvers. 1ell them they`re getting an exclu-
sive sneak previev. It a site like Boing Boing, Slashdot, or
Digg links up your app, you`ll get loads ot trac and tol-
lovers. Plus, your page rank at Google vill go up too.
Previev
A tev veeks ahead ot launch, start previeving teatures. Give
people behind-the-scenes access. Describe the theme ot the
product. lor Basecamp, ve posted screenshots and highlighted
reminders, milestones, and other teatures.
+
Also, tell people about the ideas and principles behind the app.
lor Backpack, ve posted our manitesto betore launch. 1his got
people thinking and talking about the app.
You can also oer some special golden tickets to a tev people
so they can start using the app early. You`ll get the benett ot
having some beta testers vhile they`ll teel that special glov that
people get trom being early adopters.
And again, encourage people to sign up so you`ve got a tounda-
tion ot emails to blitz once you launch. By the time ve launch
our apps, ve have thousands ot emails to ping vhich is a big
help in gaining traction.
Launch
It`s release time. Nov people can actually go to the theater
and see your app. Get emails out to those vho signed up.
Iaunch your tull marketing site. Spread the gospel as much as
possible. Get blogs to link to you. Post about your progress:
Hov many people have signed up What updatestveaks have
you made Shov momentum and keep at it.
+
lhe Poao to Lauuch Da
As soon as ve knev Blinksale vas really going to happen, ve
began noating some teasers to our mailing list. 1hese are people
vho have asked to receive intormation trom us about our projects.
1hese are our tans, it you vill. It you already have permission to
talk to a group ot people, they are the best place to start.
1he second thing ve did is get permission to talk to more people about
our product. About six veeks betore the Blinksale launch ve put up a
teaser page at our vebsite that proclaimed the coming ot an easier vay
to send invoices online. 1he page gave just enough intormation to build
excitement and suspense, vithout giving avay sensitive details that needed
to remain contdential. Prominently displayed on the page vas a nevsletter
subscription torm, requiring nothing but an email (keep it simple, so
that those interested could be notited vhen the product launched.
We spread the vord to a dozen or so triends and colleagues that ve
telt vould be interested in the product as vell, and they began to
spread the vord about the teaser page through their blogs and vebsites.
Within a tev days, ve had thousands on our mailing list. 1hese vere
extremely important people people vho are asking to learn more
about our product and vho vanted to knov vhen ve launched.
linally, about tvo veeks betore ve launched, ve invited a handtul ot triends,
colleagues, and industry mavens to help us beta test Blinksale. 1his alloved us
to get the product in tront ot people ve telt could benett trom its use and
vho could help us spread the vord about the product vhen ve launched.
It`s important to note that ve didn`t torce anyone to use or vrite about the
product. We simply vanted it to be seen and vanted people to talk about it
vhen it launched. In the end, it you`re going to build buzz this vay, you better
be sure your product can deliver. Othervise, it`s like clouds vithout rain.
When launch day arrived, ve sent an email to our mailing list,
notited our blogging triends, and encouraged our beta testers to
speak their minds. And to our great delight, the eort paid big
dividends. Shortly atter launch tens ot thousands had visited our
site and thousands ot those had signed up to use the product.
-josh illiams, founer, Blinksale
+
A Pouerful Promo 8iie
Build an ace pronotional site that introduces people to
your product
1he best promotional tool is a great product. Word vill get out
it you`ve got an app that people tnd really usetul.
Still, you need an ace promotional site too. What should you
include on this site Some ideas:
Overviev: Lxplain your app and its benetts.
1our: Guide people through various teatures.
Screen captures and videos: Shov people vhat the app
actually looks like and hov to use it.
Manifesto: Lxplain the philosophy and ideas behind it.
Case Studies: Provide real lite examples that shov
vhat`s possible.
Buzz: 1estimonial quotes trom customers, revievs, press, etc.
Forun: Oer a place tor members ot the community to help
one another.
Pricing & Sign-up: Get people into your app as quickly
as possible.
Weblog: Blogs keep your site tresh vith nevs, tips, etc.
+o
Rie ihe Blog are
Blogging can be nore eective than advertising (and its
a hell of a lot cheaper)
Advertising is expensive. And evaluating the eectiveness ot
various types ot advertising can vind up being even more
expensive than the advertising itselt. When you don`t have the
time or money to go the traditional advertising route, consider
the promote-via-blog route instead.
Start o by creating a blog that not only touts your product but
oers helptul advice, tips, tricks, links, etc. Our Signal vs. Noise
blog gets thousands ot unique readers a veek thanks to the
helptul, intormative, and interesting bits and anecdotes ve post
on a daily basis.
So vhen it came time to promote our trst product, Basecamp,
ve started there. We got the vord out on SvN and it started to
spread. lolks like ason Kottke, the BoingBoingers, im Coudal,
and a variety ot other people vith popular blogs helped raise the
visibility and things took o.
1a-da Iists is another great example ot the pover ot blog-based
marketing. We launched 1a-da vith a single post on Signal vs.
Noise, and a tev veeks later it had been mentioned on over :oo
blogs and over +:,ooo people had signed up tor their ovn 1a-da
account. Word about Backpack spread even taster. Within :
hours ot launch, more than than +o,ooo signed up.
+;
8olicii Early
Get advance buzz and signups going ASAP
We`ve already touched on it but it bears repeating: Get some
sort ot site up and start collecting emails as soon as possible. Pick
your domain name and put up a logo and maybe a sentence or
tvo that describes, or at least hints at, vhat your app vill do.
1hen let people give you their email address. Nov you`re on
your vay to having a toundation ot tolks ready and vaiting to
be notited ot your launch.
+:
Promoie Through Eucaiion
Share your knovledge vith the vorld
When a teacher appears as a contestant on eopardy, Alex 1rebek
otten comments that it`s a noble protession. He`s right.
1here`s detnitely something vondertul and revarding about
sharing your knovledge vith others. And vhen the subject
you`re teaching is your app, it serves a dual purpose: You can
give sonething back to the connunity that supports
you and score sone nice pronotional eposure at the
sane tine.
As a promotional technique, education is a sott vay to get your
name and your product`s name in tront ot more people. And
instead ot a hard sell buy this product approach, you`re getting
attention by providing a valuable service. 1hat creates positive
buzz that traditional marketing tactics can`t match. People vho
you educate vill become your evangelists.
Lducation can come in many torms. Post tips and tricks at your
site that people vill vant to share vith others. Speak at con-
terences and stay attervards to meet and greet vith attendees.
Conduct vorkshops so curious tans can learn more and talk to
you in the nesh. Give intervievs to publications. Write articles
that share helptul intormation. And vrite books. ,,
An example trom our ovn history is the Yellov lade 1echnique,
a method ve invented to subtly spotlight a recently changed
area on a page. We vrote a post about it on Signal vs. Noise.
1hat post made the rounds and got thousands and thousands ot
page vievs (to this day it`s doing huge trac,.
+,
1he post vorked on both an educational and a promotional
level. A lesson vas learned and a lot ot people vho never vould
have knovn about our products vere exposed to them.
Another example: During our development ot Puby on Pails,
ve decided to make the intrastructure open source. It turned
out to be a vise move. We gave something back to the com-
munity, built up goodvill, garnered recognition tor our team,
received usetul teedback, and began receiving patches and con-
tributions trom programmers all over the vorld.
1eaching is all about good karma. You`re paying it torvard.
You`re helping others. You get some healthy promotion. And
you can even bask in a bit ot nobility. So vhat do you knov that
the vorld vants to hear about
Ia It Ioruaro
1he articles and tips section ot our blog is one ot the most popular
sections ot our site. Passing on our knovledge about email marketing
ensures our customers get the most out ot our sottvare. It they can
provide a better service to their customers, then they`re likely to get more
business, vhich in turn creates more business tor us everyone vins.
lreely sharing our knovledge has also helped position us as experts in
the industry and strengthened our relationship vith existing customers.
1hey knov ve care about the quality ot their vork. linally, ve get
loads ot targeted inbound trac trom search engines and bloggers
vho share our articles vith their readers. 1hese are people that vould
never have heard ot our sottvare had ve not vritten that article.
-Dari Creiner, founer, Campaign Moniior
+o
Creatiu L:aueiists
1he more that a company shares its knovledge, the more valuable it
becomes. Companies that share their intellectual property and business
processes vith customers and partners are more likely to have their
knovledge (or products, passed along to prospective customers. People tend
to evangelize products and services they love, admire or tnd valuable.
-Ben McConnell an jackie Hula, auihors of Church of ihe Cusiomer
Blog ( from Napsierize Your Knoulege Cire To Receire)
leachiu Leaos to Iassiou
1hose vho teach stand the best chance ot getting people to
become passionate. And those vith the most passionate users
don`t need an ad campaign vhen they`ve got user evangelists
doing vhat evangelists do... talking about their passion.
-Kaihy 8ierra, auihor, Creaiing Passionaie Csers ( from You can oui-spen or oui-ieach)
++
Feaiure Foo
1heyre hungry for it so serve it up
Nev or interesting teatures are a great vay to generate buzz
tor your application. Special interest groups love to chev up
teature tood and spit it back out to the community. Alright,
that`s kind ot an unpleasant analogy but you get the point.
lor example, by using Puby on Pails, a nev development plat-
torm, ve generated a ton ot attention tor Basecamp vithin the
developer community.
1he Ajax elements ve used in our applications got lots ot buzz
and even led to Business :.o magazine naming 37signals a key
player in Ajax alongside big names like Google, Yahoo, Micro-
sott, and Amazon.
Another example: Bloggers took notice ot Basecamp`s rss
support since it vas one ot the trst business examples ot rss.
iCal integration, a seemingly minor teature, got us press on a
ton ot Mac-related sites vhich probably never vould have men-
tioned the app othervise.
Small teams have a leg up on integrating nev ideas into sott-
vare. While bigger companies have to deal vith bureaucratic
bottlenecks, you can rapidly implement nev ideas and get atten-
tion tor using them.
+:
Piding the hype coattails ot the technology du jour is an et-
tective and cheap vay to build your buzz. 1hat said, don`t go
adding the latest obscure technology just to gain some notice.
But it you are using something nev or notevorthy, go ahead
and spotlight it tor special interest groups.
+
Track Your Logs
Study your logs to track buzz
You need to knov vho`s talking about you. Check your logs
and tnd out vhere the buzz is coming trom. Who`s linking to
you Who`s bitching about you Which blogs listed at 1ech-
norati, Blogdex, leedster, Del.icio.us, and Daypop are hot on
your trail
lind out and then make your presence telt. Ieave comments
at those blogs. 1hank people tor posting links. Ask them it
they vant to be included on your special advance list so they`ll
be among the trst to knov about tuture releases, updates, etc.
Collect positive praise and create a buzz page at your site. 1es-
timonials are a great vay to promote your app since third-party
praise is more trustvorthy to most people.
It the comments are negative, still pay attention. Shov you`re
listening. Pespond to critiques thoughttully. Something like:
We appreciate the teedback but ve did it this vay because...
Or You raise a good point and ve`re vorking on it. You`ll
sotten up your critics and put a human tace on your product. It`s
amazing hov much a thoughttul comment on a blog can diuse
naysayers and even turn complainers into evangelists.
+
Inline Cpsell
Pronote upgrade opportunities inside the app
Lveryone knovs to pitch at the marketing site. But the sell
shouldn`t stop there. It you have a tiered pricing plan (or a tree
version ot your app,, don`t torget to call out upgrade opportuni-
ties trom vithin the product.
1ell tolks that you`ll remove barriers it they upgrade. lor
example, in Basecamp you can`t upload tles it you have a tree
account. When someone tries to upload a tle, ve don`t just turn
them avay. We explain vhy tle uploading isn`t available and
encourage them to upgrade to the paid version and explain vhy
that`s a good idea. 1he same approach is used to encourage ex-
isting customers to upgrade to a higher level account vhen they
max out their current plan.
Lxisting customers are your best bet tor sales. Don`t be shy about
trying to get repeat business trom people vho already knov and
use your product.
+
Name Hook
Give your app a nane thats easy to renenber
A big mistake a lot ot people make is thinking their app`s name
needs to be ultradescriptive. Don`t vorry about picking a name
that vividly describes your tool`s purpose, 1hat usually just leads
to a generic, torgettable name. Basecamp is a better name than
something like Project Management Center or ProjectLxpress.
Writeboard is better than CollaborLdit.
Also, don`t tocus group or committee-ize the naming process
too much. Pick a name that`s short, catchy, and memorable and
then run vith it.
And don`t sveat it it you can`t get the exact domain name you
vant. You can alvays be creative and get close vith a couple ot
extra letters (e.g. backpackit.com or camptrenov.com,.
Las Does It
Doesn`t the tech industry realize that thinking up catchy, selt-explanatory names
vould ultimately benett it in the same vay 1hey`d sell more ot vhatever it
vas, because they vouldn`t scare o consumers vho think they`re being kept
out ot the high-tech club by a bunch ot arrogant engineers. 1he technology
vould catch on quicker, too. 1he nev product vould be easier to describe, easier
to use and easier to buy vhich, tor the companies, means easier to sell.
-Dari Pogue, columnisi, Neu York Times ( from hai's in a Prouci Name?)
8uppori
Ieei lhe Iaiu
2ero lraiuiu
usuer uick
louh Lo:e
Iu Iiue Iorum
Iu|iici:e Your :creuups
+;
Feel The Pain
1ear dovn the valls betveen support and developnent
In the restaurant business, there`s a vorld ot dierence betveen
those vorking in the kitchen and those out tront vho deal vith
customers. It`s important tor both sides to understand and empa-
thize vith the other. 1hat`s vhy cooking schools and restaurants
vill otten have chets vork out tront as vaiters so the kitchen
sta can interact vith customers and see vhat it`s actually like
on the tront lines.
A lot ot sottvare developers have a similar split. Designers and
programmers vork in the kitchen vhile support handles the
customers. Lntortunately, that means the sottvare chets never
get to hear vhat customers are actually saying. 1hat`s problem-
atic because listening to customers is the best vay to get in tune
vith your product`s strengths and veaknesses.
1he solution Avoid building valls betveen your customers and
the developmentdesign team. Dont outsource custoner
support to a call center or third party. Do it yourselt. You,
and your vhole team, should knov vhat your customers are
saying. When your customers are annoyed, you need to knov
about it. You need to hear their complaints. You need to get
annoyed too.
+:
At 37signals, all ot our support emails are ansvered personally
by the people vho actually build the product. Why lirst o, it
provides better support tor customers. 1hey`re getting a response
straight trom the brain ot someone vho built the app. Also, it
keeps us in touch vith the people vho use our products and the
problems they`re encountering. When they`re trustrated, ve`re
trustrated. We can say, I teel your pain and actually mean it.
It can be tempting to rely on statistical analysis to reveal your
trouble spots. But stats aren`t the same as voices. You need to
eliminate as many buers as possible betveen you and the real
voices ot your customers.
1he tront lines are vhere the action is. Get up there. Have your
chets vork as vaiters. Pead customer emails, hear their trustra-
tions, listen to their suggestions and learn trom them.
Cut Cut the Miooie Mau
Almost all Campaign Monitor development, support and marketing are
pertormed by tvo people. Lven it ve`re torced to expand the team, ve`ll never
separate support trom development. By personally responding to every
request, ve torce ourselves to sit in our customers shoes and see things trom
their perspective.
It`s important to understand vhy your customer needs something, not just
vhat it is they need. 1hat context otten has a direct impact on hov ve
design something. Cut out the middle man. It`s much easier to give your
customers vhat they vant vhen your ears are that close to the ground.
I`ve discussed this setup vith loads ot people and the trst response is otten
shouldn`t you just hire a junior to handle your support Put yourselt in
your customer`s shoes. It you vant your steak cooked just hov you like it,
vould you rather talk to the bus boy or the chet that`s actually cooking it
-Dari Creiner, founer, Campaign Moniior
+,
Zero Training
Use inline help and FAQs so your product doesnt
require a nanual or training
You don`t need a manual to use Yahoo or Google or Amazon.
So vhy can`t you build a product that doesn`t require a manual
Strive to build a tool that requires zero training.
Hov do you do this Well, as ve`ve mentioned betore, you start
by keeping everything simple. 1he less complex your app is, the
less you`ll need to help people out ot the veeds. Atter that, a
great vay to preempt support is by using inline help and r:qs at
potential points ot contusion.
lor example, ve oer preemptive support on the screen that
allovs people to upload their logo to Basecamp. Some people
experienced a problem vhere they vould keep seeing an old
logo due to a brovser-caching issue. So next to the submit
your logo area, ve added a link to an r:q that instructed cus-
tomers to torce-reload their brovsers in order to see the nev
logo. Betore ve did this, ve vould get emails a day about this
problem. Nov ve get none.
+o
Ansuer Quick
Quick turnaround tine on support queries should be a
top priority
Customers light up vhen you ansver their questions quickly.
1hey`re so used to canned responses that shov up days later (it
at all, that you can really dierentiate yourselt trom competitors
by oering a thoughttul response right avay. During business
hours, ve ansver ,o ot all email support requests vithin ,o
minutes and otten vithin a halt-hour. And people love it.
Lven it you don`t have a pertect ansver, say something. You
can buy goodvill vith a response that is delivered quickly in an
open, honest vay. It someone is complaining about an issue that
can`t be txed immediately, tell them something like, We hear
vhat you`re saying and ve`ll be vorking on it in the tuture. It`s
a great vay to diuse a potentially negative situation.
Customers appreciate directness and vil l otten shitt trom
angry to polite it you respond quickly and in a straight-shoot-
ing manner.
++
u rm of Mau
Hov can a small team ot just three developers create an innovative product and
successtully compete vith the big guys 1he ansver is to enlist an army ot many.
Pemember trom your trst day that your customers are your most important
asset and that they are absolutely vital to your long-term success so treat your
community ot users like royalty. 1he vay to compete vith the big guys is by
starting small and paying attention to every one ot your customers.
It is your customers that vill be the trst to alert you ot bugs, that vill be the trst
to alert you ot needs that have not been met and it is your trst customers that
vill carry the nag and spread your message.
1his does not mean that your product has to be pertect vhen you launch.
Quite to the contrary, release early and otten. Hovever, vhen your customers
encounter bugs, make sure to send a reply to them quickly thanking them tor
their input.
Customers don`t expect your product to be pertect and they don`t expect that
all ot their teatures vill be implemented. Hovever, customers do expect that
you are listening and acknovledging that you care, so shov that you care. 1his is
one area vhere most large companies shov a huge detcit so develop a sense ot
community early.
At Blinklist, every single customer email is ansvered, usually vithin the trst
hour (unless ve happen to be asleep,. We also have an online torum and ve
make sure that every single post and comment gets acknovledged.
Lqually important, all ot our developers receive our customer teedback and they
are active participants in the online discussion torums. 1his vay, ve are slovly
but surely building an active and loyal BlinkIist community.
-Michael Reining, co-founer, Min1alley L Blinklisi
+:
Tough Lore
Be villing to say no to your custoners
When it comes to teature requests, the customer is not alvays
right. It ve added every single thing our customers requested,
no one vould vant our products.
It ve obeyed every vhim ot our customers, Basecamp vould
have: comprehensive time tracking, comprehensive billing,
comprehensive meeting scheduling, comprehensive calendaring,
comprehensive dependency task systems, comprehensive instant
message chatting, comprehensive viki tunctionality, and com-
prehensive vhatever-else-you-can-imagine.
Yet, the 1 request ve get on custoner surveys is to
keep Basecanp sinple.
Here`s another example: Despite some complaints, ve decided
not to support ir vith our products. 1hat vas ; ot the market
ve vere vriting o. But ve decided it vas more important
to vorry about the other ,. lixing bugs and testing tor ir
just isn`t vorth the time. We`d rather make a better product tor
everyone else.
As a sottvare development company, you have to act as a tlter.
Not everything everyone suggests is the right ansver. We con-
sider all requests but the customer is not alvays right. 1here vill
be times vhen you just have to piss some people o. C`est la vie.
+
Pelated to this, it`s critical that you as a development company
love your product. And you von`t love your product it it`s tlled
vith a bunch ot stu you don`t agree vith. 1hat`s yet another
justitcation tor vetoing customer requests that you don`t believe
are necessary.
+
In Fine Forum
Use foruns or chat to let custoners help each other
lorums and veb-based group chat are a great vay to let custom-
ers ask questions and help one another out. By eliminating the
middleman that`s you you provide an open stream ot com-
munication and save yourselt time in the process.
At our product torums, customers post tips and tricks, teature
requests, stories, and more. We pop in trom time to time to
oer some assistance but the torums are mainly a place tor the
community to help each other and share their experiences vith
the product.
You`ll be surprised hov much people vant to help one another.
+
Pullicize Your 8creuups
Get bad nevs out there and out of the vay
It something goes vrong, tell people. Lven it they never sav it
in the trst place.
lor example, Basecamp vas dovn once tor a tev hours in the
middle ot the night. ,, ot our customers never knev, but ve
still posted an unexpected dovntime notice to our Lverything
Basecamp blog. We thought our customers deserved to knov.
Here`s a sample ot vhat ve post vhen something goes vrong:
We apologize tor the dovntime this morning ve had some
database issues vhich caused major slovdovns and dovntimes
tor some people. We`ve txed the problem and are taking steps to
make sure this doesn`t happen again...1hanks tor your patience
and, once again, ve`re sorry tor the dovntime.
Be as open, honest, and transparent as possible. Don`t keep
secrets or hide behind spin. An intormed customer is your best
customer. Plus, you`ll realize that most ot your screvups aren`t
even that bad in the minds ot your customers. Customers are
usually happy to give you a little bit ot breathing room as long as
they knov you`re being honest vith them.
A side note about delivering nevs, bad and good: When bad
nevs comes, get it all out in the open at once. Good nevs, on
the other hand, should be trickled out slovly. It you can prolong
the good vibes, do it.
+o
Pe :uift, Direct, auo Houest
It may sound strange, but the best-case scenario is vhen the company
itselt reports the bad nevs. 1his is proactive and prevents your
company trom being put in a veakened, detensive position.
-Creg 8heruin, 1ice Presieni of Applicaiion Technology, CNET, an Emily
Arila, Principal, Calypso Communicaiions ( from A Primer for Crisis PR)
Posi-Launch
Cue Mouth luueup
Keep the Iosts Comiu
Petter, ^ot Peta
ii Pus re ^ot Createo Luai
Pioe Cut the :torm
Keep p 1ith the ]oueses
Peuare the Pioat Mouster
o 1ith lhe Iiou
+:
One Monih Tuneup
Issue a najor update days after launch
A quick update shovs momentum. It shovs you`re listening.
It shovs you`ve got more tricks up your sleeve. It gives you a
second vave ot buzz. It rearms initial good teelings. It gives
you something to talk about and others to blog about.
Knoving a quick upgrade is coming also lets you put the tocus
on the most crucial components betore launch. Instead ot trying
to squeeze in a tev more things, you can start by pertecting just
the core teature set. 1hen you can air out the product in the
real vorld. Once it`s out there you can start getting customer
teedback and you`ll knov vhich areas require attention next.
1his baby-step approach vorked vell tor Backpack. We
launched the base product trst and then, a tev veeks later,
added teatures like Backpack Mobile tor handhelds and
tagging since those things are vhat our customers told us they
vanted most.
+,
Keep ihe Posis Coming
Shov your product is alive by keeping an ongoing
product developnent blog post-launch
Don`t stop blogging once you launch. Shov your product is a
living creature by keeping a dedicated blog that you update tre-
quently (at least once a veek, more otten it you can,.
1hings to include:
l:qs
Hov-tos
1ips 8 tricks
Nev teatures, updates, 8 txes
Buzzpress
A blog not only shovs your app is alive, it makes your
company seem more human. Again, don`t be atraid to
keep the tone triendly and personal. Small teams some-
times teel like they need to sound big and ultra-protes-
sional all the time. It`s almost like a business version ot the
Napoleon Complex. Don`t sveat sounding small. Pevel
in the tact that you can talk to customers like a triend.
+oo
It`s ii:e
A trequently-updated product blog is the best indicator that a vebapp
is in active development, that it`s loved and that there`s a light on
at home. An abandoned product blog is a sign ot an abandoned
product, and says the people in charge are asleep at the vheel.
Keep the conversation going vith your users on your product blog, and
be transparent and generous vith the intormation you share. Iet your
company`s philosophies shine through. Openly link and discuss competitors.
Hint at upcoming teatures and keep comments open tor teedback.
A living product is one that`s talking and listening to its users. A
trequently-updated product blog promotes transparency, a sense ot
community and loyalty to your brand. Lxtra, tree publicity is a bonus.
As editor at Iitehacker, I scan the product blogs ot vebapps I love
continuously like Google, llickr, Yahoo, del.icio.us, and 37signals
product blogs. I`m much more likely to mention them than vebapps
that send out one-sided press releases out ot the blue and don`t
maintain an open conversation vith their users and tans.
-Cina Trapani, uel ereloper an eiior of Lifehacker,
ihe prouciiriiy an sofiuare guie
+o+
Beiier, Noi Beia
Dont use beta as a scapegoat
1hese days it teels like everything is in beta stage torever. 1hat`s
a cop out. An interminable beta stage tells customers you`re not
really committed to rolling out a tnished product. It says, Lse
this, but it it`s not pertect, it`s not our tault.
Beta passes the buck to your customers. It you`re not contdent
enough about your release then hov can you expect the public
to be Private betas are tne, public betas are bullshit. It it`s not
good enough tor public consumption don`t give it to the public
to consume.
Don`t vait tor your product to reach pertection. It`s not gonna
happen. 1ake responsibility tor vhat you`re releasing. Put it out
and call it a release. Othervise, you`re just making excuses.
Peta is Meauiuiess
Blame Google, et al, tor causing problems like this. lor
nov, users have been trained by the aggregate ot developers
to think beta doesn`t really mean anything.
-Mary Hoer, informaiion archiieci an inieraciion
esigner ( from The Deniiion of Beia)
ii the lime
Is it just me, or are ve all in beta, all the time
-jim Coual, founer, Coual Pariners
+o:
All Bugs Are Noi Creaie Equal
Prioritize your bugs (and even ignore sone of then)
ust because you discover a bug in your product, doesn`t mean
it`s time to panic. All sottvare has bugs it`s just a tact ot lite.
You don`t have to tx each bug instantly. Most bugs are annoy-
ing, not destroying. Annoyances can be tabled tor a bit. Bugs
that result in it doesn`t look right errors or other misdemeanor
miscues can sately be set aside tor a vhile. It a bug destroys your
database, though, you obviously need to tx it immediately.
Prioritize your bugs. Hov many people are aected Hov bad is
the problem Does this bug deserve immediate attention or can
it vait What can you do right nov that vill have the greatest
impact tor the greatest number ot people Otten times adding
a nev teature may even be more important to your app than
txing an existing bug.
Also, don`t create a culture ot tear surrounding bugs. Bugs
happen. Don`t constantly seek someone to blame. 1he last thing
you vant is an environment vhere bugs are shoved under the
rug instead ot openly discussed.
And remember vhat ve said earlier about the importance ot
honesty. It customers complain about a bug, be straight up vith
them. 1ell them you`ve noted the issue and are dealing vith it. It
it von`t be addressed right avay, tell vhy and explain that you`re
tocusing on areas ot the product that aect a greater number ot
people. Honesty is the best policy.
+o
Rie Oui ihe 8iorm
Wait until knee-jerk reactions to changes die
dovn before taking action
When you rock the boat, there vill be vaves. Atter you in-
troduce a nev teature, change a policy, or remove something,
knee-jerk reactions, otten negative, vill pour in.
Pesist the urge to panic or rapidly change things in response.
Passions nare in the beginning. But it you ride out this initial
:-: hour period, things vill usually settle dovn. Most people
respond betore they`ve really dug in and used vhatever you`ve
added (or gotten along vith vhat you`ve removed,. So sit back,
take it all in, and don`t make a move until some time has passed.
1hen you`ll be able to oer a more reasoned response.
Also, remember that negative reactions are almost alvays louder
and more passionate than positive ones. In tact, you may only
hear negative voices even vhen the majority ot your base is
happy about a change. Make sure you don`t toolishly backpedal
on a necessary, but controversial, decision.
+o
Keep Cp iih ihe joneses
Subscribe to nevs feeds about your conpetitors
Subscribe to nevs teeds about both your product and your com-
petitors (it`s alvays vise to knov the vays ot one`s enemy,. Lse
services like PubSub, 1echnorati, leedster, and others to stay up
to date (tor keyvords, use company names and product names,.
With rss, this constantly changing into vill be delivered right
to you so you`re alvays up to speed.
+o
Beuare ihe Bloai Monsier
More nature doesnt have to nean nore conplicated
As things progress, don`t be atraid to resist bloat. 1he tempta-
tion vill be to scale up. But it doesn`t have to be that vay. ust
because something gets older and more mature, doesn`t mean it
needs to get more complicated.
You don`t have to become an outer space pen that vrites
upside dovn. Sometimes it`s ok to just be a pencil. You don`t
need to be a sviss-army knite. You can just be a screvdriver.
You don`t need to build a diving vatch that`s sate at ,ooo
meters it your customers are land-lovers vho just vant to knov
vhat the time is.
Don`t int late just tor the sake ot int lating. 1hat`s hov apps
get bloated.
Nev doesn`t alvays mean improved. Sometimes there`s a point
vhere you should just let a product be.
1his is one ot the key benetts to building veb-based sottvare
instead ot traditional desktop based sottvare. Desktop sottvare
makers such as Adobe, Intuit, and Microsott need to sell you
nev versions every year. And since they can`t just sell you the
same version, they have to justity the expense by adding nev
teatures. 1hat`s vhere the bloat begins.
With veb-based sottvare based on the subscription model,
people pay a monthly tee to use the service. You don`t need to
keep upselling them by adding more and more and more, you
just need to provide an ongoing valuable service.
+oo
Co iih ihe Flou
Be open to nev paths and changes in direction
Part ot the beauty ot a veb app is its nuidity. You don`t vrap it
up in a box, ship it, and then vait years tor the next release. You
can tveak and change as you go along. Be open to the tact that
your original idea may not be your best one.
Iook at llickr. It began as a multiplayer online game called 1he
Game Neverending. Its creators soon realized the photo-sharing
aspect ot the game vas a more plausible product than the game
itselt (vhich vas eventually shelved,. Be villing to admit mis-
takes and change course.
Be a surter. Watch the ocean. ligure out vhere the big vaves
are breaking and adjust accordingly.
Conclusion
:tart Your Luiues
7siuais Pesources
+o:
8iari Your Engines
Done!
Alright, you made it' Hopetully you`re psyched to start Getting
Peal vith your app. 1here really has never been a better time
to make great sottvare vith minimal resources. With the right
idea, passion, time, and skill, the sky`s the limit.
A tev closing thoughts:
Lecution
Lveryone can read a book. Lveryone can come up vith an idea.
Lveryone has a cousin that`s a veb designer. Lveryone can vrite
a blog. Lveryone can hire someone to hack together some code.
1he dierence betveen you and everyone else vill be hov vell
you execute. Success is all about great execution.
lor sottvare, that means doing a lot ot things right. You can`t
just have good vriting but then tail to deliver on the promises
in your prose. Clean intertace design von`t cut it it your code is
tull ot hacks. A great app is vorthless it poor promotion means
no one ever knovs about it. 1o score big, you have to combine
all these elements.
1he key is balance. It you tilt too tar in one direction, you`re
headed tor tailure. Constantly seek out your veak links and
tocus on them until they`re up to par.
+o,
People
It`s vorth reemphasizing the one thing that ve think is the most
important ingredient vhen it comes to building a successtul veb
app: the people involved. Mantras, epicenter design, less sott-
vare, and all these other vondertul ideas von`t really matter it
you don`t have the right people on board to implement them.
You need people vho are passionate about vhat they do. People
vho care about their cratt and actually think ot it as a cratt.
People vho take pride in their vork, regardless ot the mon-
etary revard involved. People vho sveat the details even it
, ot tolks don`t knov the dierence. People vho vant to
build something great and von`t settle tor less. People vho need
people. ok, not really that last one but ve couldn`t resist throv-
ing a little Streisand into the mix. Anyhov, vhen you tnd those
people, hold onto them. In the end, the tolks on your team vill
make or break your project and your company.
More 1han )ust Softvare
It`s also vorth noting that the concept ot Getting Peal
doesn`t apply just to building a veb app. Once you start grasp-
ing the ideas involved, you`ll see them all over the place.
Some examples:
Special ops torces, like the Green Berets or Navy Seals,
use small teams and rapid deployment to accomplish tasks
that other units are too big or too slov to get done.
1he White Stripes embrace restraints by sticking to a
simple tormula: tvo people, streamlined songs, childlike
drumming, keeping studio time to a minimum, etc.
Apple`s iPod dierentiates itselt trom competitors by not
oering teatures like a built-in rx radio or a voice recorder.
Hurry up oenses in tootball pick up big chunks ot yards by
eliminating the bureaucracy ot huddles and play-calling.
+;o
Pachael Pay bases her successtul cookbooks and +v
shov on the concept ot o-minute Get Peal Meals.
Lrnest Hemingvay and Paymond Carver used simple,
clear language yet still delivered maximum impact.
Shakespeare reveled in the limitations ot sonnets,
tourteen-line lyric poems in iambic pentameter.
And on and on...
Sure, Getting Peal is about building great sottvare. But there`s
no reason vhy it needs to stop there. 1ake these ideas and try
applying them to dierent aspects ot your lite. You might just
stumble upon some neat results.
Keep In 1ouch
Iet us knov hov Getting Peal vorks out tor you. Send an
email to gettingreal37signals.com.
Also, stay up to date vith the latest oerings trom 37signals by
visiting Signal vs. Noise (vvv.37signals.comsvn,, our blog
about Getting Peal, usability, design, and a bunch ot other stu.
And tnally, there`s more into at our main site
(vvv.37signals.com, and a special area ve`ve dedicated to
Getting Peal (getreal.37signals.com,.
1hanks for reading and good luck!
+;+
3'signals Resources
37signals site
http:vvv.37signals.com
Signal vs. Noise veblog
http:vvv.37signals.comsvn
Basecanp Web-based project collaboration
http:vvv.basecamphq.com
srrci:i orrrr: Lnter 3L8CPH3SM vhen you upgrade trom a
tree to a paying plan and save x+o on your trst month.
Canphre Web-based group chat for business
http:vvv.camptrenov.com
Backpack Web-based infornation organizer
http:vvv.backpackit.com
srrci:i orrrr: Lnter MPLZ7XDK1 vhen you upgrade trom a
tree to a paying plan and save x on your trst month.
Writeboard Web-based collaborative vriting
http:vvv.vriteboard.com
1a-da List Web-based dead-sinple to-do lists
http:vvv.tadalist.com
Ruby on Rails Open-source veb application franevork
http:vvv.rubyonrails.org