The Customers Are Idiots

AntiPattern Name: TheCustomersAreIdiots

Type: Design

Problem: Members of design teams think that internal expertise in problem domain is an adequate replacement for customer research, and that conducting customer research is a waste of time and dangerous, because TheCustomersAreIdiots

Context: Specifying project requirements.

Forces: Team made up of one or more greybeards who have (or worse, think they have) a great deal of customer knowledge. Often aggravated by an inexperienced marketing team, a strong desire to compress schedules (what do we need three months of surveys for?), and/or management with a strong engineering bias.

Supposed Solution: Rather than asking customers what they want, the project gurus synthesize requirements based wholly (or at least mostly) on their own accumulated marketplace knowledge.

Resulting Context: Project often fails in the marketplace, because:

Project has too many features (GoldPlating, FeatureCreep) and is too expensive and difficult for the customer to use.
Gurus supposed knowledge of the marketplace is stale; resulting project is what the customer needed five years ago, but not what customer needs now.
Project is something completely new and different (possibly DisruptiveTechnology), but fails because customers do not know what it is for.

Design Rationale: Belief that internal market knowledge is superior to customer research. Especially prevalent in engineers, who are often suspicious of customer research techniques (the belief, for example, that FocusGroup?s are BS). Often compounded by belief that problem domain is special, and traditional customer research methods don't apply.

Related AntiPatterns: MarketingAreIdiots?, ThinkingOutsideTheBox?

Applicable Positive Patterns:

AntiPatternCategory: DevelopmentAntiPattern

Also Known As: UsersAreIdiots?

Opposite AntiPattern: WeAreIdiots

Examples in the Literature: Not aware of any.

Examples in Practice:

Counterpoint: The customer may be an idiot, but he is always right.

Many times I have been the sole voice in a design/requirements meeting asking if a certain feature will actually be used by the nurse/press operator/bank teller/what-have-you. Far too often the features demanded by the client come from exactly the kind of experience mentioned above -- outdated. I have always asked if the requirement for this or that feature was generated by an actual user or if it just came from some marketeer's whole cloth. You would be surprised how pissed off and defensive some people can get about their pet features.

Speaking as a greybeard, I have always differentiated between my technical knowhow and the limitations of my product domain knowledge. I have always stated that the set of features needed to be specified by people who actually went out and talked to users. I am continually amazed at how many clients don't do this basic research before committing large sums of money to a development effort. The results of such folly are plain for all to see -- the product won't sell.

Finally, I make it a point to offset the pseudo-greybeards who profess a great knowledge of product domain but don't offer hard evidence to back up their assertions about this or that feature being "essential" to the product. One doesn't have to be argumentative or contentious to make the client aware that he is being had. I do it by saying that all my technical prowess isn't worth jack-be-nimble compared to a good grasp of what the product really needs to do. I point out that until we have a feel for how the actual user is going to use the box then it's pointless to design anything, including an architecture.

-- MartySchrader

As a postscript to this, I still think it is our professional duty to point out to the client when he is being an idiot. Certainly there are diplomatic ways to do this, but it is our responsibility to make sure that he knows he's an idiot regardless. Eh?

It's amazing how often I see TheCustomersAreIdiots played out in various places. And while sometimes the customers are; as you point out--the customers are the ones who ultimately pay the bills. (From your job description; you sound like an external consultant rather than an "insider" on the company doing the project).

A wise, experienced (dare I say "old") ProgramManager I once worked for was well aware of this phenomenon (and its opposite, WeAreIdiots). He had a perfect rejoinder when management (and marketing/engineering personnel outside the project team) proposed a feature or requirement.

"And how many are you going to buy?"

As the product cost US$10k in its most basic configuration; the answer in all cases was, I would wager, "not many".

-- ScottJohnson

But sometimes Archaic processes are automated as-is instead of modernized because one is afraid of upsetting the costomer, who is set in his/her ways. In this case, they ARE idiots. But if they want to pay for a sinking ship, I suppose that is their perrogative.

If the customer is engaged and provides requirements that are dubious; that's one thing. The AntiPattern discussed on this page is the refusal to engage the customer in the first place, on the grounds that "we know better than our customers do".

Sometimes, agreed, the customers indeed are idiots. But you should make an honest effort to communicate with them before passing such a judgement.

We once got an email from a client that said (from memory):

I know you're disappointed in us. We're disappointed with our customers too. But we each have to live with the customers we've got.

That about sums it up for me.

CategoryAntiPattern