Bridging the Gap: How Product Managers Can Collaborate Effectively with Engineers

Why Collaboration Matters

In the internet industry the relationship between product managers and developers is often portrayed as antagonistic, yet both parties share the same goal of delivering successful products; miscommunication can lead to project failure and staff turnover.

Common Programmer Complaints

Frequent changes to requirements during development.

Large‑scale modifications requested during acceptance testing.

Unclear value of the requested features.

Product managers estimating developers' workload.

Insufficiently detailed requirement specifications.

Root Causes of These Complaints

The most hated issue for developers is the constant requirement churn, which usually stems from inadequate upfront communication and insufficient consensus during requirement reviews. Even when developers question a feature, product managers often cannot articulate its value, leading to further friction.

Product Manager Perspective

Belief that a feature cannot be implemented.

Desire for a “no‑change” product that is completed in one go.

Focus solely on code quantity, ignoring user experience.

Skipping self‑testing and handing off unfinished code.

Chasing new technologies without assessing product value.

Three‑Step Approach for Product Managers

Align on the big direction and reach agreement with developers before work begins.

Excel in product‑manager responsibilities by centering on User Stories, defining delivery standards, delivering low‑fidelity prototypes, and writing thorough Use Cases instead of spending excessive time on visual mock‑ups.

Apply communication techniques to mitigate confirmation bias using the five actions “齐、拉、捧、说、谦”.

Communication Techniques (“齐、拉、捧、说、谦”)

齐 (Alignment) : Before discussing a requirement, explain its background and significance, especially when changes occur.

拉 (Engagement) : Treat developers as allies; use inclusive language like “we” and “together” to create a collaborative atmosphere.

捧 (Praise) : Offer sincere, targeted compliments that acknowledge a developer’s expertise while positioning the product’s needs as a shared challenge.

说 (Persuasion) : Back arguments with data and user feedback; understand which metrics matter, how features affect them, and communicate the cost‑benefit clearly.

谦 (Deference) : Give developers space to voice their opinions; recognize that different professional lenses lead to different interpretations of the same problem.

Use‑Case Template (Example)

用例名称：提问
层次：!（用户目标层）
范围：问答网站（以下简称系统）
主用角：注册用户（以下简称用户）
其他干系者：...
后态：
前态：用户已登录。
触发事件：用户选择提问。
基本流：1. 系统显示新建问题框。
      2. 用户输入问题陈述（字数限制？），系统即时验证并提示相似问题。
      3. 用户设定该问题的相关话题。
      4. 可选项：用户补充问题说明。
      5. 可选项：…
      6. 用户提交问题。
      7. 系统验证问题有效性。
      8. 系统发布问题并显示问题页面。
扩展流：用户放弃提问：...

Additional Advice for Engineers

Improve professionalism by focusing on User Stories and detailed Use Cases rather than endless prototyping.

Adopt a mindset of “cost = effort”; recognize that overly detailed specifications increase product‑manager workload, while developers should respect that cost.

Practice deliberate perspective‑shifting to understand user experience; regularly test your own product and competitors.

Treat delivered code as your personal “brand”; thorough unit testing and self‑testing improve reputation and future opportunities.

Embrace new technologies only when they add clear value; avoid adopting tech solely for novelty, as it creates hidden technical debt.

Summary of Recommendations

Before declaring a feature impossible, ask three questions: is it necessary, is it truly infeasible, and does its cost outweigh its value?

Recognize that a requirement itself incurs cost; balance effort between product and development.

Deliberately practice switching to the user’s perspective to enhance empathy and product sense.

Deliver work that reflects your personal quality; rigorous testing and responsible ownership are essential.

Adopt new technology only when it delivers tangible product value; otherwise, treat it as “junk”.