What’s a feature?

Features are often the currency of software development and marketing, yet few people can agree on what exactly defines a feature. The term can be used to describe a particular piece of functionality, an entire set of functionality, a capability, or sometimes even a possibility. The experts are no help. Typical is webopedia.com, which goes out on a limb by stating that a feature is, “a notable property of a device or software application.”

In other words, a feature is a feature of something.

What is telling, though, is that the vast majority of definitions refer to featuritis or feature creep, the seemingly endless proliferation of features that glom onto what was once, perhaps, a product with a clear vision. Everyone knows that features pop up during the product cycle like mushrooms after a rain.

Feature Creep

So it goes with the management of a software product’s development and marketing. A project is initiated with a particular set of features in mind. But as things progress, more features creep in. Fearful of losing control, executives use the tools with which they’re familiar—deadlines and budgets—to lay down the law: “The product will be shipped in October and will sell for 100 shekels per unit, and that's that.” Anxious managers will then turn to feature-control processes, such as a Requirements Stability Index, or RSI, to manage the situation.

Problem is, this sort of approach fails, expensively and miserably. (See Wayne Greenwood’s article, “Three Traps”). According to an oft-cited Standish report, 73% of projects were either canceled or failed to meet expectations due to insufficient requirements definition and analysis. In other words, feature creep. What happened, frequently, was that projects grew beyond the point where they were either financially or technologically feasible, because of what are deemed “uncontrolled client requests.”

This is expensive and aggravating for a development organization, and the hapless user gets stuck holding the bag. The product is delivered late, it’s beyond her price point, and it is accompanied by an unwieldy manual to get through all the features she’ll never use. When she asks the sales guy where Feature X is hiding, he fumbles around until he finds something that appears to do what she says she wants it to do, but it is unrecognizable to her.

When elephants fight, the grass suffers

It was not supposed to turn out this way. Discussions of a software product in terms of its features were intended to serve as a bridge between constituents who otherwise had few terms in common: users and software developers. Users want a product to satisfy their goals (why else use a productivity application?), while software developers need to know what to build (otherwise they will just make it up themselves). Meanwhile, marketers and sales folks want to discuss the characteristics of a forthcoming product. So everybody has been instructed to talk in terms of “features.” Customer needs are translated into a marketing requirements document, which serves as a vague template for software construction. But what started out as a bridge—features—has broken apart. Users stand at one anchorage and product developers stand at the other, both scratching their heads at the expanse of shark-infested waters still separating them.

Case in point, from a recent experience at Walgreen’s in Oakland, California. At the cashier’s station was a digital wall clock on sale for $29.95. On the packaging, in small type, it noted that the clock also displayed the temperature. Meanwhile, in 45-point type, it boasted “1013 MHz transmission.” I am not certain how many people in line knew that “MHz” stands for Megahertz, but I can almost guarantee nobody cared. On the other hand, I expect shoppers would be interested in how reliable the temperature reading was, whether it displayed both Celsius and Fahrenheit, and whether it was easy to switch between the two.

Features behaving badly

Featuritis is not the only problem with feature thinking. After all, there are some features everybody can agree on, yet those features sometimes fall flat. How come?

Take Microsoft’s Office Clipboard feature. (Please, take it!) The company heard its customers say they wanted to capture multiple items and paste them across different applications. In product management-ese, this would be described as “a more robust Clipboard,” and it sounds like a useful feature. Office 2000 featured a Clipboard with the capacity for up to a dozen items that could work across applications. But while it may “work,” it behaves horribly. As far as I know, there are no documented cases of users in the wild effectively taking advantage of more than one item in the Office Clipboard with anything approaching ease.

Why?

The floating Clipboard palette appears according to some esoteric set of rules, and sometimes when you least expect (and want) it. When it does show up, meanwhile, it is parsimonious with information about the contents of the clips it harbors, so if you make six clips from Word documents, all you see are six Word icons (at least the branding people got what they wanted out the development process). The user, meanwhile, is left in the dark, wondering where a particular clip is hiding.

So how did this happen? After all, Microsoft probably employed the tried-and-true language of features: “robust, multiple items,” “cross-application,” and other seemingly precise terms. One might be tempted to say that developers failed to read the mind of the user, but given that is not part of their job description, that would be unfair.

There is a better way

Start by imagining the Clipboard not as a “feature” but as a response to a constellation of needs tied to the context and goals of users. Such a process would begin with a few questions:

  • Who is using it?
  • Why are they using it?
  • How might its appearance interfere with other key user workflows?

In order to answer these questions, managers need to interpret client requests and translate them into objective needs that are illustrated by true-to-life scenarios. These needs can then be expressed in terms of what the software product will do for a user, which amounts to your feature description.

Understanding user goals helps focus development and sales

To date, the acquisition and interpretation of user research for the purposes of product development tends to be so undisciplined and the collation of information so unstructured that the requirements coming out of this process are all but impossible to interpret with any degree of certainty. Users are afraid they are being perceived as too thick because they don’t know what “128-bit encryption” is, while developers are frustrated by wishlists filled with contradictory descriptions of large yet lightweight features that are black yet white, and which smell of apples yet of oranges as well.

Similarly, marketing and sales people are ill-equipped to speak about the product in terms other than its features. For instance, what if Microsoft’s next version of the clipboard, Clipboard Nouveau, actually had a winning conceptual and interaction design that anticipated and delivered on people’s needs for capturing, storing, viewing, and re-using clips of data? Certainly, using the language of features is going to fall flat, because of the degree to which the market’s trust in that kind of language has been degraded. To be effective in selling Clipboard Nouveau, Microsoft is going to have to take a different approach. They must begin by talking to customers and users in order to understand what they’re trying to accomplish when handling data clips and to understand the contexts in which they’re carrying out those tasks. Once that information has been collected, then Microsoft can demonstrate how Clipboard Nouveau delivers.

In other words, salespeople need to show in addition to telling. Features tell; behaviors show. Features get you in the door; behaviors close the deal.

Application behaviors serve human goals and help companies sell products

There’s no getting around it. While part of the discussion can take place using the language of features (for instance, the IT guy is going to want to know whether the product has “128-bit encryption”), the best opportunities and longest-lasting relationships are going to come when the language of goals and behaviors is introduced, because then you’re in the business of solving personal goals and organizational objectives, rather than feature checklists.

In the end, demonstrating interaction is the best way to express the value of an interactive product. A feature checklist on the spec sheet is not going to convey to a user what your product will do for him. Customer touchpoints need to be discussions about what users need; the product becomes the answer to those needs. Seen in this way, the problem of product definition and product marketing are one and the same. Not only must goals and behaviors be the foundation for how products are built but also for how they are marketed and sold.