"Necessity is the mother of taking chances."
-Mark Twain

Occasionally I encounter a motorist on the highway who is driving very slowly, some 20 miles per hour slower than the flow of traffic. This driver undoubtedly believes himself to be driving in a reasonable manner, equating his slow speed with safety. Unfortunately, he fails to recognize the greater risk of a much faster car plowing into him from behind. His slow speed has made his car into a barrier rather than part of the traffic flow, and yet he cruises on, oblivious to the squealing tires and honking horns directly behind him.

Is this really a safe practice? Not on the highways in Silicon Valley.

Likewise, many companies speak of innovation in their brochures, only to engage in what they consider to be low-risk business practices when developing a new product. Instead of innovating, they build a product very similar to their competitors', only marginally better or cheaper, perhaps with a few more features. There's a sense of comfort at many companies in this middle of the pack mentality. It seems safe — certainly safer than sticking your neck out and doing something different.

But is this really a safe practice? Not for companies in the software business.

The Larger Risk

Consider the risks of "playing it safe." If a competitor comes out of nowhere with a truly superior product, one that leapfrogs all of the other products in its space, including yours, you're instantly put in the position of playing catch-up on someone else's field, on their schedule. They're leading. You're following. You've lost control.

Meanwhile, your sales are likely to suffer while you're trying to catch up. After all, if your competitor's product is demonstrably better, it's going to be more difficult to sell your existing product to customers who can tell the difference. In some cases, you may be forced to cut your margins and compete based on price alone. Obviously, decreased sales and lower margins means taking in less revenue, which is hardly a low-risk proposition.

Compounding the problem, you also have a new, unplanned expense on your hands. Playing catch-up means increasing your development expenses unexpectedly, and usually by a lot, since you can count on paying at least double for any initiative conducted in crisis mode. This probably means getting approval from the "C-level" to fund the additional unbudgeted expenses, which will splatter red ink all over the monthly variance reports. This can be embarrassing, and tends to make the CFO and shareholders very testy.

Yet, given these high risks of playing it safe, many companies still try to rationalize their "blend with the crowd" approach. Here are a few arguments I've heard.

Mom's Favorite Argument

Last fall, I met with the Usability Manager from a leading eCommerce site. He argued against making their online purchase process more convenient for their customers, opting instead to require a lengthy registration process before allowing a sale. When pressed, his rationale boiled down to a simple observation: Everyone else was doing it, so it couldn't be all that bad.

Your mother knew that argument was weak when you tried it in grade school, typically firing back the time-honored counter-argument, "If all your friends jumped off a bridge, would you jump too?" It didn't wash in grade school, and it certainly doesn't wash now that the health of your business is at stake.

It's important to remember that the software industry is in its infancy. There are a lot of mistakes being made by software companies at all levels. The fact that many other companies are doing a particular thing doesn't mean that it's smart, right, or profitable. The dot-com implosion alone proved this point in a rather dramatic fashion.

Clearly, emulating the mistakes of others is not going to bring you success. Instead, do what you believe to be right based on an understanding of your customers, your capabilities, and your company.

The Copycat Fear

Several years ago we presented a product design to an executive of a business equipment company known for its long history of innovation. This executive challenged the "risky" strategy of making substantial improvements to their product with this question: "This design would certainly make our product stand out from the competition, but why should we build it? The other manufacturers will just copy it for their next releases anyway."

While it is true that other companies might have duplicated this company's successful product, this executive—apart from failing to respect his own company's innovative heritage—failed to understand three important points:

First, if you're making a product worth copying, you've given your marketing department a huge advantage. Your product will stand out from the crowd and your customers will have a clear, compelling reason to buy it rather than one from the other guys.

Second, if your competitors are copying your products, it means you're one step ahead of them. You're the leader, which gives you a level of control that industry followers will never enjoy. Your competitors can copy your product, but they can't copy the philosophy and process that led to your leadership in the first place. Not only does this look good in your marketing materials, it means that you don't waste time and energy playing catch-up. Instead, you can focus on the Next Big Thing.

Finally, the best way to beat out your competitors is to win before the race starts. Really good, innovative, useful products tend to inspire brand loyalty. I know people who wouldn't consider getting any car other than a BMW because of their high level of satisfaction with their current model. I see the same loyalty from users of Apple computers. Tellingly, neither BMW nor Apple commands this loyalty by copying products from other manufacturers.

What's the Difference?

A representative from a consumer PC peripheral manufacturer once asked me, "Why should we make our software better than the other manufacturer's software? If our software is no worse than theirs, who will know the difference?"

To me, this is the same as asking, "Why get out of bed in the morning?" or "Why bother doing anything of significance?"

Software companies should care about their products. They should strive for the highest quality possible at their price point. They should approach their products like a craftsperson who desires to build something truly exceptional, with meticulous attention to detail. They should sell products worthy of their customers' hard-earned money. But this isn't just about the deep personal satisfaction of doing the right thing—it's about good business practice.

In his book The Circle of Innovation, Tom Peters offers his favorite quote on this subject, from management consultant James Morse, who says, "The only sustainable competitive advantage comes from out-innovating the competition." Steve Jobs of Apple also knows this. "Victory in our industry is spelled survival," says Jobs. "The way we're going to survive is to innovate our way out of this."

Jobs should know. His company's colorful iMac computer sold over 6 million units, and inspired a staggering number of industries to sheath their products—including clothes irons and kitchen grills—in translucent Bondi Blue plastic. Equally important, Apple now has $4 billion dollars in the bank to help cope with the current recession, and, in the words of Time Magazine, "millions of fanatically loyal users who will give up their Macs only when you pry their one-button mice from their cold, dead fingers."

But Jobs doesn't see this kind of risk-taking innovation as a luxury to be enjoyed during boom markets. Rather than play it safe in a recessionary market, Jobs unveiled the successor to the original iMac recently, an innovative new design with a flat screen attached to an articulated swing arm. Of this risky endeavor, analyst Tim Bajarin stated simply, "Apple has another hit on its hands."

Take Risks. Please.

There's no denying that innovation can be risky, but not innovating can be even riskier. Resting on your laurels can cost you market leadership, financial security, and the loyalty of your customers. When the people who may buy your product are faced with a difficult—and expensive—choice, standing out from the competition is simply good business. As Will Rogers said, "Even if you're on the right track, you'll get run over if you just sit there."

References
Peters, Thomas J. and LeBaron, Dean. 1997. The Circle of Innovation: You Can't Shrink Your Way to Greatness. Knopf.

What do you think? Join the conversation in Comments

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.

This same principle applies to other products. Remember the early days of the Video Cassette Recorder? Every VCR manufacturer was expanding the capabilities of their machines to be more and more powerful. Imagine how easily a manufacturer could have surpassed the competition if they ignored the features race and simply marketed a unit that people could actually set, with a clock that would remember the time when the unit was unplugged. In terms of user satisfaction, a genuinely useful product will beat an awkward product with more features every time.

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.

What do you think? Join the conversation in Comments

I must admit I'm not terribly impressed by the quality of today's software—my benchmark for good product design isn't defined by the output of Microsoft, Apple, Adobe, or other respected software companies. Those companies produce some good work, of course, but the software industry, though no longer in its infancy, still seems to be working through its gawky adolescent stage. So, when I think about high quality products, I think of BMW automobiles, Eames furniture, and the Fender Stratocaster guitar.

The Fender Stratocaster is no less than one of the most popular, recognizable, influential, and best-selling electric guitars ever made. The Stratocaster was introduced in 1954 and has thrived fundamentally unchanged throughout 47 years of production, becoming the favored instrument of millions of guitarists including Eric Clapton, Jimi Hendrix, Mark Knopfler, David Gilmour, and Stevie Ray Vaughan. The Stratocaster—along with another revolutionary guitar, the Gibson Les Paul—stands head and shoulders above any other solid body electric guitar made. Ever. It is a model of good product design.

Today's Fender Strat (above) looks, works, and sounds the same as the original model introduced in 1954 (below).

In 1953, Leo Fender—the founder and visionary of the Fender Electric Instrument Company—began working on the next step in the evolution of the solid body electric guitar. Leo worked with Fender employees Freddie Tavares and George Fullerton, as well as musicians Bill Carson, Rex Gallion, and others to understand needs and check assumptions during the design process. Leo's goals were to build the best solid body electric guitar ever and to expand the Fender product line to increase sales.

One key to the Stratocaster's success was that the design took into account the needs and desires of professional guitarists. Not being a musician himself, Leo relied upon input from guitar players to guide the design of the instrument. As a result, it fulfilled the musicians' goals of playability, comfort, and good sound, while being easy to repair and/or customize. Benefits and features of the 1954 Fender Stratocaster included:

• An ergonomic design with forearm and tummy bevels and better overall balance that made the guitar more comfortable to play
• A "drop-in" pickguard and pickup assembly that made the Stratocaster substantially easier to mass produce, repair, and customize
• A bolt-on neck that was less expensive to manufacture (the necks of one-piece guitars sometimes warped during production and the whole instrument would need to be discarded) and easier to service
• The ability to produce new sounds not possible with other instruments, which in part inspired new musical genres like Surf and Hendrixian-style psychedelia
  

In addition to these benefits, early Stratocasters looked modern and cool, and came in all kinds of funky colors that no other company was using. All the other solid body guitars of the day—including Fender's own Telecaster model—had natural wood or "sunburst" finishes (one notable exception being the Les Paul "goldtop"). By contrast, Fender, taking a cue from the automobile industry, used automotive paints in lively solid colors such as Daphne Blue, Surf Green, and Fiesta Red.

In many ways, the Stratocaster was also an early example of a platform, spawning an entire industry of replacement and custom parts manufacturers. Today, there is no single component of the Stratocaster for which you can't find a custom replacement, from multiple vendors. For example, guitarists looking for a new set of pickups to personalize their instrument can choose from broad product lines offered by manufacturers such as DiMarzio, Seymour Duncan, Lindy Fralin, Joe Barden, EMG, and even Fender itself.

Interestingly, the Stratocaster was also unique for what it wasn't:

• First to market. The well-known Fender Broadcaster/Telecaster (1950) and the Gibson Les Paul (1952) guitars were introduced earlier, but even they weren't first to market. They were preceded by the Ro-Pat-In (later known as Rickenbacker) A22 and A25 guitars in 1932, as well as the more contemporary looking Bigsby/Travis guitar in 1947. Only hardcore guitar geeks have even heard of the Ro-Pat-In and Bigsby/Travis guitars. Being first to market made them a footnote in history, but it didn't make them successful. The Stratocaster wasn't first to market, but it was arguably best to market.
  
• Designed to match the feature list of competitors' guitars. Fender's competition touted the carved tops, glued-in necks, and ornate fretboard inlays of their guitars, which were selling quite well. The safe, easy route would have been to build a comparable guitar with similar features.
  
• Planned to be obsolete. On the contrary, Leo Fender said, "…I was always able to see the defects in the design of an instrument which overlooked completely the need of its maintenance. If something is easy to repair, it is easy to construct. The design of each element should be thought out in order to be easy to make and easy to repair."
  

Today, a vintage 1954 Stratocaster in mint condition can bring tens of thousands of dollars on the collector's market—not bad for a guitar that cost under $300 brand new. What's more, a modern guitarist could play that old 1954 guitar on his next hit record and it would still sound great. Did the Stratocaster evolve and improve? Sure. But it was designed to be great from the start.

So, what does this have to do with building software-enabled products?

Everything.

All the principles that made the Stratocaster successful can be applied to the design of software as well: It should be built as efficiently as possible without sacrificing quality. It should be easy to use. It should satisfy the goals of its customers. It should be easy to maintain, upgrade, and customize. It should exhibit the highest quality possible at its price. It should be aesthetically pleasing. It should inspire loyalty.

But we're not talking about altruism here. In the case of Fender, all the time and effort Leo and company spent sweating the details and keeping quality high went straight to the bottom line. Leo Fender had a nicely profitable business for many years, and the Stratocaster created a loyal following of musicians who insisted on playing Fender instruments. In 1964, Leo sold the business for $13 million, quite a respectable sum for a company that was initially ridiculed by other manufacturers for selling a "canoe paddle with strings."

Leo Fender, a solitary man with a small team of like-minded individuals, spent countless hours thinking through all the tough issues required to make a hunk of wood with steel wires and a couple of magnets into a huge artistic and business success. Does your flagship product deserve any less from your company's team and resources

What do you think? Join the conversation in Comments

Your online store is a good example of the breed. You've got good products at good prices, the site navigation is straightforward, the product information is rich, appropriate, and easy to find, and everyone likes the clean, uncluttered visual design of the site. So why do more than half of your customers abandon their full shopping carts?

Depending on which research report you read, roughly 25% to 75% of online shoppers abandon their shopping carts before consummating the deal. Despite the disparity in numbers, all the research firms agree on one thing: that's way too many.

There are plenty of reasons why people back out of an online purchase. Some people just change their mind like they do in "offline" stores. But unfortunately, many customers bail simply because the store checkout process is too confusing, intrusive, or tedious. The online stores that fall into this category have failed to follow one of the cardinal rules of business: Make it easy for people to give you their money.

Let's examine a few common checkout mistakes. Each one of these problems acts as a barrier to the customer placing an order, and therefore the closing of a sale.

The Marketing Info Snare

Some sites require their customers to register before allowing them to place an order. Companies do this to learn more about their customers and compile marketing data for reuse or resale. This is a clear case of misplaced priorities. In the bricks & mortar world, no store, from 7-11 to Bloomingdale's, requires their customers to register before allowing them to make a purchase, and with good reason! It comes down to a simple choice: would you rather compile marketing data or make a sale?

Not that you should stop asking for information from your customers. You just shouldn't force it upon them—it could nix the sale, and it might make some customers think twice about dealing with you at all. Generally, it's more effective to use the carrot than the stick: if you'd like your customers to register with your site, make it clear that it's their choice, but also give them a reason to fill out the form. The reason could be a contest, a free newsletter, credit towards their next purchase, whatever.

Similarly, if your registration form asks for non-required information, make it clear that those data fields are optional. Then reward customers who take the time to fill them out. It's critical to recognize that your customers' time is valuable to them, and that their information is valuable to you. Also, be clear about your intentions and be careful what you ask for—according to Forrester Research, only 6% of consumers trust how Web sites use their personal information.

The Mystery Grand Total

Customers are often uncomfortable filling out forms and supplying a credit card number before they know the total cost of their purchase (including shipping charges and tax), yet most online stores demand they do just that. This is in striking contrast to the way things work in the real world: no retail store expects customers to hand over their credit cards before telling them how much they have to pay.

Instead of keeping your customers in the dark, assume they are intelligent, busy people who are interested in making an informed purchase. The cost of the transaction is a critical piece of information in such a situation, so give your customers the grand total up front, with minimal data entry—a zip code for example. Again, be clear about why you're asking for their information: "If you enter your zip code here, we'll estimate tax and shipping costs for you automatically."

The Exact Syntax Hoop

Many online stores place seemingly arbitrary constraints on how information must be entered, from the layout of a phone number to the characters used for dates. One especially vexing example is when sites require their customers to enter their credit card number without using spaces or dashes. If your customer is moments away from giving you a boatload of cash, why be picky about how they give you their credit card number?

Look at it this way: If you ran a bricks & mortar store, would you require your customers to hand you their credit card using their left hand only? Of course not. But forcing people to enter their credit card number in an unusual, counter-intuitive format, such as without dashes or spaces, is the same thing.

An unfamiliar credit card number format is problematic for other reasons:

• It's harder for your customer to enter and verify for accuracy
• It doesn't match the way the number is printed on the card
• It's inconsistent with how people write the number on printed forms

If your goal is to close the sale with an accurate, valid credit card number, then don't make it difficult or confusing for your customers to enter their number correctly. Instead, allow them to enter the number as it's shown on the card (with spaces) or, better yet, let them enter the number any way they want—your system can put it into whatever format it needs after the fact.

Removing the Barriers

Are these trivial examples? Yes and no. A website full of little annoyances like these can feel like death by a thousand paper-cuts to your customers. How many little hassles will they tolerate before they jump ship for your competitor's site? Do you really want to know?

Every substandard interaction you introduce to your store is a barrier that lies between your customers and a completed transaction with you. If you're a businessperson who sells online-or anywhere else for that matter-it's worth spending the extra time, money, and effort required to remove the barriers and nuisances from your checkout process to make it easy for people to give you their money.

What do you think? Join the conversation in Comments

In this month's newsletter, Tony refers to a Washington Post story titled The End-User View of Techo-Nirvana: Blink, Blink, Blink. The Washington Post writer had this to say about Video Cassette Recorders:

That flashing "12:00" has become a symbol of technology as tyranny, taunt, impotence, ignorance, intimidation, humiliation, stone in the shoe and pain in the butt. It stands for innovation created without humans in mind. Yet humans have grown to live with it. To expect it. To adjust themselves to the selfishness of these machines. Like sheep.

Consider the most recent twist of the knife. Some 25 years late, the electronics industry promised to solve the flashing-12:00 problem. Today, most new VCRs are supposed to seek out a broadcast time signal and set their own clocks.

Except when they don't.

It's practically a cliché. Seemingly everyone has bashed the much-maligned VCR at one time or another, with the blinking clock their primary target. This is evidence of how widespread and annoying a problem it has been. However, while some point to solutions using today's technologies, no one has stepped forward to offer a feasible, affordable, and appropriate solution that could have prevented the whole mess back before it started. But, first things first. How did we get into this situation?

A short investigation reveals the two main causes of the blinking 12:00 problem: The VCR clock forgets the time when you unplug the VCR, and the clock is awkward to set at best. So when the VCR is unplugged and moved, or the power goes out, the user has to reset the clock to the correct time. The chronic blinking occurs when the user of the VCR either doesn't know how to set the VCR clock, or simply doesn't want to be bothered with it the third or seventh time around.

The forgetfulness of the clock is clearly a technical issue that impacts the user. But why are the clocks so difficult for consumers to set? Well, with electronic devices, developers tend to rely on many small buttons to do the work of one simple control, usually in the name of efficiency. What this means is that someone who understands how the more complex time-setting controls work can set the clock more quickly than they could with simpler controls. However, these home-use VCRs were targeted at the mass consumer market, at people who tend to be more interested in ease of use than efficiency—they just want to use their entertainment devices without feeling stupid.

Also revealed is a higher-level problem: The manufacturer of the VCR didn't delve deeply enough into the needs of their users, who had no interest in continually resetting the clock on their VCR. Setting the clock is a task, not a goal, and has nothing to do with watching movies or recording favorite shows.

So, would it have been possible to solve the blinking 12:00 problem using the technology available when the VCR first appeared on the consumer market in the mid-to-late '70's? It sounds like a worthy design challenge—it's time for you to take a trip in the WABAC machine and find out.

Shazzap! It's 1977. Jimmy Carter is the President of the United States. Debbie Boone, KC & the Sunshine Band, and Andy Gibb are slugging it out on the Billboard charts. The original Star Wars has just opened in theaters, and Elvis is still alive. Hmmm, you think to yourself. Perhaps they just didn't have sufficiently advanced technology back here in 1977...

You decide to get the easy problem out of the way first—make the clock easy to set. Heck, you didn't need to travel to the seventies to solve this one! Why not set the time with a simple rotary control, similar in operation to the ones already used by millions to set their alarm clocks or analog watches? The user simply rotates the knob until the correct time is displayed. Your solution is time-tested, easy to use, and possible with 1977 technology, as demonstrated by Atari's freewheeling video game driving controllers released the same year. This leaves you with the trickier problem: How can you eliminate the need to frequently reset the clock in the first place?

Here in 1977, the RCA SelectaVision VHS-format VCRs are selling at a price of $1,000. So, what other technologies are available? While flipping through the advertising section of the local newspaper, you notice that the new Texas Instruments 503 model digital Sports Watch is on sale for the unheard of price of $9.95, battery included.

Wait a minute. You don't have to plug the watch into the wall at all, and it keeps accurate time for years! Hmmm. It seems clear that a clock that doesn't forget the time when it's unplugged from the wall is technically feasible. Add the battery from the Sports Watch and some minor circuitry to the SelectaVision, and the VCR can now keep accurate time even when unplugged.

However, you know there are other factors to consider in addition to technical feasibility, factors like size and cost. Size isn't so much a concern with the SelectaVision—it's already a huge tank of a machine, with plenty of room inside for a small watch battery—but cost is clearly a critical issue for a consumer device. Can this timekeeping functionality be added without drastically raising the retail price of the VCR?

You do some quick math: The battery of the watch costs far less than the $9.95 retail price of the watch. Adding it and some basic circuitry to a $1,000 VCR would have a negligible impact on the price of the VCR, while providing a competitive advantage over the companies marketing VCRs that can't remember the time.

So, this fix is technically feasible, cost-effective, makes the product more enjoyable for the user, and gives the manufacturer a competitive advantage. Problem solved—time to return to 2001. Shazzap!

Great work! Unfortunately, this sort of problem is not limited to VCRs or the 1970's, and there's still plenty of work to be done. Contrary to popular belief, new technologies like wireless and voice recognition will not rescue us from bad products. Like all technologies before them, these new technologies will introduce as many problems as they solve unless they are focused with good design. This makes it critical to spend as much time thinking about your users and the design of your product as you do about the technology behind it. Otherwise, the next product you use the WABAC to fix may be your own!

What do you think? Join the conversation in Comments

All other things being equal, the more complex your product is, the harder it will be to use. And the harder your product is to use, the more your customers will rely on your technical support department, which tends to increase your costs and decrease your customers' overall satisfaction with the product. The good news is that one of the most simple and effective ways to reduce complexity is to cut unnecessary features from your product. But how do you know which features to cut?

Well, it's not easy. Marketing wants a feature that one of your competitors has so they can cook up one of those bulleted feature comparison charts. The engineers have an idea for a feature that they think is really interesting, and one of them spent the entire weekend coding it. And then there's the "squeaky wheel" customer in Arizona that wants a particular esoteric feature that no one else seems to care about…

It's difficult to determine what features are important with all these colliding views and opinions clouding your view. In order to separate the wheat from the chaff, it's helpful to follow three simple steps: 1) Keep the big picture in mind, 2) Focus on your personas, and 3) Apply a screening tool.

The big picture

Good businesses constantly balance customer, business, and technical issues as they develop new products.

All three of these factors have to be balanced in order to make a good product, of course. A product that pleases your customers but doesn't make money won't make you successful, and a stellar product that fills a market need but can't be built on schedule won't either. This is the big picture, and it is helpful to keep it in mind as we move on through the next steps.

Focus on your personas

If you don't already have a set of personas—archetypal customers that you use to make informed decisions about the design of your product—you'll need to create a set. (For more information on creating personas, see Kim Goodwin's newsletter article, Perfecting Your Personas.) Your personas will help you focus on what your customers really need, and they will become the benchmark you'll use to evaluate the customer benefit of specific features.

Apply a screening tool

A simple matrix with questions and yes/no answers will suffice. For the customer, ask questions like "Does this feature offer clear benefit to the customer?" and "Can the customer easily learn how to use this feature?" From a business perspective, typical questions include, "Will this feature help me sell the product?" and "Will customers be able to use this feature without calling technical support?" From a technical standpoint, two major questions are, "Is this feature possible given the current technology?" and "Can this feature be implemented within the schedule?"

This is not a complete matrix by any means, but it's a good start:

Note that both of the technical feasibility examples are clear deal-breakers: "No" votes in either of these rows would require a schedule change or the creation of a new technology.

The feature-cutting process in action

Let's take a run through the process. In this case, let's imagine that you're in charge of the development effort for a sporty new automobile, which, like most modern cars, is fully computerized. You already understand that you have to balance the customer, business, and technical issues, so you get the big picture.

Next up is to introduce the persona that represents your customers. Your designers—after much ethnographic research, careful thought, and animated discussion—have created a persona named Jack Caldwell.

Jack is the energetic, 42 year old owner of a small but profitable antique store. Jack wants to get to work on time, enjoy the drive, and not worry about his car breaking down. Like most folks, he would prefer to spend as little money as possible to keep his car on the road. But at the same time, Jack appreciates a nimble car that moves quite nicely when asked, which is why he gravitated towards a sportier car. He's upgrading from an older sports car with a carbureted engine, in search of something more modern and reliable.

Now that we've established Jack as our target persona, it's time to apply the screening tool. In this case, we're evaluating two different features for our automobile: the Electronic Fuel Injection (EFI) system that controls the car's engine, and the Real-Time Miles Per Gallon (RTMPG) display that shows the second-by-second fuel consumption of the car.

The Electronic Fuel Injection feature continuously measures a variety of engine parameters including the amount of air flowing to the engine, the current throttle position, and the oxygen content of the exhaust. The system uses this information to determine the exact amount of gasoline to inject into the engine at a given moment. The advantages of this system over Jack's old carbureted car include more power, better fuel economy, lower emissions, and greater reliability.

The Real-Time Miles Per Gallon feature, on the other hand, is one of those features that your development team was able to provide for "free." The car already has a feature that displays the average miles per gallon measure of fuel efficiency, which, for example, allows Jack to see what his average fuel efficiency was for a long trip. Behind the scenes, the computer calculates this Average MPG using a raw data stream from sensors that continuously monitor the fuel consumption of the engine and distance traveled by the car, in real-time. One of the engineers thought it would be useful to go one step further and display this raw, real-time data in a digital readout, because he thought it might help drivers better understand their driving habits and how they affect the overall fuel economy of the car. The Average MPG and Real-Time MPG features share the same digital readout on the dashboard, and a small control switches between the two types of information, which look very similar.

Let's plug these features into your matrix. To find the answers to the customer benefit questions, you and your designers adopt the worldview of your persona Jack and anticipate his reaction to them. The business benefit questions are answered both through your understanding of Jack's values, and by tapping the knowledge and expertise of your business and marketing people. Finally, the technical feasibility questions are answered directly by the engineering department. After much discussion and debate, here's how it finally shakes out:

Screening results

Your matrix shows the Electronic Fuel Injection feature to be a winner on all counts. Jack enjoys the benefits of overall better performance and fuel economy, and he drives his new car exactly the same way the drove his old car: He pushes on the accelerator pedal, and the car goes. This feature is definitely a keeper.

As it happens, the EFI system is also a rare example of a truly transparent feature, in that there is no change in the user interface of the fuel delivery system. The gas pedal works exactly the same way from Jack's perspective, despite a significant upgrade in real-world benefits to Jack.

On the opposite extreme is the Real-Time Miles Per Gallon feature, which scored very poorly. Jack doesn't understand the meaning or value of this feature—to him, all it does is display a succession of seemingly random numbers: 129, 56, 5, 13, 87… This real-time measure of fuel economy is useful to the computer as raw data for averaging, but is not that useful as a live status indicator for Jack. In the best-case scenario, Jack will think this raw stream of data is rather silly. In the worst-case scenario, he'll mistake this raw stream of MPG data for the more useful Average MPG reading, and assume that the feature is broken. He'll end up bringing the car back to the dealer or calling for help. There's no clear upside to this feature, so it should be removed.

The RTMPG display, in addition to being rather useless and confusing to Jack, is also a perfect example of an empty calorie feature: it provides no clear benefit to the customer, it doesn't help sell the product, and potentially requires extra work from your support staff, at a greater cost to you. Given all this, the fact that the feature can be implemented with the current technology and on schedule seems a small comfort.

Of course, these are just two extremely different types of features—you'll discover many flavors in between as you apply this process to your product.

Some additional tips

A few other things to keep in mind when you're looking for features to cut:

• Don't include special one-off features for individual customers unless you're convinced that they will benefit the majority of your customers as well. Use your personas to evaluate customer feature requests so that your team isn't unduly influenced by the "squeaky wheels." (Of course, if the "individual customer" in question is a 50,000-seat Fortune 100 account, the business benefit may outweigh the downsides.)
• Neat technical features are often confusing to customers. They may excite your engineers—smart people who have parlayed their interest in highly technical things into a career—but if a feature doesn't offer a clear and direct benefit to your customers and help you sell the product, it's better to just leave it out.
• If you haven't already, consider changing your company's marketing tactics—and I know this is both non-trivial and controversial—from competitive feature comparisons to competitive benefit comparisons. Competitive feature comparisons usually end up sparking a product "arms race," in which you and your competitors feel pressured to pile on the features as fast as possible to stay in the race. On the other hand, if you can demonstrate that your product provides your customer with a greater benefit than your competitor's product, regardless of how many more features their product has…Well, let's just say that if I were a salesman, I know which product I'd want to bet my commission checks on.

Jack drives off into the sunset

As you can see, reducing complexity by cutting features isn't just about thinning down your product. It's about making your product more appropriate, and as a result, of greater benefit to both your customers and your bottom line. And isn't that what we're all driving towards?

What do you think? Join the conversation in Comments

Have you ever tried to use a kitchen stove and ended up turning the wrong burner on by mistake? Yeah, us too. Just about everyone who cooks has run into this minor annoyance at some point in their life, if not repeatedly. So what do naughty stoves have to do with software? You may be surprised to learn that your digital products may suffer from the same fundamental problem that makes these stoves annoying and counterintuitive.

The problem with these stoves is poor or unnatural mapping. The term mapping describes the relationship between a control, the thing it affects, and the intended result. Poor mapping is evident when a control does not relate visually or symbolically with the object it affects, requiring the user to stop and think, "what's going to happen when I turn this knob?"

To understand how mapping works, it's helpful to dig a little deeper into the problem with stove cooktop controls. The typical cooktop, such as the one shown below, features four burners arranged in a flat square, with a burner in each corner. However, the knobs that operate those burners are laid out in a straight line on the front of the unit.

In this case, the result of using the control is reasonably clear: A burner will heat up when you turn a knob. However, the target of the control—which burner will get warm—is unclear. Does twisting the left-most knob turn on the left/front burner, or does it turn on the left/rear burner? The answer to this question is usually found by trial and error, or by referring to the tiny icons next to the knobs, even when the person has used the oven before.

So what are the consequences of this bad mapping? In the best case scenario, the user just feels a little silly that they twisted the "wrong" knob, or the food simply doesn't get hot until they notice their error. In the worst case scenario, they could accidentally burn themselves or something else. (I've done this: I torched a pot-holder once by accidentally turning on the burner underneath it when I thought I was turning on a different burner.) Clearly, this is an undesirable behavior of the product that doesn't contribute to customer satisfaction.

A simple solution is to change the physical locations of the cooktop knobs to suggest which burners they affect. The knobs don't have to be laid out in exactly the same pattern as the burners, just positioned so that the target of each knob is clear. This cooktop is a good example of an effective mapping of controls:

In this layout, it's clear that the upper-left knob controls the upper-left burner. The placement of each knob visually suggests which burner it will turn on. There's no confusion: The food gets hot, and nothing gets burned. (Well, except maybe when I'm cooking.) Donald Norman calls this more intuitive layout "natural mapping" in his book The Design of Everyday Things.

Unfortunately, poor mapping isn't limited to major appliances. I frequently run into a similar problem when changing the background color of a table cell in Microsoft Word. In this case, I have a simple three-column, three-row table. I select the first cell, then bring up the "Borders & Shading" dialog to change the background color of that cell.

When the dialog appears, I select the color I want and hit the OK button. I expect the selected cell to turn blue, but surprisingly, the entire table turns blue instead.

To be fair, if you read the fine print in the dialog, you'll see that all the clues are there. The dialog has a labeled list control that defaults to, "Apply to: Table." One of the other options is "Apply to: Cell." However, this is much like the little icons on the stovetop. If people actually stopped and read these things there would be no problem, but that's not how people work. The good news is that nothing gets burned in this example, but this behavior is annoying and requires the user to undo the last operation and start over. It wastes the user's time and erodes confidence that the next feature will work as expected.

Interestingly enough, the solution to this problem is also in Microsoft Word. If I do the same exact thing, but use Word's "Tables and Borders" floating toolbar instead, I get the result I want. I select a single cell, then select a color on the toolbar…

…and the selected cell turns blue, not the entire table.

Why a dialog and a floating tool bar that perform the exact same operation use two different defaults is unclear. What is clear is that the toolbar does what I expect by operating on my selection by default—like just about everything else in Word—while the dialog operates on the entire table by default. No time is wasted and the user is given no reason to question the behavior of the software.

Another example of poor mapping—of a slightly different flavor—is pictured below. In this case, it is the mapping of concepts to each other that is unclear.

This is from a website that uses a pair of drop-down menus to sort a list of search results by date. The selection in the first drop-down determines the choices present in the second. In this case, when "Re-sort results by: Date Placed" is selected in the first menu, the second drop-down presents the options "Ascending" and "Descending."

The problem lies in the terms chosen to communicate the date sorting options: "Ascending" and "Descending." An informal poll found that people were generally unsure which option they should choose if they wished to see the most recent items first in the list—it was evenly split between "Ascending" and "Descending." All of them had to think about it for a little bit. One person was especially frank, stating that in his experience the option he selected always did the opposite of what he expected.

Unlike the poorly mapped cooktop knobs, the target of this control is clear—the drop-down menu selections will affect the list below them. However, the result of using the control is unclear: Which sort order am I going to get? This ambiguity is confusing and interrupts the flow of the task at hand.

The primary issue is that the terms "Ascending" and "Descending" are non sequiturs in this context—they don't map conceptually to dates or time. People don't generally think of dates as "ascending" or "descending;" rather, it is more common to think of dates and events as being "recent," or "ancient," or "about five months ago." A quick fix to this problem would be to change the wording of the options to "Most recent first" and "Oldest first."

Given more time, you might think of better words to use than these, or better yet, a more elegant mechanism for sorting items by date. But with this simple change, the formerly confusing control addresses the concept of dates in terms relating to time. This clearer mapping makes it easy to understand what the resulting sort will be, allowing the user to focus on the task at hand rather than the interface of the website.

Whether you make appliances, desktop applications, or websites, your product may have mapping problems similar to those discussed here. The good news is that mapping is an area where attention to detail pays off—you can measurably improve a product by seeking out and fixing mapping problems, even if you have very little time to make changes. The result? A product that is easier to understand and more pleasurable to use.

What do you think? Join the conversation in Comments