Notes from Getting Real by Basecamp

Search IconIcon to open search

Don’t build a company that follows competitors. If they add 10 features, you don’t need to add 20. Don’t be defensive and paranoid.

What’s your problem. ==Great software solves your own problems, is born out of necessity and you care about it.==

Outside money is Plan B. Investors slow down the process. Besides you don’t need money anyways. Money constrains also force creativity and innovation. Which is a good thing.

Fix time and budget. If you can’t deliver, lower the scope. This helps you prioritise what really matters. If you fix all 3, what you deliver will have low levels of quality.

==It’s better to make half a product than a half-assed product==

Have a competitor and sell a different story. Don’t sell the story of faster performance when your enemy is doing the same, sell the story of a cheaper price. But generally, never sell the story of a cheaper price. ==Never compete on price.== That’s a race to the bottom.

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.

Flexibility (ie ability to quickly change and adapt) is key to building web businesses. If you cannot adapt quickly, you’ll be replaced by someone else who can. So, the less mass you’ve the better.

Mass is increased by…

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

Mass is reduced by…

  • Just-in-time thinking
  • Multi-tasking team members
  • Embracing constraints, not trying to lift them
  • Less software, less code
  • Less features
  • Small team size
  • Simplicity
  • Pared-down interfaces
  • Open-source products
  • Open data formats
  • An open culture that makes it easy to admit mistakes

Lower your cost of change. The more expensive it is to make a change, the less likely you’ll make it. And if your competitors can change faster than you, you’re at a huge disadvantage. ==If change gets too expensive, you’re dead==.

Being small isn’t a weakness. It’s a power. Don’t act big. Small companies are closer to customers by default. They’ve less bureaucracy. Less formalities.

What’s the big idea behind your product? ==Before you start building figure out your product’s purpose and how it’s different from what’s out there.== It should be brief and should help you take decisions.

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.

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

On Selecting Features

Start with “No” to every feature idea. For every new feature you need to…

  1. Say no.
  2. Force the feature to prove its value.
  3. If “no” again, end here. If “yes,” continue…
  4. Sketch the screen(s)/ui.
  5. Design the screen(s)/ui.
  6. Code it.
  7. – 15. Test, tweak, test, tweak, test, tweak, test, tweak…
  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.

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

==Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.== ~ Derek Siver

Ask your customers what they don’t want. If you could/have to remove one feature, what’d it be? What gets in your way the most?

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

On Processes

Get something real up and running quickly. It builds up momentum, and flushes out unimportant ideas. This should be your number one priority from day one. Skip details, take shortcuts but just get there. Because once you do you’ll get a much better perspective on how to proceed. Real things cause agreement in teams that may disagree while planning the prototype.

Basecamp’s process from idea to implementation

  1. Come up with ideas. What is this product going to do? … This stage is not about nitty gritty details. This is about big questions. ==What does the app need to do? How will we know when it’s useful? What exactly are we going to make?== This is about high level ideas, not pixel-level discussions. At this stage, those kinds of details just aren’t meaningful.
  2. Draw paper sketches. Nothing gets more cheaper or faster. Just get the idea from your head onto a paper.
  3. Create HTML screens. No hard coding required. Just use HTML and CSS build out interfaces and make something that looks real.
  4. Code it out. Stay flexible and expect iterations.

You can throw deliverables from away any steps anytime and start again. Expect this to happen.

Don’t let customers choose. It’s your job. Your decisions are always undo-able.

Embrace “I don’t know." Don’t cook up things to sound smart. No one can now the exact answer to an unknowable question.

Set up a rule. No meeting people for half the day. People are most productive when they’re alone. Creatives need to have alone time to get work done. Schedule all meetings and messages for the end of the day.

Do 4hr quick wins to have a reason to celebrate every week. This could be things like working on a little documentation that reduces support burden a little.

On Hiring

Take a test drive before hiring. Make them work on a project and see how they work, communicate, act. Better the resumes and other proof of work.

Prefer Generalists over Specialists for small teams. Small teams need people who can wear a lot of hats. You can’t afford a specialist who has a very narrowly defined skillset.

Hire happy and average over frustrated and great. No one can fake enthusiasm. Hiring people who interested in solving the problem. Who asks a lot of questions and gives you ideas.

If you are trying to decide between a few people to fill a position, always hire the better writer.

On Designing Interfaces

Epicentre first, extras second. ==Design the most important element of a page first.== Then go to the second most imp and so on. Don’t start designing a blog post page with the nav bar.

Design for the regular, blank and error state.

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 onethousandth==, because it’s the first one-thousandth, and it sets their expectations and initial impression.

John Gruber , author and web developer (from  Interview with John Gruber

Context over Consistency. It’s ok to be inconsistent if your design makes more sense that way. Give people just what matters. ==Give them what they need when they need it and get rid of what they don’t. It’s better to be right than to be consistent==

Build less software: Less features, less code, less waste. More code leads to exponentially more complexities.

Don’t do dead docs. It gets in the way. It disturbs the flow. Nobody reads it.

Don’t use Lorem Ipsum. Dummy texts don’t give a good idea. Use real words. What your customers will see in there.

Choose your product’s personality. And stick with it everywhere. 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?

Always have some part of your product available for free. To get attention in this world. To make people experience before they buy it.

What to have on your promo site for the product? 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.

Keep track of who’s talking about you. Who’s linking to you, who’s bitching about you. Give them early access. VIP invites. Get feedback.

Promote your plans inside the app. Don’t restrict promotion of your plans to your marketing site. Add prompts to your app everywhere there’s a limit.

Customers are not always right. Feel free to say NO to feedbacks. If you say yes to everything your customer demands, they’ll find it too complex to use anyways. They don’t know what they want.

Publicise your screwups. However small they maybe. Be honest with your customers. An informed customer is the best customer.

Do a big update 30 days after launch. It shows you’re here to stay, that you’ve more tricks up your sleeve. And it keeps the excitement up.

Keep a product blog up and running with tips, how-tos, FAQs, news and updates. It shows your product isn’t abandoned.

Public betas are an excuse. They’re like saying “it’s not ready, so if it doesn’t work don’t blame us.” But that’s not right, just don’t release it until it’s ready for the public. And then don’t wait for perfection, call it a release and solve bugs that come.

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.

When you’ll release a new change, the negative voices will be louder than the positive ones. But that doesn’t mean your change is bad. Stay calm and wait.

Resist bloat. As your software matures, don’t make it bloated or unnecessarily complicated.

Interactive Graph