1. High-Conflict Stages

1.1 Requirements Analysis and Communication Stage

Typical situations:

  • Developers do not agree with the solutions proposed by product managers, causing disputes
  • Developers believe the requirements documents provided by product managers are not clear enough, affecting subsequent development work

Core problems:

  • Product managers only describe requirements verbally, lacking clear flowcharts or documents
  • Unclear requirements lead to inconsistent understanding among developers, planting hidden misunderstandings

1.2 Development Implementation and Mid-term Change Stage

Common situations:

Problem TypeSpecific Manifestations
Requirement changesProduct managers temporarily change or add features, causing code rework
Technical communicationProduct managers lack technical knowledge, low communication efficiency
Document absenceChanges are only communicated verbally in chat, formal documents not updated in time

If changes are only communicated verbally in chat without timely updating formal documents, when deviations occur later, both parties easily blame each other for requirements that were “said but not written.”


1.3 Project Progress and Iteration Planning Stage

Conflict focus:

  • Product managers: Face launch pressure, want to release more features as soon as possible
  • Developers: Better understand the workload and difficulties of technical implementation

China-US differences:

AspectChinese CompaniesUS Companies
Overtime culturePrevalent, constant pressure before deadlinesEmphasize work-life balance
Handling methodRequire rushing workAdjust scope to meet time requirements
Engineer attitudeSilently endure or express discontentDirectly oppose or request scope reduction

1.4 Testing Acceptance and Release Stage

Conflict manifestations:

  • Delivered features do not meet product manager expectations
  • When many defects appear, both parties blame each other

Conflicts in the testing stage essentially stem from problem accumulation in previous stages, but emotions are more likely to intensify due to time pressure near release dates.


2. Main Problem Points of Conflicts

2.1 Communication Barriers and Cognitive Biases

Core problems:

  • Developers tend to use technical language, focus on implementation details
  • Product managers are accustomed to using business language, user perspective to express requirements
  • Both parties have different focuses, may talk past each other even when discussing the same issue

2.2 Unclear Role Boundaries and Mutual Shifting of Responsibility

Typical scenarios:

  • When requirement documents or process standards are imperfect, problems easily lead to mutual blame
  • Testing finds features don’t meet expectations, role definitions in documents are unclear
  • When projects are delayed, product blames development for low efficiency, development blames project management for poor handling

2.3 KPI and Evaluation Conflicts

Nature of conflict:

RoleFocus Metrics
Product managerNumber of new features, commercial metrics, quickly stacking highlights
Technical teamSystem stability, on-time delivery, technical risks

Under KPI pressure, technical managers only want tasks that are easy to implement and have controllable risks; product managers want to add features and create highlights.


2.4 Goal Inconsistency and Priority Perception Differences

FocusProduct ManagerDeveloper
EmphasisMarket performance, user needs satisfactionTechnical feasibility, efficiency, and security
PriorityQuickly develop features that can capture business opportunitiesFirst solve technical debt or performance bottlenecks

2.5 Technical Feasibility Assessment Biases

Common phenomena:

Product managers are often not from technical backgrounds, easily underestimate the development difficulty of certain features, thinking “it looks very simple” changes make programmers exclaim “OMG need to change countless lines of code.”

Two-way problems:

  • Product managers: Don’t understand technology, make unreasonable demands
  • Developers: May overestimate implementation difficulty to protect schedules

2.6 Other Common Friction Points

  • Temporary requirements: New requirements thrown out when development is almost finished
  • Detail neglect: Developers too obsessed with technical details, neglect user experience
  • Outsourcing conflicts: Conflicts between甲方 (client) and 乙方 (development team) due to contract scope and change fees

3. Summary

Key Findings

  1. Communication is the core amplifier: Poor communication is often an amplifier for all other problems
  2. Information asymmetry: Leads to understanding differences, triggers chain reactions like goal inconsistency and priority conflicts
  3. Stage correlation: Conflicts are often connected, misunderstandings planted in the requirements stage explode during development and testing

Solution Directions

  • Process standardization
  • Communication mechanism optimization
  • Goal alignment