When Apple releases a new product, they tend to surprise the heck out of people, even the devoted Apple-watchers who have spent the last few months riffling through garbage dumpsters at One Infinite Loop.
Microsoft, on the other hand, can't stop talking about products that are mere glimmers in someone's eye. Testers outside the company were using .NET for years before it finally shipped.
So, which is right? Should you talk endlessly about your products under development, in hopes of building buzz, or should you hold off until you've got something ready to go?
Fog Creek's default policy so far has been Absolute Radio Silence. At times, I've considered changing that policy. After all, why not open up our complete development process to the world, let everybody peek in the windows and see what's going on? There's nothing to hide!
In my personal life, I have a policy lifted from Marlon Brando, playing a mob boss in The Freshman: “Every word I say, by definition, is a promise.” The best way to avoid breaking promises is not to make any, and that's as good a reason as I need not to talk about future versions of our products. There are four other reasons for this in software development.
Competition. I'm not overly paranoid about competition, but as soon as you have competition that's paying attention to what you do, if you discuss features that haven't shipped yet, you're handing them an opportunity. If you keep your mouth shut until you ship, you will be guaranteed at least half a year without competition before everyone else matches that cool new feature.
Underpromise and overdeliver. When you tell a customer or potential customer you're going to add a feature, they will inevitably imagine that the feature will do all kinds of things that it may not actually do. When you tell someone about the upcoming clam steaming feature, no matter how careful you are to delimit what it actually does, they will inevitably spin elaborate fantasies about how it cures baldness and warts and has a telepathic user interface. When you finally deliver something, they are bound to be disappointed. This can only hurt.
Flexibility. If you want to keep your promises, you can't talk about upcoming features and release dates unless you're willing to lock into them. This may eliminate flexibility that you need later when Murphy strikes. And if you don't keep your promises, you've ruined something that's very hard to get back: your reputation.
Simplicity. If your policy is Radio Silence, every employee understands it and can follow it. If your policy is in any way complicated, nobody is sure what to do and things leak.
Doesn't advance buzz and publicity help? I don't know. A little, but not as much as nonadvance publicity. I'm inclined to think that publicity that comes out when you can't actually buy the product is 90% wasted. Remember that incredibly big burst of Segway publicity about a year ago? With Jeff Bezos and Steve Jobs talking about how “IT” was going to revolutionize the entire universe? Cities would be reconfigured. OK, so, we all talked about the Segway, but nobody could buy one, so it's not clear that it was publicity well-spent. And it certainly seems like the same amount of publicity would have helped more if it appeared when every Walmart has Segways in stock.
One purported advantage of talking about your products under development is to get early feedback. But honestly, you don't need feedback from the entire world. Look at the poor Chandler guys; they started talking about their product before any design was done and immediately got buried under such a deluge of feedback just managing it all was impossible. Now everybody thinks Chandler is going to be All Things to Everybody. Quite a lot to live up to. I've found that you can get just as good feedback from a few hundred carefully selected customers. The other 800,000 people that send you suggestions might be sending good suggestions, but you already heard them, so they aren't adding value. (By the way, Chandler did exactly the right thing, since they are an open source project. They don't care if competitors use their ideas, and at this stage it's worth sifting through everybody's crazy feature requests if that's the price of attracting more volunteers to write the code.)
A lot of times customers and potential customers come to me and say, “FogBUGZ (or CityDesk) is almost perfect for my needs. But I need a salad spinner. When are you going to have a salad spinner? Will the next release have a salad spinner?” To these people I have to say, “I don't know. We might, or we might not. If you really can't live without a salad spinner, I'm afraid you'll have to go somewhere else.” OK, maybe we lose a sale or two by refusing to indulge in the vaporware habit. I'm a patient man, and Fog Creek is profitable so I don't need the cash. Next year we'll have salad spinners, and I won't lose the sale. It's better than selling you something that doesn't fit your needs and having you get pissed off at me, or getting a reputation as being unable to deliver.
You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.
I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, which lets you organize anything, together, FogBugz, enlightened issue tracking software for bug tracking, and Kiln, which provides distributed version control and code reviews. I’m also the co-founder and CEO of Stack Exchange. More about me.