一般来说，互联网公司都是只有一种产品经理，但是不同的套路来了，某电商巨头所属的物流公司的产品经理有两个细分，一个叫业务产品经理，一个叫研发产品经理；
一直困惑产品分为业务产品（出brd）和研发产品(出prd)是出于什么考量。作为研发的产品经理，在违和的微妙感持续飘来飘去之余，夹在两拨人之间的抱怨那是常态，这俩波职能分别是业务产品以及研发工程师（限前后端）；
困惑的背后其实是在思考职能拆分之后的研发产品经理的核心价值在哪里。向左看：客户资源掌握在业务产品手上，可以拿用户需求+订单压brd&排期；向右看：生产力掌握在研发手里，在需求排排站的情况下，不接需求的套路可以有千千万（加之软件开发的价值多为隐性知识，让其显性化是主要的沟通成本，在此之外，工程师是否愿意将认知显性化也是个前提，万一还是个专利嘞？）；那么问题来了？你夹在中间的研发产品是干嘛的？
带着疑问去观察，随着工作任务的来临，矛盾也逐渐透露出来：
业务产品提出的需求通常有这么几类，有更偏向于一句话需求的，也就是期望大而全同时还有点那么的模糊；也有雪花般零散的小需求，一会来一个，一会再来一个；规划吗，别问，问的话很可能是在探索中；（然后一去查招人要求，要能提供某行业全链路方案，也就是传说中的面试造/设计火箭来了）；
单一业务产品描述的需求/方法论有问题么？并没有突出的问题，甚至不时还有些创新的惊喜，因为客户/业务职能方确实也是会用相似的语言描述需求以及期待/相似的套路。
矛盾：但是当多个业务需求提来类似产品功能需求的时候就会产生问题：因为不同人对相同的问题有不同的解决方案，加之对同一个产品会有不同的功能期待以及模块划分的设计；
这就好比每个人都怀着对耶路撒冷的美好想像去到那里，结果看到的是一个兴旺过，重建过，摧毁过多次的，不断变化的耶路撒冷，从而产生失望；但同时每个人都保留着对中心耶路撒冷所理想样子的权利，并且时不时冒出来争取落地；（笔者为了思考这个问题还特意去买了一本【耶路撒冷三千年】）
到了研发侧，一方面是工程师对落地产品方案要求细致+具体，用以判断同研发能力是否匹配，另一方面是大多数研发工程师只负责自己那一部分，当跨的模块多的时候则要么要求产品经理之间协调，要么依靠项目经理协调推进；
矛盾：这中间产品落地方案不合适就会遭到研发同事吐槽；除此之外做出来的东西还很有可能不是业务&用户可以认可的，因为人家心中的耶路撒冷又变了；
打个比方，就好比有资源的老板想开个新饭店，在还没有规范的菜单的情况下，招聘了客户经理（业务产品）去转化客户，从而获得预约吃饭的订单，再招你（研发产品）负责某几个包间/大厅，你从客户经理那里了解到客人说人家要海鲜，肉，素菜，水果；你就跑到厨房问各个现在或者未来一段时间将会空出时间来的大厨，问他们可以烧什么，结合当时/近期有什么食材，再反馈给客户经理推荐鱼香肉丝，清真鱼，水果拼盘；让其同客人沟通，看看客人是否满意，不满意再重复推荐&后厨确认；如此反复；
这期间可能出现几个包厢的预约客户同时叫你推荐菜品，后台师傅&食材资源冲突，供货的菜场今天没葱了，以及用户来了以后要求改菜，一会盐放多了用户不满意等等需要协调的问题，需要你协调；
问题到此结束了嘛？并么有，客人可能取消预约，也可能因为等太久菜没出来，走了；也有可能是用户吃习惯了隔壁饭店的口味到你这就是吃不顺；当然，即使用户吃完了你也不好判断用户到底满不满意，只能观察用户还来不来再吃；
随着时间的推移，顺利的话，摸索出了几个菜谱，也摸出了不同用户在包间和大厅吃饭的不同偏好，然后就是考虑量产以及利润的问题；再根据反馈不断迭代菜谱；
另外处理以上问题的同时还需要兼顾了解隔壁饭店客流量，以及其有无新品问世受到客户欢迎；
（我想了一下，有这能力咋不去印度街边摆摊卖飞饼呢？）
这么一想：至此职能上划分业务产品和研发产品的主要原因出来了：
一方面是业务产品通常将精力放在满足用户需求的解决方案上，同时就没有更多的精力通过对接到研发工程师的颗粒度上去推进产品开发落地，直接沟通很可能会出现一方以为一句话能说清楚的事情，另一方灵魂题问3k+，从而产生许多不必要摩擦；
另一方面是从解决方案可以非常的多样化，到产品设计模块化以及相对通用化还是需要一个转化与沉淀；
也正因为关注点以及思维习惯&角度的不同，不经转化的推进会产生两边的抱怨（客户经理想的是这单能不能成，以及以后能不能重复的成，大厨还以为你是拿订单来激将出人家祖传秘方），才导致了研发产品经理这个职能的诞生；如果业务产品或者研发工程师任何一方停止抱怨的话，研发产品经理也就失业了；
备注：随着时间的推移，逐渐根据观察以及他人给予的反馈，从身边所接触到的实操提炼出一个解决思路框架（也就说很可能推进的时候是无意识的，但是就是已经这么发生了，而且经过观察还是可以在一定时间内缓和业务需求以及研发节奏的方法）。
这个思路就是：拿前端换后端的时间，也就是可见不等于可得；
说人话就是：表里一套，‘背’里一套。
即表面的一套用于快速在前端给业务方一个交代：可感知的输入，输出，以及操作/样式，以及配置；
‘背’里的一套用户无感知，用于同研发沟通实现产品处理逻辑，不同研发工程师的分工协作，以方便研发工程师进行技术方案设计以及技术选型迭代。（后续细聊）
