一个优秀的运营，到底需要有多懂“产品”？

2017-02-27 10:24:00

今天我们来聊一个普遍且比较有共性的运营问题。如果聊完你们觉得还不错，以后我们可以以类似的方式来试着每周聊一次。

在互联网圈里有句话是这么说的—— 好产品要懂运营，好运营也要懂产品。

印象中，几乎超过90%以上的产品和运营大牛们都提到过这句话。

然而，对于很多工作经验一两年的产品和运营小朋友们而言，听到这句话的时候，很可能是一脸懵逼的—— 运营要懂产品，具体是要怎么个懂法？要有多懂？懂了能解决什么问题或创造什么价值？

同一个问题换到PM身上，也是同理。

所以今天这篇，我们想要稍花一点篇幅来聊下这么个问题：既然人人都说好运营需要“懂产品”，那到底需要怎么个懂法？以及，理解了哪些跟产品有关的信息之后，能给你的工作带来具体明确的帮助？

我试着总结了下，这里应该可以分成4个方面来聊，我来一个个讲。

第一，运营理解了产品经理的科学工作方法和流程后，甚至部分掌握了一些产品经理的思考方法和逻辑后，可能会降低你的无脑吐槽或提出无脑需求的比例。

参加过三节课课程的同学都应该知道，对于一个合格的产品经理而言，“用户、需求、场景”永远是其在进行产品设计和需求分析时必不可少的3要素，简单来说，我们必须对于某个需求背后的具体场景和具体使用对象有非常清晰的捕捉，才能判断这个需求是否靠谱，是否切实存在，否则，这个需求很可能是在YY。

举个例子，三节课的在线教室作业区中有人提出说想要上线一个“搜索”功能，我们试比对一下如下两种思考和表达——

A：

这一般的社区论坛都有搜索功能，我们肯定也得有啊，没有这个功能太不方便了。反正这个必须要做！

B：

我们来看一下什么人在什么时候会产生“搜索”这个需求：比如我们现在开了一个500人的班级，在这个在线班级的作业区中，假如有200人提交了作业，助教也完成了对于作业的批改之后，这时作业区内就存在了海量的信息，可能会长达20页，并且这个时候助教或班主任还会经常到班级群内告诉大家每周哪些同学的作业是很优秀的大家可以去观摩，于是这个时候对于想要前去观摩的同学们就产生了一种“想把那些优秀同学们的作业找出来”的需求。

如果这样的事情在为期8周的课程中每周都存在，这应该是一个值得做的需求。

对比如上A和B的两种思考表达，是不是感觉B的表达更靠谱？

不仅如此，在“用户、需求、场景”的基本逻辑下，还有助于我们更进一步判断，这个需求值不值得做，是否存在更好的解决方案。

比如说，要是针对B的这个“其他用户想看优秀作业”的需求，我们是否有可能专门设置一个“优秀作业区”，让助教对于作业可以打“优秀”标签，然后被标注“优秀”的作业会自动进入到这个优秀作业区就好了？

遗憾的是，就我个人的经验来看，这类相对理性成熟的“产品型思考”，在绝大多数2岁以内的运营身上并不存在。

第二，身为一名运营，假使你能够时刻拥有一种“寻找合理高效的产品机制来为运营服务”的思考，这种思考会带给你更大的可能和便利。

我们都知道，很多运营同学在做的事情都是一种类似于“依靠个人的人肉时间投入来辅助产品运转式”的工作，典型比如审核、打标签、人肉发各种优惠券、做活动啥啥啥的，但如果你长时间做的都是这一类工作，无疑是没有前途的。

我个人的观点是，运营做到了一个阶段后，一定需要时刻拥有某种产品层面的思考，才会拥有更大的可能，即：面向我当前存在的具体运营需求，如何可以借由一些产品机制的变化来帮我更好更有效的实现之？

这里我举个最近看到的例子吧。试想一下，假如你是知乎Live的运营负责人，当前面临的具体需求是要拉升知乎Live的整体用户报名数，你可能会怎么做？

我猜有人可能会说要做活动大促，有人可能会说我们做更多站内站外的推广和曝光，等等。

然而，知乎是怎么做的呢？

知乎的做法远比大多数人能想到的更为轻巧，简单说，他们上线了一个“Live主讲者可以直接给其他人赠票”的功能。

这个功能的使用，是Live主可以在自己的Live页面下点选“送票”按钮，然后选择要赠送的对象，于是，对方就会收到一条私信。比如知乎大V刘飞给我赠送了一场他的Live，我收到的私信就是这样的：

这个时候，我点击刘飞发给我的这个链接，就直接可以报名这场Live了，报名过后，“黄有璨报名了刘飞的XXXlive”的消息就会出现在所有关注了我的用户的知乎Feed流里。

这样一来，假如我有一天要开一场Live，我是不是也可以通过给苏杰刘飞张亮等等大V们赠票来更好实现我这个Live的推广了？这样是不是比以前我要一个个私信他们“求帮转一下”要来得方便和顺畅了很多？

且，这个机制上线后，我预计既可以带动Live整体数据的上升，又不会给运营带来很大的工作量和压力。

所以，能够时刻从产品层面去思考，现在是否可以存在某些更合理高效的产品机制来解决你的具体需求，是一种可贵的习惯。

第三，懂得某些产品的逻辑、架构，甚至能够粗略对于实现成本有一些评估之后，会有助于大大降低你与产品经理和研发之间的沟通成本。

我们都知道，在广大互联网公司内部，经常存在着各种产品被运营坑，运营被产品和研发蒙骗了的段子。

比如说——

运营：我们要做一个活动，很简单的balabala……这么简单后天能做出来嘛？

产品&研发：&……%￥# ……&

又比如说——

运营：我们要做一个活动，大概想这么这么搞，你们评估一下这个东西多久能做出来？

产品&研发：卧槽，你这个目测至少要搞一个月才能搞出来啊。

运营：啊，这么久？为啥呀。

产品&研发：哎呀，这个是技术问题了，反正说了你也不懂。

运营：*&……%￥# @

其实，类似这样的尴尬，假如运营能够有一些常识，对于产品方面的实现逻辑和成本都可以做出一些预估，甚至可以跟产品和研发讨论一些实现问题的时候，这样是完全可以避免的。

试想一下，假如产品和研发跟你说XX需求实现不了的时候，你可以义正辞严的回复：「怎么就做不了了？！这样这样这样不就行了嘛。。。你看，prd在此，拿去嫖！看完有什么问题再统一回复我吧」

这该是一副多美的画面……

以及，假如运营能够理解更多产品和研发层面的实现逻辑时，也会有助于你的思考更加缜密，大大降低与对方之间的沟通理解成本，成功赢得产品和研发伙伴们的好感。

试比对一下以下两种表达——

运营A：产品产品，我们准备要做一个“买得越多就多送用户礼品”的活动，你来帮我们想想怎么实现吧。

运营B：产品产品，我们准备做一个促销的活动，这个活动想通过“当日下单随机送礼品”的方式来实现，我们目前有3种礼品可以拿出来送，我想了下，是不是可以这样实现——订单尾号为5就送礼品1、尾号为8送礼品2、订单尾号为3就送礼品3，你来帮我们评估一下这个需求靠谱不靠谱？

感觉一下，运营A和B，哪一个更容易受到产品汪和程序猿们的认可和喜爱？

第四，深刻理解“产品”工作的本质，包括MVP、精益、敏捷、“少即是多”等等产品理念和工作方法之后，会有助于你可以用最合理的方法去推进很多工作的开展，能够在整个业务链条中扮演更重要的作用，以及某些时候在与产品的话语权争夺中占据主导地位。

产品的本质是什么？我的合伙人，三节课CEO Luke同志曾经给出过精辟的总结—— 所谓产品，无非一个横向和一个纵向，其中横向是业务流程，纵向则是信息架构。

所以，无论产品还是运营，最终的核心目标，都是围绕着“打造一个长期稳定、可持续的业务流程，并不断优化、调整及放大它的价值，从中获得更多的收益或回报”来展开的。

在很多公司内部，产品的话语权往往要更大，就是在于产品因为天天要思考业务流程的梳理和关键环节上的信息组织，因此想得比运营要更深入具体，从而在讨论到关键业务的时候，会给出更多有价值的思考和判断，每逢此时，运营只能沉默。

但就我所知，在很多公司内部，当运营可以更好理解业务，也离业务链条更近，思考也更深入的时候，是会更容易拿到业务环节中的话语权的，这时候，一家公司内的分工关系，就变成了运营主导，产品配合和实现的模式，典型在很多电商类的公司比如京东内部，都很容易看到这样的关系。

至于MVP、敏捷、精益等等就不用提了，我在拙作《运营之光》里就曾分享过我使用“精益”的理念来节省了N多成本成功推进落地了一个项目的真实事例。

以及，我同样还在《运营之光》中分享过一个理念：产品负责提供长期价值，运营则负责创造短期价值+协助产品完善长期价值+消费用户价值获得收入，且，只有长期价值明确、稳定的时候，创造短期价值以及消费用户价值才是有意义的。

在我还在新浪工作的时候，在某次我认为老板的方向不是那么合理的时候，我就曾经通过这套逻辑完成过与老板的沟通和说服，从而为我自己争取到了更好的工作环境和空间，而不是老板给了我一个事，我明明感觉它不靠谱，还必须得硬着头皮上阵去搞。

好了，今天的思考就到这里，希望能够带给你一些启发。不出意外的话，下周四，我们会继续重新思考一个“与产品和运营有关的问题”。

也特别感谢三节课学员群里的同学们进行的大量讨论也给我提供了很多思路，在此也把一些同学们的讨论内容摘录下来分享给你，供参考。

John Wu：

个人觉得“懂产品”可以从两方面来理解。

一方面是了解产品设计&开发的基本规则和流程，比如一个产品方案大概长什么样，需要哪些元素，产品开发怎么排期的，跟开发对接需要注意哪些细节甚至提高效率的办法（比如做方案的时候想到有能copy以前代码的地方自然就不需要再要求程序猿写新代码了），这种经历其实是可以通过时间经历来堆砌的，跟产品打交道久了，基本都会了解这些。

另一方面个人觉得比较核心的“懂产品”，是对自家产品的了解，因为产品跟产品真的差别太大，自家产品从一开始的定位满足的需求出发到最终为什么设计成这个样子搞出这些功能而不搞其他功能，哪些功能是初衷认定的核心，哪些功能期望通过用户反馈来高速迭代，肯定都是有背后思考的，能这样“懂产品”的运营围绕自家产品做事的时候也能清楚自己的核心“KPI”是啥不至于跑偏。

肖伟涛：

仅仅关注「KPI」容易损害当前产品用户的既定利益（包括体验）。比如为了提升销售额的时候一般会要求加展示露出进行导量，但殊不知产品千辛万苦搭建的「流畅体验」在运营需求下灰飞烟灭。

或者产品和开发用发际线提升2cm做出来的「猜你喜欢」，运营认为不理想就一把废弃，直接调整到「手动设置」。应该好好沟通优化算法才对吧（有优化空间的啊！别急着枪毙啊！给个机会啊大哥！）

运营懂产品最大的好处是：在做运营活动的时候，从运营设计到产品落地层面的误差会小很多很多。其实就是沟通问题。毕竟传递信息的时候，每一步都是有损失的。

雪亚：

运营代码啥的不用会，但最好能把逻辑流程图画清楚。

王册：

就像我们吃一顿饭，如果是别人做的，我们可能看到的是色香味是否俱全，而要是自己亲自准备这顿饭，那要思考食材，搭配，方法，时间点种种原因，还要考虑做出来是否能达到色香味俱全。

产品和运营是相辅相成的，我之前遇到一个问题，产品经理不懂运营，做的产品，运营操作时要不断的切换几个后台，很是繁琐，增加了不少工作量。

Alisa：

曾经有过一段创业公司差点被研发坑的经历，一个很简单的需求程序员哥们告知要十天半个月才能上线，因为懂一点点产品，所以中午撕B后，程序员哥哥当天下午下班前就做粗来了。。。（不要问我产品在哪里，当时是创业公司，部分需求都是直接跳产品的。）

Toxic：

说点其他的，懂产品的话，可以在需求评审会和平时在撕B中不处于劣势，同理，懂点技术也是如此。

运营提出一个需求，就要讲清楚这个需求对产品有什么好处，可以带来什么。毕竟，一般来说在一个团队里，运营、产品、技术的目标都是为了产品越来越好，懂产品可以更好地推进工作。

大庆：

可以把运营比做卖西瓜，如果知道西瓜怎么从地里长出来的，需要多少光照，养分；知道西瓜如何采摘，运输等细节，我们可以很轻松地向用户推销西瓜。同样，产品如果知道现在什么品种的西瓜最好卖，买西瓜的人都是什么样的，产品就可以做出更好的产品。

change：

根据老黄的定义：产品负责为客户创造长期价值，运营负责创造短期价值和帮助产品完成长期价值。可以理解为：产品承载公司长期目标或宏观目标，运营承载短期小目标或阶段性目标。所以，运营懂产品，首先要懂产品的终极目标，在这个终极目标下思考自己的小目标，保证运营的方向是正确的。然后是调性，运营得懂得产品的调性，比如金融产品，为了赢得客户信任，整体调性偏严谨，在产品文字表达上就不能太“调皮”。最后，运营的策略还要根据产品的发展阶段、产品形态等不同作相应的调整。

Caspar：

运营要懂得，运营说的一句话、一个需求，产品可能要考虑很多关联的功能、甚至多个终端（PC端、移动端等等）。产品要了解运营提出需求的背景、目的、需求。