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.
Here's what Alex (atopiler) Slacked me yesterday after he read the article in draft "One thing that I felt didn’t really come through fully was some of the true essence of cust-dev calls. This is the product snob in me talking, but it felt a bit like we're listening to what our customers wish for, and we build what they tell us to build. When it comes down to it though, what the calls really reveal, and what we’re really trying to understand more deeply than anything else is what are biggest problems and frustrations they’re dealing with on a day-to-day basis? Why are these things frustrating? Why do they put themselves through that frustration? And what would it enable them to do if those problems didn’t exist?"
And that became that middle section.
Thanks to all of these comments I'm seeing the light of what he was really getting at there and I've salted the headline and some of the earlier passages to set that up a little better.
p.s. this is my intro to HackerNews - you guys are awesome.
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. 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."
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."
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."
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):
How do you determine why something is happening?
This is the work of the UX designer. It takes time an effort. PMs usually don't have the time or understanding to do it properly, so products and companies often suffer. This is why, personally, I would be more inclined to invest in companies that have actual UX designers working for them than mere jack-of-all PMs. But hey.
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.
2) Anyone who's interested to read more on this made-up quote should see this HBR article:
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, or this 10 page thread spanning 3½ years where adding an external email to hotmail/outlook.com was broken. 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.
To allow me to fully assist with your issue, can you please make sure you've completed the following steps:
- Restart your PC.
- Copy down any annoying messages from moderators that you see.
- Try reading the messages again to see if you feel better about them now.
If this message was helpful, please remember to upvote and mark as SOLVED.
Also, well put: "You probably don't know better than them AND they probably don't know what they want."
You can't just ask customers what they want and then try to give that to them.
By the time you get it built, they'll want something new.
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?
I was thinking, wow, he is just talking sending sms messages. The crowd would laugh or woot in what seemed to be agreement.
He didn't know what he wanted, but there was a problem that he and everyone wanted a solution for. At the time in the 90s, it was a social problem (not wanting to waste time with an annoying person on the phone) but in the 2000's that problem was solved with technology.
A lot of times, customers do not know what they want. Imagine what Jerry's answer would have been if we had asked him a question about pinging his contacts list to know if they were available in 1991. He wouldn't have understood and honestly, no one would want to carry around a massive rolodex at the time, so the answer would have been silly at best.
I did find the video .. someone else noticed the same thing.
I've got a product that is growing nicely and that users love, but we haven't been able to monetize it yet. Lots of other comments point to things like Ford's (misattributed) "they'd say I want a faster horse".
Don't ask people directly what they want, find out what they are doing, what they need to do, and you'll start to find a pattern emerge.
The reason I feel you can't know what you want to find out or discuss is that you can miss exactly what the customer is telling you.
In my experience, I will often ask pointed questions about what more we can do, and I get blank stares and uses just say "it's great" and give me requests for minor improvements. When I probe them about other parts of their business, they open up about what they are doing in other segments which to them are completely different than what we do, but when I point out the similarity, and what we could do in these other areas to help them out, they perk right up and come up with a bunch of good ideas that they are happy to pay for.
So be flexible, and look for patterns more than answers. I'd also suggest, if you're in the same place as I am looking to monetize an existing product that most see as free, ask where they are spending money and see if there is opportunity for those funds to be re-allocated to you.
The first few pages blew my mind. It was a great read all the way through.
One of the main takeaways of the book is that you should always start by asking factual questions. What do you do. What software do you use to do that. When's the last time you did that. How did you feel about it. Etc.
No "What ifs", no "would yous." Don't ask how much they would pay if [you could code whatever feature by next week].
That may seem obvious, but most people go for the second type of question right away.
For example, Michelangelo was told to paint certain things, but it's how he did it that made him legend.
The real beauty, the real success of a thing, lies in the how, not necessarily the what.
It's 1901. I want a horse and buggy that can go 55 mph.
There really is no substitute for having someone (or a team) study the area in detail who has the background to be able to understand the problem(s) and is able to translate this understanding into a development plan. For anything but the most trivial problems this requires a large investment in time, money and effort.
Just blindly doing what your customers tell you is not what you should be doing, it's just design by committee on a massive scale.
True business acumen comes from understanding two things that are not as obvious:
1. A customer often does Not Know what he wants.
2. What a man wants is malleable and can be shaped and influenced by forces created by other men.
> If I had asked people what they wanted, they would have said faster horses
"I want faster (or better) horses". Needs a follow up question or ability to understand the deeper core meaning.
From the above quote. These are some off top of head self distilled thoughts on what that means
I want to get from point a to b faster. (faster vehicle or teleportation.)
I want less time traveling.
I want less prep time for traveling(E. G. Saddling horse).
I don't want to take care of my means f transportation (offer a stable service or offer non animal vehicle)
I want my destination closer.(urban)
I don't want to go to the store to buy X. (delivery service. Ala amazon?)
I want faster Internet vs I want to reach my final destination faster are similar but different outcomes.
Would you rather have Google load pages 100x faster or have above 99% chance to guess the site you really wanted/needed.
When you walk into a hardware store and ask for a 2-inch drill bit, it's not the tool you really want. What you really want is a 2-inch hole in the wall.
Years ago I saw an interview with a Sami. 'Why snowmobile instead of reigndeer?' 'I don't have to spend half an hour chasing down my snowmobile.'
Customer Development is a process that's really meant to be applied to prospective customers. The whole point is to figure out what problems the market needs, and ultimately what kind of solutions there might actually be a market for.
Instead of building something and then going to people and asking if it's useful, find out what a large segment of the market would find useful first.
Get out of the building and talk to actual people - create simple experiments to help you prove whether a market actually exists. Validate your assumptions before building. Follow the Lean Startup methodology :)
Nobody is going to tell you how to do it. it has to come from you.
On the other hand, steve jobs didn't need to ask his customers how they'd like an iphone - he told them why they'll like it.
-Vincent Van Gogh, hypothetical
Starry Night (Value: est. ~$80M-$100M+)
Vincent Van Gogh, Actual