来自犬校关于「产品经理如何建立和提高运营能力」的回答，恰好我从产品 leader 转运营 leader 有 4 个多月了，分享一些最近的思考。
可能无法回答「如何建立」，但或许能在如何扩展自己的能力栈上提供一些启发。
赛道：交易型业务，重线下
角色：广义的用户运营，偏供给方向，职责上偏体验（相对于增长）
总结过去 4 个月我在做的事情，大概是这么几件：策略、机制、影响和算账。
其实这几件事过去做产品经理的时候也都有做，但比重有所不同。接下来结合我眼中运营和产品的 2 个不同，来讲讲这 4 件事大致都在做什么：
产品解决确定性的问题，运营定义什么是问题（相对而言）
以我在社区零售业务做过的一个项目为例，运营要做的事情包括：
消费者有很多途径可以投诉门店，对应很多不同的指标，到底把哪个作为重心；
其中某个指标，问题特别发散，由 9 个不同的问题组成，且大部分都是无法场景还原的非标问题（态度不好、环境差），到底是单个单个解，还是打包一起解；
平台上的长尾门店，平均每天只有很少的订单，表现为单个门店 2-3 个月才会被投诉一次，但这群人贡献了平台绝大部分的投诉，是管长尾门店，还是管头部门店，又要怎么管…等等等等，一连串。
这些都是我眼中的策略问题，策略问题既要向上回答业务目标（DAU、GMV、毛利），也要向下给出解题路径。这整个过程，又完整构成了一笔账 —— 解决某个问题，需要花多少钱，又能挣回来多少钱，值得做嘛，为什么。
而跟我们对接的产品做什么呢？帮我们做一个 XXX 功能。有的同学可能会说，我司不是这样的，产品也要思考策略问题，也得算账。没错，前司因为特殊的业务和组织情况，也是这样，所以我本人还挺习惯这种工作方式的。
但也必须承认，大量的产品经理，只负责接需求，有意识和有能力向上思考策略问题的是少数，即便有，也是过去所经历过的业务挑战的产物，不意味着未来的产品经理还有这样的红利。
说回来，这么看，产品经理岂不是被运营吊起来打？也不尽然，我认为产品经理相对运营的优势，可能是更重视用户价值和体系化的能力建设，这两者都是因为产品经理要对研发成本负责，需要面向长期做边际收益更大的事情。所以产品经理看到运营不用怂，你还是有优势的，但如果遇到了一个产品经理转的运营，还特别熟悉你们这个赛道，那你可能会被屠杀。
（PS：这部分和业务有很强的相关性，如果是偏线上的业务，很可能没有运营，或产品自己背业务目标，并兼任运营，环境会好很多）
产品资源更闭环，运营需要四处游说（相对而言）
我们去观察一个组织会发现，通常越接近业务的职能和团队，越倾向于根据问题/客户角色分工，越接近中台的职能和团队，越倾向于根据系统模块分工，也就是组织从外到内是一个从发散到收敛的过程。为什么呢，因为组织的本质就是把外部问题内化，转化成组织成本。而这个逐渐收敛的分工过程，可以保证内部的沟通成本和外部的价值创造尽可能平滑。
所以我们看到产品对接的研发团队，一般来说都是相对固定的；而运营团队很可能不是，比如为了解决用户退货流程，减少货损成本，用户、门店、仓网、商家等面向客户的产品团队都要参与，中后台还要对应改造流程。并且，当某个产品模块接到这个需求的时候，大概率给你提需求的运营，已经和其他方向的运营游说完了，或是已经被人说服了。
正是因为这个原因，决定了运营需要关注机制和影响力建设。其中机制是可固化的部分，比如怎么和产品对齐节奏、人力、优先级，怎么和其他运营团队对齐信息、认知和目标。但机制更多是结果，在机制之前，首先是个人游说和影响力。
往小的方面说，一个新的业务命题，其中需要和某方向协作，过去没打过交道，怎么了解他们目前的业务和运转情况，怎么结识关键人，怎么让对方愿意和你共享信息，甚至接受短期的人力、业绩影响，做你发起的项目；往大的方面说，一个组织里对于业务方向的判断，总是会有很多思潮，这些思潮很可能在理念方面都是不同的，更不用说路径。而理念在事先是很难论对错的，那怎么才能让你的思潮能获得更多共识。
这些问题过去做产品经理会面对，但做运营以后更高频，且需要更加了解对方，因为大家都是直接背业务结果，更关注各自的经营数字，而不是产品经理更熟悉的那套话语体系。我到新公司以后发现，在一些业务思路上能最快跟我达成共识的，往往不是跟我一个方向的 peer，或是对接的产品同学，而是合作团队中来自前司的其他业务线的陌生人，因为我们经历过类似的业务，思考问题的方式会接近很多。
另外，前司因为特殊的业务和组织环境，曾经尝试过一个「业务经济特区」的机制，让产品经理可以直接参与一些区域的经营决策（就像过去的深圳经济特区）。
我在离职前和几个同事录过一期播客聊这段经历，感兴趣的同学可以听听，里面讲到了一些我个人经历没有 cover 的经验和思路，也聊到了产品和运营做事方式的差异：