昨天在知乎上回答了一道问题：『运营说的最多的就是「即使产品是坨便便，也要推广出去」，但如果这坨便便一直很臭怎么办？』
回答得很简短，但我觉得值得多说点，但懒得改答案了，就在这里写吧。
「即使产品是坨屎，作为运营也要把它做起来」类似的话，不知道是从哪位仁兄口里说出来的。但这句话说出来之后，似乎开辟了一个非常不好的风气；似乎，只要是老板认定的方向，做出的产品，不论好坏，运营都要把它做出牛逼的业绩。
先说一个很老的案例。
有一款游戏，在某一个大版本的开发中，出现了进度迟滞。于是项目组做了一件事情，平稳的渡过了这个尴尬的阶段：就是上线了一个回顾过往版本的活动，把过去所有出彩的大版本拿出来，组织玩家再玩一次，效果颇好。
这个游戏是传奇还是传奇世界，我已经不记得了。
但是我相信，作为运营，或多或少的都与老板或者上司发生过类似的对话：
老大：小王啊，最近用户数/收入怎么样啊？
小王：老大，最近数据不大好。
老大：为什么呢？
小王：开发进度/产品设计/……有问题。
老大：那你打算怎么办呢？
小王：我想过申请预算做活动，但目前的情况是，我们可以用过各种手段把用户引进来，但是现在的情况是留不住。
老大：那你要想办法的啊。
小王：但是现有版本不足以支撑我们做留存和活跃。
老大：这我不管了，你一定有办法，我相信你。
小王：……
我们都知道小王心中一定奔腾了千万头草泥马，但是小王可能还是得把这骨头给啃了。
我们说到传奇/传世的这个例子，其实是算好的，因为毕竟还有历史上的优秀版本和优秀活动可以作为资源拿来做运营。
但，如果没有呢？
就好像有人会问亮哥，工具类的产品怎么做运营？
我都会告诉他，先把功能做好再说。
产品、运营不分家。前提是：大家要形成合力，不能互相拉扯。
如同知乎的这个问题下的另一个回答中引述一位某国际联号酒店的CMO的观点中表达的一致：
If the product is really bad, then of course it should be the product. But if it’s above the average, do marketing for sure.
如果产品真的不好，那么当然要先把产品做好。但是，如果超过了（业内）平均水平，那当然要去做市场营销。
互联网运营与传统市场营销，殊途却同归，道理是一样的。
那么，如何判断产品已经达到了平均水平？
很简单，去和你的竞品比。
和竞品比，并不是要比功能的高大全，而是要比核心功能是否做到80分或者更多。
只要核心功能满足这个条件，那么就利用边缘功能去打开差异。
同样是团购，美团和点评有没有区别？
同样做漫画App，布卡和动漫之家有没有差异？
同样做美食评论，城觅和饭本有没有不一样？
答案是显而易见的。
但更显而易见的是，他们之间的差距一定不仅仅是产品质量或者运营能力的差异所造成的。
即便是退回到十几年前，淘宝挑战ebay易趣，虽然运营策略对头，用免费攻击ebay易趣的软肋，但也需要有支付宝帮淘宝从产品端解决用户的购买信任问题，否则的话，就靠一个对商户免费，把卖货的拉来了，可买家怎么办呢？
京东这种B2C，还可以货到付款；当年淘宝做C2C，怎么到付？那就走银联或者银行网关。
你试试去银行排一次队，开一次专业网银，你就知道支付宝在产品层面上在当年给了淘宝运营策略多大的支撑了。
盛大有一句名言：产品不足运营补。
很多人对此有误解。认为：你看，盛大当年那么屌，不也承认产品即便不好，运营也要顶上去吗？
可是，这句话的意思并不是这样。这句话本身的语境和语义是说：
作为一个游戏公司，我们运营的是一款游戏，游戏本身是在不断迭代中的。所以在某些版本上，一定会有不足，会有设计上的偏差。游戏成功的核心是游戏性，在游戏本身没有硬伤的情况下，假使某一个版本上出现了不足；这个时候，游戏的运营人员要身先士卒，用各种运营方法，做活动也好，搞舆论也好，要让游戏渡过这个不足的阶段；保持用户和收入的良好延续，顺利交接到下一个版本。
它强调的是产品与运营的协同合作！而不是把一坨屎拉出来丢给运营，让运营把臭味去除，变成香味，甚至点屎成金。
产品和运营是两个轮子，这个公司是自行车；加上开发，是三轮车；再加上市场，就变成了汽车。
轮子如果一只圆一只方，这车肯定走起来又问题，轮子如果都是圆的，但大小不一样，那走起来也不会稳当。
这里的话题就直接被替换成了，如何让产品和运营协同合作，共同走向幸福的美好生活。
办法是有的，但是在实际过程中，一定会出现「屁股决定脑袋」，减少这种现象的发生，才能让业务跑得更快，这里有几个方法，有些方法是给人力资源看的，有些方法是给产品、运营看的，各取所需。
项目组架构
这是对人力资源说的，也是给公司老板说的。
我经历过项目组架构，也经历过扁平化架构，个人的体会是，项目组架构下，可以最大化的保障产品、运营、开发三个组织的沟通的便利程度、协同的积极程度。
因为项目组架构下，大家对业务的交流和理解会更同步，业务的目标一致，背负共同的KPI，想不通力合作都不行，想互相指责都没机会。
扁平化不是不好，但扁平化对于产品经理的协调能力，对整个组织成员的主动性都有极高的要求。
有时候扁平化更容易出现排期扯皮、责任互相推的现象，因为不论产品、运营、开发，做的都不仅仅是一个项目，这个时候想要通力协作，比较难。
换位思考
产品在做设计前，要考虑运营的可行性；运营则要考虑产品的复杂度。
很多时候，产品、运营、开发会互相吐槽：「这事儿很简单啊，你怎么OOXX」
不要认为别人的事儿很简单，因为你没有做过。
运营提出的一个小需求，可能涉及多个系统，这些系统，运营并不一定完全了解，产品甚至都不如开发了解。
产品做一个小改动，可能造成很多影响，譬如，支付宝9.0去除锁屏密码这个动作，我认为在设计前产品经理可能是对用户的负面反馈没有比较深度的认知的。
开发也是一样，但今天不聊开发，懂意思就好。
保持沟通
保持沟通，非常重要，很多人说，但很多人停留在嘴上。
产品经理要能够听取运营的反馈，并愿意花时间从专业的角度给出结论。
运营要能够敏锐的从运营数据中找到用户的潜在需求，并可以用产品经理能够简单理解的方式来表述需求点，讲究需求的逻辑性。
每一次版本变更涉及的功能，产品应当去与运营进行沟通，大家用数据来说话，改了什么，为什么改，需要运营做哪些动作，引导、公告、安抚、活动，这些事情要提前沟通，预案提前准备。
大版本发布前，产品、运营要一同加入测试，从逻辑层面、操作层面、用户感知等各项层面对大版本的调整有充分的认知，并做好各项准备工作。
有问题不要憋着
不管是产品、运营、开发、市场，很容易看到业务上的一些风险，但角度不一样。
这个时候，千万不要认为只要自己做好自己这一块就好，别人的部分，别人自然会去做，就算做不好，锅也不是我背。
这是责任心的问题，也是职业度的问题。
把你看到的有关业务的风险share出来，让相关人员知晓并进行评估，非常重要。
虽然这一点理应放入沟通的范畴，但我认为这还真的值得拿出来单独说一句。
最后，让我再强调一下。
不要用运营能力去掩盖产品上的瑕疵。正视并对症下药，才是解决之道。
如果，真的碰到了这样的情况，不得不做，我对运营人员也有如下建议：
小范围的做运营动作，实时记录并分析运营数据。
及时获取用户反馈，并有条理的记录这些反馈。
把数据分析结果和用户反馈结果汇总，并给出解决建议，提交领导。
提前做好应急预案，如果出现问题，客服和运营要第一时间予以解决处理。
最后罗嗦一句：
任何推广运营上的动作，都切忌一下铺开，尽量一个渠道一个渠道试，一组用户一组用户试，规模自己把握。可控是关键。
这一点，不管产品是金子还是屎，都适用。
