Faster Horses – Henry Ford and Customer Development

Faster Horses – Henry Ford and Customer Development

Henry (“Any customer can have a car painted any color that he wants so long as it is black”) Ford was not an advocate of customer development. Although there’s no evidence that he actually said “If I had asked people what they wanted, they would have said faster horses”, it’s definitely congruent with other statements he did make. Henry was also persistent; it took a 75% drop in market share before he finally bowed to the market and brought out a successor to the Model T. All of which makes it very hard to understand why some like to trot out this saying as an excuse to go with their own vision rather than listen to their customers. The most ironic thing of all, is that, regardless of its provenance, this snarky little saying explains the source of the success Ford enjoyed and almost threw away.

Had Ford actually conducted market research, it’s very likely he would have found that people wanted horses that were faster, horses that wouldn’t bury the streets under nine feet of manure, horses that required less care and maintenance, etc. While it’s true that a naive response to these requirements would have led someone down the wrong path, the right path is shining through for anyone who cares to look. Re-read them, replacing “horses” with “transportation” and it becomes clear.

Meeting a need involves two architectures: the architecture of the problem and the architecture of the solution. In this context, requirements, as the architecture of the problem, are design decisions. In“Contexts and Challenges: Toward the Architecture of the Problem”, Charlie Alfred identified two key concepts:

  • Contexts – a set of stakeholders sharing similar goals and concerns.
  • Challenges – obstacles to delivering desired value.

He observes that:

These two concepts, in turn, lead to three important considerations. First, because value (unlike benefit) is subjective, challenges, priorities, risks and tradeoffs are inherently contextual, and the architect must treat context as a first-class concern. Second, the priority of challenges within a context needs to drive architectural decision making. Addressing the highest priority challenges first improves the quality tradeoffs and increases degrees of freedom. Third, while different contexts may pose similar challenges, frequently, the priorities of challenges varies among contexts. Tradeoffs between challenges in a context are often subordinate to tradeoffs between similar challenges across contexts.

Adequately understanding the problem space is a critical first step. People frequently express their wants and needs in terms of solutions rather than problems: “I want a car” rather than “I need transportation”. By the same token, without an appreciation of the constraints that one requirement might introduce, they may well offer up a list of features difficult and/or expensive to meet: “comfortably seat six plus four cubic feet of cargo space and get sixty miles per gallon”. With multiple groups of stakeholders, this sort of conflict is virtually assured. Jumping to the architecture of the solution without adequately addressing the architecture of the problem will lead to wasted effort due to these unresolved conflicts.

Jeff Atwood, in “Listen to Your Community, But Don’t Let Them Tell You What to Do” puts it perfectly: “Community feedback is great, but it should never be used as a crutch, a substitute for thinking deeply about what you’re building and why”. If you’re blindly taking requests without analysis, you’re not providing value. At the extreme end, Patrick Stahler’s advice in “Great value propositions: Not everybody needs to love you” applies: “a great business model is all about what you do and what you do not do”. Not all conflicts can (or should) be resolved: “if you focus on all customer segments, you have no focus”. In attempting to please all, you could easily wind up pleasing none.

Listening to customers in order to understand the problem space does not simplify the architecture of the solution. It does, however, make it much more likely that the solution actually meets the needs of the target market. Ford was lucky that his vision resonated with the market at that time. His initial success fooled him into trusting that vision above the needs of his customers and cost him dearly before he relented. As strategies go, luck doesn’t have a good long-term track record.

Important engineering principle: respect the needs of stakeholders. Anyone standing around holding sharp pointy things deserves attention.

— Grady Booch (@Grady_Booch) May 30, 2013

Gene Hughson

RELATED ARTICLES

Wireframe your “IDEA”

Wireframe your “IDEA”

Introduction It all begins with an idea in mind, often asked question how do we write specifications and why do we

READ MORE