From the cooper.com newsletter, an article that was able to clearly and poignantly articulate a discussion I’ve struggled with many times at work. As part of our proposal process we’re constantly putting together “feature lists” (which admittedly we do combine with more in-depth lists and descriptions) that describes each and every entity included in the project.

“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.”

In short, the solution:

“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.”

Please send this to every software sales, marketing and project manager that you know. No more “features”!