Open What is Getting Real?

What is Getting Real

Want to build a successful web app? Then it's time to Get Real. Getting Real is a smaller, faster, better way to build software.

• Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
• Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).
• Getting Real is staying small and being agile.
• Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.
• Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.
• Gett

Open About 37signals

About 37signals

What we do

37signals is a small team that creates simple, focused software. Our products help you collaborate and get organized. Millions of people and small businesses use our web-apps to get things done. Jeremy Wagstaff, of the Wall Street Journal, wrote, "[37signals] products are beautifully simple, elegant and intuitive tools that make an Outlook screen look like the software equivalent of a torture chamber." Our apps never put you on the rack.

Our modus operandi

We believe software is too complex. Too many features, too many buttons, too much to learn. Our products do less than the competition — intentionally. We build products that work smarter, feel better, allow you to do things your way, and are easier to use.

Our products

Basecamp turns project management on its head. Instead of Gantt charts, fancy graphs, and stats-heavy spreadsheets, Basecamp offers message boards, to-do lists, simple scheduling, collaborative writing, and file

Open Caveats, disclaimers, and other preemptive strikes

Caveats, disclaimers, and other preemptive strikes

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

"These techniques won't work for me."

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

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

"You didn't invent that idea."

We're not claiming to have invented these techniques. Many of these concepts have been around in one form or another for a long time. Don't get huffy if you read some of our advice and it remi

Open Build Less

Build Less

Underdo your competition

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

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

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

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of one-upping, try one-downing. Instead of outdoing, try underdoing.

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

• Less features
• Less options/preferences
• Less people and corporate structure

Open What's Your Problem?

What's Your Problem?

Build software for yourself

A great way to build software is to start out by solving your own problems. You'll be the target audience and you'll know what's important and what's not. That gives you a great head start on delivering a breakout product.

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

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

So we started looking at other options. Yet every tool we found either 1) didn't do what we

Open Fund Yourself

Fund Yourself

Outside money is plan B

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

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

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

Constraints force creativity

Run on limited resources and you'll be forced to reckon with constraints earlier and more intensely. And that

Open Fix Time and Budget, Flex Scope

Fix Time and Budget, Flex Scope

Launch on time and on budget

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

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

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

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

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

Prioritization

You have to figure out what's really impor

Open Have an Enemy

Have an Enemy

Pick a fight

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

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

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

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

Whe

Open It Shouldn't be a Chore

It Shouldn't be a Chore

Your passion — or lack of — will shine through

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

If your app doesn't excite you, something's wrong. If you're only working on it in order to cash out, it will show. Likewise, if you feel passionately about your app, it will come through in the final product. People can read between the lines.

The presence of passion

In design, where meaning is often controversially subjective or painfully inscrutable, few things are more apparent and lucid than the presence of passion. This is true whether the design of a product delights you or leaves you cold; in either case it's difficult not to detect the emotional investment of the hands that built it.

Enthusiasm manifests itself readily of course, but indifference is equally indelible. If your commitment doesn't encompass a genuine passion for the work at hand, it becomes a void that is al

Open Less Mass

Less Mass

The leaner you are, the easier it is to change

The more massive an object, the more energy is required to change its direction. It's as true in the business world as it is in the physical world.

When it comes to web technology, change must be easy and cheap. If you can't change on the fly, you'll lose ground to someone who can. That's why you need to shoot for less mass.

Mass is increased by...

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

Mass is reduced by...

• Just-in-time thinking
• Multi-tasking team members
• Embracing constraints, not trying to lift them
• Less software, less code
• Less features
• Small team size
• Simplicity
• Pared-down interfaces
• Open-source products

Open Lower Your Cost of Change

Lower Your Cost of Change

Stay flexible by reducing obstacles to change

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

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

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

When it comes to web technology, change must be easy and cheap. If you can't change on the fly, you'll lose ground to someone who can. That's why you need to shoot for less mass.

Open The Three Musketeers

The Three Musketeers

Use a team of three for version 1.0

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

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

If you can't build your version one with three people, then you either need different people or need to slim down your initial ver

Open Embrace Constraints

Embrace Constraints

Let limitations guide you to creative solutions

There's never enough to go around. Not enough time. Not enough money. Not enough people.

That's a good thing.

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

When we were building Basecamp, we had plenty of limitations. We had:

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

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

That forced us to come up with creative solutions. We lowered our cost of change by always building less softw

Open Be Yourself

Be Yourself

Differentiate yourself from bigger companies by being personal and friendly

A lot of small companies make the mistake of trying to act big. It’s as if they perceive their size as a weakness that needs to be covered up. Too bad. Being small can actually be a huge advantage, especially when it comes to communication.

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

There are also advantages to internal communications at small companies too. You can ditch formalities. There’s no need for arduous processes and multiple sign-offs on everything. Everyone in the process can speak openly and hon

Open What's the Big Idea?

What's the Big Idea?

Explicitly define the one-point vision for your app

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

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

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

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

With Basecamp, for example, the vision was "Project management is communication." We felt strongly that effective communication on a project leads to collective own

Open Ignore Details Early On

Ignore Details Early On

Work from large to small

We're crazy about details.

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

Success and satisfaction are in the details.

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

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

Don't worry about the size of your headline font in week one. You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" b

Open It's a Problem When it's a Problem

It's a Problem When it's a Problem

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

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

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

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

Just Wing It

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

Don't sweat stuff until you actually must. Don't overbuild. Increase hardware and system software as necessary. If you're slow for a week or two it's not the end of the world. Just b

Open Hire the Right Customers

Hire the Right Customers

Find the core market for your application and focus solely on them

The customer is not always right. The truth is you have to sort out who's right and who's wrong for your app. The good news is that the internet makes finding the right people easier than ever.

If you try to please everyone, you won't please anyone

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

The Best Call We Ever Made

The decision to aim Campaign Monitor strictly at the web design market was the best call we ever made. It allowed us to easily identify which features would be genuinely useful and, more importantly, which features to leave out. Not only have we attracted more customers by targeting a smaller group of people, these customers all have similar needs which m

Open Scale Later

Scale Later

You don't have a scaling problem yet

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

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

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

Did we experience any problems? A few. But we also realized that most of the problems we feared, like a brief slowdown, really weren't that b

Open Make Opinionated Software

Make Opinionated Software

Your app should take sides

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

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

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

A great example is the original wiki design. Ward Cunningham and friends deliberately stripped the wiki of many features that were considered integral to document collaboration in the past. Instead of attributing each change of the document to a certain person, they removed much of the visual representation of ownership. They made the content eg

Open Half Not Half-Assed

Half Not Half-Assed

Build half a product, not a half-ass product

Beware of the "everything but the kitchen sink" approach to web app development. Throw in every decent idea that comes along and you'll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.

Stick to what's truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half. Pare features down until you're left with only the most essential ones. Then do it again.

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

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

Open It Just Doesn't Matter

It Just Doesn't Matter

Essentials only

Our favorite answer to the "why didn't you do this or why didn't you do that?" question is always: "Because it just doesn't matter." That statement embodies what makes a product great. Figuring out what matters and leaving out the rest.

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

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

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

Open Start With No

Start With No

Make features work hard to be implemented

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

Each time you say yes to a feature, you're adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature's out there, you're stuck with it. Just try to take a released feature away from customers and see how pissed off they get.

Don't be a yes-man

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

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

Open Hidden Costs

Hidden Costs

Expose the price of new features

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

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

For every new feature you need to...

• 1. Say no.
• 2. Force the feature to prove its value.
• 3. If "no" again, end here. If "yes," continue...
• 4. Sketch the screen(s)/UI.
• 5. Design the screen(s)/UI.
• 6. Code it.
• 7-15. Test, tweak, test, tweak, test, tweak, test, tweak...

Open Can You Handle It?

Can You Handle It?

Build something you can manage

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

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

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

Open Human Solutions

Human Solutions

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

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

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

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

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

Open Forget Feature Requests

Forget Feature Requests

Let your customers remind you what's important

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

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

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

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep b

Open Hold the Mayo

Hold the Mayo

Ask people what they don't want

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

What about the other side of the coin? Why not ask people what they don't want? "If you could remove one feature, what would it be?" "What don't you use?" "What gets in your way the most?"

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

Innovation Comes From Saying No

[Innovation] comes from saying no to 1,000 things to make sure we don't get on the wrong track or try to do too much. We're always thinking about new markets we could enter, but it's only by saying no that you can concentrate on the things that are really important.

—Steve Jobs, CEO, Apple (from [The Seed of Apple's Innovation](https://web.archive.org/

Open Race to Running Software

Race to Running Software

Get something real up and running quickly

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

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

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

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

The Real Thing Leads to Agreement

When a group of different people set out to try and find out what is harmonious...their opi

Open Rinse and Repeat

Rinse and Repeat

Work in iterations

Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection. Design screens, use them, analyze them, and then start over again.

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

Iterations lead to liberation

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

Maybe you're smarter than me

Maybe you're a LOT smarter than me.

It's entirely possible. In fact, it's likely. However, i

Open From Idea to Implementation

From Idea to Implementation

Go from brainstorm to sketches to HTML to coding

Here's the process we use to Get Real:

Brainstorm

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

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

Paper sketches

Sketches are quick, dirty, and cheap and that's exactly how you want to start out. Draw stuff. Scrawl stuff. Bo

Open Avoid Preferences

Avoid Preferences

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

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

Preferences are a way to avoid making tough decisions

Instead of using your expertise to choose the best path, you're leaving it in the hands of customers. It may seem like you're doing them a favor but you're just making busy work for them (and it's likely they're busy enough). For customers, preference screens with an endless amount of options are a headache, not a blessing. Customers shouldn't have to think about every nitty gritty detail — don't put that burden on them when it should be your responsibility.

Preferences are also evil because they create more software. More options require more code. And there's all the extra testing and designing you need to do too.

Open "Done!"

"Done!"

Decisions are temporary so make the call and move on

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

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

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

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

Open Test in the Wild

Test in the Wild

Test your app via real world usage

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

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

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

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

Open Shrink Your Time

Shrink Your Time

Break it down

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

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

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

Smaller Tasks and Smaller Timelines

Software developers are a special breed of optimist: when presented with a programming task, they think, "That'll be easy! Won't take much time at all."

So, give a programmer three weeks to complete a large task, and she'll spend two and a half procrastinating, and then one programming.

Open Unity

Unity

Don't split into silos

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

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

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

Open Alone Time

Alone Time

People need uninterrupted time to get things done

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

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

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

When you have a long stretch when you aren't bothered, you can get in the zone. The zone is when you are most productive. It's when you don't have to mindshift between various tasks. It's when you aren't interrupte

Open Meetings Are Toxic

Meetings Are Toxic

Don't have meetings

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

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

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

Open Seek and Celebrate Small Victories

Seek and Celebrate Small Victories

Release something today

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

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

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

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

When you fi

Open Hire Less and Hire Later

Hire Less and Hire Later

Add slow to go fast

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

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

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

If there's no other

Open Kick the Tires

Kick the Tires

Work with prospective employees on a test-basis first

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

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

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

Start small

Try a small test assignment to start. Don't leap in with all of your work at once. Give your new [virtual assistant] a test project or two to

Open Actions, Not Words

Actions, Not Words

Judge potential tech hires on open source contributions

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

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

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

• Quality of work
  Many programmers can talk the talk but trip when it comes time to walk the walk. With open source, you get the nitty gritty specifics of a person's programming skills and practices.
• Cultural perspective
  Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point, values, and ideals. Look

Open Get Well Rounded Individuals

Get Well Rounded Individuals

Go for quick learning generalists over ingrained specialists

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

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

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

Open You Can't Fake Enthusiasm

You Can't Fake Enthusiasm

Go for happy and average over frustrated and great

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

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

Extra points for asking questions

Observe whether a potential hire asks a lot of questions about your project. Passionate programmers want to understand a problem as well as possible and will quickly propose potential solutions and improvements, which leads to a lot of questions. Clarifying questions also reveal an understanding that your project could be imple

Open Wordsmiths

Wordsmiths

Hire good writers

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

That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.

An Organized Mind

Good writing skills are an indicator of an organized mind which is capable of arranging information and argument in a systematic fashion and also helping (not making) other people understand things. It spills over into code, personal communications, instant messaging (for those long-distance collaborations), and even such esoteric conce

Open Interface First

Interface First

Design the interface before you start programming

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

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

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

We start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer whe

Open Epicenter Design

Epicenter Design

Start from the core of the page and build outward

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

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

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

Epicenter design eschews the traditional "let's build th

Open Three State Solution

Three State Solution

Design for regular, blank, and error states

For each screen, you need to consider three possible states:

• Regular
  The screen people see when everything's working fine and your app is flush with data.
• Blank
  The screen people see when using the app for the first time, before data is entered.
• Error
  The screen people see when something goes wrong.

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

Open The Blank Slate

The Blank Slate

Set expectations with a thoughtful first-run experience

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

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

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

Unfortunately, the customer decides if an application is worthy at this blank slate stage — the stage when there's the least amount of information, design, and content on which to judge the overall usefulness of the

Open Get Defensive

Get Defensive

Design for when things go wrong

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

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

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

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

Open Context Over Consistency

Context Over Consistency

What makes sense here may not make sense there

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

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

Intelligent Inconsistency

Consistency is not necessary. For years, students of UI and ux have been taught that consistency in the interface is one of the cardinal rules of interface design. Perhaps that holds in software, but on the Web, it's just not true. What matters on the Web is whet

Open Copywriting is Interface Design

Copywriting is Interface Design

Every letter matters

Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you're writing your interface, always put yourself in the shoes of the person who's reading your interface. What do they need to know? How you can explain it succinctly and clearly?

Do you label a button Submit or Save or Update or New or Create? That's copywriting. Do you write three sentences or five? Do you explain with general examples or with details? Do you label content New or Updated or Recently Updated or Modified? Is it There are new messages: 5 or There are 5 new messages or is it 5 or five or messages or posts? All of this matters.

You need to speak the same language as your audience too. Just because you're writing a web app doesn't mean you can get away with technical jargon. Think about your customers and think about what those buttons and words m

Open One Interface

One Interface

Incorporate admin functions into the public interface

Admin screens — the screens used to manage preferences, people, etc. — have a tendency to look like crap. That's because the majority of development time is spent on the public-facing interface instead.

To avoid crappy-admin-screen syndrome, don't build separate screens to deal with admin functions. Instead, build these functions (i.e. edit, add, delete) into the regular application interface.

If you have to maintain two separate interfaces (i.e. one for regular folks and one for admins), both will suffer. In effect, you wind up paying the same tax twice. You're forced to repeat yourself and that means you increase the odds of getting sloppy. The fewer screens you have to worry about, the better they'll turn out.

No Separate Interface

The application is everything. Anything that can be changed, added, or adjusted can be done directly through the management area of the application. This allows us to see exactly wha

Open Less Software

Less Software

Keep your code as simple as possible

You'd think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you'll have created the dreaded Big Ball of Mud.

The way you fight this complexity is with less software. Less software means less features, less code, less waste.

The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that's alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it's worth five times the effort to solve it.

Less software means you put away the crystal ball. Instead of trying to predict fut

Open Optimize for Happiness

Optimize for Happiness

Choose tools that keep your team excited and motivated

A happy programmer is a productive programmer. That's why we optimize for happiness and you should too. Don't just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftsmanship here? Would you truly be happy working in this environment eight hours a day?

This is especially important for choosing a programming language. 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 effort not merely possible or bearable, but pleasant and invigorating. It's all about making the little details of daily work enjoyable.

Happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.

We found programming bliss in the languag

Open Code Speaks

Code Speaks

Listen when your code pushes back

Listen to your code. It will offer suggestions. It will push back. It will tell you where the pitfalls reside. It will suggest new ways to do things. It will help you stick to a model of less software.

Is a new feature requiring weeks of time and thousands of lines of code? That's your code telling you there's probably a better way. Is there a simple way to code something in one hour instead of a complicated way that will take ten hours? Again, that's your code guiding you. Listen.

Your code can guide you to fixes that are cheap and light. Pay attention when an easy path emerges. Sure, the feature that's easy to make might not be exactly the same as the feature you originally had in mind but so what? If it works well enough and gives you more time to work on something else, it's a keeper.

Listen up

Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining ab

Open Manage Debt

Manage Debt

Pay off your code and design "bills"

We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt.

Hack together some bad code that's functional but still a bit hairy and you're building up debt. Throw together a design that's good enough but not really good and you've done it again.

It's ok to do this from time to time. In fact, it's often a needed technique that helps you do the whole Get-Real-ASAP thing. But you still need to recognize it as debt and pay it off at some point by cleaning up the hairy code or redesigning that so-so page.

The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don't, you'll just be paying interest (fixing hacks) instead of paying down the principal (and moving forward).

Open Open Doors

Open Doors

Get data out into the world via RSS, APIs, etc.

Don't try to lock-in your customers. Let them get their information when they want it and how they want it. To do that, you've got to give up the idea of sealing in data. Instead, let it run wild. Give people access to their information via RSS feeds. Offer APIs that let third-party developers build on to your tool. When you do, you make life more convenient for customers and expand the possibilities of what your app can do.

People used to think of RSS feeds as merely a good way to keep track of blogs or news sites. Feeds have more power than that though. They also provide a great way for customers to stay up to date on the changing content of an app without having to log in repeatedly. With Basecamp feeds, customers can pop the URL into a newsreader and keep an eye on project messages, todo lists, and milestones without having to constantly check in at the site.

APIs let developers build add-on products for your app that can turn out

Open There’s Nothing Functional about a Functional Spec

There’s Nothing Functional about a Functional Spec

Don't write a functional specifications document

These blueprint docs usually wind up having almost nothing to do with the finished product. Here's why:

Functional specs are fantasies

They don't reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.

Functional specs are about appeasement

They're about making everyone feel involved and happy which, while warm and fuzzy, isn't all that helpful. They'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 agreement

A bunch of people agreeing on paragraphs of text isn't a true agreement. Everyone may be reading the same thing but they're thinking something different. This inevitably comes out later on: "Wait, that's not what I had in mind." "Huh? That's not how we described it.

Open Don’t Do Dead Documents

Don’t Do Dead Documents

Eliminate unnecessary paperwork

Avoiding functional specs is a good start but don't stop there; Prevent excess paperwork everywhere. Unless a document is actually going to morph into something real, don't produce it.

Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

Here's an example: If a wireframe document is destined to stop and never directly become the actual design, don't bother doing it. If the wireframe starts as a wireframe and then morphs into the actual design, go for it.

Documents that live separately from your application are worthless. They don't get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it's dead.

No One's Going to Read It

I can't even cou

Open Tell me a Quick Story

Tell me a Quick Story

Write stories, not details

If you do find yourself requiring words to explain a new feature or concept, write a brief story about it. Don't get into the technical or design details, just tell a quick story. Do it in a human way, like you would in normal conversation.

It doesn't need to be an essay. Just give the flow of what happens. And if you can include the brief story in context with screens you are developing, all the better.

Stick to the experience instead of getting hung up on the details. Think strategy, not tactics. The tactics will fall into place once you begin building that part of your app. Right now you just want to get a story going that will initiate conversation and get you on the right track.

Open Use Real Words

Use Real Words

Insert actual text instead of lorem ipsum

Lorem ipsum dolor is a trusted friend of designers. Dummy text helps people get what the design will look like once it's fleshed out. But dummy text can be dangerous too.

Lorem ipsum changes the way copy is viewed. It reduces text-based content to a visual design element — a shape of text — instead of what it should be: valuable information someone is going to have to enter and/or read. Dummy text means you won't see the inevitable variations that show up once real information is entered. It means you won't know what it's like to fill out forms on your site. Dummy text is a veil between you and reality.

You need real copy to know how long certain fields should be. You need real copy to see how tables will expand or contract. You need real copy to know what your app truly looks like.

As soon as you can, use real and relevant words. If your site or application requires data input, enter the real deal. And actually type in the text — do

Open Personify Your Product

Personify Your Product

What is your product's personality type?

Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trusting? As a know-it-all? Or modest and likable?

Once you decide, always keep those personality traits in mind as the product is built. Use them to guide the copywriting, the interface, and the feature set. Whenever you make a change, ask yourself if that change fits your app's personality.

Your product has a voice — and it's talking to your customers 24 hours a day.

Open Free Samples

Free Samples

Give something away for free

It's a noisy world out there. In order to get people to notice you amid the din, give something away for free.

Smart companies know giving away freebies is a great way to lure in customers. Look at Apple. They offer iTunes software for free in order to build demand for the iPod and the iTunes music store. In the offline world, retail outlets do the same. Starbucks says a new purchase is stimulated for every five beverage samples they give away to customers. Not too shabby.

For us, Writeboard and Ta-da List are completely free apps that we use to get people on the path to using our other products. Also, we always offer some sort of free version of all our apps.

We want people to experience the product, the interface, the usefulness of what we've built. Once they're hooked, they're much more likely to upgrade to one of the paying plans (which allow more projects or pages and gives people access to additional features like file uploading and ssl data

Open Easy on, Easy off

Easy on, Easy off

Make signup and cancellation a painless process

Make it as easy as possible to get in — and get out — of your app.

If I'm a customer that wants to use your app, it should be a painless, no-brainer process. Provide a big, clear, signup button that pops and put it on each page of your marketing site. Tell folks how easy it is: "From sign-up to login in just 1 minute!"

There should always be a free option so customers can demo the app without entering credit card information. Some of our competitors require a call back, an appointment, or a special password in order to try their product. What's the deal with that? We let anyone try our apps for free at any time.

Keep the signup form as short as possible. Don't ask for stuff you don't need and don't throw a long daunting form at people.

The same principles hold true for the cancellation process. You never want to "trap" people inside your product. While we're sorry when people decide to cancel their Basecamp account, we ne

Open Silly Rabbit, Tricks are for Kids

Silly Rabbit, Tricks are for Kids

Avoid long-term contracts, sign-up fees, etc.

No one likes long term contracts, early termination fees, or one time set-up fees. So avoid them. Our products bill on a month to-month basis. There's no contract to sign and you can cancel at any time without penalty. And there are never any set-up fees.

Don't try to find "tricky" ways to get more cash. Earn it.

Open A Softer Bullet

A Softer Bullet

Soften the blow of bad news with advance notice and grandfather clauses

Need to deliver bad news like a price increase? Make it as painless as possible by giving folks plenty of advance notice. Also, consider a grandfather period that exempts existing customers for a certain period of time. These folks are your bread and butter and you want to make them feel valued, not gouged.

Open Hollywood Launch

Hollywood Launch

Go from teaser to preview to launch

If an app launches in a forest and there's no one there to use it, does it make a noise? The point here is that if you launch your app without any pre-hype, people aren't going to know about it.

To build up buzz and anticipation, go with a Hollywood-style launch: 1) Teaser, 2) Preview, and 3) Launch.

Teaser

A few months ahead of time, start dropping hints. Let people know what you're working on. Post a logo. Post to your blog about the development. Stay vague but plant the seed. Also, get a site up where you can collect emails from folks who are interested.

At this stage, you should also start seducing mavens and insiders. These are the folks on the cutting edge. They're the tastemakers. Appeal to their vanity and status as ahead-of-the-curvers. Tell them they're getting an exclusive sneak preview. If a site like Boing Boing, Slashdot, or Digg links up your app, you'll get loads of traffic and followers. Plus, your page rank at Goo

Open A Powerful Promo Site

A Powerful Promo Site

Go from teaser to preview to launch

The best promotional tool is a great product. Word will get out if you've got an app that people find really useful.

Still, you need an ace promotional site too. What should you include on this site? Some ideas:

• Overview: Explain your app and its benefits.
• Tour: Guide people through various features.
• Screen captures and videos: Show people what the app actually looks like and how to use it.
• Manifesto: Explain the philosophy and ideas behind it.
• Case Studies: Provide real life examples that show what's possible.
• Buzz: Testimonial quotes from customers, reviews, press, etc.
• Forum: Offer a place for members of the community to help one another.
• Pricing & Sign-up: Get people into your app as quickly as possible.
• Weblog: Blogs keep your site fresh with news, tips, etc.

Open Ride the Blog Wave

Ride the Blog Wave

Blogging can be more effective than advertising (and it's a hell of a lot cheaper)

Advertising is expensive. And evaluating the effectiveness of various types of advertising can wind up being even more expensive than the advertising itself. When you don't have the time or money to go the traditional advertising route, consider the promote-via-blog route instead.

Start off by creating a blog that not only touts your product but offers helpful advice, tips, tricks, links, etc. Our Signal vs. Noise blog gets thousands of unique readers a week thanks to the helpful, informative, and interesting bits and anecdotes we post on a daily basis.

So when it came time to promote our first product, Basecamp, we started there. We got the word out on SvN and it started to spread. Folks like Jason Kottke, the BoingBoingers, Jim Coudal, and a variety of other people with popular blogs helped raise the visibility and things took off.

Ta-da List is another great example of the power of blog

Open Solicit Early

Solicit Early

Get advance buzz and signups going ASAP

We've already touched on it but it bears repeating: Get some sort of site up and start collecting emails as soon as possible. Pick your domain name and put up a logo and maybe a sentence or two that describes, or at least hints at, what your app will do. Then let people give you their email address. Now you're on your way to having a foundation of folks ready and waiting to be notified of your launch.

Open Promote Through Education

Promote Through Education

Share your knowledge with the world

When a teacher appears as a contestant on Jeopardy, Alex Trebek often comments that it's a "noble profession." He's right. There's definitely something wonderful and rewarding about sharing your knowledge with others. And when the subject you're teaching is your app, it serves a dual purpose: You can give something back to the community that supports you and score some nice promotional exposure at the same time.

As a promotional technique, education is a soft way to get your name — and your product's name — in front of more people. And instead of a hard sell "buy this product" approach, you're getting attention by providing a valuable service. That creates positive buzz that traditional marketing tactics can't match. People who you educate will become your evangelists.

Education can come in many forms. Post tips and tricks at your site that people will want to share with others. Speak at conferences and stay afterwards to meet

Open Feature Food

Feature Food

They're hungry for it so serve it up

New or interesting features are a great way to generate buzz for your application. Special interest groups love to chew up "feature food" and spit it back out to the community. Alright, that's kind of an unpleasant analogy but you get the point.

For example, by using Ruby on Rails, a new development platform, we generated a ton of attention for Basecamp within the developer community.

The Ajax elements we used in our applications got lots of buzz and even led to Business 2.0 magazine naming Basecamp a "key player in Ajax" alongside big names like Google, Yahoo, Microsoft, and Amazon.

Another example: Bloggers took notice of Basecamp's RSS support since it was one of the first business examples of RSS.

iCal integration, a seemingly minor feature, got us press on a ton of Mac-related sites which probably never would have mentioned the app otherwise.

Small teams have a leg up on integrating new ideas into software. While bigger companies

Open Track Your Logs

Track Your Logs

Study your logs to track buzz

You need to know who's talking about you. Check your logs and find out where the buzz is coming from. Who's linking to you? Who's bitching about you? Which blogs listed at Technorati, Blogdex, Feedster, Del.icio.us, and Daypop are hot on your trail?

Find out and then make your presence felt. Leave comments at those blogs. Thank people for posting links. Ask them if they want to be included on your special advance list so they'll be among the first to know about future releases, updates, etc. Collect positive praise and create a "buzz" page at your site. Testimonials are a great way to promote your app since third-party praise is more trustworthy to most people.

If the comments are negative, still pay attention. Show you're listening. Respond to critiques thoughtfully. Something like: "We appreciate the feedback but we did it this way because..." Or "You raise a good point and we're working on it." You'll soften up your critics and put a human face

Open Inline Upsell

Inline Upsell

Promote upgrade opportunities inside the app

Everyone knows to pitch at the marketing site. But the sell shouldn't stop there. If you have a tiered pricing plan (or a free version of your app), don't forget to call out upgrade opportunities from within the product.

Tell folks that you'll remove barriers if they upgrade. For example, in Basecamp you can't upload files if you have a free account. When someone tries to upload a file, we don't just turn them away. We explain why file uploading isn't available and encourage them to upgrade to the paid version and explain why that's a good idea. The same approach is used to encourage existing customers to upgrade to a higher level account when they max out their current plan.

Existing customers are your best bet for sales. Don't be shy about trying to get repeat business from people who already know and use your product.

Open Name Hook

Name Hook

Give your app a name that's easy to remember

A big mistake a lot of people make is thinking their app's name needs to be ultradescriptive. Don't worry about picking a name that vividly describes your tool's purpose; That usually just leads to a generic, forgettable name. Basecamp is a better name than something like Project Management Center or ProjectExpress. Writeboard is better than CollaborEdit.

Also, don't focus group or committee-ize the naming process too much. Pick a name that's short, catchy, and memorable and then run with it.

And don't sweat it if you can't get the exact domain name you want. You can always be creative and get close with a couple of extra letters (e.g. backpackit.com or campfirenow.com).

Easy Does It

Doesn't the tech industry realize that thinking up catchy, self-explanatory names would ultimately benefit it in the same way? They'd sell more of whatever it was, because they wouldn't scare off consumers who think they're being kept out of the h

Open Feel the Pain

Feel the Pain

Tear down the walls between support and development

In the restaurant business, there's a world of difference between those working in the kitchen and those out front who deal with customers. It's important for both sides to understand and empathize with the other. That's why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it's actually like on the front lines.

A lot of software developers have a similar split. Designers and programmers work in the "kitchen" while support handles the customers. Unfortunately, that means the software chefs never get to hear what customers are actually saying. That's problematic because listening to customers is the best way to get in tune with your product's strengths and weaknesses.

The solution? Avoid building walls between your customers and the development/design team. Don't outsource customer support to a call center or third party. Do it yourse

Open Zero Training

Zero Training

Use inline help and FAQs so your product doesn't require a manual or training

You don't need a manual to use Yahoo or Google or Amazon. So why can't you build a product that doesn't require a manual? Strive to build a tool that requires zero training.

How do you do this? Well, as we've mentioned before, you start by keeping everything simple. The less complex your app is, the less you'll need to help people out of the weeds. After that, a great way to preempt support is by using inline help and FAQs at potential points of confusion.

For example, we offer preemptive support on the screen that allows people to upload their logo to Basecamp. Some people experienced a problem where they would keep seeing an old logo due to a browser-caching issue. So next to the "submit your logo" area, we added a link to an FAQ that instructed customers to force-reload their browsers in order to see the new logo. Before we did this, we would get 5 emails a day about this problem. Now we get none.

Open Answer Quick

Answer Quick

Quick turnaround time on support queries should be a top priority

Customers light up when you answer their questions quickly. They're so used to canned responses that show up days later (if at all) that you can really differentiate yourself from competitors by offering a thoughtful response right away. During business hours, we answer 90% of all email support requests within 90 minutes — and often within a half-hour. And people love it.

Even if you don't have a perfect answer, say something. You can buy goodwill with a response that is delivered quickly in an open, honest way. If someone is complaining about an issue that can't be fixed immediately, tell them something like, "We hear what you're saying and we'll be working on it in the future." It's a great way to diffuse a potentially negative situation.

Customers appreciate directness and will often shift from angry to polite if you respond quickly and in a straight-shooting manner.

An Army of Many

How can a small t

Open Tough Love

Tough Love

Be willing to say no to your customers

When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one would want our products.

If we obeyed every whim of our customers, Basecamp would have: comprehensive time tracking, comprehensive billing, comprehensive meeting scheduling, comprehensive calendaring, comprehensive dependency task systems, comprehensive instant message chatting, comprehensive wiki functionality, and comprehensive whatever-else-you-can-imagine.

Yet, the #1 request we get on customer surveys is to keep Basecamp simple.

Here's another example: Despite some complaints, we decided not to support ie5 with our products. That was 7% of the market we were writing off. But we decided it was more important to worry about the other 93%. Fixing bugs and testing for ie5 just isn't worth the time. We'd rather make a better product for everyone else.

As a software development company, you have to act as

Open In Fine Forum

In Fine Forum

Use forums or chat to let customers help each other

Forums and web-based group chat are a great way to let customers ask questions and help one another out. By eliminating the middleman — that's you — you provide an open stream of communication and save yourself time in the process.

At our product forums, customers post tips and tricks, feature requests, stories, and more. We pop in from time to time to offer some assistance but the forums are mainly a place for the community to help each other and share their experiences with the product.

You'll be surprised how much people want to help one another.

Open Publicize Your Screwups

Publicize Your Screwups

Get bad news out there and out of the way

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

For example, Basecamp was down once for a few hours in the middle of the night. 99% of our customers never knew, but we still posted an "unexpected downtime" notice to our Everything Basecamp blog. We thought our customers deserved to know.

Here's a sample of what we post when something goes wrong: "We apologize for the downtime this morning — we had some database issues which caused major slowdowns and downtimes for some people. We've fixed the problem and are taking steps to make sure this doesn't happen again...Thanks for your patience and, once again, we're sorry for the downtime."

Be as open, honest, and transparent as possible. Don't keep secrets or hide behind spin. An informed customer is your best customer. Plus, you'll realize that most of your screwups aren't even that bad in the minds of your customers. Customers are usually happy

Open One Month Tuneup

One Month Tuneup

Issue a major update 30 days after launch

A quick update shows momentum. It shows you're listening. It shows you've got more tricks up your sleeve. It gives you a second wave of buzz. It reaffirms initial good feelings. It gives you something to talk about and others to blog about.

Knowing a quick upgrade is coming also lets you put the focus on the most crucial components before launch. Instead of trying to squeeze in a few more things, you can start by perfecting just the core feature set. Then you can "air out" the product in the real world. Once it's out there you can start getting customer feedback and you'll know which areas require attention next.

This baby-step approach worked well for Backpack. We launched the base product first and then, a few weeks later, added features like Backpack Mobile for handhelds and tagging since those things are what our customers told us they wanted most.

Open Keep the Posts Coming

Keep the Posts Coming

Show your product is alive by keeping an ongoing product development blog post-launch

Don't stop blogging once you launch. Show your product is a living creature by keeping a dedicated blog that you update frequently (at least once a week, more often if you can).

Things to include:

• FAQ
• How-tos
• Tips & tricks
• New features, updates, & fixes
• Buzz/press

A blog not only shows your app is alive, it makes your company seem more human. Again, don't be afraid to keep the tone friendly and personal. Small teams sometimes feel like they need to sound big and ultra-professional all the time. It's almost like a business version of the Napoleon Complex. Don't sweat sounding small. Revel in the fact that you can talk to customers like a friend.

It's Alive

A frequently-updated product blog is the best indicator that a webapp is in active development, that it's loved and that there's a light on at home. An abandoned product blog is a sign of an aband

Open Better, Not Beta

Better, Not Beta

Don't use "beta" as a scapegoat

These days it feels like everything is in beta stage forever. That's a cop out. An interminable beta stage tells customers you're not really committed to rolling out a finished product. It says, "Use this, but if it's not perfect, it's not our fault."

Beta passes the buck to your customers. If you're not confident enough about your release then how can you expect the public to be? Private betas are fine, public betas are bullshit. If it's not good enough for public consumption don't give it to the public to consume.

Don't wait for your product to reach perfection. It's not gonna happen. Take responsibility for what you're releasing. Put it out and call it a release. Otherwise, you're just making excuses.

Beta is Meaningless

Blame Google, et al, for causing problems like this. For now, users have been trained by the aggregate of developers to think "beta" doesn't really mean anything.

—Mary Hodder, information architect and intera

Open All Bugs Are Not Created Equal

All Bugs Are Not Created Equal

Prioritize your bugs (and even ignore some of them)

Just because you discover a bug in your product, doesn't mean it's time to panic. All software has bugs — it's just a fact of life.

You don't have to fix each bug instantly. Most bugs are annoying, not destroying. Annoyances can be tabled for a bit. Bugs that result in "it doesn't look right" errors or other misdemeanor miscues can safely be set aside for a while. If a bug destroys your database, though, you obviously need to fix it immediately.

Prioritize your bugs. How many people are affected? How bad is the problem? Does this bug deserve immediate attention or can it wait? What can you do right now that will have the greatest impact for the greatest number of people? Often times adding a new feature may even be more important to your app than fixing an existing bug.

Also, don't create a culture of fear surrounding bugs. Bugs happen. Don't constantly seek someone to blame. The last thing you want is an en

Open Ride Out the Storm

Ride Out the Storm

Wait until knee-jerk reactions to changes die down before taking action

When you rock the boat, there will be waves. After you introduce a new feature, change a policy, or remove something, knee-jerk reactions, often negative, will pour in.

Resist the urge to panic or rapidly change things in response. Passions flare in the beginning. But if you ride out this initial 24-48 hour period, things will usually settle down. Most people respond before they've really dug in and used whatever you've added (or gotten along with what you've removed). So sit back, take it all in, and don't make a move until some time has passed. Then you'll be able to offer a more reasoned response.

Also, remember that negative reactions are almost always louder and more passionate than positive ones. In fact, you may only hear negative voices even when the majority of your base is happy about a change. Make sure you don't foolishly backpedal on a necessary, but controversial, decision.

Open Keep Up With the Jones

Keep Up With the Joneses

Subscribe to news feeds about your competitors

Subscribe to news feeds about both your product and your competitors (it's always wise to know the ways of one's enemy). Use services like PubSub, Technorati, Feedster, and others to stay up to date (for keywords, use company names and product names). With RSS, this constantly changing info will be delivered right to you so you're always up to speed.

Open Beware the Bloat Monster

Beware the Bloat Monster

More mature doesn't have to mean more complicated

As things progress, don't be afraid to resist bloat. The temptation will be to scale up. But it doesn't have to be that way. Just 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 writes upside down. Sometimes it's ok to just be a pencil. You don't need to be a swiss-army knife. You can just be a screwdriver. You don't need to build a diving watch that's safe at 5,000 meters if your customers are land-lovers who just want to know what the time is.

Don't inflate just for the sake of inflating. That's how apps get bloated.

New doesn't always mean improved. Sometimes there's a point where you should just let a product be.

This is one of the key benefits to building web-based software instead of traditional desktop based software. Desktop software makers such as Adobe, Intuit, and Microsoft need to sell you new versions every

Open Go With the Flow

Go With the Flow

Be open to new paths and changes in direction

Part of the beauty of a web app is its fluidity. You don't wrap it up in a box, ship it, and then wait years for the next release. You can tweak and change as you go along. Be open to the fact that your original idea may not be your best one.

Look at Flickr. It began as a multiplayer online game called The Game Neverending. Its creators soon realized the photo-sharing aspect of the game was a more plausible product than the game itself (which was eventually shelved). Be willing to admit mistakes and change course.

Be a surfer. Watch the ocean. Figure out where the big waves are breaking and adjust accordingly.

Open Start Your Engines

Start Your Engines

Done!

Alright, you made it! Hopefully you're psyched to start Getting Real with your app. There really has never been a better time to make great software with minimal resources. With the right idea, passion, time, and skill, the sky's the limit.

A few closing thoughts:

Execution

Everyone can read a book. Everyone can come up with an idea. Everyone has a cousin that's a web designer. Everyone can write a blog. Everyone can hire someone to hack together some code.

The difference between you and everyone else will be how well you execute. Success is all about great execution.

For software, that means doing a lot of things right. You can't just have good writing but then fail to deliver on the promises in your prose. Clean interface design won't cut it if your code is full of hacks. A great app is worthless if poor promotion means no one ever knows about it. To score big, you have to combine all these elements.

The key is balance. If you tilt too far in one dire