在互联网圈里有句话是这么说的——好产品要懂运营，好运营也要懂产品。
印象中，几乎超过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多成本成功推进落地了一个项目的真实事例。
以及，我同样还在《运营之光》中分享过一个理念：产品负责提供长期价值，运营则负责创造短期价值+协助产品完善长期价值+消费用户价值获得收入，且，只有长期价值明确、稳定的时候，创造短期价值以及消费用户价值才是有意义的。
在我还在新浪工作的时候，在某次我认为老板的方向不是那么合理的时候，我就曾经通过这套逻辑完成过与老板的沟通和说服，从而为我自己争取到了更好的工作环境和空间，而不是老板给了我一个事，我明明感觉它不靠谱，还必须得硬着头皮上阵去搞。
好了 ，今天的思考就到这里，希望能够带给你一些启发。