I agree that doing more listening than speaking when talking to customers is important.
It's also important to remember that customers will tell you they want features they they won't actually use or pay for. So it's necessary to develop an understanding of what your customers do and what problems they're trying to solve.
This often helps more than just listening to features they say they want. If your customers aren't in the business of building products (especially software products), their ability to ask for features is limited by the fact that if you're not an expert in how the product is created, it is difficult or impossible to know what features might be easy to add, and which ones are difficult.
It's even likely that you can add features that your customers that your customers don't even know are possible. In this case, they won't be able to ask for those features, or anything like them. As an expert (in software, or any other specialized product development field), taking the time to really understand your customers, the problems they face, and the jobs they are trying to accomplish can help you come up with new features and products that actually amaze your your customers and attract new ones.
I would add that when you put a person in a position that you have asked them for input, they will feel pressured to give SOME kind of input, whether or not it is actually warranted. You're kind of setting them up to give input in the same way you might set someone up to tell a joke, they feel pressured to fill that space with SOMETHING.
Most of the time when I have built features that came from customers, it ends up being the least used feature of a particular update cycle. Sometimes to the point that we have to reverse or highly modify it later. The reason your customer isn't in the business of making the thing you're making, is because they have no idea how to make that thing.
If you ask a person what they want out of a new Ford car, they are not going to say "Brake pads with a higher durability for longer use," they are going to say "More cupholders wouldn't hurt, and maybe you could offer it in magenta?"
Instead, you need to ask your customer about what they are doing in areas around your software. Not "What would you like in a new car?" but "What have you been doing in your car?" and "How much maintenance do you have to do?" and "What's the worst thing about the stuff you do in the car?"
Then maybe you can find out that the brakes make a squealing sound because they are mis-adjusted and are wearing out the pads too early.
Great points! Being willing to listen is step 1. That's the product culture that needs to exist first and foremost. Completely agree with you: knowing what to do with the feedback you receive, and how to interpret it in order to innovate and solve real problems is the key that I firmly believe drives the ultimate success of a product. That's a product development/design problem that's alluded to in the middle of the article, but hard to really do it justice in a few small blurbs. Feels like a good topic to be the subject of its own stand-alone post as a follow-up to this one :)
"Part 2: Listen to Your Customers, but Don't Do Everything They Say" haha.
As you pointed out, you did allude to it in the article. I was just trying to add a bit more based on first hand experience with software customers.
And hey, sometimes customers will just flat out tell you that they need a feature that is blindingly obvious to them, but didn't occur to your product development team. It's nice when it is that easy.
So I agree that the knowing how to interpret what your customers say is and important part of being able to act on what they share with you. That certainly doesn't diminish the importance of anything you wrote, though. Without engaging with customers and properly listening to them, there wouldn't be any information to interpret.
There can be counterexamples to that advice. Maybe since Tailwind is in the B2B space, this affects their bias of the recommendation.
If you're in the Enterprise/SaaS/B2B space, it seems more common to closely track what your (paying) customers want.
However, if you're in B2C or mass market, there are successful examples of being bold with providing something your customers didn't ask for. An example is the Facebook "newsfeed" feature rollout in 2006.[1] They initially had a user revolt over it but Mark Z and his team stuck to their guns and sure enough, the newsfeed became addictive and contributed to the envious engagement metrics that Myspace/Friendster couldn't match.
It's the modern variation of Ford's apocryphal "if I had asked people what they wanted, they would have said faster horses."
But that doesn't mean all counter-intuitive decisions by businesses always make sense. Steve Jobs removing the floppy drive on iMac met disapprovals and eventually was vindicated by fast USB adoption ... but the jury is still out on removing the headphone jack from the iPhone 7.
Setting aside the missteps by Apple, a creative startup could identify with Steve Jobs saying, "customer's don't know what they want until we've shown them."
> It's the modern variation of Ford's apocryphal "if I had asked people what they wanted, they would have said faster horses."
This x100 times. After building several B2B products I've found that the most successful features are the ones the customers weren't expecting and didn't ask for...
It's ok to do customer development in order to track what your users want and at least cover their expectations, but you'll never create amazing products with this mentality...
"You'll never create amazing products with this mentality..."
I think that this kinda misses the point. If you're only building the things they explicitly ask for, then yes, you're right. However, customer development isn't mean to track what your users want and cover their expectations; it's to uncover the biggest pain points/real problems to come up with amazing solutions for - what's actually _worth_ pursuing and potentially building? How exactly those solutions manifest themselves often times does not come directly from customers, but the amazing ones are just as often inspired by insights gleaned from customer development.
The article you shared actually backs up my point exactly. Example: what could be obvious to one of your customers can end up being amazing to you and your other customers. In practice, I've found this dynamic play out time and time again.
The Atari Lynx wasn't massive because it needed to be; the creators listened to their customers:
"In all the focus group testing, and we did a lot of it with consumers, we had a bunch of different models that we showed them," Mical recalled in an interview with 1UP.com. "[We asked] "which one do you like? Which one would you like to have it be?" We showed them big ones; we showed them little ones. We showed them gigantic ones; we showed them little tiny ones. They loved the big ones. They all told us, 'Make it big. Make it big. This one feels like it's substantial and I'm really getting my money's worth.' They all told us to make it big, so we made it big. And when it came out on the market, they all said, 'Why is this damn thing so big?' It'd drive me nuts, because the original Lynx was mostly air space inside. We put it in, because that's what they told us they wanted."
Focus groups are absolutely the worst way of getting product insights. Unless they are extremely well run to counterbalance a huge number of cognitive biases and random influences within the group, don't do them. They can be worse than useless.
Yep, and in addition to not knowing what they want (at least sometimes), customers also don't generally have a detailed understanding of the costs associated with building new features. It's easy to say "I want X" if you're not the one who has to build it, integrate it into an existing platform, support it, etc.
Also, "customers" are not a monolithic group. Some will try to pull you in one direction, and others will want you to go the opposite way. You'll go crazy trying to please all of them. Just saying "listen to your customers; they'll tell you what to build" is a massive oversimplification.
At the end of the day, customer feedback can be very valuable, but only as a starting point. You have to internally decide which of the things, if any, you actually want to build.
But if you wrote a blog post that said: "listen to your customers and consider building what they ask for", it would sound obvious (because it is) and wouldn't drive any clicks.
Firstly, you might consider that close to all basic ideas behind objectively successful products (eg the telephone, Facebook, photo copiers, Twitter, rabbit vibrators) were NOT arrived at by asking the target audience what they wanted. Most were intuition born of observing that audience.
When you ask people direct questions about what they want, it takes a great deal skill and judgement to actually get a successful product idea from that. In fact it's almost not worth the bother, and few professional designers really do it very often by choice. Far better to try to observe what people do (often by giving them tasks to complete in some sphere of activity) and see what comes out of that. You might see your target audience performing needless operations, misunderstanding things, or doing things that appear irrational to you but rational to them. Once you see that sort of thing happening, it's far easier then to see what they might need or really want.
I wouldn't go so far to say that asking people what they want is a bad idea, but it's getting close. Perhaps it's a mildly toxic idea best avoided in preference to observation.
Users are a source for problems, not solutions, that's the designer's job. However, the most common way that users articulate problems is in the form of solutions. It's then the designer's job to reverse engineer what the problem is from the proposed solution and design a solution that both fixes the problem and is contextually appropriate to the rest of the product.
So when you listen to users and they tell you "you should do X", just blindly doing X is a path to failure but similarly ignoring them is also a path to failure.
There's an art to properly eliciting insight from users and it's a mix of observation, interrogation and thought. In general, the best advice I've found is focus on the emotional and not the logical. When you ask when was the last time you had a problem with our product, you force the user to come up with ad-hoc logical arguments and paradigms that are most often wrong. If you ask when was the last time you were frustrated or annoyed with our product, you hone in much more reliably on real sticking points.
One of my teachers used to express this succinctly the following way -
Imagine a patient going to a doctor and asking a course of antibiotics. Any doctor would erase that request and start asking the patient to describe their problem. This, he said, is the core of how a user feedback conversation should go.
I should add that the key to this, also mentioned also in the article, is frequency. Observe often. Over time, you can then build hypotheses (which you can then also test out if you want). To use a crass example, Steve Jobs was anecdotally very driven by hypothesis. This (perhaps accidentally) let him to stick to his guns in design decisions because he was able to say things like, "I believe people want visually desirable computers in their homes, not overtly functional ones".
I built my business by listening to customers. Do I discount a bunch of ideas that come my way? Absolutely.
But over over time you begin to develop a filter that separates really good ideas and mediocre ideas that serve a single or rare use case.
Observing is great if you have the bandwidth, but if you're a one-person-show, listen to your customers, listen to your instinct, and develop features that are going to drive revenue and push you forward.
I think that the key questions are not what you want or what you want to have but rather what you want to do or even more importantly what you want to accomplish.
Of course in addition UX designers do have their own demons to fight. I would call one of them as cosmic expansion of the space, that is - contrast will decrease and distance between meaningful UI elements will increase over the time.
Agreed, When conducting user feedback we always try to identify what the users frustrations are and then our team will work on coming up with solutions based off our findings.
No, because heatmaps only tell you what is happening, not why.
And even then they can be telling you nothing at all because you don't know things like user intent. Harry Brignull's summary of the issues on this is required reading here (about eye tracking but applies to all such heat mapping tools):
Working as a designer, I've come to appreciate a lot of the ideas in Non Violent Communication. This is more or less the central idea of NVC: needs are very low level and highly likely to be shared by many people, whereas the strategies used to fulfil those needs are much more specialized and particular to a person or a small number of people.
People will communicate and confront you with their strategies for fulfilling the need they have rather than communicating the need itself.
Learning to "listen for needs" is not only valuable for conflict resolution, but also for service development.
This is very true. I'm going to read the NVC book after reading your comment.
Similarly, I've found that users often express all sorts of suggestions for how to accomplish some need they have. While many of their ideas are (from a UX/design standpoint) horrible, the core need is valid and often highlight something important that has been misunderstood or overlooked by the design.
The hardest people to get "needs" information from are intelligent, computer-literate people, who are often unwilling to admit that they find something counter-intuitive, and often frame their feedback in a way that conceals that fact... But who will end up not using something because of the friction that a suboptimal design causes.
I've also found it helpful to let people draw mocks of their solutions with a sharpie and to also share my own impromptu sharpie mocks with them based on their feedback.
At the very least, this process makes them feel respected and lower their guard which can often help them share information that is helpful in designing a product.
The craziest moments are when it turns out after weeks of trying to understand a user's feedback, that the user simply wanted a report view of some information and was trying to give feedback to make an interaction design turn into a report. This is quite common, especially in a feedback group where the highest status person is the manager who does actually need a report but is offering general feedback on general usability.
You must listen to your customers, but then you must conceptualize their needs, prioritize them, and think about how to solve those needs well.
There is nothing worse than a "Christmas tree product" where every customer has hung some requirement and there is no conceptual unity or design. Loads of "enterprise" products are hairballs like this.
Most people will read this title as, "Build what your customers tell you to build." The key here is that most customers will be happy to tell you they want all kinds of features and the best/only solution or feature looks like X. You have to go deeper. You have to listen to understand what they actually need.
I hate being that guy that trots out a quote from a historic figure, but c'mon, this is a slam dunk:
"If I had asked people what they wanted, they would have said faster horses."
Yup. To be blunt, customers often don't know what they need. Often they don't even know what their real problems are.
But they know what their pain points are, and a good BA or Product Manager/Owner will know how to dig into those pain points and unearth the real problems that need solving, and how best to go about solving them.
Great example of this is from a music software from Propellerheads. Everyone was complained about the bulky, sluggish file browser. It stayed like that for a few versions, but then they reinvented the whole file browsing experience instead of doing the easy solution of just making it simply faster.
Sometimes there can be value in doing rapid shallow MVP type iteration with key customers, but there should ideally be a step between that and stuff going into the mainline product where somebody thinks.
The signal to noise ratio tends to be poor though. So many will insist and swear and beg and threaten about what they think they need, or what they used to do, or what they won't pay for but would like to have if it's free and maintained indefinitely. There's often a background noise of "all change is bad" and some improvements are not as clear as helicopter vs rush hour traffic, so the benefit will take time to appreciate.
The trick, of course - and rather old news - is reading between the lines and not becoming arrogant in response to the lower quality feedback. You probably don't know better than them AND they probably don't know what they want.
This is true. And the bigger a company is the more there is to trawl through.
Still, you get stuff like this 14 page thread dating back two years asking Dropbox to stop forcing new folders to automatically sync[1], or this 10 page thread spanning 3½ years where adding an external email to hotmail/outlook.com was broken[2]. Never any official response, just moderators posting form responses like robots. Those are where I feel things have gotten a bit ridiculous, when the company stops ever interacting with the customers at all.
Oh my god I can't stand moderator responses. Worse when they're just copy+paste and they didn't even read your request/question. Been happening on Github more and more too with issues.
Very true. The helicopter vs. rush hour example is kind of like finding the holy grail, and that's what you strive for. In practice, the majority the improvements you can extract from these conversations end up being much smaller. But many small improvements compound and also help create the invaluable customer feeling of "Hey, I feel like the team behind this product really gets me!"
Also, well put: "You probably don't know better than them AND they probably don't know what they want."
Great point about the signal to noise ratio. One interesting thing there is how the ratios differ between a mostly emotional experience (a new social platform for example) vs.. say.. a product that helps the user make more money (most B2B).
You'll often have much less noise when all of your users want roughly the same specific thing.
But, like you said, there's definitely still a bunch of noise.
For sure it gets a lot worse if you have multiple different groups saying different things and you don't know which are the most important or profitable.
If Apple did that than they would been out of business 25 years ago.. Steve Jobs did not ask Apple customers what to build but predicted what in the future apple should build to get more customers.
This is not to say that customer feedback is not important but to clarify that it pertains to very short-term marketing in that it only refers to somewhat minor-point increments in fine-tuning the current product.
I have to whole-heartedly disagree with this. Customer development and feedback don't just apply to short-term marketing and minor-point improvements. That couldn't be further from the truth.
The "They'll tell you what to build" isn't meant to be taken literally. If you listen and try to truly understand people's problems, they'll guide you towards the most useful solutions. Coming up with those solutions is still up to you in most cases, though.
Re: Apple - they understood the real problems that their potential customers had. No, customers didn't come and tell them to go and build a device like the iPhone. However, from understanding the market and the pain points that people had with mobile phones, Apple was able to identify an opportunity to enter a new market and disrupt it.
Actually, I'd suggest people did tell them to build the iPhone, and the iPod.
They looked at the problems with the MP3 market at the time, tiny devices with poor user-interfaces and their solution to the state of the market at the time was the iPod. Unexpected from Apple which was only a computer company at the time.
Once we had our iPods we were carrying around an iPod and a phone (Blackberry was huge at the time). They understood customers wanted a single device, it had to have great messaging like a blackberry, and do all the music and video needs of an iPod of that era. Blackberry had apps, a web-browser, maps, etc. It's important not to forget that. Apple did a better job with the browser and gave the thing a full-size touch screen. Customers didn't ask for that, but they had asked for the basic device. Apple took what was asked for and put their own scrutiny to it to see just how amazing they could make it.
Readit News
It's also important to remember that customers will tell you they want features they they won't actually use or pay for. So it's necessary to develop an understanding of what your customers do and what problems they're trying to solve.
This often helps more than just listening to features they say they want. If your customers aren't in the business of building products (especially software products), their ability to ask for features is limited by the fact that if you're not an expert in how the product is created, it is difficult or impossible to know what features might be easy to add, and which ones are difficult.
It's even likely that you can add features that your customers that your customers don't even know are possible. In this case, they won't be able to ask for those features, or anything like them. As an expert (in software, or any other specialized product development field), taking the time to really understand your customers, the problems they face, and the jobs they are trying to accomplish can help you come up with new features and products that actually amaze your your customers and attract new ones.
I would add that when you put a person in a position that you have asked them for input, they will feel pressured to give SOME kind of input, whether or not it is actually warranted. You're kind of setting them up to give input in the same way you might set someone up to tell a joke, they feel pressured to fill that space with SOMETHING.
Most of the time when I have built features that came from customers, it ends up being the least used feature of a particular update cycle. Sometimes to the point that we have to reverse or highly modify it later. The reason your customer isn't in the business of making the thing you're making, is because they have no idea how to make that thing.
If you ask a person what they want out of a new Ford car, they are not going to say "Brake pads with a higher durability for longer use," they are going to say "More cupholders wouldn't hurt, and maybe you could offer it in magenta?"
See also "The Bike Shed Problem": http://bikeshed.org/
Then maybe you can find out that the brakes make a squealing sound because they are mis-adjusted and are wearing out the pads too early.
"Part 2: Listen to Your Customers, but Don't Do Everything They Say" haha.
As you pointed out, you did allude to it in the article. I was just trying to add a bit more based on first hand experience with software customers.
And hey, sometimes customers will just flat out tell you that they need a feature that is blindingly obvious to them, but didn't occur to your product development team. It's nice when it is that easy.
So I agree that the knowing how to interpret what your customers say is and important part of being able to act on what they share with you. That certainly doesn't diminish the importance of anything you wrote, though. Without engaging with customers and properly listening to them, there wouldn't be any information to interpret.
They very rarely had any idea about what they wanted to see behind the curtains.
If you're in the Enterprise/SaaS/B2B space, it seems more common to closely track what your (paying) customers want.
However, if you're in B2C or mass market, there are successful examples of being bold with providing something your customers didn't ask for. An example is the Facebook "newsfeed" feature rollout in 2006.[1] They initially had a user revolt over it but Mark Z and his team stuck to their guns and sure enough, the newsfeed became addictive and contributed to the envious engagement metrics that Myspace/Friendster couldn't match.
It's the modern variation of Ford's apocryphal "if I had asked people what they wanted, they would have said faster horses."
But that doesn't mean all counter-intuitive decisions by businesses always make sense. Steve Jobs removing the floppy drive on iMac met disapprovals and eventually was vindicated by fast USB adoption ... but the jury is still out on removing the headphone jack from the iPhone 7.
Setting aside the missteps by Apple, a creative startup could identify with Steve Jobs saying, "customer's don't know what they want until we've shown them."
[1] https://techcrunch.com/2006/09/06/facebook-users-revolt-face...
This x100 times. After building several B2B products I've found that the most successful features are the ones the customers weren't expecting and didn't ask for...
It's ok to do customer development in order to track what your users want and at least cover their expectations, but you'll never create amazing products with this mentality...
Relevant: "Obvious to you. Amazing to others."
https://sivers.org/obvious
I think that this kinda misses the point. If you're only building the things they explicitly ask for, then yes, you're right. However, customer development isn't mean to track what your users want and cover their expectations; it's to uncover the biggest pain points/real problems to come up with amazing solutions for - what's actually _worth_ pursuing and potentially building? How exactly those solutions manifest themselves often times does not come directly from customers, but the amazing ones are just as often inspired by insights gleaned from customer development.
The article you shared actually backs up my point exactly. Example: what could be obvious to one of your customers can end up being amazing to you and your other customers. In practice, I've found this dynamic play out time and time again.
"In all the focus group testing, and we did a lot of it with consumers, we had a bunch of different models that we showed them," Mical recalled in an interview with 1UP.com. "[We asked] "which one do you like? Which one would you like to have it be?" We showed them big ones; we showed them little ones. We showed them gigantic ones; we showed them little tiny ones. They loved the big ones. They all told us, 'Make it big. Make it big. This one feels like it's substantial and I'm really getting my money's worth.' They all told us to make it big, so we made it big. And when it came out on the market, they all said, 'Why is this damn thing so big?' It'd drive me nuts, because the original Lynx was mostly air space inside. We put it in, because that's what they told us they wanted."
http://www.usgamer.net/articles/too-good-for-its-day-ataris-...
Also, "customers" are not a monolithic group. Some will try to pull you in one direction, and others will want you to go the opposite way. You'll go crazy trying to please all of them. Just saying "listen to your customers; they'll tell you what to build" is a massive oversimplification.
At the end of the day, customer feedback can be very valuable, but only as a starting point. You have to internally decide which of the things, if any, you actually want to build.
But if you wrote a blog post that said: "listen to your customers and consider building what they ask for", it would sound obvious (because it is) and wouldn't drive any clicks.
Welton's law of startup advice: for each trite bit of advice, there is an equal and opposite bit of trite advice.
Firstly, you might consider that close to all basic ideas behind objectively successful products (eg the telephone, Facebook, photo copiers, Twitter, rabbit vibrators) were NOT arrived at by asking the target audience what they wanted. Most were intuition born of observing that audience.
When you ask people direct questions about what they want, it takes a great deal skill and judgement to actually get a successful product idea from that. In fact it's almost not worth the bother, and few professional designers really do it very often by choice. Far better to try to observe what people do (often by giving them tasks to complete in some sphere of activity) and see what comes out of that. You might see your target audience performing needless operations, misunderstanding things, or doing things that appear irrational to you but rational to them. Once you see that sort of thing happening, it's far easier then to see what they might need or really want.
I wouldn't go so far to say that asking people what they want is a bad idea, but it's getting close. Perhaps it's a mildly toxic idea best avoided in preference to observation.
So when you listen to users and they tell you "you should do X", just blindly doing X is a path to failure but similarly ignoring them is also a path to failure.
There's an art to properly eliciting insight from users and it's a mix of observation, interrogation and thought. In general, the best advice I've found is focus on the emotional and not the logical. When you ask when was the last time you had a problem with our product, you force the user to come up with ad-hoc logical arguments and paradigms that are most often wrong. If you ask when was the last time you were frustrated or annoyed with our product, you hone in much more reliably on real sticking points.
Imagine a patient going to a doctor and asking a course of antibiotics. Any doctor would erase that request and start asking the patient to describe their problem. This, he said, is the core of how a user feedback conversation should go.
This is exactly right and IMO one of the most important skills a PM should have.
But over over time you begin to develop a filter that separates really good ideas and mediocre ideas that serve a single or rare use case.
Observing is great if you have the bandwidth, but if you're a one-person-show, listen to your customers, listen to your instinct, and develop features that are going to drive revenue and push you forward.
Of course in addition UX designers do have their own demons to fight. I would call one of them as cosmic expansion of the space, that is - contrast will decrease and distance between meaningful UI elements will increase over the time.
And even then they can be telling you nothing at all because you don't know things like user intent. Harry Brignull's summary of the issues on this is required reading here (about eye tracking but applies to all such heat mapping tools):
http://www.slideshare.net/harrybr/what-you-need-to-know-abou...
People will communicate and confront you with their strategies for fulfilling the need they have rather than communicating the need itself.
Learning to "listen for needs" is not only valuable for conflict resolution, but also for service development.
Similarly, I've found that users often express all sorts of suggestions for how to accomplish some need they have. While many of their ideas are (from a UX/design standpoint) horrible, the core need is valid and often highlight something important that has been misunderstood or overlooked by the design.
The hardest people to get "needs" information from are intelligent, computer-literate people, who are often unwilling to admit that they find something counter-intuitive, and often frame their feedback in a way that conceals that fact... But who will end up not using something because of the friction that a suboptimal design causes.
I've also found it helpful to let people draw mocks of their solutions with a sharpie and to also share my own impromptu sharpie mocks with them based on their feedback.
At the very least, this process makes them feel respected and lower their guard which can often help them share information that is helpful in designing a product.
The craziest moments are when it turns out after weeks of trying to understand a user's feedback, that the user simply wanted a report view of some information and was trying to give feedback to make an interaction design turn into a report. This is quite common, especially in a feedback group where the highest status person is the manager who does actually need a report but is offering general feedback on general usability.
You must listen to your customers, but then you must conceptualize their needs, prioritize them, and think about how to solve those needs well.
There is nothing worse than a "Christmas tree product" where every customer has hung some requirement and there is no conceptual unity or design. Loads of "enterprise" products are hairballs like this.
TL;DR: It's not listen -> implement. It's listen -> THINK -> implement.
I hate being that guy that trots out a quote from a historic figure, but c'mon, this is a slam dunk:
"If I had asked people what they wanted, they would have said faster horses."
Don't worry, it was a made up quote. You're safe.
Deleted Comment
But they know what their pain points are, and a good BA or Product Manager/Owner will know how to dig into those pain points and unearth the real problems that need solving, and how best to go about solving them.
The trick, of course - and rather old news - is reading between the lines and not becoming arrogant in response to the lower quality feedback. You probably don't know better than them AND they probably don't know what they want.
Still, you get stuff like this 14 page thread dating back two years asking Dropbox to stop forcing new folders to automatically sync[1], or this 10 page thread spanning 3½ years where adding an external email to hotmail/outlook.com was broken[2]. Never any official response, just moderators posting form responses like robots. Those are where I feel things have gotten a bit ridiculous, when the company stops ever interacting with the customers at all.
[1] https://www.dropboxforum.com/t5/Dropbox/Stop-auto-inheriting...
[2] https://answers.microsoft.com/en-us/outlook_com/forum/oemail...
Also, well put: "You probably don't know better than them AND they probably don't know what they want."
This is not to say that customer feedback is not important but to clarify that it pertains to very short-term marketing in that it only refers to somewhat minor-point increments in fine-tuning the current product.
The "They'll tell you what to build" isn't meant to be taken literally. If you listen and try to truly understand people's problems, they'll guide you towards the most useful solutions. Coming up with those solutions is still up to you in most cases, though.
Re: Apple - they understood the real problems that their potential customers had. No, customers didn't come and tell them to go and build a device like the iPhone. However, from understanding the market and the pain points that people had with mobile phones, Apple was able to identify an opportunity to enter a new market and disrupt it.
They looked at the problems with the MP3 market at the time, tiny devices with poor user-interfaces and their solution to the state of the market at the time was the iPod. Unexpected from Apple which was only a computer company at the time.
Once we had our iPods we were carrying around an iPod and a phone (Blackberry was huge at the time). They understood customers wanted a single device, it had to have great messaging like a blackberry, and do all the music and video needs of an iPod of that era. Blackberry had apps, a web-browser, maps, etc. It's important not to forget that. Apple did a better job with the browser and gave the thing a full-size touch screen. Customers didn't ask for that, but they had asked for the basic device. Apple took what was asked for and put their own scrutiny to it to see just how amazing they could make it.
Any reference on this?