Skip to main content

Faster Horses

“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford

Henry Ford has so many memorable quotes but this one is definitely my favorite. I was reminded of it earlier today by Eric Dodds posing an oft-wondered question - “is the customer always right?”

It’s an important thing to consider for any company, as the answer to this question will greatly influence how products, ideas, marketing strategies, etc, are imagined and developed. How much stock should you put into input from your user base? How much should you trust your own instincts and experience in your respective field? What happens when these two approaches conflict?

To many people, the answer would seem obvious and likely something along the lines of:

Of course the customer is always right! If the customer isn’t happy, then you don’t have a business!

While I would completely agree with the obviousness of needing customers to support a business, I don’t believe that a users happiness is dependent on giving them exactly what they ask for. Rather, a customers happiness is dependent on meeting whatever need it is they’re seeking fulfillment for, as best as you can — exceeding their expectations, when possible.

I often find myself depending on Henry Ford’s wisdom when making design and development decisions. Perhaps it seems prideful of me but I tend to rely heavily on my own instincts when creating something. However, this certainly doesn’t mean that I ignore user input. On the contrary, I listen very carefully to users. But here’s where the Henry Ford approach comes into play — instead of asking a user how they would like for me to solve their problem, I listen more for the central “story” of what their problem is.

In light of this thought process, it’s important to understand two things that Henry Ford was not saying:
  1. Users are stupid
  2. Users don’t know what they need

On the contrary, users know exactly what they need. The challenge in meeting their needs is that users are often ignorant — the word “ignorant” being used in the purist possible way (i.e. not indicating stupidity). Using a simple tautology, you don’t know what you don’t know — and nobody can be faulted for that.

This is what Henry Ford did so well. He listened for the central story. Since automobiles hadn’t been mass-produced or perfected yet in the early 20th century when Ford began working on the Model T, the general population wouldn’t have known to ask for a car. However, what they did know is that they wanted to get between point A and point B at a faster pace.

Fortunately for us, Henry Ford was not content to simply seek out faster horses. And we shouldn’t be either.


  1. "Rather, a customers happiness is dependent on meeting whatever need it is they’re seeking fulfillment for, as best as you can — exceeding their expectations, when possible."

    Very well said. The lesson is that there is a disparity between our actual problems and our ability to communicate about them with imperfect or incomplete knowledge.

    Great stuff—keep it coming!

  2. Great content, expertly delivered


Post a Comment

Popular posts from this blog

The Future of Education

It's always very interesting to me to see the directions that people go after college. I know several people who have degrees in Graphic Design and are now database administrators and administrative assistants. Others I know have degrees in Finance and are now Worship Pastors. An Art History major who's a full-time nanny, an Interior Design major who's a Campus Manager for a church, the list goes on an on.

This pattern could be indicative of many things. Perhaps the job market at the time didn't present any opportunities for the chosen field when graduation came. Maybe after 4 years of studying towards a degree in a particular topic, there was a realization that it really wasn't that enjoyable. However, I'm convinced that it correlates to the state of the education system. Not that it's necessarily broken, and certainly not that it's useless, but that it's due for some thoughtful reconsideration.

According to a study done by Jaison Abel and Richard Di…

Building a Product

This is the second post in a series I’m writing about a company I’m starting up (or have started, depending on when you’re reading this). You can read other posts in the series here.
As I’ve talked about here, I’m starting a company called MailSnail. In this post, I want to share the ins and outs of how we’ve built the product (i.e. the actual web application).

The Buzzwords I’ve tried my hardest to make this post as approachable as I possibly can for anybody and everybody. I don’t want this to be something that is only interesting to folks who know what HTTP stands for or can rattle off it’s associated status codes. So for my non-tech readers, please bare with me for this one section and keep on reading.

For my fellow tech-nerds, I figured you might not care so much about the minute implementation details but rather are just more interested in a list of all of the pieces of our tech-stack (because you already know the implications of each in their use). So here’s the quick and dirty …

MailSnail Series

Starting in August of 2015, I began building a company called MailSnail with my friend and co-founder, Matt Bertino. To follow along with my personal thoughts on the ins and outs of the company, experiences, lessons learned, technical details, etc., please check out the posts below. I’ll continue to add new posts here as I publish them.

Post 1: Starting a Company
Post 2: Building a Product
Post 3: Launching a Product