It is here that I call into question the utility of the feature as the basic unit of progress and of value for a knowledge product. My thesis is that features are a suboptimal control for piloting nearly any kind of project intended to produce an object or service in the 21st century. This is largely due to the fact that features only address peoples' tasks rather than their goals, and that modern manufactured goods are usually controlled by software, ultimately making them knowledge products as well. As such, I'm going to be using software as the archetype for project management going forward.

Businesspeople love features because they're like a scoreboard for how they size up against their competitors in bullet point format. Businesspeople like money, and feature lists useful for determining how close they are to having a new thing to sell.

Programmers love features because they correspond directly to units of code. Programmers get off on success in technical mastery, so feature lists are a good way to know which problems are interesting and which are boring.

What ends up happening at the outset of a project is that a non-programmer from some other part of an organization comes to a lead programmer with a list of features, in some shape or other, which they thought would make a product that would sell well, and they ask the programmer how long it would take to implement them. The programmer typically replies with a figure that is unacceptable to the non-programmer. What inevitably follows is a ping-pong game of positional bargaining of features for chunks of time. When they finally agree on what is usually an unrecognizable result, the schedule is drawn up and everybody gets to work.

Before I rip into this scenario, I'd like to underscore that my Dashboard dictionary says that a feature is a distinctive attribute or aspect of something. Further, I submit that they don't sell products, but only hazard inhibiting sales. My nose is a feature of my face. If my face didn't have a nose, I probably would have significant trouble finding dates. Likewise, a phone that didn't do text, or a washing machine without a delicate cycle, or whatever, probably wouldn't sell too many units — or if they did, they'd be part of some obscure micro-niche. Micro-niches are great, but only if that's what you're trying to target on purpose.

When we talk about features in software, we're really talking about specific units of behaviour, which coalesce together to form an experience that a person interacts with over time. As such, people don't actually use individual features per se but more like a structure or sequence of them. Moreover, this person rarely cares about which exact features she's using and even less about how the businesspeople or programmers decided to classify them.

So, when a suit comes to a programmer with a list of features, he's:

1. Probably lifting most of them from somewhere else, and
2. Has already mulled it over with his buddies and decided that combination of features will make them rich(er).

Really what he's done is offer up a hodge-podge of ingredients, somersaulting over any notion that a real person would be better equipped to carry out her real-life goals on an ongoing basis with such a product. But the joke is on him, because the programmer gets to cherry-pick over the list and decide which would be interesting technical problems to solve, which he can coerce into something that's already made, and which would be untenable slogs. This is a meeting between viability and capability with zero thought toward desirability.

And this isn't just desirability to buy the product, it's desirability to keep using it. It's important to understand that the customer is not always the same person as the user. Anything sold to enterprise is a good example of this. Toys and cat food are also good examples. While it's really tempting to target products toward the people actually buying them, it's important to remember that if little Skippy breaks his choo-choo the day after purchase or Muffin won't touch the Tuna Surprise, it will have a similar negative effect as the jacket with a zipper that snags your clothes, or the news site that hits you with an interstitial ad before letting you see the content, or whatever.

This is more or less what user experience professionals are supposed to do — champion the users of a product, advocate its desirability and mediate between the business and technical interests. Alan Cooper's book The Inmates are Running the Asylum is completely indispensable in discussing their value. In my opinion they're still a bit all over the place, and they usually don't have a lot of power. They're still sorting themselves out, here's just part of the menagerie:

• Interaction designers, which are often confused with interface designers. The former figure out what goes on the screens, the latter actually make the screens.
• Information architects, which in some ways are descended from librarians, who care deeply about things like organizing huge swaths of information into taxonomies, and data visualization.
• Content strategists, who are descended from writers and editors, and who figure out what various things are telling people at various times.
• Usability engineers, who are chiefly forensic in function, and do all sorts of baroque things like eye-tracking tests after whatever has already been made.

Recently, however, there's been some upheaval in that community, with this one pretty influential guy Jesse James Garrett ragging everyone out in the field for splitting hairs, and how everyone doing it should just concentrate on one thing: user experience. I think it's a step in the right direction, but I think it goes a bit deeper. One more digression and then I'll wrap up.

I wanted to touch on one more thing mentioned in that article: feature creep. At some point along the line it becomes obvious that a certain feature is an absolute must-have or a reeeeaallllly nice-to-have. If you leave it out, you suffer a potentially huge opportunity cost. If you make it happen, it pushes the project back, and you know at least one programmer is going to have to pull at least one all-nighter. It's part of the reason why programmers pad their estimates so much. I think this has a lot to do with how software projects are financed and managed, and I could probably go on about for pages in a separate screed. One thing I can say with confidence is abstaining from implementing something you know would be valuable is a bad idea.

What I think is missing from the process is someone with authority over the desirability of a product. This isn't a product manager, or even a project manager, or even really a manager at all. This is an architect — someone who defines the product and fits it into the rest of the world. Someone who can communicate — to any other stakeholder — where every part belongs and why. The architect would do this by interpreting the goals of real people, to extrapolate the tasks needed to achieve those goals, then correspond those to features and implementations. Through this, everybody from the financiers to the programmers can understand and agree with what is and is not to be made, ultimately obviating feature negotiations. This is the essence of what the eminent software management theorist Frederick Brooks calls conceptual integrity.