三三得九

产品和运营的差异也是我最近半年持续在思考的问题，心流给我提供了一个全新的视角，是有点奇怪的视角，但也很有趣。背景是纯银在犬校写道：下午写了两个半小时的测试用例，忽然意识到一件非常非常有趣的事情。 仅就我个人的经历而言：从运营出发的思考与工作，非常依赖判断的准确性，也依赖运营视角的想象力与执行力，但并不复杂，更多靠的是经验和手感。从产品出发的思考与工作，有很多高复杂度，重脑力的任务，很容易进入沉浸态，运营侧却少有这般大脑全速运转的时刻。我连连赞同，并表示转运营之后，偶尔会忙里偷闲，借着写（运营）需求文档的机会重回产品经理的自己，感觉那会儿大脑才是沉浸式的飞速运转，像在吸氧。后来我们又聊到这背后的原因，引出了我的思考：思考层面，两者都有机会进入心流状态产品和运营都要尽可能理解商业目标、理解业务逻辑、理解用户场景，在这点上，两者都有机会进入心流状态。执行层面（任务领受和交付）：产品是面向系统的，运营是面向事件的，这决定了产品有更多机会进入心流。假定：抛开行业阶段和业务差异，虚构一个初始态，把产品和运营看做两个完全平行没有价值贵贱的岗位。交付差异：产品的交付对象是研发，运营的交付对象是除研发外的任何角色。由此可见，两者的区别是任务能否被标准化和规模化复制，如果可以，自然是产品加工一下让研发去复制，如果不可以，那就运营自己想办法搞。影响：这就决定了产品在执行层面有更多系统化思考的要求，更容易进入心流；而运营面对的任务本身就难以标准化，自然更接近玄学般的手感，不是进入心流就能解决的，反而需要多做、多观察，多和各种人交互。也就是手感是结果，不是原因或擅不擅长。当然提手感也不是说运营就更举重若轻，只是运营的价值更离散，更容易出现极值，优秀的运营妙手连连，普通的运营疲于奔命；而产品的价值更收敛，更有确定性，更接近去尾。延伸：什么导致了两个岗位价值权重的差异因为不同业务可标准化的程度不同，这背后既有空间（天花板）差异，也有进程差异。比如在线下业务里，有不少事情理论上是可以标准化的，但需要考虑当下值不值得以及策略上如何标准化的问题，所以运营更容易站到前面，先筛选一下、尝试一下；内容行业我不是很懂，但感觉规律应该是类似的，产品能产生的边际价值，阶段性低于了投入成本，所以天降大任于内容品味好的运营。这些差异，结合行业的特征、公司的情况，久而久之就会内化成每个公司的岗位价值排序，形成产品和运营之间的分工边界。这个过程就像植物生长、物种演化一样，价值原点不同，生长环境不同，长出来的高矮胖瘦也不同。

研究组织规律一直都是我的兴趣爱好，最近俞军老师也在某社区提到了研究组织规律的好处：我的理解，在一个产品/业务/行业发展壮大的过程中，一般来说，相对收益更大的关注点，依次是：产品--商业--组织。产品形态最优解不确定时，产品经理的边际价值很高。但…（此处省略 50 字），产品经理如果转而更多关注商业规律和组织规律，工作内容和角色上也更多偏重经营，会有更大的边际价值。关注组织规律，是因为，一个产品发展到较大规模后，一般来说，各种组织问题会成为显著瓶颈，约束了该产品的可持续发展、创新能力、市场竞争力。产品经理如果不想成为这方面的牺牲品，就不能埋头只研究用户和市场，最好学习些组织规律，涉及人才、激励、文化、战略等。我之前在即刻上写过，过去 4、5 年如果有什么看待问题的视角，是一旦意识到以后，世界就变得大不相同的，在我这边有：理解协作、理解组织、理解组织能力。这 3 点恰好都指向了组织规律。算是受益于这个兴趣吧，对于日常工作过程中观察到的组织现象，我都会尝试去思考和理解背后的原理。久而久之会感受到理解组织的有趣之处，他和理解业务和用户一样，都是一门复杂的实践科学，既要理解使用者（员工视角），也要理解决策者（管理者视角），还要理解业务（组织视角）。但和后者又不一样的是，理解组织规律的 Know How 过程是有额外 Bonus 的，就是帮助我更好的看待、攻克甚至掌控/操纵日常协作难题，也就是一鱼两吃、事半功倍。确实非常有趣，我时常会想，如果有一天我不再做产品和运营了，可能会去做一个 HR 吧。是以为记，作为#组织规律 的序言和目录。——————————组织#1 业务基因的底层，是组织能力https://xiaobot.net/post/283fd301-edb1-419d-9214-283bf1e9e2e3组织#2 跨职能沟通，除了讲目标、讲思路，还应该关注什么？https://xiaobot.net/post/c1960d83-f214-446e-8f0b-ce0f1689e9ca组织#3 组织惯性是个筛选器https://xiaobot.net/post/40843c15-e46e-45a6-809a-c024af2d2ed4组织#4 组织分工如何影响协作习惯&能力https://xiaobot.net/post/7b7f116f-d648-470e-99ff-cde075511d60组织#5 我们应该从什么视角去理解组织分工https://xiaobot.net/post/b5ee5b79-4501-4443-ab60-c93c3cf2fb3b组织#6 线上线下业务对「分蛋糕」的要求迥异https://xiaobot.net/post/15df498e-5b46-4039-b71a-99bbee3b87bc组织#7 See - Feel - Changehttps://xiaobot.net/post/ed137dcf-2274-49ce-b3bf-66fd3426f42e组织#8 用研为什么慢慢可有可无了https://xiaobot.net/post/cf74c6ef-eed6-46a0-a1b5-4208b06363e7组织#9 职业（不）成熟度也是一种组织成本https://xiaobot.net/post/36b499e8-3a3f-433e-b8e4-0ff45b22ff57理解产品经理从「增长中心」变成「成本中心」的一个视角https://xiaobot.net/post/b1cb5daa-0b13-4408-9106-21b95933af57产品面向系统，运营面向事件https://xiaobot.net/post/99e252a9-556e-4f40-a02c-069f3d7108ae

这是一个年轻同学很容易被带偏的问题，我称之为「精确性陷阱」，拿最典型的 AB 实验来说吧。AB 实验的价值本质俞军老师曾有过一个比喻：AB 实验好比偷看答案。仔细想想，背后其实有 2 层含义：答案是什么，提前就知道了提前知道了，就不用争论了用白话说，一层是精确、一层是共识。其中前者是基础，但后者才是价值更大，节省更多组织成本的那个。为什么这么说呢，我们且看两者无法兼得的时候，哪个会先被放弃。无法 AB 时的价值取舍AB 不那么奏效的场景，一般分为 2 种：AB 测不准，如一些多变量、隐性变量、长周期变量的决策AB 不可用，如涉及公平性的策略，或涉及线下流程，无法分组怎么解决呢？1. 针对 AB 测不准：扩展实验方法本身，比如分桶实验、DID 倍差法、应对携带效应的 91/28 分组法等等等等。但稍微研究一下就会发现，这些方法都不能在根本上解决精确性问题，不过是在成本可接受的范围内打了个补丁，让测量结果更靠谱一些，来维系AB 实验的靠谱程度。我也遇到过类似的情况，且以上补丁包均不奏效。最终的方法是准确度分级 + 观测评估分离，也就是大幅降低精确性要求，但仍然结合定性分析，守护实验工具带来的「共识」价值。2. 针对 AB 不可用：寻找可控的、可解释的中间指标，结合 AA、用户调研、行为分析等手段分段证明。这类情况我也遇到过不少，很折腾，不同业务情况的选择也不同，非常个性化，在此不展开了。但背后的原则仍是：放弃对精确量化的幻想，寻找降级方案，用中间指标和指标之间丰富的逻辑关系来填充共识缝隙。数据是一种共识工具绕了一大个圈子，其实只是想说明一个问题：对于策略改进的评估，在精确和共识不可兼得时，精确总是被无条件放弃的那个。这背后的本质是：AB 实验的共识价值要远大于精确数据的最大价值是「模糊的正确」带来的共识即，数据是一种共识工具。由此可知，对于任何策略改进，都要把「共识」作为第一目标，「精确」是一种手段和投入，要关注其边际收益，而不是掉入「精确性陷阱」。思考题：把「共识」作为一种方法「数据量化」作为一种共识工具，其初始成本 _____，复制成本 _____，生效周期 _____「老板认同」作为一种共识工具，其初始成本 _____，复制成本 _____，生效周期 _____「竞品做了」作为一种共识工具，其初始成本 _____，复制成本 _____，生效周期 _____「逻辑说服」作为一种共识工具，其初始成本 _____，复制成本 _____，生效周期 _____「情绪感染」作为一种共识工具，其初始成本 _____，复制成本 _____，生效周期 _____……

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