
Argue with your customers - nate
https://www.rockstarcoders.com/customer-feedback/
======
johngalt
In my experience it's better to pay attention to what your customers _do_ ,
rather than what they say. Often peoples true goals aren't directly stated, or
even known to themselves. If you asked people what type of store they want to
shop in, very few would describe a walmart, and yet walmart seems to gain
plenty of customers.

This sort of behavior is compounded when you throw in things such as
distributed decision making. You will get piles of disjointed feedback, and
almost none of it is informative about what actually drives adoption of your
product.

~~~
tacon
My favorite book on customer development is "The Mom Test"[0], by a
YCombinator alum. The name is terrible, but the content of that book is
golden. He tells the terrifying story of talking to customers constantly as
they wasted a million dollars building something the customers were not going
to buy. There are various ways the customer pays you before the product is
ready, and if they aren't paying you, they aren't really interested. Payment
can be in the form of time (they meet with you), personal reputation (they
recommend you to friends), company reputation (they arrange a meeting with
their boss, or coworkers), etc.

[0] [https://www.amazon.com/Mom-Test-customers-business-
everyone-...](https://www.amazon.com/Mom-Test-customers-business-everyone-
ebook/dp/B01H4G2J1U/)

~~~
iovrthoughtthis
This is probably the book I recommend the most of any book, ever.

------
npollock
One hack we've employed with our customers in interviews and through surveys:
have them rank/prioritize our current features, and consider/rank a set of
potential new features. It's much easier for someone to order a list
(reaction), than to provide an explanation (creation). Not a substitute for a
full interview, but a quick way to determine what your customer values.

~~~
jfindley
How do you control for people's abstract desires not mapping well to what they
actually want?

Example to illustrate my point: Focus groups over the past 15 years or so have
consistently told car mfrs that consumers want larger cars - larger cars are
assumed to be more luxurious and associated with financial success, and thus
are desirable. The end result is that previous small, manoeuvrable, city cars
are now bigger and harder to park. Consumers or small cars are generally
unhappy with this trend, as they wanted a small car for the ease of parking
etc, but focus groups are frequently insufficiently well tuned to pick up up
on this nuance.

My experience in this industry over many years is that users often don't have
a clear idea of what they want, and in the cases when they do a non-trivial
amount of time it's a so tightly tethered to one special-snowflake usecase
that virtually noone else finds value in it.

~~~
ASpring
This is why user experience researchers have a job. It's not about asking the
user what they want, it's about observing how they work, their problems, their
current workarounds, and then building something they need.

------
dmlorenzetti
My father worked for a large software company for many years. I remember him
telling me how they successfully responded to a Request For Proposals with a
much smaller proposal that said, in essence, "You don't know what you're
actually looking for; pay us $ to help figure that out before you pay $$$ to
build it."

~~~
jbob2000
Oh I have a good story about that! Healthcare software is rife with these
sorts of things.

We had a potential client come in saying they had the toughest requirements;
terabytes of data would be collected, we'll need PhD data scientists to write
very complex algorithms, huge servers to handle the incredible load and uptime
needed, full suite of mobile and desktop apps, blah blah blah.

We analyze his requirements a bit and it turns out he needs actually just
needs a survey with 5 questions, none of which collected personal information.
And he treats 20 patients a year. We call him in, set him up a Google Form in
front of him, and sent him on his way. Probably saved the Canadian healthcare
system millions on that one.

Looking back on this experience, I think some people are incredibly ego-
driven, so the prospect of doing something off-the-shelf or for free doesn't
enter their conscience.

~~~
FooHentai
Or sometimes it's just a missing piece of critical thinking - 'Is what I'm
doing unique to me, or is it something other people need to be doing as
well?'. Most times there are others doing the same things, and that means
there's a market probably being served by someone already that you can
leverage to meet your needs.

Or down the other path where that question is never asked is the madness of
'fully customizable' LOB stuff, like SAP or Domino.

I have that conversation often in the enterprise apps space, and so frequently
the fundamental question just hasn't been considered while everyone rushes
towards a horrible custom code nightmare that's entirely unnecessary.

~~~
Terr_
> the madness of 'fully customizable' LOB stuff

An observation from working with LOB stuff: Often software is simply the tool
companies use so that they can spend dollars to defer fixing issues with
training, procedures, or management.

For example, some salespeople have an incentive to over-promise and under-
charge in order to make their quotas and bonuses, which causes problems down
the line for the company finances and whomever needs to fulfill those
requests.

Rather than changing the compensation structure -- or asking the direct
managers to do their job with oversight -- the company decides to spend bucks
on software, programming the computer to tsk-tsk-tsk and wag an admonishing
digital finger. Since there's no followup or moral suasion, a month later
nothing has changed except that the sales team has found different "dump
stats" for achieving their goals.

------
gumby
An unstated problem of trying to gauge customer (or prospective customer
experience) is orthogonal to this article: people are very reluctant to tell
you to your face that your baby's ugly.

I have had the experience of launching a product where people gave the idea
rave reviews, were willing to pilot it (and the pilots met their success
criteria) but garnered almost no sales. The fact was though it addressed what
CxOs claimed was one of their top 3 problems, they just didn't want to do what
was necessary to actually deal with it. (I think if we had actually had the
problem ourselves we would have known this).

~~~
sbinthree
My experience with my current company could be considered the opposite of
this. People are willing to pay us large amounts of money (surprisingly so)
because they need a solution for this particular problem and nothing exists,
but they hate what we have built and constantly complain / write angry emails
offering feedback of all varieties. What they don't do is leave, despite not
being locked in. Strange.

~~~
hikarudo
I've had exactly the same experience.

There's a saying in Brazil for this concept: "he who scorns, wants to buy"
(quem desdenha quer comprar)

~~~
yread
makes sense, if they dont complain they dont care

------
guptaneil
This form of user interviews with existing customers also inoculates your
customer against marketing from competitors, since they are now more invested
in defending their decision to buy your product.

~~~
tacon
I heard that similar tactic on some podcast by a services guy. I can't
remember the actual field, let's say "lose weight" services. They ask the new
client "How committed are you to losing weight?" Let's say the client says "4
out of 5". You might think you should ask: "Why aren't you a 5?" But the ninja
move is to ask "But why aren't you a 3?" This forces the client to tap into
their own self-motivation (which is all there is, after all) and they start to
convince themselves why they are committed to the results.

------
asaph
This reminds me of the classic Monty Python sketch called "Argument Clinic".

[https://www.youtube.com/watch?v=uLlv_aZjHXc](https://www.youtube.com/watch?v=uLlv_aZjHXc)

~~~
naringas
no it doesn't

~~~
asaph
Yes it does.

~~~
reificator
Look, this isn't an argument, it's just contradiction.

~~~
bena
No, it isn't

~~~
dugluak
Yes, it is.

------
blt
Yes, and apply the same philosophy to your product manager, etc. as a
developer. Developers tend to assume that the manager has carefully considered
the cost of what they ask for, and is certain that the result is worth it. But
this usually isn't true. Managers tend to ask for more than the developers can
deliver. They do not always remember to make clear to employees which requests
are essential vs. "nice to have". I think this is often an honest mistake -
the manager does not realize they are failing to communicate their priorities.

If the cost/benefit seems fishy, the developer should ask the manager for more
justification. A lot of developers don't realize they can push back.

~~~
mooreds
Not just that they can push back, but that the business, product or service,
and developer happiness is better if the developer and manager partner on
understanding the business problem and solving it. This is in contrast to the
developer just "implementing to spec" and then being surprised when the end
user is bummed that "this doesn't work the way I thought it would".

We are experts in our domain of software development and do no one favors when
we hide it and just do what we're told.

(That isn't to say that the developer has the only opinion that matters, just
that they are a stakeholder with expertise and should act like it.)

~~~
blt
Agreed. I think it's hard for a non programmer to estimate the difficulty of
implementing a certain feature. Both in time and in technical debt. For
example if some feature really doesn't fit in the program architecture and
will require ugly hacks to achieve. It's the programmer's duty to let the
manager know when such a cost will be incurred.

------
TickleSteve
The crux of this is:

Giving the customer what they ask for != solving the customers problem.

------
euske
Just writing down my train of thoughts here. This article made me think of a
machine learning-like approach of learning the customer needs. You want to
find out the true distribution of them. Apparently, the more clearly you can
identify the needs, the more win for your products. But in some areas, the
customers are "noisy" and the boundary (of what's okay and what's not) is not
clear. So you want to try various approaches to figure out the shape of what
the "needs" look like.

In some sense, brainstorming (without criticizing the ideas) is a bit like
generative methods. You only want to find the center of distribution. But
sometimes you want to know the exact boundary. In that case, you need to
employ a discriminative way; to try both sides of the boundary to define the
better shape of it.

------
bobwaycott
Always. I’ve been practicing this for 10 years, most of which I’ve been
working as a consultant building custom software for internal business
processes, as well as customer-facing software for clients’ users. My typical
process looks something like this when a feature/change request or random idea
is asked for—which almost always comes in along the lines of, “Can we get X
added in that does Y and looks like Z?”:

1\. I never say yes to any request immediately. I always tell a client,
“Anything is possible that doesn’t violate the laws of physics, but let’s dig
into this more.”

2\. Ask what they’re trying to accomplish. What problem are they trying to
solve? What mistake are they trying to prevent? What is the end goal? I ask
questions until I can explain back to the customer what they’re really wanting
to do and why.

3\. I then push back on why I think we _should not_ do what they’re asking for
in the way they’re asking for it. Not in an asshole way, but I do challenge
their request, its utility, the value it will bring the
business/customers/employees, etc. When doing this, I always spend time on
educating them on the tech behind the scenes, potential pitfalls, how adding
something (especially if it’s visible to people) will make it nearly
impossible to ever remove it once users get used to it, when they’re asking
for something that would be more effort the way they’re asking for it to be
done than it’s worth when it’s trying to solve for a rare edge case, etc.

4\. After explaining the problems with _their_ idea as given by non-experts, I
start suggesting other ways we could accomplish their goals--using a simpler
UX, or even no UX at all--relying on the ability to automate things if we have
enough information, hiding all the complexities of a given business process
behind a single button once we have the right info to intelligently take
action.

5\. I give a couple of recommendations for potential ways forward that solve
the real problem in a way I’ll enjoy building it out. I spend time explaining
what I see as the benefits & trade-offs with my suggestions for solving their
problems, as well as how long the options should take. I try to always include
at least one option that is as simple and quick-to-build as possible (internal
MVP approach), and one option that has more bells and whistles (when
relevant/appropriate). Then I let them make the choice.

Following this pattern has pretty much never failed me. What feels best about
it is when I see clients actually _learn how their software works_ when I’m
working for them. I love it when they remember the discussions we’ve had,
internalized it, and recall it when we talk 6 months later about their new
idea. Over time, their ideas improve because their understanding of how their
software works improves. They also become increasingly invested in our working
relationship as their trust in my concern for solving their problems—and not
just doing their bidding—increases.

Never shy away from challenging your customers’ ideas—but always do it in a
respectful manner that gets to the heart of their real problems and educates
them along the way. They’ll appreciate it, and will keep coming to you for
more. I don’t think this is unique to being a consultant, either—the same sort
of process can be followed with direct users of your own product.

~~~
sjclemmy
This is pretty much the pattern I follow. People like to come up with
solutions and so they ask - can you do this? The answer is of course ‘yes’,
but it’s not necessarily the correct solution to the unstated problem.

------
gabept
I work scaling support teams on a daily basis and I couldn't agree more with
this.

Beyond the product itself, there's also the question about the relationship
with your team, which is often very important. In that regard, it's even
worse, and many customers will try to be very nice and say that your team was
very helpful, omitting some redflags of a bad customer support experience.

I remember a saying from a friend as follows:

"A relationship with customer is like a marriage.

If everything is too perfect, there are no conflicts or issues, and you just
love each other....

There is definitely something wrong. "

It's imperative to 'open them up' and find out what's really happening before
it's too late.

------
annywhey
Although browbeating does have a lot of value, especially when there are
already some bounds on what the problem is and how it can be solved with your
product, you will hit a point where your customers say, "I don't know" and
mean it. And that's when you have to start to treat feedback more holistically
and use the customer as a final validation of an internal model. [1]

[1]
[http://ludamix.com/dive/performance/](http://ludamix.com/dive/performance/)

------
sjclemmy
Some companies I’ve worked with aren’t able to specify their requirement.
Sometimes it’s better to say to them - let’s build a product that adheres to
your stated requirements, and then you can use it. This allows them to
identify all the parts of the business process they hadn’t been aware of or
anticipated and provides a much better basis for creating a clear
specification that is built on a shared understanding of the actual business
processes and requirements.

------
hluska
Two problems:

1.) If you have to pay people to give feedback, you're doing something very
wrong.

2.) If you interrogate a customer who cares enough to give you candid
feedback, your odds of ever getting candid feedback from that customer drop to
near zero.

The quest for meaningful feedback cannot overwhelm the need to serve customers
and treat them well.

~~~
ASpring
> If you have to pay people to give feedback, you're doing something very
> wrong.

Why? This is a more unbiased way of getting feedback than letting your most
vocal users tell you about their problems with your product. Paying users for
feedback is more common in B2C apps but happens quite a bit in B2B also.

~~~
hluska
> Why?

You're adding an incentive other than "I want to improve this product because
it makes $x easier" and end up with way too many "I don't know" answers. At
least with vocal users (or better yet, tech support cases), you have some
degree of passion. Sometimes the passion results in overstating certain
problems, but that's still valid.

------
myrandomcomment
I have found that saying "why are you asking for X...can you tell me what you
are trying to achive with X?" works wonders as a starting point. Make it about
the outcome and not the how is a big part of moving forward and being
successful.

------
yread
I'm just reading Talking to humans and this fits nicely with it. Highly
recommended

------
yesenadam
_Osborn 's "Brainstorming" methodology had 2 main tenants_

1\. It should be _tenets_. A _tenant_ is "a person who occupies land or
property rented from a landlord". A _tenet_ is a "principle, opinion, or dogma
maintained as true by a person, sect, school; a thing held to be true"[0].
I've seen this mistake a couple of times before on programmer blogs.

2\. I think he means _method_. It seems _methodology_ is starting to take over
from _method_ in a lot of areas, maybe because it's longer and sounds more
impressive and scientific. No-one wants to talk about their _method_ when they
can talk about their _methodology_. But in scientific papers, the
_methodology_ is the part where they explain the reasons why they're using the
methods they're using. The two words mean two different things.[1] Let's keep
it that way!

[0] The Online Etymology Dictionary goes on: early 15c., from Latin tenet _he
holds_ , third person singular present indicative of tenere _to hold, grasp,
keep, have possession, maintain,_ also _reach, gain, acquire, obtain; hold
back, repress, restrain;_ figuratively _hold in mind, take in, understand_
[https://www.etymonline.com/word/tenet](https://www.etymonline.com/word/tenet)

Incidentally, I didn't realize until I started learning Spanish that "ten" or
"tain" in English words means _to have_. Spanish inherited _tenere_ as _tener_
, to have, and adds prefixes to make a lot of other verbs, e.g. _abstener,
contener, detener, mantener, obtener, retener, sostener_ , all of which mean
something like what they do in English - _to abstain, contain, detain,
maintain, obtain, retain, sustain_ \- various forms of 'having' (or not
having). "Ten" is in words like _tenacious_ \- from Latin _tenax_ , holding
fast, clinging, and _tenable_ \- capable of being held/maintained.

[1] "Etymologically, methodology refers to the study of methods. Thus the use
of _methodology_ as a synonym for methods (or other simple terms such as
_means, technique,_ or _procedure_ ) is proscribed as both inaccurate and
pretentious."
[https://en.wiktionary.org/wiki/methodology](https://en.wiktionary.org/wiki/methodology)

------
natmaka
Isn't this plain ole rational skepticism?

------
stcredzero

        Us: Why did you choose to buy our product?
        User: I liked it over your competition.
        Us: Great. What was better about us?
        User: I don't know. I just liked it.
    
        Ugh. If we have a week of conversations like this, 
        we'll end up with nothing.
    

What people do and where people look has a lot more to do with what they
really want than what they say.

