产品和运营这亦敌亦友的关系

互联网产品团队的核心作用是产品、运营、研发UI/交互。这四种关系分为两种：需求提出者与满足方之间的关系，如产品对研发和设计师的需求，以及对产品运营的需求。产品和运营是需求方，R&D和设计师是满足方。产品和运营等相互依赖和合作的关系。如果这两个角色想要做好自己的工作，他们必须继续密切合作，没有任何人都不能。然而，在产品和运营协同工作的过程中，会出现许多复杂而难以解决的问题，如下：运营认为产品不注重运营，但运营应对产品负责：为什么PM从不与我们讨论功能，他们了解用户需求，了解行业？功能上线后，用户会发出一片骂声，让操作出来安抚解释，其实就是擦屁股。几个版本的效果很好，PM在群里的邮件里愉快地写了效果评估。事实上，这是因为运营的核心用户支持我们。我们为新版本策划了活动。信用是PM？为什么运营需求总是优先级最低？根据需要预测什么效果，不上线怎么预测？这不是形式主义愚弄人吗？产品认为，操作总是没有发挥应有的作用：当操作不能盯着KPI做活动时，数据就会上升，为什么不看保留呢？我知道有奖送礼什么的，让产品烟雾缭绕，一点氛围都没有。为什么操作不能有一些基本的产品思维，更不用说那些无关紧要的需求了，这和用户直接反馈有什么区别，让我们花时间解释为什么不这样做。我们需要的是爆点，而不是小打小闹。如果你说你知道行业内有很多朋友，请邀请更多的大牌来活跃，帮助传播和推广。以上描述虽然极端，但很有代表性。相信很多公司的产品和运营同学都有过类似的感受。因此，让这两个角色配合默契、有序运作、形成合力并不容易。让我们来谈谈产品和运营之间的关系，也是敌人和朋友。1.产品和运营合作出现问题的根本原因是：两个目标不一致，导致从起点到具体实施是两条平行线，不能拧成绳子，不能形成合力。由此可见，统一产品和运营目标是解决这一问题的核心点。为什么目标不一致，因为屁股决定头。从组织结构的角度来看，许多公司的产品和运营分为两个团队，由两个不同的老板负责。既然团队和老板都是两个，那么目标肯定是两个，否则这两个老板和两个团队的价值是无法衡量的。比如两个人炒一盘菜，一个负责切，一个负责炒，颜色、香味都是谁的功劳，很难分辨谁是幕后的黑手。如果两个人互相推卸责任，就会进入扯皮阶段，很难治愈。一般来说，在团队分工中，工作内容与目标的重叠将被避免，以确保团队或个人的独立性。这样做的目的是为了确保员工的个人发展空间，也很容易清楚地衡量工作产出，暴露存在的问题。综上所述，由于团队分工问题，产品和运营目标不统一。此外，两个团队的结构也会带来其他负面影响。例如，为了争夺话语权，两位老板发生了对峙。这种状态的原因是个人利益，而不是工作，必然会影响决策的合理性，最终影响产品的进展。2.如何解决这个问题，想想你在百度的经历。第一年，产品和运营是两个独立的团队，原因如上。虽然总体上是正常的，但也会有自己的战斗、运营活动、核心用户和内容规划；PM做各种产品优化，以不断改进转换等数据。单独看任何一方的工作都是正常合理的，但双方同时可以发现交集和合作很少。第二年，为了孵化独立的新项目，优化团队结构，每个新项目都建立了一个独立的团队，每个团队都有一个PM作为负责人。虽然每个团队不到十个人，但所需的角色，如产品、运营、研发、设计，麻雀小五脏俱全。在这个小团队中，虽然每个成员都有不同的分工，但目标是相同的，但每个人都通过完成自己的任务来实现这个目标。例如，PM优化操作流程，提高流量转化率，确保开发任务按需要和时间点完成，尽量减少BUGUI设计师的页面效果，不仅满足PM的功能需求，而且满足操作的预期基调。在每天的晨会（站会，10分钟）和每周的例会（1小时）中，每个人都会抛开自己的分工，加入产品讨论。虽然经常有不可靠的建议，但这就像一个团队。虽然经常有不可靠的建议，但它就像一个团队。但这种模式也有一个缺点，那就是只适合5-20人的小团队。若人数增加到30人，肯定行不通。原因是:首先，老板直线管理这么多人的成本和难度都很高，沟通和信息交流也不会那么顺畅。如果老板和员工之间再增加一个层次，变成金字塔架构，那就更复杂了。其次，如果是30人的团队，产品和运营商的数量也会增加，比如5人，这意味着产品和运营分别建立了二级团队。如果一个独立的小团队成为一个大团队，上面提到的目标就会不统一，各自为战。因此，如果可以分成小团队，或者本来就是小团队的公司，可以尝试上述方案。一旦团队规模变大，就不再适用了，这也是业内人士羡慕的团队「小而美」的原因吧。当然，大团队也不是没有解决办法，可以通过扁平化的团队结构来缓解产品和运营合作不良的问题。比如一个总监同时管理产品和运营团队，两个团队分别有一个中层经理，另一个小团队。这样的三层团队设置在层次上是可以接受的，承担30人的团队也没问题。3.说到产品和运营的关系，谁更有话语权，就要说话语权。两者之间肯定会有强弱关系，不可能有一碗水端平状态，只是强弱差或大或小。当然，每个人都想领导项目，但有时他们无法控制。有两个因素决定了一个团队是产品驱动还是运营驱动：团队基因。团队基因主要由创始人团队带来，因此基本上相当于创始人基因。这一规律适用于从一家公司到一个小团队。所以，要看团队是什么角色驱动的，主要看老板。如果老板出身PM，公司很可能是产品驱动；如果是技术背景，那么运营角色一定很弱，不被重视。因为技术人员一般不注意也不懂操作，两个角色真的太远了。产品属性。一般来说，这取决于产品是什么。不同类型的产品适合不同的团队结构，这也决定了角色之间的发言权。工具产品必须由产品驱动，如天气、笔记和照片应用程序。即使渠道起着很大的作用，它也不会成为驱动者；O2O产品必须由运营驱动，如团购和家庭应用。因此，如果你想看看一个团队中哪个角色更有发言权，哪个角色是主导地位，你可以从上述两个因素中看出。4.如何配合团队结构，那么如何配合产品和运营是合理的，可以发挥双方的合力。在我看来，它分为两个阶段：产品上线前后。当然，可能没有这样一个纯粹的阶段，但也有这样一个状态。上线前的第一步:产品的功能规划和发展方向是老板的决策。决策完成后，应告知团队全体成员项目的背景、方向和规划，让大家充分了解信息，有助于后续的实施过程。第二步:后续实施环节规划是产品与运营协同工作的开始。例如，受众、功能特征、版本节奏、运营规划等，双方应共同参与讨论，得出一般框架和计划。第三步:按照框架计划，大家开始分开行动。产品绘制原型，设置功能细节；操作准备内容、流量渠道和核心用户，以及在线规划后的爆炸点。在这个阶段，产品和运营可以暂时分离，没有频繁的合作。但由于前两步的铺垫，双方在分开行动的过程中也了解对方的计划和进展，因此信息是交换的。第四步:在上线前的准备阶段，以前分开行动的产品和运营的双方都要回到一起，交出之前的作业。也就是说，每个人都为产品的推出做好了准备，什么是进展，什么是问题，什么是后续计划，并进行交流和讨论。问题解决后，就可以上线了。上线后进入产品正式运营阶段，产品与运营再次结合协同工作。在这个阶段，需要高频的沟通和相互促进的工作。操作，主要*用户反馈。在做好内容、用户、活动、渠道等操作的同时，及时详细通知用户反馈，让团队了解用户对产品的反应。*用户需求，转化为产品需求，推动PM上线。提出工具需求，可以大大提高运营效率，促进PM产品的解决。除了修复bug和完成产品需求外，产品协助运营的规划和实施还应注意运营反馈，因为这是产品投入用户群体后的反应，也是确认之前决策的过程。注意运营中遇到的问题，能否通过产品解决。主动与运营学生沟通，给出解决方案，促进研发的完成。还需要注意运营措施是否合理，是否能促进产品目标。如发现偏离目标或只有KPI的行为，应及时沟通，促进改进。当然，产品上线前后不仅要做这些事情，还要提到需要产品和运营合作的节点。由于每个项目的情况都非常复杂，所以上述事项肯定不完整，只能作为一个想法，例如。5.为什么很多操作都想转移PM其实产品和操作的关系？描述起来很简单。产品负责功能设计，也是R&D和设计师支持的接口；操作负责维护、拉动和推广，所有机器无法解决的问题都需要操作来解决。在我看来，产品和运营是两种不同但平等的职位，需要不同类型的人才。但是为什么现在很多新人更愿意从事产品工作，甚至已经做过运营的同学也想转做产品，主要是因为「神话中的产品经理」供需失衡造成的。主要原因是李开复、周鸿毅等明星老板公开声称自己是产品经理，过于理想化地描述了这个职位的工作内容，从而吸引了更多优秀的年轻人加入这个领域。此外，公司深受影响，更注重产品经理这样的岗位，愿意花更高的工资邀请这样的人才。在这种供求关系的推动下，优秀的年轻人愿意加入，觉得自己的职位高，工资高；公司也愿意以高价邀请人，认为产品经理很重要，只能以高价邀请人。这就是为什么一些运营商想要改造产品。当然，产品经理也应该从基层开始，甚至从打杂开始。很多PM已经工作了一两年，还在团队里打杂消防，或者做一些边缘化的事情，这是很正常的。写完了。