Getting Real

The smarter, faster, easier way to build a successful web application, by 37signals (now Basecamp)

I just love this book. It’s a wonderful read for anyone who is currently building a web app. Each chapter is only about two pages long and full of wisdom and examples. After just one sitting, I found myself rethinking the product creation process. This is how business books should be written.

It was written years ago, but the only section where it needs updated is “Promotion”. I’ve read Rework (by the same authors), but I liked this one better. Read a few of my notes and highlights below and decide for yourself.

You can download the book for free here.

The starting line

Build less

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.

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.

Less features, less options/preferences, less promises, less people.

What’s your problem?

Build software for yourself. 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?

Fund yourself

Constraints force creativity. What can do you in three months instead of six? What can you do with two people instead of ten? What can you do with $5k instead of $100k? Run on limited resources and you’ll be forced to reckon with constraints earlier and more intensely. And that’s a good thing. Constraints drive innovation. Constraints also force you to get your idea out in the wild sooner rather than later – another good thing. A month or two out of the gates you should have a pretty good idea of whether you’re onto something or not. If you are, you’ll be self-sustainable shortly and won’t need external cash. If your idea’s a lemon, it’s time to go back to the drawing board.

Fix time and budget, flex scope

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.

This will help you prioritize, set expectations, and be more flexible.

Have an enemy

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.

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

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

Paraphrasing; once a consumer has bought a competitor’s story, it’s hard to persuade him to buy into your own. Because people hate admitting they’re wrong. Instead, you must tell a different story and persuade listeners that yours is more important than the story they currently believe. – Seth Godin

One of the quickest ways to get yourself into trouble is to look at what your competitors are doing… some people have even started to generate spreadsheets online with a detailed feature by feature comparison. However, this can quickly lead one astray. Instead, we stay focused on the big picture and keep asking ourselves, what is the key problem we are trying to solve and how can we solve it. – Michael Reining, co-founder, MindValley & Blinklist

It shouldn’t be a chore

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.

People can tell if you were passionate about building a product. It shines through.

Stay lean

Less mass

The more massive an object, the more energy is required to change its direction. When it comes to web technology, change must be easy and cheap. That’s why you need to shoot for less mass.

Mass is increased by long term contracts, excess staff, permanent decisions, thick process, physical or mental inventory, tech lock-ins, long-term roadmaps…

Mass is reduced by just-in-time thinking, multi-tasking team members, less features, less software, less code, simplicity, an open culture that makes it easy to admit mistakes…

Less mass businesses can make mistakes and fix them quickly. They can change their priorities, product mix, and focus. Most importantly, they can change their minds.

The Three Musketeers

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).

The efficiency of the team is approximately the inverse of the square of the number of members in the team. I’m beginning to think three people is optimal for a 1.0 product release. – Marc Hedlund, entrepreneur-in-residence at O’Reilly Media

Embrace constraints

There’s never enough time, money, or people to go around. That’s a good thing. Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.

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

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

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

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

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

Be yourself

Differentiate yourself from bigger companies by being personal and friendly. Smaller companies are closer to the customer by default, which means you can talk with your customers, not down to them.

Priorities

What’s the big idea

Define the one-point vision for your app. What does it stand for? What’s it really all about? Think big. Why does it exist? What makes it different than other similar products? Then, when you’re working and there’s a sticking point, you can ask, “Are we staying true to the vision?” The vision should be brief. Examples:

  • 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

If your product can accomplish your vision, everything else will fall in line. Once you make the big decision about what your vision is, all the little decisions down the line will come much easier.

Ignore details early on

Work from large to small.

Success and satisfaction is in the details. However, so are stagnation and delays. Don’t focus on details too early in the process. There’s plenty of time to be a perfectionist… later.

Details reveal themselves as you use what you’re building. You’ll see what needs more attention. That’s when you do it, not sooner.

It’s a problem when it’s a problem

Don’t waste time on problems you don’t have yet. You don’t need to worry about scaling to 100,000 users if it’ll take you two years to get there.

Hire the right customers

The customer is not always right. The truth is, you have to sort out who’s right and who’s wrong for your app.

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.

You’ll attract more customers by targeting a smaller group of people.

Scale later

“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.

Customers don’t usually care about a brief slowdown. As long as you keep people in the loop and are honest about the situation, they’ll understand.

Make building a solid core product your priority instead of obsessing over scalability.

The bigger problem isn’t scaling, it’s getting to the point where you have to scale.

Make opinionated software

When someone uses software, they’re not just looking for features, they’re looking for an approach.

If people don’t like your vision, there are plenty of other products out there.

Don’t try to be all things to all people. Have an attitude. People are either on your bus or off your bus.

Feature selection

Half, not half-assed

If you throw in every decent idea, you’ll wind up with a half-assed version of your product.

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

Basecamp started with just the messages section. They knew that was the heart of the app, so they ignored milestones, to-do lists, and other items for the time being. Then, they based future decisions on real-world usage instead of hunches.

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

It just doesn’t matter

Some common things just don’t matter. Think of adding text formatting to Facebook comments – there’d be additional processing power, UI requirements, and a learning curve. You can get the same effect with * and CAPS LOCK. Determining what doesn’t matter is where the real gains are made.

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

Start with no

The secret to building half a product instead of a half-ass product is saying no. Every time you say yes to a feature, you’re adopting a child. 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.)

The initial response for a feature request should be “not now”. If it keeps coming back, that’s when we know it’s time to take a deeper look.

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

Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying,“Does it do [x]?”,“Do you plan to add [y]?”. Finally Jobs said, “Wait wait – put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.” – Derek Sivers

Hidden costs

Even if a feature makes it past the “no” stage, you still need to expose its hidden costs. Be on the lookout for feature loops: features that lead to more features.

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. Test, tweak, test, tweak, test, tweak, test, tweak... 8. Check to see if help text needs to be modified. 9. Update the product tour (if necessary). 10. Update the marketing copy (if necessary). 11. Update the terms of service (if necessary). 12. Check to see if any promises were broken. 13. Check to see if pricing structure is affected. 14. Launch. 15. Hold breath.

Can you handle it?

Build something you can manage. It’s easy to make promises, but it’s much harder to keep them. (You might not be able to manage an entire affiliate program or give away 1 GB of space for free just because Google does too. Maybe you should look at scaled-down versions of those ideas.) Make whatever it is that you’re doing something you can actually sustain – organizationally, strategically, and financially.

Human solutions

Build software for general concepts and encourage people to create their own solutions. Don’t force conventions on people. Give people just enough to solve their own problems their own way, and then get out of the way.

When making a todo list app, they intentionally omitted the ability to assign people, categories, and due dates to tasks. They figured that people could just add [Marketing] to the front of an item to mark it as a marketing item; that people could write (Due: April 7) instead of picking something in the UI.

Do the best job you can with the root of the problem, then step aside.

Forget feature requests

How do you manage feature requests? You don’t. Just read them and throw them away. The ones that are important will keep bubbling up anyway. Those are the only ones you need to remember.

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

Hold the mayo

Ask people what they don’t want. Instead of asking customers which feature they think is missing, ask them what they don’t use, and what gets in their way the most. Sometimes the biggest favor you can do for customers is to leave something out.

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. — Steve Jobs

Process

Race to running software

Get something real up and running quickly. Real things lead to real reactions, and that’s how you get the truth.

Rinse and repeat

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

From idea to implementation

Here’s the process we use to Get Real:

  1. Brainstorm. Come up with ideas — what’s your product going to do? To post project updates; to centralize archives; to get a bird’s eye view of what’s going on with projects; etc. This stage isn’t about the details, but the big questions. What does the app need to do? How will we know when it’s useful?
  2. Paper sketches. Draw stuff out. Convert concepts into rough interface designs. This step is all about experimentation, and there are no wrong answers.
  3. Create HTML screens. Get something real posted so everyone can see what it looks like on screen. Don’t write any real code yet – just the HTML and CSS.
  4. Code it. When the mock-up looks good and demonstrates enough functionality, go ahead and plug in the programming code. Remember to stay flexible and expect multiple iterations. Feel free to throw it away and start again if it turns out crappy — it’s natural to go through this cycle multiple times.

Avoid preferences

Decide the little details so your customers don’t have to. In Basecamp, the number of messages per page is 25. Messages are sorted in reverse chronological order. The five most recent projects are shown on the dashboard. There aren’t any options. That’s just the way it is.

If you make a bad call, people will tell you. As always, you can adjust.

“Done!”

Decisions are temporary, so make the call and move on.

Test in the wild

Test your app via real-world usage. There’s no substitute for real people using your app in real ways. Get real data and feedback, and improve based on that info.

“Do it quick”

  1. Decide it it’s worth doing, and if so:
  2. Do it quick – not perfect. just do it.
  3. Save it. upload it. publish it
  4. See what people think

Though I’m always reluctant to add new features to things, once I have that “yeah!” moment of deciding something is worth doing, it’s usually up on the website a few hours later, flawed but launched, letting feedback guide future refinement of it. — Derek Sivers

Shrink your time

Estimates that stretch into weeks or months are fantasies. Keep dividing problems into smaller and smaller pieces until you’re able to digest them.

The organization

Unity

Integrate your team so there’s a healthy back-and-forth throughout each process; don’t operate in silos. Even better, hire people with multiple talents who can wear different hats during development.

Alone time

People need uninterrupted time to get things done. When you have a long stretch when you aren’t bothered, you can get in the zone.

Make half the workday alone time: no one is allowed to message, call, meet, or reply to emails immediately. It works great in the middle of the day because people need to phase into it, kind of like REM sleep. You don’t just start in the zone; you work your way there.

Meetings are toxic

Do you really need a meeting? Instead of resorting to a meeting, simply the concept so you can discuss it quickly via email.

Meetings break up your flow, cover an abysmally small amount of information per minute, have conversational drift, and are about abstract concepts, among other things.

When you do have a meeting, set a 30 minute timer. Invite as few people as possible. And never have a meeting without a clear agenda.

Seek and celebrate small victories

Release something today. The most important thing in software development is motivation. Long, drawn out release cycles are motivation killers. Quick wins that you can celebrate are great motivators.

Ask: “What can we do and release in 4 hours?” 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 don’t really need.

Staffing

Hire less and hire later

Do you really need to hire someone else? There’s no need to get big.

Kick the tires

Work with prospective employees on a test basis first. Before you hire someone, give them a small project to chew on. You’ll learn pretty quickly whether the right vibe is there.

Actions, not words

Judge potential tech hires on open source contributions. Take a look at their open source projects to see the quality of their work, how they make decisions, how many projects they’ve actually completed, and their level of passion.

Get well rounded individuals

Go for quick learning generalists over ingrained specialists. Hire designers who can write, and programmers who can design. Everyone should have good communication skills and the ability to talk with customers.

You can’t fake enthusiasm

Hire “happy and average” over “frustrated and great”. Someone who’s enthusiastic can be trusted to get things done when left alone.

Wordsmiths

Hire good writers. If you’re trying to decide between a few people to fill a position, always hire the better writer.

Being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They think clearly. Those are the qualities you need.

Interface design

Interface first

Design the interface before you start programming. Revise it as you go, asking questions like: does this make sense? Is it easy to use? Does it solve the problem at hand?

As soon as I realized my frustration with off-the-shelf invoicing software, I decided to draw out how I would prefer my invoicing solution to work. I pulled out an orange pen, because it was the only thing handy that evening, and had about 75 percent of the UI drawn out within a few hours. I showed it to my wife, Rachel, who was ironing at the time, and asked, “What do you think?” And she replied with a smile, “You need to do this. For real.”

Over the next two weeks, I refined the designs, and completely mocked up static HTML pages… We never did any wireframes beyond those orange-pen sketches… The UI design became our benchmark for the initial project scope. – Josh Williams, Blinksale

Epicenter design

When designing a page, ask: what can’t this page live without? In a blog post, the post itself is the most important thing — not the sidebar or comments or footer. Start from the most important thing, then move onto the second most important, and so on.

Don’t “build the frame then drop the content in”.

The result is a friendlier, more focused design.

Three state solution

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

  • Regular. This is what people see when everything’s working.
  • Blank. This is what people see when using the app for the first time, before they’ve entered any data.
  • Error. This is what people see when something goes wrong.

Keep reading for more on this.

The blank slate

When people use your app for the first time, they’ll be looking at a bunch of blank screens. Ignoring these screens is one of the biggest mistakes you can make. It’s your app’s first impression, and you never get a second first impression.

Designers always fill templates with data. (It’s prettier that way.) But the natural state of the app is devoid of data. Unfortunately, the customer decides if an application is worthy at this blank slate stage. When you fail to design an adequate blank slate, people don’t know what they’re missing because everything is missing.

Most designers and developers ignore this state, but that’s a huge mistake. So what should they be including?

  • Use it as an opportunity to insert quick tutorials and help blurbs
  • Give a sample screenshot of the page populated with data so people know what to expect (and why they should stick around)
  • Explain how to get started
  • Answer key questions that first-time viewers will ask: what is this page? What do I do now? What’ll this look like when it’s full?
  • Set expectations to reduce intimidation.

Another aspect of the Mac OS X UI that I think has been tremendously influenced by Steve Jobs is the setup and first-run experience. I think Jobs is keenly aware of the importance of first impressions… I think Jobs looks at the first-run experience and thinks, it may only be one-thousandth of a user’s overall experience with the machine, but it’s the most important one-thousandth, because it’s the first one-thousandth, and it sets their expectations and initial impression. — John Gruber

Get defensive

Make sure you have clear error messages, tooltips for confusing features, and so on. If customers become confused and you don’t offer a solution, they’ll categorize your app as confusing.

Context over consistency

Does every global navigation link need to be on every page? Does a calendar view always need to be in grid form? It’s okay to be inconsistent if your design makes more sense that way.

Copywriting is interface design

Great interfaces are written. Do you label a button Submit or Save or Update or New or Create? Is it Earnings: $5,000 or You've made $5,000?

Speak the same language as your audience. Think about what those buttons/labels/sentences mean to your customers. Don’t use internal lingo. Keep it short, simple, and sweet.

Icons with names, form fields with examples, buttons with labels, step-by-step instructions in a process, a clear explanation of your refund policy. These are all interface design.

One interface

If you split your application into public and private interfaces, both will suffer. Combine them and conditionally show functions on the public interface. The fewer screens you have to worry about, the better they’ll turn out.

Code

Less software

Build less complexity. Keep your code as simple as possible. Each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud.

Fight this by building less software. Less features, less code, less waste. Restate any hard problem that requires a lot of software to 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 still a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.

In other words, chop up hard problems into easy ones. We’ve found solutions to easy problems are not only easier to implement and support, they’re easier to understand and easier to use.

Less software reduces your codebase and that means less maintenance busywork (and a happier staff). It lowers your cost of changing something. It results in fewer bugs. And it leads to less support.

Don’t be afraid to say no to feature requests that are hard to do. Save time/effort/confusion by leaving out features.

Slow down too. Don’t take action on an idea for a week and see if it still seems like a great idea after the initial buzz wears off. This extra time often helps you come up with an easier solution.

Encourage programmers to make counteroffers: “The way you suggested will take 12 hours. But there’s a way I can do it that will take only 1 hour.” Let the software push back.

The “secret” to good software design wasn’t in knowing what to put into the code; it was in knowing what to leave out! It was […] knowing where to leave space rather than trying to cram in more design. – Brad Appleton

Optimize for happiness

Choose tools that keep your team excited and motivated. A happy programmer is a productive programmer. Would you be happy working in this development environment for eight hours a day?

Programming languages are not created equal. While just about any language can create any application, the right one makes the effort both pleasant and invigorating.

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

Code speaks

Listen when your code pushes back. It will offer suggestions. It will suggest new ways to do things.

If a feature requires weeks 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.

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.

If [your technical people] are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things. – Martin Fowler

Manage 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 okay to do this from time to time. It’s often needed to Get Real ASAP. But recognize it as debt, and pay it off at some point by fixing it.

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

Open doors

Add APIs and RSS feeds.

APIs let third-party developers build onto your product. Their tools can be the key factor in winning customers.

RSS feeds give customers another way to consume their data. They’re not just for blogs: Basecamp lets customers pop a URL into their newsreader to stay up-to-date on their projects.

Words

There’s nothing functional about a functional spec

Don’t write functional specifications documents. They force you to make the most important decisions when you have the least information. 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. “Wait, that’s not what I had in mind.”

These kinds of sheets lead to feature overload. There’s no cost to adding another bullet point. And then you please someone who’s a pain by adding their pet feature. And that’s how you wind up with an overloaded site that’s got 30 tabs across the top of the screen.

Instead, write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain, it’s too complex. The process shouldn’t take more than a day.

Then begin building the interface – it will be the alternative to the functional spec. Draw some quick paper sketches, and code it with HTML. Then let people use them and get feedback.

A “spec” is close to useless. I have seen lots of total crap work that was based on specs. It’s the single worst way to write software, because it by definition means that the software was written to match theory, not reality. – Linus Torvalds, creator of Linux (from Linux: Linus on Specifications)

Don’t do dead documents

Cut out as much paperwork as possible. Build, don’t write. Copious documentation and long emails don’t matter.

Take consolation in the fact that if you give your product enough room to grow itself, in the end if won’t resemble anything you wrote about anyway. – Gina Trapani, web developer and editor of Lifehacker

Use real words

Insert actual text instead of lorem ipsum. Lipsum makes you look at the shape of text instead of what it should be: valuable information someone is going to have to enter and/or read. You need real copy to see how your design looks and feels; to see how long certain fields should be; to see how tables will expand or contract. As soon as possible, use real and relevant words.

Personify your product

Think of your product as a person. What type of person do you want it to be? Polite? Strict? Serious? Paranoid? Deadpan? Once you decide, keep that in mind to guide the copywriting, interface, and feature set. Your product has a voice, and it’s talking to customers 24 hours a day.

Pricing and signup

Free samples

In order to get people to notice you, give something away for free. (You can even give an entire product away for free to get attention for related products.) Get people to experience the quality of what you’ve built. Once they’re hooked, they’re much more likely to pay you.

Make bite-size chunks: devise specialized, smaller offerings to get customers to bite. – Ben McConnell and Jackie Huba, Church of the Customer

Give away your hit single. […] Consider giving one of your songs (per-album) as a free promotional download to the world. […] Don’t worry about piracy for this song. Let people play it, copy it, share it, give it away. Have confidence that if the world heard it, they will pay for more. – Derek Sivers

Easy on, easy off

Make signup and cancellation a painless process. Provide a big, clear signup button that pops up on each page of your marketing site. Tell people how easy it is: “From sign-up to login in just 1 minute!”

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

Never trap people inside your product. Make it easy for them to cancel their subscription. Make sure people can get their data out if they decide to leave. It’s their data and they should e able to do with it what they want. Giving people control over their information builds trust. It’s the right thing to do, and it builds goodwill.

Silly rabbit, tricks are for kids

Avoid long-term contracts, sign-up fees, etc. Don’t find “tricky” ways to get more cash. Earn it.

A softer bullet

Soften the blow of bad news (for instance, a price increase) with advance notice and grandfather clauses. Consider a grandfather period that exempts existing customers for a certain period of time. Make folks feel valued, not gouged.

Promotion

Hollywood launch

Build up buzz for your product by going with a Hollywood-style launch:

  1. Teaser. A few months ahead of time, start dropping hints. Post a logo. Post to your blog about the development. Stay vague, but plant the seed. Get a site up where you can collect emails from folks who are interested. Seduce mavens and insiders – the tastemakers – by appealing to their vanity and status by getting an exclusive sneak preview.
  2. Preview. A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Post screenshots and highlight milestones and other features. Tell people about the ideas and principles behind the app; post a manifesto. Offer “golden tickets” so people can use the app early.
  3. Launch. Send out emails to your waitlist. Get blogs to link back to you. Share your updates and your tweaks. Show momentum and keep at it.

A powerful promo site

The best promotional tool is a great product. Word will get out if you’ve got an app that people find really useful. But you still need an ace promotional site that introduces people to your product. Ideas of things to add:

- Explain what your app does and how it can benefit users. - Highlight features. - Show screenshots and videos of the app. - Explain the philosophy behind it. - Provide case studies to show what's possible. - Showcase testimonials and press.

Ride the blog wave

Blogging can be more effective than advertising, and it’s a hell of a lot cheaper. Signal vs. Noise (Basecamp’s blog) gets thousnads of unique readers a week thanks to helpful, informative, and interesting bits and anecdotes we post on a daily basis.

Solicit early

Get advance buzz and signups going ASAP. 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.

Promote through education

Share your knowledge with the world. Educate others – like the people who you want as customers. Post tips and tricks on your website that people can share with others. Speak at conferences and stay afterwards to meet and greet with attendees. Conduct workshops so curious fans can learn more and talk to you in the flesh. Give interviews. Write articles that share helpful information. “And write books. ;)”

An example from Basecamp’s history is the Yellow Fade Technique, a method we invented to subtly spotlight a recently changed area on a page. We wrote a post about it on Signal vs. Noise. That post made the rounds and got thousands and thousands of page views (to this day it’s doing huge traffic).

During the development of Ruby on Rails, Basecamp made the infrastructure open source. It turned out to be a wise move and built goodwill and recognition for the team.

What do you know that the world wants to hear about?

People tend to evangelize products and services they love, admire, or find valuable. – Ben McConnell and Jackie Huba, Church of the Customer

Those who teach stand the best change of getting people to become passionate. And those with the most passionate users don’t need an ad campaign when they’ve got user evangelists doing what evangelists do… talking about their passion. – Kathy Sierra, Creating Passionate Users

Feature food

New or interesting features are a great way to generate buzz for your application. (Basecamp’s use of Ajax, RSS, and an iCal integration got them a lot of press.)

You can ride the hype of popular tech to get press. (But don’t add obscure features to your application just for that.)

Track your logs

Who’s talking about you? Who’s linking to you? Who’s bitching about you? Find out and then make your presence felt. Leave comments; thank people for posting links. Ask them if they want to be included on your special advance list. Collect positive praise and create a “buzz” page at your site. Testimonials make you appear more trustworthy.

If comments are negative, still pay attention. Show that you’re listening. Respond to critiques thoughtfully: “We appreciate the feedback but 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 on your product. It’s amazing how much a thoughtful comment on a blog can diffuse naysayers and even turn complainers into evangelists.

Inline upsell

Promote upgrade opportunities inside the app. For instance, if you offer a free plan, gray out features and add an explanation of what they’ll do if the user upgrades.

Name hook

Give your app a name that’s easy to remember. Don’t worry about picking a name that vividly describes your business’s purpose; that usually just leads to a generic and forgettable name. Basecamp is better than “Project Management Center” or “ProjectExpress”. Writeboard is better than “CollaborEdit”.

Don’t focus group of committee-ize the naming process too much. Pick something short, catchy, and memorable, and run with it.

Don’t sweat if you can’t get the exact domain name you want. You can always be creative and get close. (i.e. backpackit.com or campfirenow.com)

Support

Feel the pain

Have your whole team help with support. Don’t outsource it, and don’t put up walls between support and development and design. Listening to customers is the best way to get in tune with your product’s strengths and weaknesses.

Zero training

Use inline help and FAQs so your product doesn’t require a manual or training. Keep your product simple and add inline help 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.

Answer quick

Quick turnaround time on support queries should be a top priority. Customers light up when their questions are answered quickly; they’re used to canned responses that show up days later (if at all).

Even if you don’t have a perfect answer, say something. Deliver it 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.”

Tough love

If we added every single thing our customers requested, no one would want our products. Be willing to say no.

Basecamp gets a lot of feature requests, but the #1 request they get is to keep the app simple. Another example: despite some complaints, they wrote off 7% of the market by refusing to support Internet Explorer 5. They wanted to focus on making a better product for the other 93%, not worry about fixing bugs for a depreciated browser.

It’s critical that you love your product. You won’t love your product if it’s filled with a bunch of stuff you don’t agree with.

In fine forum

Use forums or chat to let customers help each other. Eliminate the middleman – that’s you – and let people talk amongst themselves. You’ll be surprised how much people want to help one another.

Publicize your screwups

If something goes wrong, tell people even if they wouldn’t know otherwise. Be honest, open, and transparent. Customers are happy to forgive as long as you’re being honest.

When bad news comes, get it all out in the open at once. By contrast, good news should be trickled out slowly to prolong the good vibes.

Post-launch

One month tuneup

Launch with the core product. This lets you “air it out” in the real world. You’ll start getting feedback and know which areas require attention next.

Then push an update 30 days later with the top features your customers have been requesting. This shows momentum and gives you a second wave of buzz.

Keep the posts coming

Show your product is alive by keeping an ongoing product development blog that’s updated weekly. Include FAQs, new features, updates, fixes, how-tos, buzz, press, and anything else you’d like. Don’t be afraid to keep the tone friendly and personal.

Don’t use “beta” as a scapegoat