产品经理和研发两个岗位，相爱相杀，互相甩锅又离不开彼此。研发是实现需求的人，而需求又得由产品将业务语言转述成产品语言给到研发的。
作为产品经理，是否需要知道功能在技术上是如何实现的呢？
当然需要知道，但仅需要到知道的程度
01
产品经理可以分得很细，根据面对的市场对象可以分为ToC、ToB、ToG这三大类产品经理
三类产品对技术实现的理解程度要求是不一样的。
对于C端产品，一般产品功能相对简单，因为在整个系统里所涉及到的角色很少，比如IM，它所面对的是对话双方，在这里只要A能把信息通过文字输入、语音等方式传递给B，那么基础的业务也就通了。而如何从A传递给B不用了解。
对于B端产品会复杂很多，B端业务一般涉及到的角色远不止2个，一个复杂的B端系统，一般会由N个子系统进行相互嵌套，不同系统之间又有着一定关联度。
特别是使用微服务做系统架构的团队，对产品经理的要求将更高。
如果产品经理在做业务的时候不知道调用哪些服务来组合，很可能需求文档都写不清楚，更不用说开发了。
G端产品的要求介于C和B之间。这里不详细展开
所以我们常说C端产品重用户体验和同理心，B端产品重逻辑。
02
好的产品一定懂得如何和研发沟通 ，有句不恰当的比喻：见人说人话，见鬼说鬼话。
产品经理就得这么去做，产品经理是和人打交道的一个岗位，但又不像运营那样只和人打交道。人包括了用户、运营、Leader、研发、测试、客服……这所有的岗位产品经理都需要接触，哪怕是同样一件事，跟不同人沟通的时候就得说对方能听得懂的语言。
所以产品经理需要知道需求在技术上如何实现，不然你和研发和测试就很难沟通在一个频道上。
那产品对需求的实现上需要了解到什么程度呢？
衡量标准很简单，产品需求的PRD写得没有漏洞，研发可以根据文档直接上手，不会有质疑的程度就算合格。
一份好的PRD已经是代码了，缺的只是一个研发根据文档里的每一行字用对应语言写下来而已。
我这里有一个通用公式，告诉你如何去理解需求的技术实现
很简单，输入->输出。
任何一个产品不管它前台展示了什么信息，一张图片，一段文字或者是一个数字（金额）。总有个地方会将原始信息输入进去，你不用考虑黑盒是什么，那是研发要去理解的部分，你只要清楚如果要在前台输出A，那么需要在哪里，由谁输入B
就像能量守恒定理描述的一般，能量既不会凭空产生，也不会凭空消失。前台的任何信息就和能量一样是不会凭空出现的
我的公众号文章，里面每个文字，都是我通过公众号后台输入进去的，系统不会自动为我生成。顶上的公众号入口也是我在后台通过选择公众号按钮插入进去的。
再如购物车系统，购物车里面的商品信息，一定是你在看商品的时候通过加购按钮添加进来的。展示出来的SKU、图片等也都有自己的出处
碰到复杂一点的系统，你需要理解的实现原理是这样的
但不管多复杂的系统，拆开后总会发现它是由一个又一个输入输出构建而成的。
最后的话
社会分工发展的现在，早就由单兵作战变成了团队合作。专业的事让专业的人去做。
产品经理相较于其他岗位会特殊一些，因为你得链接不同岗位，每个岗位的专业知识你都应该涉猎一些，这样在沟通上相比其他人才更有优势。
特别是非互联网岗位的你，如果要转行做产品，如何和研发和运营在一个频道上沟通比学会软件如何使用更重要。
