As a product manager, have you ever found yourself struggling to push forward a project due to slow progress, lack of cooperation from other teams, ineffective meetings, and difficulties in execution? This article aims to reveal the underlying logic of how large organizations operate and provide a reusable framework for breaking down collaboration barriers.
Why Do Your Excellent Plans Always Get Stuck When Involving Multiple Teams?
Many product managers, when they first join a large corporation, share similar frustrations:
- Their plans are logically sound, backed by data, and optimized for user experience.
- However, whenever these plans involve collaboration with multiple teams, the project grinds to a halt.
On the surface, the issues seem to be delayed processes, insufficient resources, or conflicting priorities.
- But the deeper reason often lies in the fact that you have unknowingly affected someone's "incentive structure".
In an organization, people's behaviors are driven not by what is right or wrong, but by personal gains and losses.
- When your proposed plan may affect someone's KPI, authority, promotion opportunities, or resource allocation, even if they do not openly object, the execution will be subtly slowed down, diluted, or stalled.
This is not "internal friction" but a natural reaction of the organization.
- The real problem is not that others are not cooperating, but that you have not made it safe, beneficial, and low-risk for them to cooperate with you.
From "Pushing Processes" to "Managing Fears": The Leap in PM Thinking
When I was pushing for my first cross-team resource integration project in a large corporation, I spent three weeks and had five meetings, but there was no progress.
- Each meeting ended with everyone expressing support, but when it came to execution, excuses like "dependencies are not ready" or "scheduling conflicts" would arise.
Later, I adjusted my strategy and instead of directly pushing the plan, I conducted one-on-one interviews with key stakeholders, asking only one question:
"What are you most concerned about with this project?"
The answers revealed the truth:
- One manager feared fluctuations in core metrics would affect quarterly assessments;
- Another was worried about not being able to report growth data after investing resources.
They were not opposed to the project itself but were each carrying different "fears" — and my previous communication approach had amplified these fears.
When you say, "This change can improve resource utilization,"
- To person A, it sounds like "My metrics might decline";
- To person B, it sounds like "You're going to occupy my schedule".
At this point, persuasion is ineffective. The real breakthrough lies in converting "persuasion" into "transaction" and "process management" into "fear management".
Constructing the "Fear Map": A Fundamental Tool for Cross-Team Progress
I systematized this method into the "Fear Map", which is not a PPT-style stakeholder matrix, but a cognitive tool that truly understands the driving forces behind organizational behavior.
What is a Fear Map?
The core of a Fear Map is to identify the most feared consequences for each key decision-maker in a project. Common types of fears include:
- Abnormal metrics leading to accountability
- Investing resources without achieving results, unable to report back
- Being marginalized, losing authority
- Disrupting existing priorities, affecting team goals
- Taking on additional responsibilities without corresponding benefits
How to Draw a Fear Map?
Step 1: List all key roles
- Not just direct collaborators, but also indirect influencers, resource approvers, and upper-level managers.
Step 2: One-on-one communication, ask the core question
- Do not ask vague questions like "What do you think?"
- Directly ask: "If we are to push this forward, what part are you most concerned about?"
This question collects real feedback and conveys respect and empathy, greatly reducing defensive psychology.
Step 3: Convert "fears" into "solution designs"
- For example:
- For colleagues fearing metric fluctuations, design a minimal pilot + quick rollback mechanism;
- For those needing data reports, set up a short-cycle verification framework to ensure conclusions can be drawn within two weeks;
- For responsible persons worried about being bypassed, invite them to co-lead the launch and joint reporting, sharing the glory of achievements.
These designs aim not to "perfectly solve problems" but to make it safe, beneficial, and low-risk for others to support you.
Case Review: Why a Project That Should Have Taken Two Weeks Was Delayed for Two Months
I once guided a new PM in optimizing internal collaboration processes, and after thorough validation, the plan could improve efficiency by 30%.
- However, he directly proposed it in a full-team meeting without prior communication with related team leaders.
As a result, the other party strongly refused on the spot: "Our current process is fine." In reality, it was not the plan that was the problem, but he sensed "territorial invasion" — his team being implied as "inefficient".
The project was stalled for two months. Later, we re-analyzed, drew a fear map, and found that the real fear of the responsible person was being weakened in presence and affecting team value assessment.
Solution Adjustment:
- Invite him to participate in scheme optimization, becoming a co-initiator;
- Have him lead the core achievements in the final report;
- Emphasize that this is "team-created efficiency practice", not external interference.
After adjustment, the project was restarted in just one week and successfully launched within three weeks. It was not because the plan changed, but because the "fears" were resolved.