Question

这一章的最后，我换个角度继续来聊聊“运营”和“产品”。我在本书前面的内容里提到过这样一句话——好产品要懂运营，好运营也要懂产品。事实上，这句话并非我的专属，印象中，几乎超过 90%以上的产品和运营“大牛们”都提到过这句话。

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

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

同一个问题换到产品经理身上，也是同理。

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

我试着总结了下，分成 4 个方面来聊。

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

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

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

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

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

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

不仅如此，在“用户、需求、场景”的基本逻辑下，还有助于我们更进一步判断，这个需求值不值得做，是否存在更好的解决方案。比如说，针对 B 的这个“其他用户想看优秀作业”的需求，我们是否有可能专门设置一个“优秀作业区”，让助教对作业可以打“优秀”标签，然后被标注“优秀”的作业会自动进入优秀作业区就好了？

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

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

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

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

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

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

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

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

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

图 2-26

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

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

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

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

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

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

比如说——

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

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

又比如说——

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

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

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

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

运营：*&……%￥#@

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

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

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

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

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

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

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

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

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

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

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

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

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

至于 MVP、敏捷、精益等就不用提了，我在本书前文中就曾分享过我使用“精益”的理念来节省了 N 多成本成功推进落地了一个项目的真实事例。

如果你有印象的话，我还在本书前文中分享过一个理念：产品负责提供长期价值，运营则负责创造短期价值+协助产品完善长期价值+消费用户价值获得收入，且，只有长期价值明确、稳定的时候，创造短期价值以及消费用户价值才是有意义的。

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

关于这个话题，我的思考就分享到这里，希望能够给你带来一些启发。

到此为止，第 2 章也就正式告一段落了，我仍然希望强调一下，对于一个新人来说，优先要做的事情，应该是让自己具备一些良好的思维方式和工作习惯，而不是直接奔着方法和技巧去。两者间的关系，好比一个是内功心法，另一个是武功招式，假如内功和心法没有足够的积累，直接就奔着招式去了，是很容易走火入魔的。

而像内功心法这种更贴近于底层思维、工作习惯和价值导向的东西，我觉得，可能也是运营的“光”之所在。