产品人员干的活往往是多而杂的，对于B端产品更是如此。
在早期，团队规模较小时，一个B端产品人员可能会同时做着多件事，包括产品设计、交互设计、迭代管理、产品测试、对外宣讲、产品维护、甚至是项目维护等多个职能。
在业务较少、迭代速度慢的时候还能勉强应付。
但是随着业务的发展，团队的扩大，会发现越来越分身乏术。什么都要干，但结果却是什么也干不好。
比如，刚做好一个迭代计划，可能由于紧急项目支撑，全部就都搁置了，结果发现自己的产品似乎总是在补功能，补漏洞，管理杂乱无章，产品进展缓慢。
因此，面对这种局面，必然要往前一步。
就是要分工，让专业的人做专业的事情。
二、如何分工那么对于B端产品运营团队该如何分工呢?
我们首先需要把我们的事情全部罗列出来。罗列的时候不用去想合适不合适？用穷尽法的原则，想到就写上，结果如下：
团队 | 需要做的工作 |
产品运营部 | 市场分析、需求分析、产品设计、交互设计、迭代管理、产品材料撰写、对外宣传、市场解决方案、市场支撑、产品安装、项目维护。 |
Tips:刚刚还说有产品测试，这个本来就属于测试的活，规模小了产品运营团队还能勉强凑合，规模大了，测试这种专业性的活还是单独划分给测试团队去做吧。
仔细想想我们感觉自己身兼多职的主观感受还是因为不同的角色面对的对象是不一样的。所以接下来，我们把这些工作以不同任务面向对象来划分，可以分为面向内部团队，面向市场销售，面向项目实施，划分结果如下：
面向对象 | 需要做的工作 |
团队内部 | 需求分析、产品设计、交互设计、迭代管理、产品材料撰写 |
市场销售 | 对外宣传、市场解决方案、市场支撑 |
项目实施 | 产品安装、项目维护 |
有了以上划分后，我们可以根据面向的对象把职能进行细分，分成三个小团队，如下：
部门
| 团队 | 面向对象 | 需要做的工作 |
产品设计团队 | 团队内部 | 需求分析、产品设计、交互设计、迭代管理、产品材料撰写 | |
产品运营部 | 产品运营团队 | 市场销售 | 对外宣传、市场解决方案、市场支撑 |
项目管理团队 | 项目实施 | 产品安装、项目维护 |
以上，产品运营部的三驾马车初现雏形，市场运营（MO）主要负责产品的市场沟通与宣传，产品设计（PD）主要负责产品的迭代，项目管理（PO)主要负责产品的项目对接。
三、如何解决信息隔阂的问题对于管理来说，从来都是抓住关键少数人即可，划分成三个团队管理，需要赋予三个团队的组长管理职能，并且做日常的管理引导，这里就不多赘述。我们主要说说划分成三个团队后会面临的问题。
因为不同的人分属于不同的团队，面向对象不同，那么原来由一个团队全面对接所有对象的优势就没了。
这个优势即可以获取各个对象的反馈信息，并且综合考虑用于迭代。
而分成三个团队后，可能会造成产品设计团队没有市场信息渠道而闭门造车。产品运营团队，没有项目管理问题反馈而宣传时候不能迅速识别客户的诉求。项目管理团队，没有获取产品设计的最新规划而不能很好应对项目实施中的新需求。
似乎成了死循环。
其实有得必有失，穷则变，变则通，通则达，我们分成团队后确实会造成信息隔阂，解决办法就是信息流转起来就好。如下图所示：
产品设计人员要把产品的功能和计划以发布说明的方式告知给市场运营和项目管理人员；
项目管理人员要把项目反馈以需求池的形式提交给产品设计人员，把项目案例以项目管理会议报告的形式提交给市场运营人员；
市场运营人员要把市场需求以需求池或MRD的方式提交给产品设计人员，把市场解决方案以标准文档的形式给项目管理人员。
以上三驾马车就能快速奔跑起来，且信息能够及时传递，不会造成内部的信息孤岛现象发生。
四、结语俞军说不同公司产品经理的工作都是千差万别的，所以不同公司也都有自己的产品运营的特点，以上仅为一家之言，供大家在寻找管理方法之时有一些参考。
