Asking your customers what they want doesn't work
Product builders argue that directly implementing customer feature requests often backfires, because users typically describe their own imagined solutions rather than the underlying problems they need solved. Instead, commenters advocate approaches like “jobs to be done,” observing real behavior, probing for root pains, and validating willingness to pay, while warning against over-indexing on loud minorities, internal politics, or sales-driven one-off demands. The core tension is between respecting user input and exercising strong product vision to create solutions customers will actually adopt and pay for.
Limits of “Ask Customers What They Want”
- Many argue customers often describe solutions near what they already have, not what would truly help.
- Requests are frequently contradictory or mutually exclusive; people only realize tradeoffs when pressed.
- Vocal minorities can distort perceived demand (e.g., small phones, dresses with pockets).
- Some see the title idea overused as an excuse to ignore legitimate user needs.
Focusing on Problems / Jobs-to-be-Done
- Strong support for asking: “What problem are you solving?” or “What job are you hiring this product to do?”
- Milkshake and commute stories: improving the “product” only made sense once the actual job (easy breakfast while driving, shorter commute) was understood.
- Similar lens applied to AirPods, Segway vs scooters, cars vs “faster horses.”
Observation vs Direct Questioning
- Watching users work (screen recordings, shadowing, support standups) is seen as more revealing than self-reported wants.
- XY problem: users describe their own proposed solution; you must dig to uncover the underlying pain.
- However, some complain that overzealous “you don’t really want X” responses can be infuriating when X is actually well thought through.
Product Vision vs Feedback
- Distinction drawn between:
- Visionary product creation (intuition, prior research, timing).
- Iterative refinement (usability tests, bug fixes, confused flows).
- Examples like touchscreen phones show going against stated preferences can succeed if the overall experience is better, though missteps (no apps/3G/copy-paste) show vision is fallible.
Validation, MVPs, and Experiments
- Some insist “don’t build before validating”; others say their best work came from building for their own known problem first.
- Validation can mean: presence of a painful problem, hacked-together user solutions, paid commitments, or rapid low-cost experiments (manual workflows, quick toggles) before full implementation.
Enterprise/B2B Complications
- Buyer ≠ user: features may exist solely to satisfy procurement, compliance, or checklists (e.g., SAML/SSO), even if rarely used.
- Sales-driven feature demands (“can’t close without X”) are common; sometimes justified, often wrong, and expensive in long-term maintenance.
General Takeaways
- Listen broadly but take little at face value; synthesize rather than implement literally.
- Ask what users want to do, what they don’t want, and what they’d actually pay for.
- Being a real user of your own product is repeatedly cited as a powerful compass.