Customer Wants vs Needs
This cluster debates the nuances in product development between building what customers explicitly request versus what they truly need and will pay for, stressing the importance of deep conversations to uncover underlying problems rather than blindly following feature requests.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Happy this conversation helped you :)I find this topic to be really sensitive to me as I find that the first impact with the customer is always a big reality check for every idea I have.I often find myself building what “I think” people/companies want, but I think it’s healthy to try and build what they’re already willing to pay for!
I've been working on a project recently. Review after review with the president of the company. He's a good dude but new ideas are frequent, and he is almost too focused on what the thing should be / look like / etc. Same with our customer paying for it (but who doesn't use it) who has strong feelings about "if it does X, Y will happen".They're all more experienced with the industry than I, but their explanations didn't quite jive. I'm n
Why you should look beyond what users are asking for in feature requests.
"you need to talk individually to early adopters to make a really good product" The text is really about this.
Ah, okay. Took that to mean customer support or similar. Customers sometimes describe what they want, not what they need, what they would pay for, what might change things entirely, etc. There is some amount of product direction that is made without existing customer input.
Build what your customers want (and will pay for), not what they say they want. These can be the same thing, but often are not.
This. Don't develop the product you want - develop the product users can access.
When in doubt, ask 'What will add value to my users?' If the answer is 'I don't know' then step away from the desk and go talk to them.
You're both right and wrong; on the one hand it is often hard to figure out what people want based on what they say and trial and error works (lookup "skunkworks") well in many industries as long as you 1) keep failure costs low 2) have methodology to rapidly progress from failures and instantly apply insights. On the other hand, sanj is right to - there are many better ways to go about this. Think about all the things that tick you off about non-technical sites (sites that a larger audience c
he brings up about givign people what they want and not what you ask for. that is so hard to do. how many times have you built what you envisioned and then went, "This is what i asked for, but it doesn't feel right." The key is conversation, the more back and forth you have with customers, the more you will get a feel for what they really want.