Getting Real

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. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of outdoing, try underdoing.

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, with one person instead of 10, with $5k instead of $100k? Constraints drive innovation and force you to launch sooner. 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

To launch on time and budget, keep them fixed. Only scale back the scope. This will help you prioritize and set expectations.

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.

Having an enemy creates a 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.

One of the quickest ways to get yourself into trouble is to look at what your competitors are doing [...] 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, 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

Make decisions that keep your app easy to change.

Embrace constraints

Constraints are often advantages in disguise. Instead of freaking out about your constraints, embrace them. Let them guide you. Constraints drive innovation and force focus.

We dealt with many constraints 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.

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? Use this to make decisions. 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.

You can also define maxims to help you make decisions; for instance, err in favor of your users. (When writing billing code, it'd be better to cancel a charge entirely than to bill someone twice.)

Ignore details early on

Work from large to small. Don't focus on details too early in the process. There's plenty of time to be a perfectionist... later.

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.

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.

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 – you can get the same effect with * and CAPS LOCK. Determining what doesn't matter is where the real productivity gains are made.

Start with no

The secret to building a great 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.

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.

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

Be on the lookout for features that lead to more features.

Can you handle it?

Build something you can manage. 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 let people create their own solutions.

When making a todo list app, we intentionally omitted the ability to assign people, categories, and due dates to tasks. We 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.

Forget feature requests

Don't manage feature requests. Just read them and throw them away. The ones that are important will keep bubbling up.

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

Don't expect to get your app right the first time. Let it morph and evolve. 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? This stage isn't about the details, but the big questions. How will you know when you have something 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 backend code yet – just HTML and CSS.
4. Code it. When the mock-up looks good and demonstrates enough functionality, go ahead and build the thing. 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. Don't provide options. 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.

"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

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

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.

When you do have a meeting, make it as small as possible. Set a timer. Write a clear agenda.

Seek and celebrate small victories

Increase morale by releasing something today. Quick wins that you can celebrate are great motivators.

Staffing

Hire less and hire later

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

Kick the tires

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. This helps you measure their passion and quality of work.

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

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?

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.

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. 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. Here are some tips to fix this:

• 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

Your design doesn't always need to be consistent. Think about the context for which a customer is using a page.

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.

One interface

Don't split your application into public and private interfaces. 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

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.

Build less features. If a problem requires a lot of code, solve 80% of it for 20% of the effort. The original problem is almost never so bad that it's worth five times the effort to solve it.

Solutions to easy problems are not only easier to implement and support, they're easier to understand and use.

Don't be afraid to say no to feature requests that are hard to do.

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! – Brad Appleton

Optimize for happiness

Choose tools that keep your team excited and motivated. A happy programmer is a productive programmer.

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.

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, but you need to fix it at some point. Regularly put aside some time to pay off your code and design debt.

Open doors

Add APIs, RSS feeds, etc. Let third-party developers build onto your product. Their tools can be the key factor in winning customers.

Words

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.

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 easy. Tell people they can register in less than a minute. Keep the signup form short. And give them access to their data if they want to leave.

A softer bullet

Soften the blow of bad news (for instance, a price increase) with advance notice and grandfather clauses. 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

Your promotional site needs to be great. 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 thousands of unique readers a week thanks to helpful, informative, and interesting bits and anecdotes we post on a daily basis.

Solicit early

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

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

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. – Kathy Sierra, Creating Passionate Users

Track your logs

Who's talking about you? 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." 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. Basecamp is better than "Project Management Center".

Support

Feel the pain

Have your whole team help with support. 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.

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.

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.

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 immediately. Even if they wouldn't know otherwise. Be honest, open, and transparent. Customers are happy to forgive as long as you're being honest. 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.

Better, not beta

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." If it's not good enough, don't release it yet. If it is, put it out and call it a release.

All bugs are not created equal

You don't need to solve each bug immediately. Prioritize them on how serious they actually are.

Ride out the storm

After you make a big change, negative feedback will pour in. Resist the urge to panic or rapidly change things in response. Passions flare in the beginning. Things usually die down if you ride out this 48 hour period. Don't make a move until some time has passed.

Remember that negative reactions are almost always louder and more passionate than positive ones. You may only hear negative voices when the majority of your base is happy about a change.

Don't backpedal on necessary but controversial decisions.

Keep up with the Joneses

Subscribe to your competitors' newsfeeds.

Beware the bloat monster

You don't need to keep adding new stuff. Sometimes there's a point where you should just let a product be. Just provide an ongoing valuable service.

Go with the flow

Be open to the fact that your original idea may not be your best one. Flickr was originally a video game, but its creators realized the photo-sharing aspect of the game was a more plausible product than the game itself. Be open to changing course.

Conclusion

Success is all about great execution. You need to do a lot of things right: good design, good code, good copywriting, and more. 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. And, if you're going to work with people, make sure they're passionate and do good work.

---

All in all, this was a wonderful book packed with simple, actionable advice. My favorite takeaways were:

• Let the software push back. Instead of forcing a programming framework to work how you want it to, follow its natural structure.
• Make opinionated software. Don't try to appeal to everybody. Take a stance. Make decisions for your customers. If people don't like it, they don't need to use it.
• Initially, focus only on the essentials. For the first version of your product, solve the essentials of the problem. Release an awesome "half product" instead of a "half-assed product".
• 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.
• Don't ignore the onboarding process. What do your dashboards look like after the customer signs up? You only get one chance to make a first impression.
• Leave things out. Sometimes the biggest favor you can do for customers is leave things out. Just because x number of people request something, doesn’t mean you have to include it.
• Do less than your competitors. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of outdoing, try underdoing.
• Some common things just don’t matter. Think of adding text formatting to Facebook comments – you can get the same effect with * and CAPS LOCK.
• Err in favor of users. Define maxims such as this to help you navigate complex engineering decisions.
• Build less software. Solving 80% of the original problem for 20% of the effort is still a win.
• Don't split public and private interfaces. The fewer screens you need to worry about, the better they'll turn out. (And the easier they are for customers to understand.)

If you're interested in reading it yourself, Basecamp offers the book for free here. I'd definitely recommend it if you want to build a product.