'''AntiPattern Name''': ''WeAreIdiots''

'''Type''': ''Design''

'''Problem''': Members of design teams think that internal expertise in problem domain is a dangerous thing, because of the possibility that it might be stale; therefore a decision is made that ''every'' customer feature or major decision will require customer validation.

'''Context''': Specifying project requirements.

'''Forces''': Lots of things can cause this one; including any combination of:
	* New management team who doesn't trust in-house experts (engineering, marketing). Especially if preceding management team was canned (for poor performance), and new team wants to be seen DoingSomethingDifferent. Even more so if preceding team had reputation (deserved or otherwise) for GoldPlating, or generally had a long line of projects that failed.
	* Management team that has little experience in product development.
	* Marketing team that distrusts (or wishes to disempower) engineering; sees customer research as keys to kingdom.
	* Marketing or management who wishes to be seen as customer-focused; to please boss (or own sense of how products rightly should be developed).
	* Availability of cool new tools and techniques for requirements analysis. See GarbageInGarbageOut.

'''Supposed Solution''': Rather than depending on in-house expertise, which may be substantial; all requirements (including minute details and implementation issues with little customer impact) must be traceable to articulated customer requests.

'''Resulting Context''': Project often fails, because:
	* Late due to AnalysisParalysis
	* Some key feature that is obvious to everyone, including the customer, is omitted because it never was mentioned in customer research. (''What do you mean, they want a steering wheel in their car? That never came up in the focus groups!'')
	* Project has too many features (GoldPlating, FeatureCreep) and is too expensive and difficult for the customer to use.
	* A me-too project is developed; when what the customer really needs is something new and innovative.
	* Customer sample is not selected properly, or input from customers is too varied, to generate a good set of requirements. Delivered product does not meet customer needs.
	* A rigid contract is established with vendors meaning any deviation from specification leads to change control hell.

'''Design Rationale''': Belief that customer research is superior to internal market knowledge. Especially prevalent in sales/marketing, who are often suspicious of greybeards. Often compounded when the underlying complexities inherent in any design are not understood by those drafting the requirements.

'''Related AntiPattern''': TheCustomerIsAlwaysRight

'''Applicable Positive Patterns''':

'''AntiPatternCategory''': DevelopmentAntiPattern

'''Also Known As''': 

'''Opposite AntiPattern''': TheCustomersAreIdiots

----
'''Examples in the Literature''': Not aware of any.
----
'''Examples in Practice''':
----
CategoryAntiPattern CategoryManagementAntiPattern