Getting Real by 37 Signals

My Thoughts

One of my favorite books. So action packed, relevant and appliacable. I have read it 3 times now. And will probably re-read it again in the future.

If you want to create your own business this is a must read. It doesn’t matter if you can code or not. This books will be useful for any type of person.

The coolest thing is that it is still mega applicable even with all the recent advances in AI.

Problems with summarizing this book

I read all my books in Readwise Reader. So, my reading flow involves reading the full text, and taking highlights to remember the things that stood out the most to me. Then, go over those highlight and write a summary. Recently I have been integrating AI into this flow by helping me sinthesize my highlights into a summary, in different ways.

I’ll write a separate post about this in detail. The reason I metnion this here is that that flow is nearly impossible for this book. Getting Real is so dense that it is hard to compress further. I heard DHH mention somewhere that in writing this book they have thrown out a lot, and it shows!

Learnings

Build less than your competitors - solve simple problems well rather than tackling complex ones
Solve problems you personally experience - this ensures genuine passion and understanding
Self-fund if possible - constraints drive innovation and force faster market validation
Fix time and budget, but keep scope flexible - better to make half a product than a half-assed product
Focus on a core target market - don’t try to please everyone
Make opinionated software with a clear vision - take a stance and stick to it
Say no to most feature requests - only build what’s absolutely essential
Launch quickly and iterate based on real feedback - don’t wait for perfection
Keep your code and features simple - complexity grows exponentially with each addition
Design the interface first - it’s cheaper to change design than code
Write good copy - every word in your interface matters and is part of the design
Skip long functional specifications - they rarely match the final product
Give something away for free to attract customers
Make signup and cancellation processes painless - avoid contracts and tricks
Build buzz through blogs and preview releases rather than expensive advertising
Let customers help each other through forums and community features
Be transparent about problems and quick to communicate issues
Keep showing progress after launch through regular updates and blog posts
Don’t hide behind “beta” labels - commit to quality from day one
Prioritize bugs - not all issues need immediate fixing
Stay lean as you grow - resist feature bloat and unnecessary complexity
Focus on execution - ideas are common, but great execution is rare
Maintain a balance between design, code, promotion, and support - weakness in any area can sink the product

’How to Read a Book’ Analysis

Key Sentences

The best designers and the best programmers aren’t the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter.

This sentence encapsulates the book’s core philosophy that success comes from strategic elimination rather than addition. It proposes that the key skill in software development is the ability to identify and focus only on what’s truly essential.

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.

This sentence explains the fundamental reason behind the book’s “less is more” approach. It proposes that complexity in software grows exponentially, not linearly, making simplicity not just desirable but necessary for success.

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

This concluding statement reveals the book’s ultimate proposition: that success in software development isn’t about having unique ideas or perfect plans, but about superior execution of the fundamentals.

Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else.

This sentence presents the book’s contrarian strategy for market success. It proposes that focusing on simple, well-executed solutions is more valuable than tackling complex problems, challenging the common assumption that more complex equals better.

Unity of the Book

The fundamental unity of “Getting Real” is: Build successful web applications by embracing constraints, staying lean, and focusing on execution over planning - which means building less software, making opinionated choices, launching quickly, and iterating based on real-world feedback rather than getting bogged down in specifications, features, and perfection.

This central theme unifies all the book’s advice about funding, features, design, coding, promotion, and support - it’s all about stripping away the unnecessary to focus on what truly matters for shipping and succeeding with web applications in the real world.

Author’s Problems

Main Problem

How can small teams build successful web applications in a world dominated by large companies and complex software?

Supporting Problems

How can small teams compete effectively against larger, better-resourced competitors? This is foundational as it shapes the entire approach to development and business strategy
How can developers determine what features and functionality are truly essential? This problem must be solved to achieve the lean, focused approach the book advocates
How can teams maintain speed and agility while building quality software? This addresses the practical execution challenges once the strategic direction is set
How can small teams effectively launch and market their products without big budgets? This problem deals with getting traction once the product is built
How can teams maintain and grow their product without falling into the complexity trap? This addresses the long-term sustainability of the approach
How can teams make decisions quickly and confidently without extensive research and planning? This underlies the ability to execute on all other aspects

The order is significant because each problem builds on the previous ones:

First, you need to understand how to compete (1)
Then you need to know what to build (2)
Then how to build it effectively (3)
Then how to get it to market (4)
Then how to maintain and grow it (5)
Throughout, you need to make good decisions quickly (6)

Book’s Structure

Overview of Major Parts

Foundation (The Starting Line, Stay Lean) establishes core philosophy of constraints and simplicity. It also sets up the mindset needed for the approach.
Strategic Decision Making (Priorities, Feature Selection) builds on foundation by showing how to make choices. It also provides framework for deciding what matters.
Execution (Process, Interface Design, Code) shows how to implement the strategic decisions and provides practical application of the core principles
Market Engagement (Promotion, Support, Post-Launch) demonstrates how to take the product to market and how to maintain the approach long-term

How Parts Work Together

The structure follows a natural progression from mindset → decisions → execution → market engagement. Each section builds upon the previous:

The foundation sections establish WHY you should embrace constraints and simplicity
The strategic sections show WHAT to focus on given those constraints
The execution sections detail HOW to build within these parameters
The market sections explain how to SUSTAIN this approach

Prompt Ideas

Product Development & Decision Making

“I’m considering adding [feature] to my app. Using the principles from ‘Getting Real’, analyze if this feature is truly essential by considering: (1) How many users will benefit (2) Hidden costs of implementation (3) Maintenance burden (4) Alternative simpler solutions”
“Help me strip down this complex feature idea into its simplest possible implementation that solves 80% of the problem with 20% of the effort. Current idea: [describe feature]”
“Review my product’s current feature set and identify potential areas of bloat using 37 Signals’ principles. Here are my features: [list features]”

Interface & Copy Writing

“Rewrite this technical error message to be more human and match my product’s personality, which is [describe personality]. Error message: [paste message]”
“Review these three interface states for my [feature/screen]: Regular state, Blank state, and Error state. Suggest improvements based on defensive design principles: [describe states]”
“Help me write clear, human interface copy for these UI elements following 37 Signals’ principles: [list UI elements needing copy]”

Marketing & Promotion

“Create a Hollywood-style launch plan (Teaser → Preview → Launch) for my new [product], including specific content ideas for each phase”
“Generate ideas for blog posts that would be valuable to my target audience while subtly promoting my [product], following 37 Signals’ blog promotion strategy”
“Help me craft a product manifesto that explains the philosophy and ideas behind my [product], similar to how 37 Signals did with Backpack”

Project Management

“Analyze this feature request using the ‘It’s a Problem When It’s a Problem’ principle. Help me decide if we should implement it now or wait: [describe feature request]”
“Help me create a ‘scope down’ version of this project that maintains its core value but can be shipped faster: [describe project]”
“Review these user complaints about [feature/change] and help me determine if they’re knee-jerk reactions I should wait out or legitimate issues needing immediate attention”

Support & Communication

“Help me write a transparent and honest announcement about this recent service issue, following 37 Signals’ principles of crisis communication: [describe issue]”
“Create a template for saying ‘no’ to feature requests in a way that’s firm but respectful, explaining our product vision and philosophy”
“Help me write a blog post for our one-month tuneup announcement that shows momentum and addresses user feedback: [list recent changes/updates]”

Product Strategy

“Analyze my competitor’s product and help me identify opportunities to ‘solve the simple problems’ they’re leaving behind while pursuing complexity: [describe competitor’s product]”
“Help me define my product’s personality and voice using 37 Signals’ principles. Here’s my product description: [describe product]”
“Review my product’s current pricing and signup process for friction points and suggest improvements based on 37 Signals’ ‘Easy On, Easy Off’ principle”

Development Process

“Help me evaluate if this bug needs immediate attention or can wait, using 37 Signals’ bug prioritization framework. Bug details: [describe bug]”
“Create a checklist of questions to ask before adding any new feature, based on 37 Signals’ feature selection principles”

General Business Strategy

“Help me identify ways to create free tools or features that could lead users to my main product, similar to how 37 Signals used Writeboard and Ta-da List”
“Analyze my current product and suggest ways to reduce its ‘mass’ to make it more adaptable to change: [describe current product state]”
“Help me craft a strategy for staying lean while scaling my product’s success, focusing on simplicity over feature expansion”

Highlights

Introduction

Chapter 3: Caveats, disclaimers, and other preemptive strikes

We think it’s better to present ideas in bold strokes than to be wishy-washy about it. If that comes off as cocky or arrogant, so be it. We’d rather be provocative than water everything down with “it depends…”

The Starting Line

Chapter 4: Build Less

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.

Chapter 5: What’s Your Problem?

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

Chapter 6: Fund Yourself

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.

Chapter 7: Fix Time and Budget, Flex Scope

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.

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

Chapter 8: Have an Enemy

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.

Stay Lean

Chapter 10: Less Mass

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.

Chapter 11: Lower Your Cost of Change

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.

Chapter 14: Be Yourself

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.

Note: Similar to how Derek Sivers notified users of the shipped order

Priorities

Chapter 15: What’s the Big Idea?

Organizations need guideposts. They need an outline; employees need to know each day when they wake up why they’re going to work.

Chapter 16: Ignore Details Early On

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.

There’s plenty of time to be a perfectionist. Just do it later.

Note: And later and later and later…

Chapter 17: It’s a Problem When It’s a Problem

Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention on the things that require immediate care.

Chapter 18: 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

Chapter 19: Scale Later

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

Chapter 20: Make Opinionated Software

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.

Note: To the point of people saying all the products are taken, what’s the point of trying. Just build something that exists but with a different vision

Feature Selection

Chapter 21: Half, Not Half-Assed

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.

Chapter 22: It Just Doesn’t Matter

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

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

Chapter 24: Hidden Costs

For every new feature you need to…

1. Say no.
1. Force the feature to prove its value.
1. If “no” again, end here. If “yes,” continue…
1. Sketch the screen(s)/UI.
1. Design the screen(s)/UI.
1. Code it.
7-15. Test, tweak, test, tweak, test, tweak, test, tweak…
1. Check to see if help text needs to be modified.
1. Update the product tour (if necessary).
1. Update the marketing copy (if necessary).
1. Update the terms of service (if necessary).
1. Check to see if any promises were broken.
1. Check to see if pricing structure is affected.
1. Launch.
1. Hold breath.

Chapter 26: 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.

Note: I feel like this goes against the have a vision #### chapter, a bit.

Though I still like this point

Chapter 27: Forget Feature Requests

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

Note: Feature requests

Chapter 28: Hold the Mayo

Why not ask people what they don’t want? “If you could remove one feature, what would it be?” “What don’t you use?” “What gets in your way the most?”

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

Process

Chapter 30: Rinse and Repeat

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.

Chapter 32: Avoid Preferences

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

Preferences are a way to avoid making tough decisions

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.

Chapter 33: “Done!”

Decisions are temporary so make the call and move on

The Organization

Chapter 39: Seek and Celebrate Small Victories

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.

Staffing

Chapter 42: Actions, Not Words

Judge potential tech hires on open source contributions

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

Interface Design

Chapter 46: Interface 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.

Note: I would generally disagree, I feel like design is a waste of time. This is because this is my least favorite part.

Now with recent AI developments this is even further from the truth.

Chapter 48: 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.

Chapter 49: 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.

Chapter 50: Get Defensive

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.

Chapter 52: 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?

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 mean to them. Don’t use acronyms or words that most people don’t understand. Don’t use internal lingo. Don’t sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more.

Good writing is good design. It’s a rare exception where words don’t accompany design. 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.

Chapter 53: 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.

Code

Chapter 54: 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 is easier to manage.
Less software reduces your codebase and that means
less maintenance busywork (and a happier staff).
Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code.
Less software results in fewer bugs.
Less software means less support.

Encourage programmers to make counteroffers. You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.

Chapter 58: 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.

Words

Chapter 59: 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.

Note: I feel like this is similar to designing a web page first before coding.

Spec can help you think through the implementation before writing any code.

It’s like “I don’t think and write, I wrote to think”.

Though argument in this #### chapter are convincing. It depends on how you approach a spec and what you use it for.

Chapter 62: Use Real Words

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.

Chapter 63: 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.

Chapter 64: 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 encryption).

Chapter 65: 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.

Chapter 66: 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.

Chapter 67: 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.

Promotion

Chapter 68: 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 Google will go up too.

Preview

A few weeks ahead of launch, start previewing features. Give people behind- the-scenes access. Describe the theme of the product. For Basecamp, we posted screenshots and highlighted reminders, milestones, and other features.

Also, tell people about the ideas and principles behind the app. For Backpack, we posted our manifesto before launch. This got people thinking and talking about the app.

You can also offer some special “golden tickets” to a few people so they can start using the app early. You’ll get the benefit of having some beta testers while they’ll feel that special glow that people get from being early adopters.

And again, encourage people to sign up so you’ve got a foundation of emails to blitz once you launch. By the time we launch our apps, we have thousands of emails to ping which is a big help in gaining traction.

Launch

It’s release time. Now people can actually go to the “theater” and see your app. Get emails out to those who signed up. Launch your full marketing site. Spread the gospel as much as possible. Get blogs to link to you. Post about your progress: How many people have signed up? What updates/tweaks have you made? Show momentum and keep at it.

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.

Chapter 70: 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-based marketing. We launched Ta-da with a single post on Signal vs. Noise, and a few weeks later it had been mentioned on over 200 blogs and over 12,000 people had signed up for their own Ta-da account. Word about Backpack spread even faster. Within 24 hours of launch, more than 10,000 signed up.

Chapter 73: 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 have to deal with bureaucratic bottlenecks, you can rapidly implement new ideas and get attention for using them.

Riding the hype coattails of the technology du jour is an effective and cheap way to build your buzz. That said, don’t go adding the latest obscure technology just to gain some notice. But if you are using something new or noteworthy, go ahead and spotlight it for special interest groups.

Chapter 74: 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.

Support

Chapter 80: 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.

Chapter 81: 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.

Chapter 82: 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.

Post-Launch

Chapter 83: 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.

Chapter 84: 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.

Chapter 85: 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.”

Chapter 86: 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.

Chapter 87: 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.

Chapter 88: 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.

Chapter 89: 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.

Chapter 90: 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.

Conclusion

Chapter 91: Start Your Engines

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 direction, you’re headed for failure. Constantly seek out your weak links and focus on them until they’re up to par.