Caveats, disclaimers, and other preemptive strikes
Just to get it out of the way, here are our responses to some complaints we hear every now and again:
"These techniques won't work for me."
Getting real is a system that's worked terrifically for us. That said, the ideas in this book won't apply to every project under the sun. If you are building a weapons system, a nuclear control plant, a banking system for millions of customers, or some other life/finance-critical system, you're going to balk at some of our laissez-faire attitude. Go ahead and take additional precautions.
And it doesn't have to be an all or nothing proposition. Even if you can't embrace Getting Real fully, there are bound to be at least a few ideas in here you can sneak past the powers that be.
"You didn't invent that idea."
We're not claiming to have invented these techniques. Many of these concepts have been around in one form or another for a long time. Don't get huffy if you read some of our advice and it reminds you of something you read about already on so and so's weblog or in some book published 20 years ago. It's definitely possible. These techniques are not at all exclusive to Basecamp. We're just telling you how we work and what's been successful for us.
"You take too much of a black and white view."
If our tone seems too know-it-allish, bear with us. 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..." Of course there will be times when these rules need to be stretched or broken. And some of these tactics may not apply to your situation. Use your judgement and imagination.
"This won't work inside my company."
Think you're too big to Get Real? Even Microsoft is Getting Real (and we doubt you're bigger than them).
Even if your company typically runs on long-term schedules with big teams, there are still ways to get real. The first step is to break up into smaller units. When there's too many people involved, nothing gets done. The leaner you are, the faster — and better — things get done.
Granted, it may take some salesmanship. Pitch your company on the Getting Real process. Show them this book. Show them the real results you can achieve in less time and with a smaller team.
Explain that Getting Real is a low-risk, low-investment way to test new concepts. See if you can split off from the mothership on a smaller project as a proof of concept. Demonstrate results.
Or, if you really want to be ballsy, go stealth. Fly under the radar and demonstrate real results. That's the approach the Start.com team has used while Getting Real at Microsoft. "I've watched the Start.com team work. They don't ask permission," says Robert Scoble, Technical Evangelist at Microsoft. "They have a boss that provides air cover. And they bite off a little bit at a time and do that and respond to feedback."
Shipping Microsoft's Start.com
In big companies, processes and meetings are the norm. Many months are spent on planning features and arguing details with the goal of everyone reaching an agreement on what is the "right" thing for the customer.
That may be the right approach for shrink-wrapped software, but with the web we have an incredible advantage. Just ship it! Let the user tell you if it's the right thing and if it's not, hey you can fix it and ship it to the web the same day if you want! There is no word stronger than the customer's — resist the urge to engage in long-winded meetings and arguments. Just ship it and prove a point.
Much easier said than done — this implies:
Months of planning are not necessary.
Months of writing specs are not necessary — specs should have the foundations nailed and details figured out and refined during the development phase. Don't try to close all open issues and nail every single detail before development starts.Ship less features, but quality features.
You don't need a big bang approach with a whole new release and bunch of features. Give the users byte-size pieces that they can digest.If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better. Ideas can sound great on paper but in practice turn out to be suboptimal. The sooner you find out about fundamental issues that are wrong with an idea, the better.
Once you iterate quickly and react on customer feedback, you will establish a customer connection. Remember the goal is to win the customer by building what they want.