For decades, most ISVs have taken this approach to creating new versions of software: Pile on additional features, market them as the newest and greatest, then sit back and hope the revenue comes pouring in.
In the best case, before starting development the vendor surveys users to find out which features top their wish lists, and their order of priority. In other cases, the approach can be a casual one: Getting a few sales people into the office and asking "So, what do these people want?" And, of course, there's the "developer knows best" approach, which bypasses any polling or information-gathering in deference to the developer's superior knowledge of what the customer needs.
Once the feature list is prioritized, developers go to work ladling these new features into the software framework, trying to fit in as much as possible within the promised delivery time. If they can't deliver a feature list that looks good on a spec sheet, web site and press release, they might delay delivery or compromise on a reduced feature set that will stem the tide until the next product release.
What's not to like?
If users get what they think they requested, and the features actually do what they are purported to do, then this feature-driven approach works fine. Users can justify upgrade purchases to their bosses based on waving the spec sheet and reiterating the vendor's promises of better performance and quality.
From the vendor side, it works wonderfully. A new version of software with additional features typically opens up a fresh revenue stream, giving an existing product new life and making a substantial contribution to the vendor's bottom line.
So, if the user is happy and the vendor is happy, what's the issue?
The issue is one of missed opportunity; the opportunity to do something really great that users have never seen before and could never even imagine, much less request in a feature survey or discussion; something that gets a job done in a way that makes their lives better.
Developing this type of product requires going beyond features. It means concentrating on what the customer wants to achieve. Sounds simple, but it is extremely difficult. The rewards for getting it right, however, are much greater.
Take a look at the search engine market just before the turn of the century. Alta Vista, Hotbot and Infoseek were doing a pretty good job with their search engines, and people were relatively happy to use them. You didn't hear a lot of cries from the general public for a simpler, more effective search engine. Then came Google.
A couple of smart guys from Stanford figured out that all people cared about was the fastest, simplest, best way to search. They developed a product that does one thing awesomely well. By concentrating on the end result – better search – and pioneering new ways to get there, Google changed the whole landscape, and created a brand name that's both a noun and a verb.
Another example is Slashdot. For decades, computer professionals received their news and views from trade journals, conferences, textbooks, and informal interaction. Few of us thought that we wanted or needed a central place that gathered this information and filtered it with a distinct attitude; a site that celebrates the unique culture of the computer professional under the slogan: "News for nerds. Stuff that matters." Slashdot recognized the need, and came up with a unique solution to which its audience gravitated.
Booth Google and Slashdot tapped into needs that were never expressed explicitly. The processes that begat these two phenomena could not have come from asking customers about features or methodologies for delivering information.
Aiming to delight
When a customer is asked about features, the software development process is stunted from the beginning. The customer is only going to talk about what he or she knows in technical terms. As Steve Jobs said in a 1998 interview with Business Week, "It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them."
What customers do know, often in passionate detail, is what they want to achieve. If a company can deliver on just one thing a significant number of customers really want, something that changes their work lives, these customers are not just pleased, but delighted.
With the feature-based approach to development, a software company might have a guaranteed "well done" from the customer, but there will never be that transcendent feeling that comes from forging a connection with a customer that goes beyond the product; a connection that makes customers feel that you are in touch with their needs and desires.
They'll know it when they see it
Conventional wisdom says that you can't sell a product without promoting new features. The rationale is that customers talk the simplicity talk, but they buy feature-laden complexity. Offering a simple way to complete a task that used to take multiple, tedious steps is not enough to sell a product.
It's true that there will always be people who want more features, just as there are people who want to wear multiple gold chains or buy the car with the most options. But, that's not always the case any longer in the software market, if it ever was. Software professionals know their jobs inside and out, or certainly well enough to recognize a tool that can save them time and energy. They'll settle for new features and incremental improvements if that's what you got, but they'll devour anything that elegantly solves a problem in a simple way – even if it doesn't come with a page-long feature list.
The key is getting potential customers to try the product. That's where providing free trials of the complete software over an ample amount of time makes the difference. Many companies don't do this, for fear of piracy or that the software will be used to take care of a problem during the evaluation period and not purchased. But, these are chances a vendor should be willing to take if it thinks it has a superior solution to offer.
Once someone has a chance to try something that works better and more simply, evidence shows that not only will they buy in a big way, they will become advocates for the company that solved their problem. That's what separates what Jobs calls the "insanely great" product from the merely competent one.