When users request a specific feature, like an API, don't take it at face value. Ask 'why' to uncover the underlying job-to-be-done. The user's goal might be a centralized view of comments, which can be solved with a dedicated feed—a much simpler solution than building a full API.
Related Insights
Asking users for solutions yields incremental ideas like "faster horses." Instead, ask them to tell detailed stories about their workflow. This narrative approach uncovers the true context, pain points, and decision journeys that direct questions miss, leading to breakthrough insights about the actual problem to be solved.
Even roles far from the customer, like engineering, make countless micro-decisions. Without an intuitive understanding of customer pull—what they're trying to achieve and why they're blocked—these decisions will likely miss the mark, even when just following a requirements document.
Users aren't product designers; they can only identify problems and create workarounds with the tools they have. Their feature requests represent these workarounds, not the optimal solution. A researcher's job is to uncover the deeper, underlying problem.
Customers request specific features (supply), but this masks the true demand—the underlying problem they're trying to solve. Focusing on the 'why' behind the request leads to simpler, more effective solutions, like building a digest email instead of a complex 'advanced settings' page.
When handed a specific solution to build, don't just execute. Reverse-engineer the intended customer behavior and outcome. This creates an opportunity to define better success metrics, pressure-test the underlying problem, and potentially propose more effective solutions in the future.
Avoid the trap of building features for a single customer, which grinds products to a halt. When a high-stakes customer makes a specific request, the goal is to reframe and build it in a way that benefits the entire customer base, turning a one-off demand into a strategic win-win.
Truly innovative ideas begin with a tangible, personal problem, not a new technology. By focusing on solving a real-world annoyance (like not hearing a doorbell), you anchor your invention in genuine user need. Technology should be a tool to solve the problem, not the starting point.
When designing for kids, the founder learned not to take feature requests literally. A child asking for a bike basket to hold rocks isn't just asking for a rock holder; they're expressing a deeper need for a versatile container for their adventures. The key in user research is to infer the underlying problem from their specific examples.
Instead of waiting for experience teams to request an API, platform teams should analyze top-level business goals and proactively propose services that unlock new use cases. This shifts the dynamic from a reactive service desk to a strategic partner.
To cut through MVP debates, apply a simple test: What is the problem? What is its cause? What solution addresses it? If you can remove a feature component and the core problem is still solved, it is not part of the MVP. If not, it is essential.
