Colleagues, tell us about your methods of protection against "The customer is always right" in the development process?

Question

Project management

Colleagues, hello! Sometimes (recently in general very often) it begins to seem to me that the thesis "The customer is always right" was invented by very stubborn clients with hay in their heads. I regularly come across the fact that despite the agreements (including in the contract) that after the layout has been agreed and development has begun, it is impossible to make changes to the prototype, at least quickly and free of charge. In addition, clients regularly and spontaneously begin to fantasize and advise conversion-killing (design and performance) user stories (home-grown ux-experts). I do not strive to take the place of a product-owner, but often the wishes of the client drown a promising project. How do you explain to clients that this is impossible and bad, and how do you limit yourself / your team from conflicting requirements of the customer / business unit?
UPD: the ultimatum approach is not a solution. With such an answer, the client is still left with a misunderstanding why he is wrong. The task is not to be solved by an ultimatum, but by mutual understandings and agreements.

Answer 1

I explain to the client why it is not necessary to do as he wants. But if he insists, then I do it. After all, this is his project and his money. If he does not want to get an expert opinion and a profitable product, but only wants the implementation of his ideas, this is his right. Several of these clients bring me a very good income: they come up with a crazy idea, I implement it, I take payment, after a month or two they ask to remove this madness, I also take payment for this. And so for several years.

Answer 2

Why is half of the saying always given?)))
A step away from the contract is no longer a client.
I violated the agreements, even stupidly in terms of payment terms - this is no longer a client.
Are you working for money? So it's kind of a business. Business DOES NOT EQUAL almond-mongering!
As soon as this becomes a core in your head, your business will become real, i.e. irresistible and enjoyable.
is that what you think, very often it is artificially formed by dishonest so-called. the client has a feeling in your head))) he understands everything, just the goals of the so-called. clients a little different than yours.

Answer 3

There is a simple rule, any whim for your money

Answer 4

If the client cannot coherently explain why he needs this feature in this edition, you ask him to type the text that he takes responsibility for the result of the feature implementation
. But it is better to offer the client to do AB testing of your edition and its edition
We write down all the details of the feature to the smallest detail
Behavior conflicting features are described in detail at the junctions
The main thing is not to think that you are the most experienced and smart here
We believe that the client knows his audience better and what they need

Answer 5

I do not agree with most of the answers in this thread
1) Do not deviate from the TK, all dorayuotki are only paid. Of course, this is correct on the part of the freelancer, since this provides him with full remuneration, but on the part of the client it is unrealistic to immediately write such a specification that would suit his needs, changes will always be needed, and why should the client pay (and much more important, what is also needed and wait) until you complete the old requirements before giving new ones? A good freelancer must be flexible. I personally prefer to make one huge TOR, which will allow you to see the whole project, but work on small TOR (1-2 weeks of work) and thus the client can change the product development vector quite painlessly
2) The freelancer is an expert, and the client is a fool and does not understand anything. A freelancer usually understands various metrics, patterns, cases better, but does not understand the most important thing - the specific goals and objectives of the client (often because it is even difficult for clients to formulate them clearly). The simplest example from my practice: I wanted to add various ways of retaining users and motivation to invite acquaintances to the product, but this was no longer so important for the client, he had a potential buyer for a startup and it was much more important for him to bring the current version to the "wow effect" rather than developing chips for the future. Naturally, the client did not tell me anything about the sale - he himself was not sure that he would sell a startup, and sharing such information with the contractor is not always successful - it can be demoralized. In general, I thought the client's ideas were stupid just because that I did not know his true aims. Therefore, try by hook or by crook to try to impose
3) Freelancer = ordinary performer. In my opinion, in order to get effective cooperation, a freelancer must be a partner, and not just a performer. Moreover, the freelancer must clearly make this clear to the client from the first stages of communication. Freelancer = a professional in his field who does his job well and who should be listened to in matters relating to his work. If the client does not initially see you as a pro who is ready to improve his product on his own initiative, then in this case I would refuse the project.
4) The freelancer does not care about the final result of the project, the main thing is to get money for his work. I believe that a freelancer is primarily interested in making the client’s product successful, since in this case the freelancer’s product will be at the “support” stage, which will require less effort and bring more income (it will be easier for the client to part with a large amount of money, if the project is already in production and successful, and it will be quite difficult for him to go to other freelancers, since you already know the project well and do the work in good faith)
In general, in my opinion, the problem is that freelancers initially position themselves as employees, as well as in unwillingness to refuse projects just because the client seems inadequate or simply misperceives the realities of the project.

Answer 6

There will always be such wishes - it's neither good nor bad ... just
Here is an example from my recent work:
- Do it for us like Wildberries, they have a lot of customers, a lot of orders and a lot of money and I like it
- But they big, it’s hard for them to redo the whole design, you don’t have customers and you can make it as simple and convenient as possible
- They have big profits, many orders, and therefore you are wrong
[headshot]
- They have a profitability of 2-3%, costs so many billions, 150 employees on the site (diz + progers) and their average salary is such and such
- Hands
on I'm what. Examples help, detailed explanations help - for this you need to take their point of view and continue the thought for them, often it collapses in that it is expensive to maintain.
Why is that? Are you a corporation? Have you heard of Agile?

Answer 7

It all depends on the level of stubbornness of the client. Sometimes, when you cannot adequately explain the uselessness of a certain feature in such and such a place, then perhaps it is needed there. Here you need to "go down" to the level of the customer (many developers have such a complex) and use simple examples to explain why your option is really better. If the client does not respond to the arguments, then perhaps you should do as he requires before that, by actually taking a written agreement from him (or something like that).
In any case, the client turned to you as specialists. And you have your own principles and rules for doing business. Your development principle does not allow you to grab tasks during the sprint and, moreover, redo everything 5 times a day. If a client wants quality service, he must also accept your rules of the game, as professionals in their field. Otherwise, any money-hungry student will blurt out what they tell him and what will fall apart in the second week of use. Arguments of this kind also bear fruit.
As mentioned earlier, sometimes you just have to resign yourself to do what is required, while not forgetting to mention that unplanned tasks undermine the workflow and will require additional funding, because you had everything planned out.

Answer 8

The phrase "Either we do it this way or we don't do it at all" - does not fit?

Answer 9

It all depends on the income from a particular customer and the presence / absence of other projects. There is fish for fishlessness and cancer, and when there is something to do in abundance, then you can choose and refuse someone. The main thing is not to get bogged down and that the work done is paid. Changes, again, are different, if you can do it within half an hour, then it's easier to do it than to start butting with the customer for many hours. And if the change requires large additional. costs, then the customer must provide a cost estimate for his Wishlist. If he pays, then no problem.

Answer 10

The methods of protection against "The customer is always right" in the development process look something like this: 7 red lines . Learn :)
PS By the way, for erudition - the story has domestic roots .

Answer 11

God, such a "tormented" topic)) The principle is simpler than any understanding of what is happening ...
1) You do everything that is asked and redo it for the same money. what was asked to be done earlier.
2) You see. that the client is already very intrusive - set the price 1.5-2 times more and discourage the "be smart".
You either earn money or build communism. See what is closer to you))