Argue with your customers

In my experience it&#x27;s better to pay attention to what your customers <i>do</i>, rather than what they say. Often peoples true goals aren&#x27;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.<p>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.

One hack we&#x27;ve employed with our customers in interviews and through surveys: have them rank&#x2F;prioritize our current features, and consider&#x2F;rank a set of potential new features. It&#x27;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.

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, &quot;You don&#x27;t know what you&#x27;re actually looking for; pay us $ to help figure that out before you pay $$$ to build it.&quot;

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&#x27;s ugly.<p>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&#x27;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).

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.

This reminds me of the classic Monty Python sketch called &quot;Argument Clinic&quot;.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=uLlv_aZjHXc" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=uLlv_aZjHXc</a>

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&#x27;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. &quot;nice to have&quot;. I think this is often an honest mistake - the manager does not realize they are failing to communicate their priorities.<p>If the cost&#x2F;benefit seems fishy, the developer should ask the manager for more justification. A lot of developers don&#x27;t realize they can push back.

The crux of this is:<p>Giving the customer what they ask for != solving the customers problem.

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 &quot;noisy&quot; and the boundary (of what&#x27;s okay and what&#x27;s not) is not clear. So you want to try various approaches to figure out the shape of what the &quot;needs&quot; look like.<p>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.

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&#x2F;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?”:<p>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.”<p>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.<p>3. I then push back on why I think we <i>should not</i> 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&#x2F;customers&#x2F;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.<p>4. After explaining the problems with <i>their</i> 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.<p>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 &amp; 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&#x2F;appropriate). Then I let them make the choice.<p>Following this pattern has pretty much never failed me. What feels best about it is when I see clients actually <i>learn how their software works</i> 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.<p>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.

I work scaling support teams on a daily basis and I couldn&#x27;t agree more with this.<p>Beyond the product itself, there&#x27;s also the question about the relationship with your team, which is often very important. In that regard, it&#x27;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.<p>I remember a saying from a friend as follows:<p>&quot;A relationship with customer is like a marriage.<p>If everything is too perfect, there are no conflicts or issues, and you just love each other....<p>There is definitely something wrong. &quot;<p>It&#x27;s imperative to &#x27;open them up&#x27; and find out what&#x27;s really happening before it&#x27;s too late.

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, &quot;I don&#x27;t know&quot; and mean it. And that&#x27;s when you have to start to treat feedback more holistically and use the customer as a final validation of an internal model. [1]<p>[1] <a href="http:&#x2F;&#x2F;ludamix.com&#x2F;dive&#x2F;performance&#x2F;" rel="nofollow">http:&#x2F;&#x2F;ludamix.com&#x2F;dive&#x2F;performance&#x2F;</a>

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.

Two problems:<p>1.) If you have to pay people to give feedback, you&#x27;re doing something very wrong.<p>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.<p>The quest for meaningful feedback cannot overwhelm the need to serve customers and treat them well.

I have found that saying &quot;why are you asking for X...can you tell me what you are trying to achive with X?&quot; 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.

I&#x27;m just reading Talking to humans and this fits nicely with it. Highly recommended

<i>Osborn&#x27;s &quot;Brainstorming&quot; methodology had 2 main tenants</i><p>1. It should be <i>tenets</i>. A <i>tenant</i> is &quot;a person who occupies land or property rented from a landlord&quot;. A <i>tenet</i> is a &quot;principle, opinion, or dogma maintained as true by a person, sect, school; a thing held to be true&quot;[0]. I&#x27;ve seen this mistake a couple of times before on programmer blogs.<p>2. I think he means <i>method</i>. It seems <i>methodology</i> is starting to take over from <i>method</i> in a lot of areas, maybe because it&#x27;s longer and sounds more impressive and scientific. No-one wants to talk about their <i>method</i> when they can talk about their <i>methodology</i>. But in scientific papers, the <i>methodology</i> is the part where they explain the reasons why they&#x27;re using the methods they&#x27;re using. The two words mean two different things.[1] Let&#x27;s keep it that way!<p>[0] The Online Etymology Dictionary goes on: early 15c., from Latin tenet <i>he holds</i>, third person singular present indicative of tenere <i>to hold, grasp, keep, have possession, maintain,</i> also <i>reach, gain, acquire, obtain; hold back, repress, restrain;</i> figuratively <i>hold in mind, take in, understand</i> <a href="https:&#x2F;&#x2F;www.etymonline.com&#x2F;word&#x2F;tenet" rel="nofollow">https:&#x2F;&#x2F;www.etymonline.com&#x2F;word&#x2F;tenet</a><p>Incidentally, I didn&#x27;t realize until I started learning Spanish that &quot;ten&quot; or &quot;tain&quot; in English words means <i>to have</i>. Spanish inherited <i>tenere</i> as <i>tener</i>, to have, and adds prefixes to make a lot of other verbs, e.g. <i>abstener, contener, detener, mantener, obtener, retener, sostener</i>, all of which mean something like what they do in English - <i>to abstain, contain, detain, maintain, obtain, retain, sustain</i> - various forms of &#x27;having&#x27; (or not having). &quot;Ten&quot; is in words like <i>tenacious</i> - from Latin <i>tenax</i>, holding fast, clinging, and <i>tenable</i> - capable of being held&#x2F;maintained.<p>[1] &quot;Etymologically, methodology refers to the study of methods. Thus the use of <i>methodology</i> as a synonym for methods (or other simple terms such as <i>means, technique,</i> or <i>procedure</i>) is proscribed as both inaccurate and pretentious.&quot; <a href="https:&#x2F;&#x2F;en.wiktionary.org&#x2F;wiki&#x2F;methodology" rel="nofollow">https:&#x2F;&#x2F;en.wiktionary.org&#x2F;wiki&#x2F;methodology</a>

Isn&#x27;t this plain ole rational skepticism?

<p><pre><code> 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&#x27;t know. I just liked it. Ugh. If we have a week of conversations like this, we&#x27;ll end up with nothing. </code></pre> What people do and where people look has a lot more to do with what they really want than what they say.