When stakeholders do not want to cooperate: product momentum in three real stories.

This happened at 17EdTech. My main role at that time was interaction designer, but one project had fallen into difficulty: an O2O exam and marking system connecting online and offline work.

The history of this project was not good. The product manager had changed three or four times in past iterations. Each change added another layer of confusion to the system logic. What users finally saw was a product with contradictory logic and a very complicated workflow. The main users were teachers, and their feedback was strong: the marking process was complex and inefficient, especially in double-marking scenarios such as mock entrance exams. The system had not really solved their core problem.

The reality at that moment was simple: no product manager was responsible for this project. Nobody was doing the overall sorting. The project was still running, but nobody was truly owning it.

I made a choice: I stepped in.

Nobody asked me to do that. I did it because when a product in front of you is clearly hurting users, and you have the ability to do something, waiting for someone else to handle it is not a choice that feels right.

I started by sorting out the full product logic. This was not only an interaction problem. I went back to product definition: what was the core scenario this system needed to serve? What were the core tasks of different roles such as paper-setting teachers, marking teachers, and administrators? Which parts of the existing system logic were broken, where were they broken, and why?

After that, I made a three-phase iteration plan:

• Phase one: make the core flow work. The main path for paper input, question display, and marking experience had to become smooth first, and the most painful problems had to be solved first.
• Phase two: improve detailed components, handle edge cases, and complete special flows such as double marking.
• Phase three: after the system became stable, organise the product documents and hand the project over to the formal product manager.

Having a plan is not enough. The path for pushing it matters just as much.

The person who could really make this happen was the head of the product department. He had the authority to coordinate resources and make final direction decisions.

But he was in the product department and I was in the design department. This was not a relationship where I could simply cross the line and go talk to him directly. If I had done that, it would not only have gone against the normal communication rules of the organisation, it could also easily have been seen as a designer stepping over the line to tell product what to do. That would have hurt later cooperation.

I needed to do two things: first, make the plan solid; second, find the right communication path.

I prepared full documentation: a product-logic map, specific problem locations in the current system, a three-phase plan, and the goal and verifiable deliverables for each phase.

Then I went to my own manager, the head of the design department, and explained the full situation and the plan to her. She agreed with the direction and helped me set up time with the product leader so that we could discuss it together.

This choice of communication path was as important as the content of the plan itself.

If I had gone directly to the product leader, even with a good plan, his first reaction might have been: why are you coming to me this way? With my own leader making the introduction, the conversation respected the organisation structure, and her support made it much more likely that the plan would be taken seriously.

There is a big difference between appearing with a clear structure and work that is already more than half done, and appearing empty-handed just to say there is a problem someone should deal with.

The plan was accepted. The project entered an ordered iteration cycle. Without the PM title, I had in practice led the rebuilding of the product direction until it was handed over to a formal product manager.

This happened at Qingyue Technology, when the parent company Fengwu Technology had just completed the acquisition of a property company called Oudian Garden.

The acquisition was complete at the business level. But after an acquisition, system integration is the real challenge. Fengwu planned to deploy its own SaaS property-management system at Oudian Garden and unify the management process. At that time, I was responsible for the product and interaction work for this project.

Why he resisted

The original property operations leader at Oudian Garden was one of the most critical stakeholders in the project. He was the core user of the system. His team would use it. His work process would be changed by it.

But he did not want to cooperate.

The reason was understandable and very human. The acquisition changed his position. Before, he had been the top person in that property company. After the acquisition, he had to report to new management sent from above. In practice, he had been downgraded. This change in power, together with dissatisfaction about the acquisition terms, made him strongly resistant to everything brought in by the acquiring side, including this system.

In practice, that resistance meant this: he refused to provide requirements, refused to join requirement discussions, and did not cooperate with system research.

For the project, this was a very real problem. If you do not understand the actual operation flows and pain points of the property company, you cannot design a system that is truly useful. A system that nobody wants to use is still a failed system, even if deployment itself goes smoothly.

When direct communication is blocked, go to the frontline and find the answer there

Talking to him directly was not an effective path. His resistance was emotional. At that stage, trying to use logic to convince him that the system would be good for him was meaningless.

So I changed direction. I went to his subordinates and to frontline workers.

These were the people really running the property every day: guards, cleaners, maintenance workers, front-desk staff. They had real work pain points, and they did not carry the same political position. By talking to them, I slowly pieced together a real operation picture: where they spent the most time, which tasks were most difficult, and which broken processes caused the biggest trouble when problems happened.

Two issues appeared again and again.

The first was employee exit management. Security guards and property staff changed often. But when someone left, their access keys, system passwords, and device permissions were often not taken back in time. Management did not know how many permissions were still floating outside, and there was no mechanism to track them. This was a real security and management risk, and the person responsible for this issue was exactly that original leader.

The second was device management. Maintenance records, fault reports, and repair follow-up for property equipment still relied a lot on paper records and spoken communication. It was scattered, inefficient, and easy to get wrong.

These two issues pointed to the same thing: he did have management pain points. He had just never said them openly.

Do not talk about the system. Talk about the problem he really cares about.

I changed the way I talked to him. I stopped introducing system functions. I went to him with solutions for the real pain points we had found.

I explained that our research had shown how difficult it was to track the permissions of people who had left. The system could directly help with that. It could record who had which permission and when that permission was removed, and administrators could check it at any time. The equipment-maintenance part could also be tracked in one place, without relying on paper notes anymore.

These words were not saying, you should use our system. They were saying, we noticed these real problems on your side, and we can help solve them.

That change altered the nature of the conversation. His defensiveness began to drop, and he started to discuss real function details.

Trust was built slowly. One talk could not solve it. But once the direction became right, the process became predictable: every time we solved one problem he truly cared about, trust increased a little. In the end, the SaaS system was successfully deployed at Oudian Garden.

There was another stakeholder conflict in the Oudian Garden project that is worth talking about separately, because the solution was a product-level one.

The property company had a rule: security guards should not be given direct access to owners' phone numbers, in order to protect privacy. But the real operational situation was this: cars were often parked illegally, and guards needed to contact the owners to move them. If they could not get the contact information, the process was very inefficient. Sometimes it led to disputes, and sometimes even affected safety.

Two valid needs directly conflicted: privacy protection versus fast response on site.

The solution was to introduce a virtual phone-number mechanism. The system generated a virtual number for each owner. In the app, the guard scanned the plate number, and the system automatically matched the corresponding virtual number. When the call connected, the system forwarded it. The guard only saw and dialled the virtual number. The owner's real phone number stayed hidden the whole time.

This satisfied the management requirement for privacy protection. It also solved the efficiency problem for guards who needed to contact owners quickly. Two conflicting needs became able to exist inside one product through one technical mechanism.

This case made me realise something important: many conflicts that seem like an either-or choice are not really asking you to take sides. They are asking you to find a technical or design path that allows both sides to hold.

If you are also in a situation where you need to push something forward but do not have direct authority, this kind of scene is probably more common than people like to admit in product work.

To me, influence is built on solving real problems, not on holding a title.