最近时常需要兼任产品相关的工作，也就是传说中「产品经理」的相关职责。

关于研发和产品之间势同水火的状态，业界已有很多段子。产生矛盾的原因多半还是因为互相对于对方的知识领域不了解，同时又无法说服对方。

作为研发，在设计一个产品原型的时候，画具体界面的时候，本能地会首先去考虑技术上是否可实现，毕竟再好的设计也要落地了才能发光发亮。于是，有研发背景的产品经理，本能上设计出来的产品一定是可实现的，研发的同事拿到设计稿至少不会因为不可实现而吵起来。

显然，这也是一种局限，这样的设计相对比较保守，稳妥/能做出来为主要宗旨。中规中矩，甚至没有特色，用户体验和界面美观上就会有欠缺。作为产品，用户体验、产品的核心价值如何体现才是最重要的点，围绕这些点，操作是否简洁明了、界面是否符合受众的审美才是关键。

一边追求稳妥，一边追求体验，体验通常意味着一些细节的处理，一个看似很小的功能需要暗含很多处理逻辑，用户用起来无感，但是背后的设计可能相当复杂，于是很大程度上会需要增加研发的工作量。能不能实现，以及如何更好地实现，这些都是研发需要考虑的问题，有些只是需要更多的时间，有些需要去引入新的技术框架，但这些过程，如果没有一定的技术背景，很难去预估工作量，那个吵翻天的点就在这里，产品经理认为改一下应该很快啊，就几个按钮嘛，而研发心中已经一万只在奔腾，但似乎又跟产品解释不通，真是懊恼。

反之亦然。产品觉得某个按钮不应该放在 A 处，而应该放在 B 处，而对于研发来说，也许并没有太大区别，也许牵一发而动全身，但就是不理解为什么非得放在 B 处，这时候该换做产品心中一万只在奔腾，但跟研发也同样解释不通，更是气愤。

多数的沟通不良，都是认知上的偏差，如果研发有设计背景，而产品有研发背景，沟通上势必会顺畅很多。作为一个有追求的研发，花点时间去研究下设计，比起产品的人去研究技术，通常情况来说，要更容易一点。再加上，如果在设计产品的时候，能够暂时抛开技术的局限，那就无敌了。

原型图工具真是个好东西，可以在真正研发开始之前就把很多产品细节展示出来，所以我一般倾向于提供比较详细的原型图，而不是简单的跳转关系的草图，原型图中小到一个按钮的图标、一个点击动作、一个加载提示都是最接近最终产品形态的。有这样一个原型的好处在于，无论是跟领导沟通，还是跟研发的同事沟通，都非常顺畅，界面长什么样、如何跳转都看得清清楚楚，这样研发的同事心里也有底，哪些点会需要消耗较多的工作量、难度如何，也都一清二楚了。

最理想的沟通状态是，双方对对方的领域都有所了解，至少有基本的常识，基于这样一个「共同的认知」，沟通的结果也一定不会差。那这样是不是意味着我们需要掌握很多领域的知识，理论上是这样的，就像查理·芒格时常提到的「跨学科」是一个道理，不要认为做出一个投资决策仅仅具备金融知识就够了，一个详尽的调研和决策可能会涉及很多行业。但如果每个学科都精通，确实需要付出异于常人的精力，对于我们大多数人来说，可能会有点困难，那么就退一步，不需要个个都精通，但是常识性的理论（Common Sense）还是要花时间去学习下，这样至少碰到问题，我们会知道要从哪入手，再去找寻更深入的答案。

所以当同时需要兼顾产品和研发时，对我来说，有技术背景，保证产品可实现这一点无需担心，跟技术同事沟通也不存在任何阻碍，更大的挑战在于如何跳出技术的限制，有时候确实需要更天马行空一点，用好的设计来倒推更好的技术实现方式。