Mockery Blog

“If I’d asked people what they wanted, they would have said a faster horse.”

- Henry Ford

I just heard that quote yesterday from a pretty smart guy, and I really like it. Some people disagree, but I couldn’t agree more. Sliced Bread Design had a great and very detailed take on it. My favorite bit from it:

So, what should Henry Ford have been asking his customers? Instead of, “What do you want?” he could have asked, “Is there anything you particularly like or don’t like about your horse and wagon?”

You can probably very easily ask someone what software they want you to build, bang out the code, and deliver exactly what they asked for. They might even be really happy with it. But if that’s all you’re doing, what separates you from everyone else? What we need to do is break down user requests into desired implementations and desired results.

Implementations are a means to an end.

Customers are not going to make clear distinctions in feature requests between desired implementations and desired outcomes. It is up to us to do make that distinction, because if we can come up with a better implementation that produces the same result, we both win. A customer may ask for a dialog, but what he/she’s really asking for is whatever that dialog lets them do.

Applying this to Henry Ford’s quote, if we had a customer ask us for a faster horse, we could simply break down the request into implementation and outcome. The desired outcome is fairly clear; get me and my stuff from point a to point b faster. The desired implementation? Some kind of rocket-powered superhorse. The outcome is what the customer is willing to pay for, though; the implementation is merely a suggestion. If you can can come up with a better implementation (and Henry Ford sure did), people will not be disappointed.

As a developer, it’s easy to become fixated on details; they’re our bread and butter. That’s why it’s important to take a step back when analyzing customer requests and remember that users have exactly the opposite fixation. They’re willing to work with just about any implementation that lets them accomplish their task. We need to give them what they really want, whether or not it’s what they asked for.

Sometimes it occurs to me that I’m putting up with unreasonable pain from the software I use on a day-to-day basis. It’s really easy to get into habits and put up with some pretty big deficiencies.

I think it’s dangerous allowing users to put up with annoyances. You’re basically training them to dislike and resent your software and pushing them to find a replacement. Just getting the job done is not nearly good enough.

I will not allow this to happen with Mockery. I’ve got the UserVoice page set up. I’m on top of support emails. The rest of this is just a process of making sure that users communicate any issues to me and making sure there aren’t any annoyances just minor enough for people to work around them.