High-tech companies are in a hurry—as well they should be—but many hurt themselves by trying to move products out the door too quickly. I often hear executives repeat homilies like "Ship early, ship often," and "Launch and learn." They assume that there is no penalty for simply slapping something together, shipping it, and then upgrading their product or site in a rapid iteration cycle. Unfortunately, there is a big, hidden cost associated with this tactic.

Rapid development environments like the World Wide Web have promoted the idea of simply iterating many versions of a product or service until something works. Arguably, the Web is in its nascent stage and companies are still experimenting to see what works and what doesn't, yet this should not be an excuse for iteration without planning, nor should "speed to market."

The easy-to-change nature of the World Wide Web plays into this because a web-based advertisement or marketing campaign can be aired for a tiny fraction of the cost (and time) of print or TV advertising. The savvy Web marketer can get almost instantaneous feedback on the effectiveness of an ad, so the speed of the iteration increases dramatically. Many times, iteration takes the form of things getting hacked together overnight, often boiling down to "throw it against the wall and see what sticks." Many managers of Web start-ups use this embarrassingly simple doctrine of design-by-guesswork, writing programs all too quickly, then putting them before their users. They then listen to the complaints and feedback, measure the patterns of the user's navigation clicks, change the weak parts, and ship it again. The problem lies in the questionable nature of this feedback. After all, you can sell dirty water in the desert to rave reviews, but the same product elicits a different response in an upscale restaurant. In the case of your product, the less desperate users have probably already moved to your competitor after being dissatisfied with your first efforts, so you never hear their opinions.

In general, programmers aren't thrilled about the iterative method because it means extra work for them. Typically, it's the managers that are new to technology that like the iterative process because it relieves them of having to perform rigorous planning, thinking, and product due diligence—in other words, interaction design. Of course, it's the users who pay the dearest price.

Just because customer feedback improves your understanding of your product or service, you cannot then deduce that it is efficient, cheap, or even effective to toss random features at your customers and see which ones they like and which ones they dislike. In a playing field of novelty technologies, this can be a marginally viable strategy, but in any market in which there is the least hint of competition, it is extremely risky. Even when you are all alone in a market, it is a very wasteful method. Further, what does it do to support your brand strategy?

Many otherwise sensitive and skilled managers are unashamedly proud of this method. One mature, experienced executive asked me, in self-effacing rhetoric, "How could anyone presume to know what the users want?" This is a staggering assertion. Every business person presumes. The value that most business people bring to their market is precisely their "presumption" of what the customer wants. Yes, that presumption will miss the mark with some users, but if you don't presume at all, every user will be unhappy. This misguided executive believed that his customers didn't mind plowing through his guesses to do his design work for him. Today, in Silicon Valley, there might be lots of enthusiastic Web-surfing hardcore users who are willing to help this executive figure out his business, but how many struggling users did he alienate with his hit and miss approach? As he iterated, reacting only to those people with the stamina to return to his Web site, how many customers did he lose permanently? What did they want? It has been said that Stalin cleared a minefield by marching a regiment through it. Effective? Yes. Efficient, humanitarian, viable, desirable? No.

The biggest drawback of this process, of course, is that you frustrate your users and customers, and given the shift in the marketplace to customers who are more demanding, educated, and far less loyal, experimenting on them is not something you can afford to do.

While it's true that you can learn from trial and error, those trials should be informed by something more than random chance, and should begin from a well-thought-out design. Cutting corners during the design stage will only create busywork for your developers and test the loyalty of your customers. Your customers and your business deserve better.