"McKinsey Structured Strategic Thinking" always emphasizes the importance of "clear definition". So when discussing this issue, we also need to clarify a definition.

That is, what is the cooperation model for the product? Is it a subscription system? Project system? Or the person-month system?

Most cases where similar problems are encountered are project-based cooperation, that is, customized contracts.

Because the subscription system is basically based on the product's own iteration cycle, customer needs need to be filtered and screened by the product team, and ultimately form their own needs for product iterations. The product R&D team has relatively high autonomy in demand.

The person-month system is based on how many cards are punched and how much expenses are settled. As long as people are here, we can change it how you want.

"The actual product does not match the propaganda" is an important reason for this type of problem. Because user expectations are HE Tuber raised too high in the pre-sales stage, users have psychological bias after seeing the actual deliverables.

Of course, from the perspective of different roles, in the pre-sales stage, in order to win the bid, user expectations will basically be raised. However, after winning the bid, you must make a good handover with the delivery team and expose the pits that have been dug, don't hide them.

Regarding this topic, you can take a look at the historical article written before about the handover from pre-sales to deliveryTherefore, some pre-sales promises are not reflected in the contract, or the contracts are vague, but they are indeed stated during the pre-sales. From the perspective of the implicit contract spirit, we should still try to satisfy them. Otherwise, it may affect Party B’s company’s reputation, which may in turn affect other projects and other customers.

Of course, there are different solutions to the same needs. As for the amount of workload, please refer to Article 5 below.

Many problems are, in the final analysis, a matter of trust. Although different people have different temperaments and temperaments, if you establish a good relationship of trust with your customers in the early stage, there will be a lot of room for maneuver on these issues.

So, by the time something goes wrong, it's already a little late. But it was not too late, after all, things had not yet reached an irreversible situation.

Just like when we get sick, getting sick must be because we didn't pay enough attention to certain aspects before, but the sickness itself is also a reminder to pay more attention to certain aspects.

The trust relationship and project progress between Party A and Party B also influence and promote each other. I have experienced actual cases of relying on product managers to change customer attitudes, and I have also experienced situations where a good hand of cards was beaten to pieces.

So, back to today’s topic, there should be a lot of room for negotiation regarding the definition of new needs and optimization needs.

If not, then there must have been a problem before, and this problem must not only be manifested at the demand level, but subsequent acceptance and payment may be difficult.

When there is a problem in the relationship between your team and the client, use the method of easing the relationship in private, break it down one by one or make insinuations, and use your own professional ability, or you can take a big step back, and he can take a small step back. It's more important.

Don’t get too hung up on details unless authorized by your leader.

This year I often ask for insights in different channels, because I really think it is particularly important. It is a very critical product thinking and an essential ability and habit for a good product manager.

When a customer says they want to optimize a certain requirement, what is the reason?

Probably to be consistent with the contract. In particular, many veteran employees within the system are very serious and at the same time worried about taking responsibility. No matter whether what is written in the contract or demand statement is correct or not, they must follow this content.

It may be that the function of the product is really not easy to use. There are many product managers from Party A who are much more professional than Party B, so they can find problems in the product. In this case, I can only blame myself for being inferior to others.

On the other hand, this is an opportunity for rapid advancement, so seize it tightly.

Maybe the customer is enjoying themselves. No matter who the person making the demand is, they may fall into blind self-pleasure and put forward some false demands. This requires product managers to identify the "scenarios", "pain points" and "goals" behind this demand through effective demand insights.

Later, analyze whether the current demand can achieve the goal behind it?

Just like your request is to ask Zhang Fei to buy a razor. If he really buys it, then we are really wizards in the product industry. But does Zhang Fei really need to buy it?

(Of course, this question does not conflict with the classic interview question: How to sell a razor to Zhang Fei, but their starting points are different)

It's also possible that you haven't gotten the real reason for the customer's needs. As mentioned in last year's article, when a customer asks you to buy water, it is not necessarily because you are thirsty. There may be other reasons. The final form of expression is: buy a bottle of water ( 

Therefore, demand insight is the premise of "disputing" with customers whether it is a new demand. Only by understanding what the other party wants can you know which method is more effective.

If the customer always insists that this is an optimization requirement, we can also use our professional capabilities to make the optimization requirement changes smaller or more reasonable.

There are several prerequisites for this step:

The product manager is familiar with the existing business and system status, knows what risks may exist during the modification process, or can find simpler modification methods through the underlying design logic;

Product managers have the right to speak within the team, otherwise they will encounter obstacles and blame each other during the optimization process;

Have a certain degree of technical thinking and be able to initially evaluate the amount of modification work required for different solutions.

These three points can actually be summarized into one point: this product manager is experienced and capable.

Of course, in actual work, many people will directly escalate similar problems to the leadership or business level and solve them through the company's strength. There is nothing wrong with this approach in itself, but it just lacks some opportunities for us product managers to try and exercise.

The growth rate through difficult harvest is still very fast.

Even if the functions are optimized, don’t fall into the same trap twice. The scope of the original requirements is not clearly defined, and the scope of optimization requirements must be agreed upon through consultation.

In addition, these optimization functions also require workload evaluation. Even if the customer does not settle the bill now, we regard it as a silent cost. When iterating new contracts in the future, if the customer's trust is re-established, it is not impossible to make up for the workload. .

I think the essence of this problem is that there is something wrong with the demand management process within the team.

Regardless of whether the customer participates in the demand analysis stage, the two parties must not have reached an agreement during the demand review

Or the process for subsequent demand changes is not standardized, traceable, and undocumented.

It may also be due to changes in personnel on both sides and failure to do a good handover of work, leading to inconsistent perceptions8. Write at the end

Many friends will mention the term "contract spirit". I think it should be viewed from two aspects:

Product managers should not take the initiative to mention the scope of the contract and the boundaries of the contract with the customer multiple times. Because if we really want to get serious, there are too many functions that are not agreed upon in the contract. Just a few random questions from customers are enough for the product manager and the project team to drink.

Most customers also pay attention to the spirit of contract. Even if they are occasionally serious and embarrassed, they still need to be responsible for their own companies and the results of their own projects. After all, everyone works for the company.

Therefore, whether optimization requirements are considered new requirements or not, I have no say in this matter, and neither do you. However, we can use many actions to make the people who have the final say calculate according to our assumptions.

My final point can be summed up in one sentence:

First, take a step back to express your stance, then ease the relationship through professionalism, use demand insights as the benchmark, and find a solution that satisfies both parties, ultimately prompting the customer to take a small step back.