Most Product Managers have, at one time or another, heard the apocyphal quote often attributed to Henry Ford, “If I asked my customers what they wanted, they’d have said a faster horse.” And when we hear the line, we laugh because there’s no way that we would do such a thing — the “faster horse” is a fictional thing that we’d never actually spend out time and effort working on. We slap each other on the back, smile, and then go back to our office where all too often we return to working on the “faster horse” that we’ve deluded ourselves into thinking is innovative and fresh. It’s an unfortunate fact that much of what we do really is just delivering faster horses, giving our customers what they say they want (or worse, what sales tells us they say they want), and not digging deep enough to uncover the real need, problem, and desire that’s driving the request.
“Faster Horses” Aren’t Always Bad
First, if you’re building a faster horse, don’t beat yourself up about it right away. A lot of work that needs to be done on a product actually does fall into the “faster horses” category — there are bare minimums that customers expect from our products, there are competitive features that we have to check boxes for on RFPs, there are features that your CEO insists simply must be built, regardless of whether you’ve dug in to discover the root cause of the pain. This is a normal part of the job of a Product Manager, making sure that we’re doing the things that will meet the minimum expectations of our customers, our market, and our internal stakeholders. Not everything we do is going to be ground-breaking, innovative, or a fresh take on a latent problem. Sometimes we need to just go with the flow and check the boxes that we’re asked to. It’s all part of the game.
Everything Shouldn’t Be a “Faster Horse”
But it’s only part of the game. Maybe 25% of it, at the maximum threshold of acceptable behavior as a Product Manager. The other 75% of what you do needs to involve deeper analysis, deeper understanding, and actual customer research. Making connections and getting information directly from our customers is so incredibly cheap in most markets these days that it’s ridiculous and negligent of us to not do so when we’re working on some problem or solution that’s been brought to us, or that we’ve created from nothing but our own knowledge and intuition about the world in which our product lives. We need to practice the five why’s, active listening, user empathy, and other methods of engaging with the people who are actually using our product, so that we gain a deep understanding of their motivations, problems, and concerns. And we need to fight for this insight, for these practices, for the value that they bring, even if it’s not popular, even if people don’t see the value, and especially when people think they know the customer from their view in a corner office and conference calls with sales and marketing. We need to engage in the behaviors that we know are likely to lead to resounding success and innovation that matters — which means fighting the good fight for really understanding and engaging with your customers and users, not just using anecdotes and hearsay to decide what to do next.
Avoid “Faster Horses” By Just Doing Your Job
As Product Managers, we suffer from that same myopia all too often. We’re busy people, negotiating with developers, reviewing marketing and sales collateral, creating user stories and prioritized backlogs. And all of that takes time, energy, and effort — all too often leaving us with no time or capacity to actually engage with our customers. And all too often, we do so in the name of “making sure it’s done right” and allowing others in the organization a pass on their own responsibility and accountability to do their jobs. Developers should be able to work through a sprint with a modicum of questions that can be answered as they come up. Marketing and Sales should be empowered and capable of developing their own collateral and materials without the constant oversight of a Product Manager. Our backlogs should require regular care and maintenance, but they should also be able to live on their own for a week or so, and then be reviewed when we come back down to Earth. One of the best things about Product Managers is our desire to not only enable other people in the organization for success, but to shepherd them toward it whenever possible. But when we take on such a high touch approach inside the company, we’re sacrificing perhaps the single most important part of our job — engaging outside the company. Any Product Manager who goes more than two weeks without actual contact with a real customer or user isn’t doing their job effectively. They’re sacrificing a short-term need for a long-term benefit. They’re abrogating their own responsibilities as a driver of user-centered design, an advocate for data-driven decisions, and ultimately their role in the organization as the voice of the customer. You can’t be that, if you’re never actually listening to what customers actually have to say.
