Don't Build What They Ask For: The Art of Need-Finding
11/23/2024
Exploring the critical skill of discovering what customers truly need versus what they ask for, and how this shapes better product decisions
Written by: Jonathan Haas
“If I had asked people what they wanted, they would have said faster horses.” This quote, often attributed to Henry Ford, encapsulates one of the most challenging aspects of product management: the gap between what customers ask for and what they truly need. In the trenches of product development, we’re constantly navigating this delicate balance between listening to our customers and interpreting their deeper needs.
The Feature Request Trap
When a customer says “I need a faster horse,” they’re not really asking for a faster horse. They’re expressing a need for more efficient transportation. When they say “I need an export to Excel button,” they’re often not really asking for Excel integration—they’re expressing a need to analyze or share data in a way their current tools don’t support.
Yet the allure of the direct feature request is powerful. It comes pre-packaged with apparent clarity: a specific solution we can immediately understand and estimate. It feels actionable. It seems to reduce risk—after all, we’re giving customers exactly what they asked for. But this is often an illusion.
The Archaeology of Need
Finding the true need beneath a feature request is like archaeological excavation. Each layer you remove reveals something closer to the truth. Here’s how to dig deeper:
1. The Five Whys of Feature Requests
Start with the request and keep asking “why?” until you reach bedrock. Let’s take a real example:
Customer: “We need the ability to export our data to Excel.”
- Why? “So we can create monthly reports for management.”
- Why do you need these reports? “To track trend changes in user behavior.”
- Why are trend changes important? “To identify potential churn risks early.”
- Why is early identification crucial? “Because our retention efforts are most effective in the first signs of disengagement.”
- Why? “Because once users fully disengage, they rarely come back.”
Now we’ve uncovered something valuable: This isn’t about Excel exports—it’s about proactive churn prevention. The solution might be automated churn prediction alerts, not an export function.
2. Context Is Everything
Feature requests don’t exist in a vacuum. They’re shaped by:
- The customer’s current workflows and tools
- Their past experiences with other products
- Their understanding of what’s possible
- Their organizational constraints
- Their immediate pain points
Understanding this context is crucial. Often, a feature request is constrained by what the customer believes is possible, not what would best solve their problem.
3. The Jobs-to-be-Done Framework
Instead of asking “What feature do they want?” ask “What job are they trying to get done?” This shifts the focus from solutions to outcomes. Consider the classic example of the milkshake study: Customers weren’t buying milkshakes because they wanted a milkshake—they wanted something to make their morning commute less boring and keep them full until lunch.
The Art of Saying No While Saying Yes
Once you understand the true need, you often find yourself in a position where you need to reject the specific feature request while still addressing the underlying problem. This requires:
1. Empathetic Communication
Show that you understand both their request and their need: “I hear you asking for Excel export capabilities, and I understand the crucial need to identify churn risks early. Let me show you how we’re thinking about solving this…“
2. Solution Exploration
Present alternative solutions that might better address the core need: “Instead of requiring you to export and analyze data manually, what if we built automated alerts that notify you when we detect early signs of user disengagement?“
3. Iterative Validation
Propose quick experiments to validate your understanding: “Before we build a full export system, could we try sending you automated weekly reports with the key metrics you’re looking for?”
The Long-Term View
Building what customers ask for might win you short-term praise, but building what customers truly need wins you long-term loyalty. The key is to:
- Make need-finding a continuous process, not a one-time event
- Build trust through demonstrated understanding of customer problems
- Educate customers about what’s possible beyond their current context
- Share your product vision and help customers see how solving their true needs fits into it
Closing Thoughts
The gap between what customers request and what they need represents both the greatest challenge and the greatest opportunity in product management. By developing the skills to bridge this gap—to excavate true needs from feature requests—we can build products that don’t just satisfy customers but delight them in unexpected ways.
Remember: Customers are experts in their problems, not necessarily in the solutions. Our job is to be experts in finding and building the right solutions to those problems, even when—especially when—they differ from what was initially requested.
The next time a customer comes to you with a feature request, treat it as the starting point of a conversation, not the end of one. The true need is out there, waiting to be discovered.