在开发一个新功能时，产品经理小李拿着原型图走进会议室，说要加个“一键分享到10个平台”的功能。架构师老张听完，皱了皱眉，不是因为技术做不到，而是这个需求背后没说清：用户真需要吗？系统扛得住吗？
角色不同，关注点自然不一样
产品经理盯着用户体验和市场反馈，总希望功能多、上线快。架构师则关心系统稳定性、扩展性和技术债。一个想往前冲，一个想稳着走，听起来像在打架，其实可以配合得很好。
比如公司要做个会员积分系统。产品经理的想法是尽快上线基础功能，收集用户行为数据。架构师考虑的是未来可能对接第三方商城、支持积分兑换、防刷机制。如果两边不沟通，最后可能做出一个改一次崩一次的系统。
协作的关键是互相“翻译”
产品经理不需要懂微服务怎么拆，但得让架构师明白这个功能为什么重要。同样，架构师不用逐行解释代码，但得告诉产品：“你现在要加的这个按钮，会触发三个数据库写操作，高峰期可能拖慢整个订单流程。”
有个实际例子：做直播带货功能时，产品提了个“实时显示观众点赞数”。架构师没有直接答应，而是问：“实时是秒级更新就行，还是必须毫秒级？” 产品说“用户感觉流畅就行”，于是团队决定用每2秒轮询一次，既满足体验，又避免服务器被打爆。
用文档建立共识
好团队不会只靠口头沟通。常见的做法是写技术方案文档（RFC），产品经理参与评审。文档里写清楚：要做什么、为什么做、技术选型、影响范围。
<!-- 示例：功能影响评估表 -->
功能名称：用户等级系统
负责人：产品经理 - 小李，架构师 - 老张
依赖服务：用户中心、消息队列、数据库分表
性能预估：QPS 增加约 200，缓存命中率需保持 95% 以上
上线节奏：灰度发布，先开放 10% 用户这种文档不求多复杂，关键是谁都能看懂。产品能从中看到上线风险，架构师也能确认业务优先级。
日常协作的小技巧
每周安排一次15分钟的“对齐会”，不写议程，就聊最近遇到的卡点。产品说说用户投诉最多的问题，架构师讲讲系统报警最多的模块。时间一长，彼此就能预判对方的思路。
还有一个实用做法：在需求池里给每个任务标上“技术复杂度”。不是为了推活，而是让产品知道，有些功能看着小，背后改动大。比如“换个按钮颜色”可能只是前端一行代码，而“根据用户习惯动态换色”就得上AI模型了。
真正的协作不是谁听谁的，而是双方都愿意多走一步。产品开始关心响应时间，架构师也开始问用户画像，项目自然就顺了。