Featuritis is a common ailment in the software development process, and Web development seems similarly vulnerable. The disease is characterized by a radid growth of new features in response to competition without regard for the specific benefits of these features for the intended audience. Symptoms include fuzzy return-on-investment calculations and the lack of a cohesive marketing plan balancing online presence with physical presence. Afflicted companies suffer from loss of liquidity, and long-term exposure to featuritis can be fatal to a business.
I've seen a good many Web developers lament that their clients only want "brochureware", simple sites that merely describe the services offered by the client firm. Some of these developers suggest that it's the role of client education to illustrate why increasing investment in non-obvious elements of a company's online presence, such as a mailing list or chat forums, can keep a company ahead of the competition.
In truth, it depends.
While "brochureware" is not always optimal, the term has taken on an unnecessary connotation of "bad". Companies still print brochures, and they continue to play a useful role in external communications. In some cases a site that serves a similar purpose to a brochure is not inappropriate. If you think about it, most of the content at service company sites is effectively a combination of brochures and annual reports, and that's not necessarily bad. For those sites, that's what the visitor came for.
One could create an inappropriately disdainful term for the opposite approach by calling it "gadgetware".
Whether "brochureware" or "gadgetware" would be most appropriate for a given client will, of course, depend on the unique aspects of the client's market and how your client differentiates their company from their competitors.
This issue was raised recently in discussion with a developer whose client owns an accounting firm. The unqiue nature of accounting makes it an excellent case in point.
Unlike most service industries, the accounting profession is driven by radicaly different marketing approaches than, say, a plumber or a gardener would use. A good plumber merely needs to understand plumbing, but a good account needs to understand you: your financial goals, spending habits, record-keeping practices, etc. The accounting rules are important, but the effectiveness of an accountant to apply those rules well depends on a more intimate knowledge of the customer than most other professions need.
Accordingly, most people switch accountants far less frequently than they switch plumbers, so the relationship has an inherently long-term nature to it, and an ongoing one. This implies that an accounting firm needs to acquire fewer new clients than a plumber to have the same growth rate, since a plumber's old clients are probably not needing ongoing services (indeed, the best plumber will see his client exactly once).
The most successful accountant I know does not have a Web presence at all. We've talked about it, but he's just not interested: like dentists and some other professionals, accountants tend to get most of their new clients from word-of-mouth referrals, so he feels a Web site would just be a distration. In his case, with his company growing well since he broke away from one of the Big Five a few years ago, he may be right.
Trust plays an inherently more critical role in accountant relationships than many other professions. With my accountant, the number of word-of-mouth referrals which become clients is above 90%, but his return on any more general marketing methods (mass mailings, ads, a Web site) is so low that he just doesn't bother. He spends his marketing time networking with clients, and for him this is far more effective than any canvassing approach.
One thing we need to be very careful of in this industry is aggressive up-selling, talking clients into features they don't need. I've seen too many developers lose clients because they didn't listen to the client's core concerns. And I've seen just as many companies over-invest in their Web presence because someone told them it was all somehow part of The New Economy (which, in case anyone missed it, died several months ago and has been since replaced by traditional business logic).
I usually don't mind if a competing Web developer makes mistakes, but this mistake happens so often it's beginning to make folks wary of the industry as a whole. It's becoming one of the blights on our trade, just as the few truly greedy lawyers have forever destroyed perceptions of a once-noble profession.
It may be the case that gadgetware is a better fit for a client, possibly even for an accountant. There's a lot of extranet stuff that could be done to streamline workflow, but only if there's a strong case that it provides a more favorable return on investment than other methods of solving the same problem. Spending $1000 to save $100 just isn't smart, no matter how technoligically nifty the resulting system may be.
But you don't really have to decide between gadgetware and brochureware at all, at least not at first. Even if additional features are useful to a site, they can be added after the critical marketing material is in place. Adding features like a mailing list for newsletters require a significant ongoing commitment to do well, not to mention excellent copy writing skills, which few professionals outside of copy writers possess. These additional goals are probably best served by waiting until the client is comfortable with their new online presence before making that level of investment.
Forging ahead by insisting that the client build The Ultimate Site in the first go-round introduces a number of unnecessary risks to the relationship:
The cool thing is that if you slow down and go at the client's pace, you may still build The Ultimate Site in good time, but you risk nothing along the way: The client can have initial goals met and feel satisfied with the work, Once the core problem of getting online is solved, the client is much more likely to understand the benefits of specific enhancements beyond those basics.