We talk to a lot of technology companies here at Cooper, and over the years we've seen some clear patterns emerge. On the positive side, more and more companies are realizing the importance of a good user experience and of the overall usability of their products. Unfortunately, we also continue to see companies falling into the same product development traps, to the detriment of their products, their customers, and their business.
These traps can be hard to spot, because they often appear to be standard business practices (especially when the company has never done it any other way), but when you take a step back you see that those practices really don't make much sense. If you have the nagging feeling that there's something not quite right with your product development initiative, it may be because you're falling into one of these traps. To help you recognize bad practices and work to avoid them, here are three common development pitfalls.
(Note that in this article, "product" refers to anything that uses a microprocessor—from handheld computers, service-oriented Web sites, and desktop computer applications to microwave ovens, digital cameras, and library kiosks.)
Trap 1: Start With Technology
Many of the companies we meet believe that their hot new technology is the key to their success, and therefore want to build their product and company around it. We often have to ask the questions, "Why would someone want to buy this? What problem does it solve?"
While a useful technology that is truly unique and breakthrough is of great value, in reality such technologies are rare. The overwhelming majority of these companies merely possess a technology that is proprietary and already built. Basing a product on technology that is proprietary and already built can be much riskier than having to create new technology for a product. There are two reasons for this.
First, "proprietary" just means that the company owns the technology. Any other company can provide the same benefits that this company can, it just has to use different technology to do it. Doing the same thing someone else does with different technology doesn't necessarily provide any real value to customers or provide differentiation in the marketplace.
Second, a technology that has been built before a good product design is in place can impose severe limitations on the overall quality and value of the ultimate product. Instead of engineering technology to support a viable solution, the design of the solution is forced to work around the idiosyncrasies of a particular technology. In other words, if you start with technology, technology will drive the product. If you start by devising a solution to a worthy problem, the solution will drive the product. Given that your customers are in the market for a solution, not raw technology, it makes sense to begin from the solution.
The payoff for this change in philosophy is simple: It's easy to sell the value of a product that genuinely and obviously fills a person's needs or provides them enjoyment. It's much more difficult to justify the purchase of a technology product that has hot, proprietary technology, but unclear benefits.
Trap 2: Be First To Market
Conventional wisdom—if such a phrase can be applied to the software industry—asserts that being first to market is critical. In fact, many of the biggest successes in the technology industry have been just the opposite.
The Apple Newton was one of the first handheld computers of it's type, but it flopped, and the market for handheld computers languished until the Palm Pilot hit the scene as a stunning success, a full four years later. The Pilot didn't succeed because it was first to market—it succeeded because it was a compelling product that met the needs of the people for whom it was designed (business professionals), was easy to use, and fit in your pocket.
Many successful software franchises also arrived on the scene late. Adobe Photoshop wasn't the first photo editing software to market. Intuit's Quicken wasn't the first financial planning software to market. Microsoft Word wasn't the first word processor to market. And yet, each of these are huge successes, dominant in their respective markets.
On the other hand, the most recent poster children for First-to-Market Failure were the dotcoms. "First to market!" was their rallying cry, but it was also their siren song. They proudly proclaimed that they were a new breed of fast companies that built products in "Web time," only to go down in flames in a spectacular fashion two years later.
Part of the problem with being first to market lies in the price that companies pay to be first. They shortcut the planning process, impose irrational deadlines on their developers, and prioritize speed over quality. The company then ships the product it is able to build with the little time and minimal planning it gave itself, rather than the best product it is capable of building.
Most companies tend to be in denial on this issue. They often blame product failure on uncertain markets, bad timing, or a host of other reasons. While there are many contributing factors to an unsuccessful product, when was the last time you heard an executive simply say, "We rushed this thing to market and it just wasn't very good"?
The alternative is to build a high-quality product that provides real value to your customers, while accepting the possibility that it may hit the market after other competing products have been released. It may take a little longer to build, but you'll have the competitive advantage of having a superior product. If someone beats you to market with a weak product, use this to your advantage. If you can prove you have the better product, the market will stop caring who was first.
Trap 3: Have the Most Features
You've undoubtedly heard the expression "less is more." Though you wouldn't guess it from most of the products on the shelves today, this dictum is especially true for software.
Several years ago, we redesigned the software application for a consumer sheet-fed scanner. The original application had a great many features, on par with those of its competitors. A key component of our solution involved removing roughly 70% of the features from the program entirely, then ensuring that the remaining features—which our research indicated were the features users actually needed and used—were as good as possible.
When we first showed the design to our client, they were very nervous. They felt that this lack of features would disappoint their customers, and that the application would seem less powerful. Like many technology companies, they had been conditioned to equate features with power—the more features you have, the more power you get. The client agreed to let us proceed with the design on the condition that a paper prototype of the design would be usability tested for verification once the design was complete.
When testing day arrived, the client was surprised to find that the test users all thought the new design was in fact more powerful than both the original version of the client's product and their competitors' products. Our client was pleased and relieved, and went on to build and release the product to rave reviews.
The test users believed the new design was more powerful because the features of the original and competing products, though greater in number, were hard to find and inconvenient to use by comparison. Making a smaller set of key features easy to find and a pleasure to use made less into more.
Avoiding the Traps
If you suspect your development team (or your company) has fallen into one or more of these traps, the first step is to work to shift your colleagues away from the thinking that led you into trouble in the first place. Convince them that focusing on the needs of your customers is more important than maintaining technical or marketing agendas. If you're able to do that, the next step is to point your group toward the solution. Fortunately, the fix is the same no matter which trap you may have fallen into: Build a high-quality product that will truly satisfy your customers. Customer satisfaction and loyalty trumps hot technology, novelty, and feature lists every time.