15 ms·

Asking your customers what they want doesn't work

332 points by AntonZ234 3y ago

bbor 3y ago
Idk if I’m convinced by “HCI dogma disproven because sometimes customers are contradictory or unclear”. If you forgive the clickbait headline and actually read the (pre-promotion?) article, it’s good stuff - totally agree that it’s about asking customers questions that help you answer your questions, not just letting them design the product directly.
- mysterydip 3y ago
  Also true the old adage "if you try to please everyone, you'll end up pleasing no one". Your most vocal complaints do not necessarily translate to the largest majority issue (I'd say often quite the opposite). Make sure any changes won't alienate your core demographic.
  - Affric 3y ago
    This is true to a large extent but if you let edge cases build up over a long time you end up with an n-dimensional long tail. A whole bunch of customers to whom you’re not providing the expected quality of service. It depends on the type of good/service/commodity you supply.
sjfjsjdjwvwvc 3y ago
Asking customers what they want - or rather what their problem is - doesn’t work but it’s the best method we have
kazinator 3y ago
What people say they want is usually a stone's throw from what they already have. If you radically want to change what people have, asking people what they want won't get there.
kraig911 3y ago
about 10+ years ago I was asked to make a system that would give users the ability to get an email alert "whenever something happened on their server" Well users said they wanted it and welp when a user turned the feature on as asked they got a lot of emails... I think the disconnect isn't that we should give users what they ask but try and make something that can help their problem from their perspective. I've also been on product teams that would per se "we'll just make sure they won't need to be alerted if something happens on their server - we won't let it happen"
gyomu 3y ago
The cliché quote of “if Henry Ford has asked people what they wanted, they’d have said a faster horse” is a cliché for a reason. Most people don’t know what they want - that’s why good product designers who can identify, synthesize, and execute products are worth big money. There are 2 things to differentiate - product vision, and learning how to listen to feedback. The former, designing new products that solve people’s problems, is a craft that has no silver bullet. It requires a mix of experience, intuition, technical know how, observing the landscape of existing alternatives, knowing how to anticipate technical/economic/sociological evolutions, etc. The latter is about making sure that what you designed does what you intend it to, identifying what confuses your users, what gets in their way, etc. This is where all the classical methods of user observation/testing/surveys/etc can be useful. This sounds easy and obvious, but it is anything but - i have met my fair share of designers who stick to their principles and are unwilling to budge when reality conflicts with their ideology, companies that inexplicably never fix bugs that most of their users encounter and rage about on the support forums/social media, etc. The two are very different skillsets, and it’s hard enough to be good at one, let alone both. The article uses Intuit as a case study; the dynamics of how to do genuinely great work when your business involves selling an antidote to a poison you lobby for is an exercise left to the reader.
- nradov 3y ago
  And yet there is still a significant global industry for breeding faster horses. It's much smaller than the auto industry, but still a profitable niche.
  - justinl33 3y ago
    But for a completely different customer segment too.
  - jiggawatts 3y ago
    Do you commute to work in a car, or on horseback?
    - nradov 3y ago
briantakita 3y ago
I wonder how many of your customers secretly don't want to be your customer but have to be for some reason or another. If this is the case, then asking these customers for what they want may illicit a response to create satisfaction from their unsatisfactory circumstance.
bruce511 3y ago
I do a lot of email support, and I find lots of examples of the XY problem masquerading as a feature request. [1] Someone will ask for some feature - and usually its easy to add - but I try and understand the root problem first. Mostly they don't tell me the problem, they tell me their solution. This is often either a bad approach or a flat-out wrong approach. Implementing it "as asked" doesn't help. The only way for me to add a feature elegantly, and to documentation in a way that will be useful to others, I to understand the root pain it is fixing. This also makes it easier to sell. "Identify the pain. Make it go away" is a powerful sales technique. Lastly, sometimes the pain is internal - the Sales team need it fixed, not the customer. Some features get added because -decision makers- think its important, and it demos well, although we know full well that customers will never actually use it. [1] https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem
- cratermoon 3y ago
  There's also stuff that comes from inside organizations, and sometimes the business can't even say why they want something, other than "it checks a box we think we should check". Especially true when replacing legacy software, there's always pressure to port over cruft even when there's high confidence that it's not used any more and costs more to build than it's worth. Some business people just can't let go of, for example, generating reports that no one ever actually reads.
WalterBright 3y ago
What works better is asking them what their problems are. What also works is I ask myself, what do I want? Since I'm a programmer, pleasing myself goes a long way towards pleasing the users.
corethree 3y ago
Whenever I see stuff like this I think of Steve jobs: In 2007, right before the first iPhone launched, Steve Jobs was asked the obvious question: The design of the iPhone was based on discarding every physical interface element consumers were used to except for a touchscreen. Would consumers be willing to give up the then-dominant physical keypads with tactile feedback for a more clumsy experience with a touch screen keyboard? His answer was brusque: “They’ll learn.”
- magicalhippo 3y ago
  And I still long for physical keys on my "smartphone" as I miss every 3rd letter or so on that flat surface with zero tactile feedback...
  - corethree 3y ago
    Steve was prescient. He's so knowledgeable about consumers he knew that consumers would willingly take UI/UX design and back pedal by several decades just to accept the novelty of a dynamic touch screen. As much as you as a consumer hate the touch screen... consumers as a whole are the ones who chose to go this direction.
    - tsimionescu 3y ago
      I think this is a misunderstanding of the UX of phones. The fact that keyboard input is harder on a touchscreen than a physical keyboard is of course a disadvantage. But it is a much smaller disadvantage than the UX gains from having more screen space for content when you're not typing. Also, a touchscreen is much better for input than a keyboard for various navigation features - panning, zooming, selection, not to mention many styles of games are all more suited to touchscreen input then keyboard input. So, the choice is between a phone with a good keyboard but half the screen size (horrible for the web, maps, photos), or a phone with a subpar but still functional keyboard with a full screen. The UX is clearly overall much much better on the second one.
      - 3y ago
lgkk 3y ago
From experience customers never know what they want. There is a reason you, as an entrepreneur, are passionate about building something that’s hopefully better at solving the problem. I really hate the advice of don’t build something before validating. That has literally never worked for me. That’s like asking a leading question and shooting yourself in the foot at the same time. You should have some conviction why you’re doing something. Don’t one of those people who tries to do something in an industry they have zero clue about (99% chance of failure). If you know what you’re doing you should have a 60% plus chance of success. It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.
- nine_k 3y ago
  > don’t build something before validating It depends on what counts as validation. To me, it's the presence of the problem, and how many people are looking for some solution. This is why, I think, many validation-first sites are intentionally vague when describing the solution.
  - mindcrime 3y ago
    To me, it's the presence of the problem, and how many people are looking for some solution. I love how Steve Blank talks about the ideal situation being when the customer has already cobbled together a solution from an old vacuum cleaner, four dozen zip ties, an Arduino, a stepper motor, and some old coat hangers (or whatever). Why? Isn't it bad when the customer already has a solution? Well maybe sometimes. But if the underlying problem is a high value problem, the customer has - by cobbling something together - validated A. that the problem exists, and B. that they need a solution. And if they're smart, they know they don't want to be in the business of maintaining this cobbled together P.O.S. which works 63% of the time, violates half a dozen fire-code regulations, and isn't remotely close to being their core competency. No, they want somebody like you to come along and offer a proper solution and will probably purchase your solution as long as the price is right or you don't blow the sale in some other way.
- ryanjshaw 3y ago
namuol 3y ago
Great podcast on the subject from some product people from Basecamp: https://demandthinking.com/episodes/2017/7/23/episode-1-think-you-might-be-building-the-wrong-thing-youve-misinterpreted-demand https://demandthinking.com/episodes/2017/7/23/episode-1-thin...
ConcernedCoder 3y ago
I often tell my wife my software job is like being a home builder, people think they know what they want, but it's not until they're standing in the thing trying to use it that they figure out what parts work and don't work well for what they actually need... and I spend quite a bit of iterating before we end up with the final working thing -- which is usually far removed from the initial design.
- AntonZ234 3y ago
  That's a great metaphor.
- robocat 3y ago
  Do you have another metaphor where improvement actually occurs? I learn unforeseen faults in my house, but the faults don't get fixed. Good software fixes its problems where the home builder metaphor lacks that concept.
wduquette 3y ago
First you ask what they want; then you ask what problem they are trying to solve. It’s that second one that’s important.
pcurve 3y ago
The article basically quotes this video clip of Clay Christensen. https://www.youtube.com/watch?v=Stc0beAxavY https://www.youtube.com/watch?v=Stc0beAxavY I included this video in a onboarding guide for my team and many enjoyed it.
- john-tells-all 3y ago
  Clay Shirky told the same story in his excellent book `Cognitive Surplus: Creativity and Generosity in a Connected Age` https://witandwisdomofanengineer.blogspot.com/2010/07/engineering-milkshake-mistakes.html https://witandwisdomofanengineer.blogspot.com/2010/07/engine... TLDR: McDonald's customers buy milkshakes. Marketing people ask customers how they can make milkshakes better... to sell more. They make changes with zero change in sales. A researcher asks people who buy milkshakes: what is the job that the shake fills for you? Why do you "hire" the shake? Answer: early morning commuters want something to eat while driving to work. A shake isn't a good breakfast, but it's quick and easy to buy then consume while driving to work. Satisfying. The point is making a shake "better" won't help anyone! "How can we make it better" is the wrong question!
  - esafak 3y ago
    Making it easier to drink on the road, easier to buy, etc. would make it better for this use case. So "better" is contextual.
- AntonZ234 3y ago
  Yeah, most of the article is direct quotes from his book 'Competing against luck'. I felt he tells it in an amazing way, so no need to ruin that :)
skgough 3y ago
If people knew how to solve their own problems they wouldn't be giving you their money. I know there's a modicum of technical ability necessary to do certain things with computers, but for the most part, those can be solved by following rules and creative use of Excel. The value comes from giving people a framework to solve their problems, doing the thinking for them while accounting for the edge cases that they didn't get to, and then compiling that system of rules into a program.
exabrial 3y ago
Hilariously, asking them what they DON’T want actually does work in practice. Asking your customers what they want is a form of designed by committee. What people want is the well thought out, self consistent vision of a single artist, minus a few things.
nfriedly 3y ago
I'm biased, but I think FullStory is really useful for seeing where people are hitting hiccups when trying to use your software, and you can often tell what they were trying to do, e.g. clinking thr visa icon instead of the credit card button in a checkout form.
- bezier-curve 3y ago
  I was going to look this up, but it seems at least one of the people that maintain my pihole's lists have already blocked the domain. In any case, I like not being monitored in real time.
  - adra 3y ago
    The whole concept of real user monitoring is that it allows you to detect erroneous patterns in how they specifically use your product, so that you can ideally fix said problems if they're common enough. I'm not wildly excited over the idea of being tracked either, and ideally this is something driven via the site offering the service, but it can be a very valuable tool for FE devs to figure out why customers are having a negative experience without having to tell you explicitly, which is great.
jvm___ 3y ago
If Henry Ford asked his customers what they wanted they would say faster horses.
- nitwit005 3y ago
  And faster horses would have made a fortune if he could have produced them.
  - bluGill 3y ago
    Not really because horses are expensive. They eat even on days you don't use them. Miles per hay bale needs to be asked about. Those using a horse already wanted a faster one. Most people would not have found a fast horse better. Henry Ford gave the people faster transport that they could afford.
    - nitwit005 3y ago
      You can still, to this day, make considerable money selling faster horses.
- ipaddr 3y ago
  Why wouldn't they say faster travel?
  - motoxpro 3y ago
    The same reason they wouldn't go one step further than that and say more time with my family.
csours 3y ago
I like the article, HATE the title. You should ask your customers lots of stuff, and take VERY LITTLE at face value. Implementing features that customers ask for is a sure path to ruin; you have to keep asking questions and digging in beyond just "I want it to do X." To be fair, that is basically what the article says, I'm just very tired of the cliched title. Also, I second the recommendation for Christensen and Deming, and I will add Sidney Dekker, primarily "Field Guide to Human Error" but I'm sure the other books are also very good.
- mindcrime 3y ago
  You should ask your customers lots of stuff, and take VERY LITTLE at face value. Exactly. But a time when you can take it at face value is when the question is something along of the lines of "will you sign a purchase order for this right now?" or the like. And to tie back to what someone in another post here said about validation: one of the best way to validate that your solution is real, and will actually sell to the customer (which is the only thing that matters, from a certain point of view) is exactly to ask your customer "will you buy this, right now?" or a close variant. If the answer is "yes, send the bill and get the order underway" then you've validated something. If you get hemming and hawing and "well, maybe, let me talk to the purchasing committee" or whatever, you're still just thrashing around. And even if you don't go for the actual sale yet (maybe the product isn't ready yet) you can take the approach Steve Blank[1] talks about, and work up to a questions of the form "would you pay a million dollars for this right now" and "well, how much would you pay for it then?" and "if I offered this to you FOR FREE right now, would you start rolling it out immediately" etc. Those answers will really tell you something about where you really stand in your customer's eyes vis-à-vis actually selling your thing. [1]: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/0989200507 https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
  - bluGill 3y ago
    Even the purehase order isn't always enough. If the cost of developing that feature, inclueding long term maintenaece is less than they are willing to pay fine. However often they are buying from you to share costs wiht your other customers, and what they want is you to split the costs.
polishdude20 3y ago
It does but you need to ask them more vague questions. Like, with the car vs horse thing, depending on the way the question is asked, they'll either say "a faster horse" or "a way to get home faster so I can spend more time with my kids" This involves actually getting to know your customers and not just treating them as pawns to make more money. You want to find the underlaying wants.
- cratermoon 3y ago
  Reminds of the story about commuters saying they want a toaster in their car when what they really want is to spend less time commuting so they have time to make toast at home.
hasoleju 3y ago
Asking what job was the product hired to do is similar to my favorite question: What pain are they trying to remove with the product? Talking to customers is still important to understand the motives for their actions and the problems they have. Sometimes they even don't tell you directly that they have a problem. The action is actually normal for them and only an outsider who tries to understand what they do sees this problem. An example of this are AirPods. Everyone was used to headphones with cable. Non one identified the cable as a problem. That's why at first AirPods felt strange when you saw them. But as soon as you had your own wireless headphones you immediately noticed the problem you had with the cable. The pain of always untwisting the cable and making sure it ran nice under your jacket was real.
- 10000truths 3y ago
  > An example of this are AirPods. Everyone was used to headphones with cable. Non one identified the cable as a problem. That's why at first AirPods felt strange when you saw them. But as soon as you had your own wireless headphones you immediately noticed the problem you had with the cable. Surely you're not implying that Apple invented this? Wireless headphones and Bluetooth earpieces existed and saw widespread use long before AirPods were relevant. What Apple did was miniaturize the guts into a stylish form factor. Their branding and market share did the rest.
  - nottorp 3y ago
    > Wireless headphones and Bluetooth earpieces existed Afaik you had either full headphones with a headband, in-ears with the battery hanging off a cable between them and the one-ear standalone things that were good only for calls. Also the little charging box that you could keep in your pocket was nowhere to be seen. So yes, airpods were a lot more convenient when launched. Has little to do with branding. Everyone is cloning it now :)
ClassyJacket 3y ago
""If I'd asked my customers what they want, they'd have said a faster horse. " - Henry Ford" - Steve Jobs
jillesvangurp 3y ago
Classic mistakes in product management: 1) assuming the user understands what they want/need - this is rarely the case. Figuring out what they really need is your job. 2) assuming that what you are building is something the user wants - until people use it, you have no proof for this. Lots of startups fall into the trap of building stuff that nobody wants or needs. 3) assuming what users ask for is actually what they need - always figure out why they are asking for this, whether they are actually going to use it if you build it (I've had cases where we built stuff that was never used), and what it is worth to them. 4) assuming that what your sales people say the customer wants is actually what they want or need. This one is tricky. I've had sales people go "unless you build X, I can't close the deal" and then you build X and it doesn't make a difference. Reason: the sales person's analysis was wrong. Especially with new products, figuring out if it is something users want is tricky. Do users actually like the new thing? They won't be asking for it because it is a new thing. You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need. The classic example is selling cars when they were invented is that all customers ever asked for was faster horses.
- xkcd1963 3y ago
  1 and 3 is the same, if 4 then add 5) assume what devs say is actually what they want or need
  - jillesvangurp 3y ago
    They are similar but there's a difference between a customer explicitly asking for something / demanding it, and soliciting feedback.
- nirvdrum 3y ago
  > The classic example of selling cars when they were invented is that all customers ever asked for was faster horses. I look at the Segway as a counter example. Maybe people really did just want a faster way to walk through a city. No offense to Dean Kamen —- he has a very impressive set of accomplishments. I fully support performing user studies to better understand the problem domain and the feature space. I think your bullet points illustrate some of the challenges in finding the right balance. Unfortunately, I’ve run into way more Segway builders than I have car inventors. They build something based on founder intuition or just bad user studies and then glibly dismiss customer requests as calls for faster horses. I lack the time, energy, and desire to adapt to whatever custom workflow is added because I supposedly don’t know my domain well enough to know what I want. There’s probably a B2C and B2B split in there, but I’ve never seen that distinction made in application of some of this advice. I know you aren’t advocating for the outright dismissal of user feedback, but I’ve seen that interpretation time and time again. I’d love for us to get a new metaphor or apocryphal story.
at_a_remove 3y ago
I wish understanding what the customers actually want (or even better, what they will want) were more valued in the tech world. I have a peculiar knack for it, which has extended from web design to data analysis and even tough medical conversations. One would think it to be something valuable, but instead bosses seem to value a slavish "drive into a brick wall" conformation to their orders over foresight and insight.
- motoxpro 3y ago
  Sounds like you should start a company :)
Simon_ORourke 3y ago
Both internal stakeholders and external customers don't know what they want. Recent conversation I had with a customer went... Me: Do you want X? Customer: Yes, absolutely. Me: What about Y? Customer: That too. Me: X and Y are mutually exclusive. Customer: Oh, ok. What should I ask for? As pointed out by a few posters here, your job is to tell your customers what they want.
- AntonZ234 3y ago
  I've had similar experiences with internal stakeholders.
- xg15 3y ago
  But wouldn't this also be an opportunity to dive deeper? Ok, so at a basic level you want both X and Y, but those are mutually exclusive. Why do you want both? Is one a "must" and the other a "nice to have"? Are X and Y needed in different situations/by different departments? Etc... As a concrete example, a customer demand of "I want the light be on but I also want it to be off" sounds nonsensical, but maybe they really just want to have a light switch.
SSchick 3y ago
Only clicked this to see how many people would mention 'faster horse', I was not dissapointed. Happy new year ya'll.
deleted 3y ago
[deleted]
praptak 3y ago
I remember being a dev lead for a small internal product. I think 80% of the requests were "add custom behavior guarded by a checkbox". Fortunately we could just walk over to the (internal) customers, discuss the requirements and avoid creating a single huge function with logic determined by 37 checkboxes.
- tsimionescu 3y ago
  Conversely, I've had designers who I was asking for a way to more nicely represent 37 checkboxes keep insisting that we may find a way to reduce them, even though I kept explaining that these are all features in some external protocol that we are modeling and that we can't go and ask the IETF to please reduce the options they offer. My point being that it's important to distinguish between fundamental and incidental complexity, which isn't always so clear cut. I think that's one of the hardest skills in making good products of any kind.
neilv 3y ago
> Here’s a classic example of trying to give the customers what they want, from Intuit [...] CUSTOMERS: We just want to minimize the pain of tax return filing. INTUIT: [lobbies government to keep that pain going strong]
austin-cheney 3y ago
I experienced this when I ran a moderately popular open source tool for other developers. Users have no idea what they want. The only way to know with any kind of certainty is to be both a user (customer) and the developer expert and have enough authority to tell them what they want. When you have those three ingredients selling to new users becomes much easier and well as reengaging relationships with existing users (customers). Nobody cares otherwise even if you have the best product and value on the market.
xg15 3y ago
I think instead of viewing this with the "the customer doesn't understand themselves" lens, you could better view this problem as one of misaligned goals, where asking the customer gets you advice how to archive the customer's goals, not the companies'. E.g. in the milkshake examples, customers probably were giving all kinds of advice how to make the milkshake taste better or how to streamline the buying process, etc. And this feedback would certainly improve the milkshake-buying/drinking experience of those who already decided to get themselves a milkshake. However that's not the goal of the company: The company wants to sell more milkshakes, not better ones - it probably couldn't care less what people do with their milkshakes once they bought them. So the companies' goal is probably better served by tracking their customers and finding out how they get to the decision to buy a milkshake in the first place - but that's not really the customer's goal.
- bluGill 3y ago
  Well the compeny should care what someone does as repeat customers and recomendations matter.
mattigames 3y ago
One of the most pop-culture (AKA "memed") examples of this is dresses with pockets, you find so many comments from women saying they want them, and then fail to buy then once a company is born that focus on that feature, and is not that they are purposely lying, I bet some really would like to be the kind of person who values pocket/utility over other factors, but in front of the mirror some other factors impose a bigger influence; it's just human nature, the vast majority of people in general are not what they want to be and that is just one more of those cases.
ChrisMarshallNY 3y ago
In my case, I’ve found it effective to ask a user what they want to do, as opposed to what they want.
DeathArrow 3y ago
I think the question isn't what customers want. It's rather what customers are going to buy.
- jen20 3y ago
  100% - the roles of user and purchaser being different are a good chunk of the reason most enterprise-targeted software is compete shit. The user has no choice, and the person purchasing doesn’t care provided it’s cheaper by a couple of pennies on the dollar.
  - esafak 3y ago
    Which means it's your job to educate the buyer about your product's value, not cost. If you merely want to save money, buy nothing.
mmmmmbop 3y ago
A common pitfall that isn't listed in the article is listening to a loud minority of customers. If you had been reading Hacker News or any other tech-savvy platform, you'd have been well excused for thinking there's a huge demand for a capable iPhone with a smaller screen. In reality, the sales numbers for iPhone minis were disappointing. It turns out that people spending a lot of time writing online about tech hardware are not representative of the iPhone customer base at large.
- deleted 3y ago
  [deleted]
- nottorp 3y ago
  > In reality, the sales numbers for iPhone minis were disappointing. Disappointing for Apple, i.e. only a few tens of millions. I know a few people that are very happy with their iPhone minis. They have nothing to upgrade to now. But it's cheaper this way :)
  - mmmmmbop 3y ago
    Right. I think the point of the article was to determine what's best for your business at large, not what would make a few customers happy at the expense of your overall success.
- izacus 3y ago
  > In reality, the sales numbers for iPhone minis were disappointing. Disappointing by whos metric? It outsold most Android phones and massively outsold first few iPhone models released. Were iPhones 3G, 3GS, 4, etc. also disappointing? Just because the PERCENT was low, it doesn't mean the SHIPPED UNITS were low. In reality, any company you create will sell their product in VASTLY LOWER number than any iPhone Mini. Should you be fired and go bankrupt because your sales will be disappointing by Apple standards too? Should we just liquidate all companies that cater to less than 20 millions of unit sold? Should all other companies catering to small (< 20 million, the number of small iPhones shipped) audiences not exist and be replaced by average products for average people? No more Mac Studios, no more XDR displays, no more 15" 4000$ MacBooks?
guytv 3y ago
Though not immediately relevant, it's pertinent to bring up "The Mom Test" (https://www.momtestbook.com/ https://www.momtestbook.com/) book. This book offers insights into conducting customer interviews without inadvertently guiding them towards giving the answers you want to hear, or asking them to forecast whether they'll use your product.
- thom 3y ago
  I searched the thread to make sure someone mentioned this because I found it very useful. It encourages you to ask customers about real experiences instead of opinions, and gives you ways to identify things they care enough about to invest time/money into.
xracy 3y ago
Hot take, People have spent wayyyy too long assuming they know better than their customers what they want, and oftentimes use this as an excuse to justify ignoring what customers want. Asking your customers what they want is a really good first step in figuring out what they want. You're not always going to be able to just magically intuit what your customers want. Sometimes you need to put in the hard work to figure out what they're doing and how you can make it better. I hate XY problems, because as often as I'm the person wanting to figure out what question someone is actually trying to ask, I'm the person on the other side asking an actually well-thought-out question and getting told I don't want that.
davidgerard 3y ago
> "What job were you trying to do for yourself that caused you to come here and hire that milkshake?" "hire"? This makes the text look like synonym converter output.
- dmd 3y ago
  It's either a non-native english speaker or a marketer so far up their own ass they can see daylight again ... but I repeat myself.
robviren 3y ago
I completely agree, but it sure does help to listen to everybody. I always joke that I am a complaint sponge that just absorbs every little nit pick and bother anyone has with a product. Listening is the cheapest and easiest thing I can do to make someone feel better about whatever it is I end up having to do. An overwhelming amount of the time I am unable to fulfill a request because the backlog is filled to the gills with other requests. Listening to people, asking clarifying questions, and digging into their issue and how they feel about it almost always makes them feel better. Don't retread ground that has already been covered, but I have a much better time telling them their idea may not be implemented for a long time after taking thoughtful time with them to make them feel heard. I also try to disappoint upfront. No use telling them the idea is in the backlog if they have heard that 1000 times only to have the ticket sit there for years. At worst you learn a little more what someone thinks while getting them to talk and complain, an act most people find comfort it. At best you get incredibly useful empathy on a nagging issue that can benefit others. So yes, people usually have no idea what they want, but good luck telling people that. It's the PMs job to get everybody on board for the vision of a thing and how it addresses the problems behind the problems otherwise a perfect implementation of something a customer did not feel heard on will land quite different that something that they did. My two cents for what it is worth.
alexpotato 3y ago
One thing I wish happened more often was an iterative approach to features vs time to delivery. (Speaking of having been both a customer and PM-like roles) e.g. Customer: this is a list of features I would like PM: Ok, we reviewed that list and here is a "menu" of the features with how long they will take Customer: Great! I reviewed that list and I would rather have multiple quick to market features rather than wait for that "big" feature. Asking customers what they want with no "price discovery" on either side is just people dreaming up ideas.
- esafak 3y ago
  That's more like the cost. You could also ask them what they would be willing to pay for each feature. Good idea, though!
donatj 3y ago
When we were in startup / small business mode we had a founder who was absolutely incredible at turning customer feedback into actionable and well thought out “actually here’s a better solution” He was out shortly after the acquisition, and now we get videos emailed to us by corporates UX team of them asking the worlds most inept users how things should work and given changes based directly on this feedback. I swear agreeing to be in a test group is self selecting for people who don’t understand the most basic UI metaphor. It’s frankly been a race to the bottom.
spacecadet 3y ago
J2BD is my fave framework. That and GTFO. I was just lamenting to some Clients over drinks how the tech industry has spent the last 20 years stuck in confirmation bias hell...
deimantasa 3y ago
For the last 5 or so years, I'm building mobile POC/MVP apps for my clients. I also launched several startups myself (all failed eventually). 2/3 generated some revenue. Main lessons learned and pits fallen into: - Collect feedback from the user. Once all feedback is collected, try to find patterns and understand, will solution really solve anything and if it will - how much work it takes vs how much value overall biz gets. If it doesn't bring any value/revenue - might even consider scraping feature out to not bring more tech debt along the way - Focus on only things that matter. Pretty much every single client I work with ends up implementing features that seems nice, look good, but brings little to no value to the overall biz. Feature just was built in just for the sake of having a `bigger and more functional product` - Be aware if feedback comes from payed vs free user. It's very easy to focus on wrong things as ^ Overall, I keep seeing feedback collection going well. However the conclusion from it - just getting messy.
anticorporate 3y ago
While I think there's some truth to this idea, modern companies and the software industry in particular has taken it to the absolute extreme. We're not just no longer asking people what they want, we're ignoring the existence of anything that a person could want aside from a momentary dopamine boost. It's also really pretentious. Go read Shit User Stories for some particularly amusing/egregious examples.
bob1029 3y ago
Our product's history explores the full depth of this spectrum. At the beginning, the only thing we were interested in was what our customers (banks) thought about their business and how our product might be able to improve it. We had no clue what we were doing but were accumulating ideas rapidly. We were tripping over ourselves in order to serve the customers' every last idle whim. We felt we were not worthy of their business. Somewhere in the middle, we gained traction and realized that if we built our product to make 10+ different customers happy in their own unique ways that we would have nothing in the end. Today, our product is more of a turn-key consulting package than it is any specific software or technology. Our customers look to us for guidance on how to run their businesses now. Once you are driving this kind of bus, you can normalize your software stack with much more confidence. The word "boring" has entered our lexicon recently. One fun point about our kind of customer - they are very herd-like creatures. Once you get a few of them moving in a certain direction, you can push the rest along for the ride with virtually zero effort. I am beginning to think this isn't just applicable to risk-adverse bankers.
a13n 3y ago
In consumer apps this is true. In B2B and especially enterprise it’s less true. Especially if you sell to tech companies. If your customer says they need an Okta integration with SCIM provisioning, they probably actually do need an Okta integration with SCIM provisioning, and not having that will impact your sales and retention metrics.
mch82 3y ago
“Chapter 1: The Milkshake Dilemma” from “Competing Against Luck” (Christensen 2016) cited in the article is one of my favorite nonfiction book chapters of all time. The milkshake case study perfectly illustrates the jobs-to-be-done concept that the vertical axis of the disruptive innovation graph measures. Coincidentally, I listened to the Competing Against Luck audio book on a long walk today. Fun to see it on HN.
kirykl 3y ago
Can be summed up nicely as sung by the Stones: identifying what your customers need is better than giving what they want

332 points by AntonZ234 3y ago

bbor 3y ago

Idk if I’m convinced by “HCI dogma disproven because sometimes customers are contradictory or unclear”. If you forgive the clickbait headline and actually read the (pre-promotion?) article, it’s good stuff - totally agree that it’s about asking customers questions that help you answer your questions, not just letting them design the product directly.

mysterydip 3y ago
Also true the old adage "if you try to please everyone, you'll end up pleasing no one". Your most vocal complaints do not necessarily translate to the largest majority issue (I'd say often quite the opposite). Make sure any changes won't alienate your core demographic.
- Affric 3y ago
  This is true to a large extent but if you let edge cases build up over a long time you end up with an n-dimensional long tail. A whole bunch of customers to whom you’re not providing the expected quality of service. It depends on the type of good/service/commodity you supply.

sjfjsjdjwvwvc 3y ago

Asking customers what they want - or rather what their problem is - doesn’t work but it’s the best method we have

kazinator 3y ago

What people say they want is usually a stone's throw from what they already have. If you radically want to change what people have, asking people what they want won't get there.

kraig911 3y ago

about 10+ years ago I was asked to make a system that would give users the ability to get an email alert "whenever something happened on their server" Well users said they wanted it and welp when a user turned the feature on as asked they got a lot of emails... I think the disconnect isn't that we should give users what they ask but try and make something that can help their problem from their perspective. I've also been on product teams that would per se "we'll just make sure they won't need to be alerted if something happens on their server - we won't let it happen"

gyomu 3y ago

The cliché quote of “if Henry Ford has asked people what they wanted, they’d have said a faster horse” is a cliché for a reason. Most people don’t know what they want - that’s why good product designers who can identify, synthesize, and execute products are worth big money. There are 2 things to differentiate - product vision, and learning how to listen to feedback. The former, designing new products that solve people’s problems, is a craft that has no silver bullet. It requires a mix of experience, intuition, technical know how, observing the landscape of existing alternatives, knowing how to anticipate technical/economic/sociological evolutions, etc. The latter is about making sure that what you designed does what you intend it to, identifying what confuses your users, what gets in their way, etc. This is where all the classical methods of user observation/testing/surveys/etc can be useful. This sounds easy and obvious, but it is anything but - i have met my fair share of designers who stick to their principles and are unwilling to budge when reality conflicts with their ideology, companies that inexplicably never fix bugs that most of their users encounter and rage about on the support forums/social media, etc. The two are very different skillsets, and it’s hard enough to be good at one, let alone both. The article uses Intuit as a case study; the dynamics of how to do genuinely great work when your business involves selling an antidote to a poison you lobby for is an exercise left to the reader.

nradov 3y ago
And yet there is still a significant global industry for breeding faster horses. It's much smaller than the auto industry, but still a profitable niche.
- justinl33 3y ago
  But for a completely different customer segment too.
- jiggawatts 3y ago
  Do you commute to work in a car, or on horseback?
  - nradov 3y ago

briantakita 3y ago

I wonder how many of your customers secretly don't want to be your customer but have to be for some reason or another. If this is the case, then asking these customers for what they want may illicit a response to create satisfaction from their unsatisfactory circumstance.

bruce511 3y ago

I do a lot of email support, and I find lots of examples of the XY problem masquerading as a feature request. [1] Someone will ask for some feature - and usually its easy to add - but I try and understand the root problem first. Mostly they don't tell me the problem, they tell me their solution. This is often either a bad approach or a flat-out wrong approach. Implementing it "as asked" doesn't help. The only way for me to add a feature elegantly, and to documentation in a way that will be useful to others, I to understand the root pain it is fixing. This also makes it easier to sell. "Identify the pain. Make it go away" is a powerful sales technique. Lastly, sometimes the pain is internal - the Sales team need it fixed, not the customer. Some features get added because -decision makers- think its important, and it demos well, although we know full well that customers will never actually use it. [1] https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem

cratermoon 3y ago
There's also stuff that comes from inside organizations, and sometimes the business can't even say why they want something, other than "it checks a box we think we should check". Especially true when replacing legacy software, there's always pressure to port over cruft even when there's high confidence that it's not used any more and costs more to build than it's worth. Some business people just can't let go of, for example, generating reports that no one ever actually reads.

WalterBright 3y ago

What works better is asking them what their problems are. What also works is I ask myself, what do I want? Since I'm a programmer, pleasing myself goes a long way towards pleasing the users.

corethree 3y ago

Whenever I see stuff like this I think of Steve jobs: In 2007, right before the first iPhone launched, Steve Jobs was asked the obvious question: The design of the iPhone was based on discarding every physical interface element consumers were used to except for a touchscreen. Would consumers be willing to give up the then-dominant physical keypads with tactile feedback for a more clumsy experience with a touch screen keyboard? His answer was brusque: “They’ll learn.”

magicalhippo 3y ago
And I still long for physical keys on my "smartphone" as I miss every 3rd letter or so on that flat surface with zero tactile feedback...
- corethree 3y ago
  Steve was prescient. He's so knowledgeable about consumers he knew that consumers would willingly take UI/UX design and back pedal by several decades just to accept the novelty of a dynamic touch screen. As much as you as a consumer hate the touch screen... consumers as a whole are the ones who chose to go this direction.
  - tsimionescu 3y ago
    I think this is a misunderstanding of the UX of phones. The fact that keyboard input is harder on a touchscreen than a physical keyboard is of course a disadvantage. But it is a much smaller disadvantage than the UX gains from having more screen space for content when you're not typing. Also, a touchscreen is much better for input than a keyboard for various navigation features - panning, zooming, selection, not to mention many styles of games are all more suited to touchscreen input then keyboard input. So, the choice is between a phone with a good keyboard but half the screen size (horrible for the web, maps, photos), or a phone with a subpar but still functional keyboard with a full screen. The UX is clearly overall much much better on the second one.
    - 3y ago

lgkk 3y ago

From experience customers never know what they want. There is a reason you, as an entrepreneur, are passionate about building something that’s hopefully better at solving the problem. I really hate the advice of don’t build something before validating. That has literally never worked for me. That’s like asking a leading question and shooting yourself in the foot at the same time. You should have some conviction why you’re doing something. Don’t one of those people who tries to do something in an industry they have zero clue about (99% chance of failure). If you know what you’re doing you should have a 60% plus chance of success. It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.

nine_k 3y ago
> don’t build something before validating It depends on what counts as validation. To me, it's the presence of the problem, and how many people are looking for some solution. This is why, I think, many validation-first sites are intentionally vague when describing the solution.
- mindcrime 3y ago
  To me, it's the presence of the problem, and how many people are looking for some solution. I love how Steve Blank talks about the ideal situation being when the customer has already cobbled together a solution from an old vacuum cleaner, four dozen zip ties, an Arduino, a stepper motor, and some old coat hangers (or whatever). Why? Isn't it bad when the customer already has a solution? Well maybe sometimes. But if the underlying problem is a high value problem, the customer has - by cobbling something together - validated A. that the problem exists, and B. that they need a solution. And if they're smart, they know they don't want to be in the business of maintaining this cobbled together P.O.S. which works 63% of the time, violates half a dozen fire-code regulations, and isn't remotely close to being their core competency. No, they want somebody like you to come along and offer a proper solution and will probably purchase your solution as long as the price is right or you don't blow the sale in some other way.
ryanjshaw 3y ago

namuol 3y ago

Great podcast on the subject from some product people from Basecamp: https://demandthinking.com/episodes/2017/7/23/episode-1-think-you-might-be-building-the-wrong-thing-youve-misinterpreted-demand https://demandthinking.com/episodes/2017/7/23/episode-1-thin...

ConcernedCoder 3y ago

I often tell my wife my software job is like being a home builder, people think they know what they want, but it's not until they're standing in the thing trying to use it that they figure out what parts work and don't work well for what they actually need... and I spend quite a bit of iterating before we end up with the final working thing -- which is usually far removed from the initial design.

AntonZ234 3y ago
That's a great metaphor.
robocat 3y ago
Do you have another metaphor where improvement actually occurs? I learn unforeseen faults in my house, but the faults don't get fixed. Good software fixes its problems where the home builder metaphor lacks that concept.

wduquette 3y ago

First you ask what they want; then you ask what problem they are trying to solve. It’s that second one that’s important.

pcurve 3y ago

The article basically quotes this video clip of Clay Christensen. https://www.youtube.com/watch?v=Stc0beAxavY https://www.youtube.com/watch?v=Stc0beAxavY I included this video in a onboarding guide for my team and many enjoyed it.

john-tells-all 3y ago
Clay Shirky told the same story in his excellent book `Cognitive Surplus: Creativity and Generosity in a Connected Age` https://witandwisdomofanengineer.blogspot.com/2010/07/engineering-milkshake-mistakes.html https://witandwisdomofanengineer.blogspot.com/2010/07/engine... TLDR: McDonald's customers buy milkshakes. Marketing people ask customers how they can make milkshakes better... to sell more. They make changes with zero change in sales. A researcher asks people who buy milkshakes: what is the job that the shake fills for you? Why do you "hire" the shake? Answer: early morning commuters want something to eat while driving to work. A shake isn't a good breakfast, but it's quick and easy to buy then consume while driving to work. Satisfying. The point is making a shake "better" won't help anyone! "How can we make it better" is the wrong question!
- esafak 3y ago
  Making it easier to drink on the road, easier to buy, etc. would make it better for this use case. So "better" is contextual.
AntonZ234 3y ago
Yeah, most of the article is direct quotes from his book 'Competing against luck'. I felt he tells it in an amazing way, so no need to ruin that :)

skgough 3y ago

If people knew how to solve their own problems they wouldn't be giving you their money. I know there's a modicum of technical ability necessary to do certain things with computers, but for the most part, those can be solved by following rules and creative use of Excel. The value comes from giving people a framework to solve their problems, doing the thinking for them while accounting for the edge cases that they didn't get to, and then compiling that system of rules into a program.

exabrial 3y ago

Hilariously, asking them what they DON’T want actually does work in practice. Asking your customers what they want is a form of designed by committee. What people want is the well thought out, self consistent vision of a single artist, minus a few things.

nfriedly 3y ago

I'm biased, but I think FullStory is really useful for seeing where people are hitting hiccups when trying to use your software, and you can often tell what they were trying to do, e.g. clinking thr visa icon instead of the credit card button in a checkout form.

bezier-curve 3y ago
I was going to look this up, but it seems at least one of the people that maintain my pihole's lists have already blocked the domain. In any case, I like not being monitored in real time.
- adra 3y ago
  The whole concept of real user monitoring is that it allows you to detect erroneous patterns in how they specifically use your product, so that you can ideally fix said problems if they're common enough. I'm not wildly excited over the idea of being tracked either, and ideally this is something driven via the site offering the service, but it can be a very valuable tool for FE devs to figure out why customers are having a negative experience without having to tell you explicitly, which is great.

jvm___ 3y ago

If Henry Ford asked his customers what they wanted they would say faster horses.

nitwit005 3y ago
And faster horses would have made a fortune if he could have produced them.
- bluGill 3y ago
  Not really because horses are expensive. They eat even on days you don't use them. Miles per hay bale needs to be asked about. Those using a horse already wanted a faster one. Most people would not have found a fast horse better. Henry Ford gave the people faster transport that they could afford.
  - nitwit005 3y ago
    You can still, to this day, make considerable money selling faster horses.
ipaddr 3y ago
Why wouldn't they say faster travel?
- motoxpro 3y ago
  The same reason they wouldn't go one step further than that and say more time with my family.

csours 3y ago

I like the article, HATE the title. You should ask your customers lots of stuff, and take VERY LITTLE at face value. Implementing features that customers ask for is a sure path to ruin; you have to keep asking questions and digging in beyond just "I want it to do X." To be fair, that is basically what the article says, I'm just very tired of the cliched title. Also, I second the recommendation for Christensen and Deming, and I will add Sidney Dekker, primarily "Field Guide to Human Error" but I'm sure the other books are also very good.

mindcrime 3y ago
You should ask your customers lots of stuff, and take VERY LITTLE at face value. Exactly. But a time when you can take it at face value is when the question is something along of the lines of "will you sign a purchase order for this right now?" or the like. And to tie back to what someone in another post here said about validation: one of the best way to validate that your solution is real, and will actually sell to the customer (which is the only thing that matters, from a certain point of view) is exactly to ask your customer "will you buy this, right now?" or a close variant. If the answer is "yes, send the bill and get the order underway" then you've validated something. If you get hemming and hawing and "well, maybe, let me talk to the purchasing committee" or whatever, you're still just thrashing around. And even if you don't go for the actual sale yet (maybe the product isn't ready yet) you can take the approach Steve Blank[1] talks about, and work up to a questions of the form "would you pay a million dollars for this right now" and "well, how much would you pay for it then?" and "if I offered this to you FOR FREE right now, would you start rolling it out immediately" etc. Those answers will really tell you something about where you really stand in your customer's eyes vis-à-vis actually selling your thing. [1]: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/0989200507 https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
- bluGill 3y ago
  Even the purehase order isn't always enough. If the cost of developing that feature, inclueding long term maintenaece is less than they are willing to pay fine. However often they are buying from you to share costs wiht your other customers, and what they want is you to split the costs.

polishdude20 3y ago

It does but you need to ask them more vague questions. Like, with the car vs horse thing, depending on the way the question is asked, they'll either say "a faster horse" or "a way to get home faster so I can spend more time with my kids" This involves actually getting to know your customers and not just treating them as pawns to make more money. You want to find the underlaying wants.

cratermoon 3y ago
Reminds of the story about commuters saying they want a toaster in their car when what they really want is to spend less time commuting so they have time to make toast at home.

hasoleju 3y ago

Asking what job was the product hired to do is similar to my favorite question: What pain are they trying to remove with the product? Talking to customers is still important to understand the motives for their actions and the problems they have. Sometimes they even don't tell you directly that they have a problem. The action is actually normal for them and only an outsider who tries to understand what they do sees this problem. An example of this are AirPods. Everyone was used to headphones with cable. Non one identified the cable as a problem. That's why at first AirPods felt strange when you saw them. But as soon as you had your own wireless headphones you immediately noticed the problem you had with the cable. The pain of always untwisting the cable and making sure it ran nice under your jacket was real.

10000truths 3y ago
> An example of this are AirPods. Everyone was used to headphones with cable. Non one identified the cable as a problem. That's why at first AirPods felt strange when you saw them. But as soon as you had your own wireless headphones you immediately noticed the problem you had with the cable. Surely you're not implying that Apple invented this? Wireless headphones and Bluetooth earpieces existed and saw widespread use long before AirPods were relevant. What Apple did was miniaturize the guts into a stylish form factor. Their branding and market share did the rest.
- nottorp 3y ago
  > Wireless headphones and Bluetooth earpieces existed Afaik you had either full headphones with a headband, in-ears with the battery hanging off a cable between them and the one-ear standalone things that were good only for calls. Also the little charging box that you could keep in your pocket was nowhere to be seen. So yes, airpods were a lot more convenient when launched. Has little to do with branding. Everyone is cloning it now :)

ClassyJacket 3y ago

""If I'd asked my customers what they want, they'd have said a faster horse. " - Henry Ford" - Steve Jobs

jillesvangurp 3y ago

Classic mistakes in product management: 1) assuming the user understands what they want/need - this is rarely the case. Figuring out what they really need is your job. 2) assuming that what you are building is something the user wants - until people use it, you have no proof for this. Lots of startups fall into the trap of building stuff that nobody wants or needs. 3) assuming what users ask for is actually what they need - always figure out why they are asking for this, whether they are actually going to use it if you build it (I've had cases where we built stuff that was never used), and what it is worth to them. 4) assuming that what your sales people say the customer wants is actually what they want or need. This one is tricky. I've had sales people go "unless you build X, I can't close the deal" and then you build X and it doesn't make a difference. Reason: the sales person's analysis was wrong. Especially with new products, figuring out if it is something users want is tricky. Do users actually like the new thing? They won't be asking for it because it is a new thing. You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need. The classic example is selling cars when they were invented is that all customers ever asked for was faster horses.

xkcd1963 3y ago
1 and 3 is the same, if 4 then add 5) assume what devs say is actually what they want or need
- jillesvangurp 3y ago
  They are similar but there's a difference between a customer explicitly asking for something / demanding it, and soliciting feedback.
nirvdrum 3y ago
> The classic example of selling cars when they were invented is that all customers ever asked for was faster horses. I look at the Segway as a counter example. Maybe people really did just want a faster way to walk through a city. No offense to Dean Kamen —- he has a very impressive set of accomplishments. I fully support performing user studies to better understand the problem domain and the feature space. I think your bullet points illustrate some of the challenges in finding the right balance. Unfortunately, I’ve run into way more Segway builders than I have car inventors. They build something based on founder intuition or just bad user studies and then glibly dismiss customer requests as calls for faster horses. I lack the time, energy, and desire to adapt to whatever custom workflow is added because I supposedly don’t know my domain well enough to know what I want. There’s probably a B2C and B2B split in there, but I’ve never seen that distinction made in application of some of this advice. I know you aren’t advocating for the outright dismissal of user feedback, but I’ve seen that interpretation time and time again. I’d love for us to get a new metaphor or apocryphal story.

at_a_remove 3y ago

I wish understanding what the customers actually want (or even better, what they will want) were more valued in the tech world. I have a peculiar knack for it, which has extended from web design to data analysis and even tough medical conversations. One would think it to be something valuable, but instead bosses seem to value a slavish "drive into a brick wall" conformation to their orders over foresight and insight.

motoxpro 3y ago
Sounds like you should start a company :)

Simon_ORourke 3y ago

Both internal stakeholders and external customers don't know what they want. Recent conversation I had with a customer went... Me: Do you want X? Customer: Yes, absolutely. Me: What about Y? Customer: That too. Me: X and Y are mutually exclusive. Customer: Oh, ok. What should I ask for? As pointed out by a few posters here, your job is to tell your customers what they want.

AntonZ234 3y ago
I've had similar experiences with internal stakeholders.
xg15 3y ago
But wouldn't this also be an opportunity to dive deeper? Ok, so at a basic level you want both X and Y, but those are mutually exclusive. Why do you want both? Is one a "must" and the other a "nice to have"? Are X and Y needed in different situations/by different departments? Etc... As a concrete example, a customer demand of "I want the light be on but I also want it to be off" sounds nonsensical, but maybe they really just want to have a light switch.

SSchick 3y ago

Only clicked this to see how many people would mention 'faster horse', I was not dissapointed. Happy new year ya'll.

deleted 3y ago

[deleted]

praptak 3y ago

I remember being a dev lead for a small internal product. I think 80% of the requests were "add custom behavior guarded by a checkbox". Fortunately we could just walk over to the (internal) customers, discuss the requirements and avoid creating a single huge function with logic determined by 37 checkboxes.

tsimionescu 3y ago
Conversely, I've had designers who I was asking for a way to more nicely represent 37 checkboxes keep insisting that we may find a way to reduce them, even though I kept explaining that these are all features in some external protocol that we are modeling and that we can't go and ask the IETF to please reduce the options they offer. My point being that it's important to distinguish between fundamental and incidental complexity, which isn't always so clear cut. I think that's one of the hardest skills in making good products of any kind.

neilv 3y ago

> Here’s a classic example of trying to give the customers what they want, from Intuit [...] CUSTOMERS: We just want to minimize the pain of tax return filing. INTUIT: [lobbies government to keep that pain going strong]

austin-cheney 3y ago

I experienced this when I ran a moderately popular open source tool for other developers. Users have no idea what they want. The only way to know with any kind of certainty is to be both a user (customer) and the developer expert and have enough authority to tell them what they want. When you have those three ingredients selling to new users becomes much easier and well as reengaging relationships with existing users (customers). Nobody cares otherwise even if you have the best product and value on the market.

xg15 3y ago

I think instead of viewing this with the "the customer doesn't understand themselves" lens, you could better view this problem as one of misaligned goals, where asking the customer gets you advice how to archive the customer's goals, not the companies'. E.g. in the milkshake examples, customers probably were giving all kinds of advice how to make the milkshake taste better or how to streamline the buying process, etc. And this feedback would certainly improve the milkshake-buying/drinking experience of those who already decided to get themselves a milkshake. However that's not the goal of the company: The company wants to sell more milkshakes, not better ones - it probably couldn't care less what people do with their milkshakes once they bought them. So the companies' goal is probably better served by tracking their customers and finding out how they get to the decision to buy a milkshake in the first place - but that's not really the customer's goal.

bluGill 3y ago
Well the compeny should care what someone does as repeat customers and recomendations matter.

mattigames 3y ago

One of the most pop-culture (AKA "memed") examples of this is dresses with pockets, you find so many comments from women saying they want them, and then fail to buy then once a company is born that focus on that feature, and is not that they are purposely lying, I bet some really would like to be the kind of person who values pocket/utility over other factors, but in front of the mirror some other factors impose a bigger influence; it's just human nature, the vast majority of people in general are not what they want to be and that is just one more of those cases.

ChrisMarshallNY 3y ago

In my case, I’ve found it effective to ask a user what they want to do, as opposed to what they want.

DeathArrow 3y ago

I think the question isn't what customers want. It's rather what customers are going to buy.

jen20 3y ago
100% - the roles of user and purchaser being different are a good chunk of the reason most enterprise-targeted software is compete shit. The user has no choice, and the person purchasing doesn’t care provided it’s cheaper by a couple of pennies on the dollar.
- esafak 3y ago
  Which means it's your job to educate the buyer about your product's value, not cost. If you merely want to save money, buy nothing.

mmmmmbop 3y ago

A common pitfall that isn't listed in the article is listening to a loud minority of customers. If you had been reading Hacker News or any other tech-savvy platform, you'd have been well excused for thinking there's a huge demand for a capable iPhone with a smaller screen. In reality, the sales numbers for iPhone minis were disappointing. It turns out that people spending a lot of time writing online about tech hardware are not representative of the iPhone customer base at large.

deleted 3y ago
[deleted]
nottorp 3y ago
> In reality, the sales numbers for iPhone minis were disappointing. Disappointing for Apple, i.e. only a few tens of millions. I know a few people that are very happy with their iPhone minis. They have nothing to upgrade to now. But it's cheaper this way :)
- mmmmmbop 3y ago
  Right. I think the point of the article was to determine what's best for your business at large, not what would make a few customers happy at the expense of your overall success.
izacus 3y ago
> In reality, the sales numbers for iPhone minis were disappointing. Disappointing by whos metric? It outsold most Android phones and massively outsold first few iPhone models released. Were iPhones 3G, 3GS, 4, etc. also disappointing? Just because the PERCENT was low, it doesn't mean the SHIPPED UNITS were low. In reality, any company you create will sell their product in VASTLY LOWER number than any iPhone Mini. Should you be fired and go bankrupt because your sales will be disappointing by Apple standards too? Should we just liquidate all companies that cater to less than 20 millions of unit sold? Should all other companies catering to small (< 20 million, the number of small iPhones shipped) audiences not exist and be replaced by average products for average people? No more Mac Studios, no more XDR displays, no more 15" 4000$ MacBooks?

guytv 3y ago

Though not immediately relevant, it's pertinent to bring up "The Mom Test" (https://www.momtestbook.com/ https://www.momtestbook.com/) book. This book offers insights into conducting customer interviews without inadvertently guiding them towards giving the answers you want to hear, or asking them to forecast whether they'll use your product.

thom 3y ago
I searched the thread to make sure someone mentioned this because I found it very useful. It encourages you to ask customers about real experiences instead of opinions, and gives you ways to identify things they care enough about to invest time/money into.

xracy 3y ago

Hot take, People have spent wayyyy too long assuming they know better than their customers what they want, and oftentimes use this as an excuse to justify ignoring what customers want. Asking your customers what they want is a really good first step in figuring out what they want. You're not always going to be able to just magically intuit what your customers want. Sometimes you need to put in the hard work to figure out what they're doing and how you can make it better. I hate XY problems, because as often as I'm the person wanting to figure out what question someone is actually trying to ask, I'm the person on the other side asking an actually well-thought-out question and getting told I don't want that.

davidgerard 3y ago

> "What job were you trying to do for yourself that caused you to come here and hire that milkshake?" "hire"? This makes the text look like synonym converter output.

dmd 3y ago
It's either a non-native english speaker or a marketer so far up their own ass they can see daylight again ... but I repeat myself.

robviren 3y ago

I completely agree, but it sure does help to listen to everybody. I always joke that I am a complaint sponge that just absorbs every little nit pick and bother anyone has with a product. Listening is the cheapest and easiest thing I can do to make someone feel better about whatever it is I end up having to do. An overwhelming amount of the time I am unable to fulfill a request because the backlog is filled to the gills with other requests. Listening to people, asking clarifying questions, and digging into their issue and how they feel about it almost always makes them feel better. Don't retread ground that has already been covered, but I have a much better time telling them their idea may not be implemented for a long time after taking thoughtful time with them to make them feel heard. I also try to disappoint upfront. No use telling them the idea is in the backlog if they have heard that 1000 times only to have the ticket sit there for years. At worst you learn a little more what someone thinks while getting them to talk and complain, an act most people find comfort it. At best you get incredibly useful empathy on a nagging issue that can benefit others. So yes, people usually have no idea what they want, but good luck telling people that. It's the PMs job to get everybody on board for the vision of a thing and how it addresses the problems behind the problems otherwise a perfect implementation of something a customer did not feel heard on will land quite different that something that they did. My two cents for what it is worth.

alexpotato 3y ago

One thing I wish happened more often was an iterative approach to features vs time to delivery. (Speaking of having been both a customer and PM-like roles) e.g. Customer: this is a list of features I would like PM: Ok, we reviewed that list and here is a "menu" of the features with how long they will take Customer: Great! I reviewed that list and I would rather have multiple quick to market features rather than wait for that "big" feature. Asking customers what they want with no "price discovery" on either side is just people dreaming up ideas.

esafak 3y ago
That's more like the cost. You could also ask them what they would be willing to pay for each feature. Good idea, though!

donatj 3y ago

When we were in startup / small business mode we had a founder who was absolutely incredible at turning customer feedback into actionable and well thought out “actually here’s a better solution” He was out shortly after the acquisition, and now we get videos emailed to us by corporates UX team of them asking the worlds most inept users how things should work and given changes based directly on this feedback. I swear agreeing to be in a test group is self selecting for people who don’t understand the most basic UI metaphor. It’s frankly been a race to the bottom.

spacecadet 3y ago

J2BD is my fave framework. That and GTFO. I was just lamenting to some Clients over drinks how the tech industry has spent the last 20 years stuck in confirmation bias hell...

deimantasa 3y ago

For the last 5 or so years, I'm building mobile POC/MVP apps for my clients. I also launched several startups myself (all failed eventually). 2/3 generated some revenue. Main lessons learned and pits fallen into: - Collect feedback from the user. Once all feedback is collected, try to find patterns and understand, will solution really solve anything and if it will - how much work it takes vs how much value overall biz gets. If it doesn't bring any value/revenue - might even consider scraping feature out to not bring more tech debt along the way - Focus on only things that matter. Pretty much every single client I work with ends up implementing features that seems nice, look good, but brings little to no value to the overall biz. Feature just was built in just for the sake of having a `bigger and more functional product` - Be aware if feedback comes from payed vs free user. It's very easy to focus on wrong things as ^ Overall, I keep seeing feedback collection going well. However the conclusion from it - just getting messy.

anticorporate 3y ago

While I think there's some truth to this idea, modern companies and the software industry in particular has taken it to the absolute extreme. We're not just no longer asking people what they want, we're ignoring the existence of anything that a person could want aside from a momentary dopamine boost. It's also really pretentious. Go read Shit User Stories for some particularly amusing/egregious examples.

bob1029 3y ago

Our product's history explores the full depth of this spectrum. At the beginning, the only thing we were interested in was what our customers (banks) thought about their business and how our product might be able to improve it. We had no clue what we were doing but were accumulating ideas rapidly. We were tripping over ourselves in order to serve the customers' every last idle whim. We felt we were not worthy of their business. Somewhere in the middle, we gained traction and realized that if we built our product to make 10+ different customers happy in their own unique ways that we would have nothing in the end. Today, our product is more of a turn-key consulting package than it is any specific software or technology. Our customers look to us for guidance on how to run their businesses now. Once you are driving this kind of bus, you can normalize your software stack with much more confidence. The word "boring" has entered our lexicon recently. One fun point about our kind of customer - they are very herd-like creatures. Once you get a few of them moving in a certain direction, you can push the rest along for the ride with virtually zero effort. I am beginning to think this isn't just applicable to risk-adverse bankers.

a13n 3y ago

In consumer apps this is true. In B2B and especially enterprise it’s less true. Especially if you sell to tech companies. If your customer says they need an Okta integration with SCIM provisioning, they probably actually do need an Okta integration with SCIM provisioning, and not having that will impact your sales and retention metrics.

mch82 3y ago

“Chapter 1: The Milkshake Dilemma” from “Competing Against Luck” (Christensen 2016) cited in the article is one of my favorite nonfiction book chapters of all time. The milkshake case study perfectly illustrates the jobs-to-be-done concept that the vertical axis of the disruptive innovation graph measures. Coincidentally, I listened to the Competing Against Luck audio book on a long walk today. Fun to see it on HN.

kirykl 3y ago

Can be summed up nicely as sung by the Stones: identifying what your customers need is better than giving what they want