Featurism, Featuritis, and Feature-Creep

Besides simultaneously gathering requirements for an ambitious “hack” of an soon-to-be-orphaned proprietary platform and helping consultants settle on the scope of a sparkling new “Next Generation” information platform, I have the pleasure of sitting across from two high-motivated client-services coworkers who are on the phone for a large chunk of each workday, talking to clients about their web sites and how they do or don’t (and sometimes should and could) work.

These guys are without a doubt “customer-focused” and I’m proud to work with them in my role as a project manager (besides they’re good fun too). But due to the nature of our company (and its the history) they frequently are in the awkward position of trying to provide their services (experience, expertise, etc) to reluctant client stakeholders who in fact display little “stake” in the undertakings.

Effective mapping of features/functionality to business objectives has always been a challenge in the fast moving, technology-drunk, Internet business environment. ROI was “discovered” sometime in the 2nd half of 2000 if I recall my consulting days correctly, but it was mostly used as a club against organizational opponents or as leverage to suppress prices.

Anyway, I want to engage with my client service companions and others with a dialogue about “feature-creep” and the management (and mapping) of features to clearly articulated business objectives. For them it may seem to be a “whose job is this anyway?” when they advice and experience falls in deaf (or distracted) ears. As a project manager I can at least enjoy a “legalistic” pursuit of how features/functionality map to business objectives, and specifically make the case for a weighing of features to revenue opportunities,

Luke W makes a good comment (from his perspective as a information architect/experience designer) on feature-creep and how it’s a phenomenon that won’t go away anytime soon (there’s plenty of “guilt” to go around).

“An effective interface design not only meets user needs, but also
achieves business goals. The problem is that there is an endless pool
of user needs to meet (“wouldn’t it be cool if…”) and business goals
are always derived from a “grow or die” mentality. As a result, our
products continue to grow and each redesign of a software package
brings more features (frequently driven by new technologies).”

But he correctly points out there is almost opportunity here (beside an opportunity to fine-tune your ranting) to revisit our users (clients, readers, etc) to better understand when and how they may use new features:

“….we need to think in terms of frameworks and flexible designs that can
grow or change as technology and user needs change; and, perhaps most
importantly, we need to form mutually beneficial relationships with
marketing, product development, and business units (that means aligning
our goals and learning the language of other disciplines). After all,
it’s when these considerations are in alignment with user experience
strategies that great products get made.”

Interface Design Labors: Feature-Creep

Luke W’s Functioning Form