Critical Path Newsletter

Reducing the cost of failure

Just like any other industry, software companies look for ways to cut costs. After the year 2000, when the dot-com bubble burst, everyone panicked, realized that they needed to cut costs, and sent development to India. But where should software companies really be looking if they want to reduce costs and be more effective?

Mike Cowpland once said "no one bats a thousand in R&D." So true. The vast majority of software products aren't world-altering. Out of ten, only one is likely to be a big winner.

Imagine only one cup of coffee out of ten was drinkable. Imagine you had to buy nine rotten bananas to get a good one.

In consumer-speak, it means the one successful product has the price of nine not-so-great products embedded into its cost. A lousy ratio—but a great opportunity for cost-savings.

I believe that the next wave of cost-cutting will be right there: avoiding the development of products that, well, suck. Instead, successful companies will create more winning products. By doing this, you can make a lot more money.

Successful Products

The success of a software product is a factor of:

    * Cost
    * Time to market
    * Quality
    * How much users love it

In the last point, I use the word 'love' deliberately. A successful product is one that users adopt quickly and become passionate about. Not just another .mp3 player—an iPod.

In the end, all the other things contribute to this one key factor. Cost means the users can afford it. Time to market means that it comes out at the right time. Quality means people love using it.

I believe the key factor in creating products people love is designing for usability. People will love a product that does what they want in a simple and compelling way.

To do this, we have to get users involved in design, but in the right way. It’s easy to ask users questions—and hard to know if you got the answer you need. Or if you’re asking the right question.

For example, let's say you're making a movie instead of software. To ensure success, you ask ten people if they would like a film about vampires in space (and who wouldn't?). Eight people say yes, so you move ahead.

But will 80% of people really go see "Darkness Beyond"? What if they don't like the actress who plays the heroine? What if the critics hate it? What if the trailer makes the movie look boring?

In other words, what if there are a whole bunch of factors that your research couldn’t account for by its very nature? Your research wasn’t wrong–just limited.

It's the same for software. If you ask people what features they will use and how often, their actual behaviour will probably be different than they predict. How much people say they will like your product is not necessarily a reliable indication of how much they will actually like your product.

For most software programs, you want to look at the interaction design and the task flow, so usability testing is what you need. Instead of asking people to guess what they would like in terms of experiencing the product, usability testing lets you see how they will actually interact with the project.

It works like this...

A usability research specialist works with your team to develop a protocol that tests how easy it is for a user to accomplish tasks and goals in a typical context. It's important that you understand your goals and the end user’s tasks before you spend a lot of money on development (not to mention valuable time that you can never get back).

Based on this work, the researcher develops a picture of the target user and recruits test participants who match the target. The researcher runs test sessions using a formal scientific process to show us how people will really behave faced with the critical tasks that users have to accomplish using your product. The test sessions may be videotaped so that you can watch where users have issues with the product and where they succeed.

Once you know that, you’ve looked into a crystal ball that shows you the possible future of your product from the user point of view without having to have spent all your money developing it and then finding out it has problems. Then you and the expert UI designers can determine what the actual future of the product will be.

Yes, testing usability is more expensive than not testing usability. But testing usability is less expensive than developing a product that takes six months for three guys to create and ends up being a miserable failure because the users hate it.

And usability testing is a clinical process that takes a couple of weeks of valuable time. Definitely does not appeal to the cowboy in us. But imagine all the time this process could save if it reveals that none of the testers use a feature that would have taken a month of development—or even saves a costly re-design.

Mike Cowpland might be right about our R&D batting average. But maybe that means that we need to work on our swing.