Faster horses and the Model T: Flaws in the classic product manager’s adage

As product managers, we’ve all heard the adage that if Henry Ford had asked people what they wanted, they would have said a faster horse. And if he’d listened, the Model T might have been designed to gallop in exchange for carrots.

In all seriousness, you can expect that any mention of Ford or horses in product management circles are the opening notes of a clarion call to banish focus groups and user research, break out your black turtleneck and dad jeans, and GO BUILD SOMETHING TRULY GREAT.

This is terribly misguided. It’s an idea that poisoned the mindset of product managers for years, and needlessly delayed the rise of lean product management and the age of product discovery.

PMs who rely solely on gut intuition to make product decisions (just to maintain the self-image of a lone wolf product genius) are setting themselves up to waste thousands of hours developing products and features that no one wants or needs.

The Henry Ford camp peddles a false dichotomy — that either we can go build exactly what our users ask for, or we can lock ourselves in a room with a whiteboard, stack of post-its, a crate of Soylent, and commence innovating.

There’s a third alternative here. We can get out of the building, listen to our users, work to uncover their underlying needs, then assume our responsibility as PMs of guiding our teams toward the best possible solution for the functional and emotional needs we’ve identified.

Get out of the building, listen to users, work to uncover their underlying needs, then assume our responsibility as PMs of guiding our teams toward the best possible solution for the functional and emotional needs we’ve identified.

Why are people asking for a faster horse (solution idea)?

• They need to transport themselves/goods in less time — functional need
• They need to win a horse race — functional need
• They need to razzle-dazzle a lovely dame or a dashing poodle-faker with their fancy prancing (i.e. equestrian showmanship) — emotional need

In the short run, some of these needs might best be addressed with an automobile, but others might actually be better addressed with, well… a faster (or fancier) horse.

What’s more, the needs voiced by users dictate what feature set our solution would need to have in the short-term—and long-term—to win new adopters. For example, if a core need of one segment of potential horse owners is to razzle-dazzle others with their skills and status, it might not be such a bad thing if the v1 Model T were extremely expensive and demanded significant expertise to operate. This barrier to entry could actually compel them to adopt the automobile as a way of impressing others.

So in short, asking users what they need does not mean you’ll blindly build whatever solution ideas they offer you. Your primary goal is to sleuth out underlying needs a novice PM would have missed at first glance, and this is where the masterful technique comes in. We’re all pretty bad at identifying our own needs, and even then, might not be willing to admit (even to ourselves) that our core need in horse ownership is to razzle-dazzle others.

It’s hard for PMs to tease out these details, but productboard CEO Hubert Palan has a priceless tip for you. Without further ado, here’s how you can help users lock on to their own needs and willingly explain them to you:

TL;DR

• People don’t talk about problems naturally. Their thinking is framed by the existing solution.
• What you want to do, and where user research is really valuable, is to find out what needs users have. Ask why people need faster horses and focus on that (then ask why again, and then maybe one more time…). It’s not the job of the customer to figure out a solution. It’s your team’s job. Your job as PM is to understand the problem.
• To make things more concrete, ask about existing solutions that people are using. They are a solid indication of the underlying problems. If there is no existing solution, not even an attempt at a homegrown, hacked together one, you might determine whether the user’s need is significant enough to warrant your team’s time in solving it.
• To get the best information about underlying needs, avoid leading the witness —i.e. asking “Hey, would you use my product?”
• Key technique: Say to the user: “So, it sounds like [their existing solution] is actually working pretty well!” They’ll no longer be defensive about their current way of doing things, or feel like you’re hard-selling them on an alternative. This often sparks a wave of pain points that they’ll be happy to describe for you and THAT might just spark the next great solution idea.

.     .     .

productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a 15-day free trial of productboard today.