颍水很忙，刚加入公司不到2个月，结果TA方向的主要产品负责人秋叶休假了，她作为TA接口人直面用户，压力非常大。
但是忙碌的时候，也才更锻炼人，也才能考察出个人的综合素质。
颍水做了一个小的产品方案，我反馈说："太技术了，期望能更多面向用户视角，所见即所得的设计产品。"
颍水还是非常积极主动，很认可的我的反馈，就去修改了。当然，修改并没有那么容易，一方面缺少历史文档，颍水无法完整了解业务，另一方面研发很忙，如果要想充分了解产品，PM就需要自己去读"代码"，即"存储过程"。
虽然认可我的反馈，但是颍水还表示了很焦虑，因为做一个东西，投入的精力过大了，效率难以保证。
TA的产研边界一直是个问题，秋叶来了一年多，也并没有很好地解决这个问题。并不是我一定不能让产品经理去了解代码，而是如果放任下去，危害非常大：
-
产研的边界模糊不清，研发越来越依赖PM的"技术方案"输入才能工作
-
PM的工作内容越来越多，为了和开发交流，需要写很多"伪代码"，没有精力更多地走进业务
-
PM难以给用户提供清晰准确的方案，无法在产品评审时深度共识，未来的bug和变更就会非常多，后患无穷
为什么TA的这些PM都是会陷入这个怪圈呢，我认为有2个原因：
-
TA这个产品的特性，PM承担了前端开发的角色，技术更多是做后端开发
-
PM还不是真正的产品经理，更多承载了"顾问"的角色，这也是我主动替换了秋叶前任的原因
如此这般下去，PM的产品工作质量就会越来越差。
所以，我在TA产研双周会上提出了这个问题，和我的Leader一起进行了讨论。
会议过程不过多赘述了，每一个次对于现状的打破，都是要"血淋淋"的，总之，大家认可了我提出的新的产研边界，PM要更关注业务、产品，而不是技术实现，研发也不能只停留在原地，要去了解产品，要能和业务在同一个场景下对话。
因为历史的产品文档不全，尤其是缺少用户视角的设计，所以会后，颍水又找到我，认为按照新的方法落地是有困难的。我也很理解，所以我们共识，在新的产品上，按照新的方法执行；对于历史的产品，PM还是可以去了解技术的，但是要逐步补齐产品设计，有计划脱离技术去做产品设计。
我并不觉这一次的沟通就能彻底解决问题，还好大家都认为可以在产研双周会上持续追踪，但这个方向是不会错的。通才很重要，但首先要是专才。