产品经理要学会“见人下菜碟”

产品经理常陷入“尊重所有用户”的误区，却忽略了资源有限下的取舍。真正的成熟，是学会按业务逻辑而非人情厚薄，对用户进行权重分层。本文深入B端与C端场景，剖析决策权、付费权等关键维度，教你如何在冲突中做出明智判断，避免沦为工具人。

———— / BEGIN / ————

“见人下菜碟”这句话，平时语境好像是个贬义词。

因为一般情况下它表达的意思都是：看人下菜、逢高踩低、谁有权谁就多照顾一点，谁没分量谁就敷衍一点。带着很强的道德瑕疵，听起来就不是什么好话。

但是！恕我直言，在产品语境里，你就是得学会某种意义上的“见人下菜碟”。

当然，我说的不是职场厚黑学，不是曲意逢迎，也不是谁官大就听谁的。

而是你要非常清楚地知道，面对不同角色，不能用同一套标准理解需求，不能用同一种力度分配资源，更不能拿“我们尊重每个用户的声音”这种正确废话，来掩盖自己不会做判断。

产品经理最容易沦为工具人，不是不会画原型，而是不再追问真实需求。

而真实需求，很多时候不是“谁说了什么”，而是“谁的诉求会真正影响业务成败”。

一、先把这句话从道德语境里拽出来

很多产品团队最喜欢说的一句话是，“所有用户都很重要”。

这句话不能说错，但如果你真按字面执行，项目大概率会做废。

因为产品工作从来不是在真空里做公平题，而是在有限资源里做取舍题。

你只有这么多人、这么点预算、这么点工时、甚至还要被卡排期。

研发不可能无限加人，测试不可能无限扩容，老板的耐心和客户的窗口期也都有限。你每多做一个需求，背后都是别的需求被延后、别的风险被放大、别的机会被放弃。

所以产品经理真正面对的问题，从来不是“要不要一视同仁”，而是：

当不同用户的诉求冲突时，你到底先满足谁。

这时候再说“大家都很重要”，就像别人问你想吃什么的时候你说“我都行”。听起来没错，但对做决定没有任何帮助。

假装一视同仁，往往不是尊重用户，而是不敢负责。

因为一旦你承认用户有权重差异，你就必须进一步回答几个很难的问题：

• 谁是关键角色？

• 谁掌握决策权？

• 谁影响付费和续费？

• 谁决定项目能不能真正落地？

• 谁如果不满意，会直接卡住主流程？

这才是产品经理该做的判断。

不是按人情厚薄分高低，而是按业务逻辑分轻重。

二、产品经理真正要分的，不是人情，而是用户权重

很多人一听“分层”，就下意识把它理解成对人区别对待。

也没毛病，但不是那种意义上的“区别对待”。

不是“这个人我喜不喜欢”“这个人好不好说话”“这个人是不是领导嫡系”，而是这个角色在业务流程里到底处于什么位置。

我通常会把用户权重大致看成几类因素的交叉：

• 决策权：谁能拍板

• 付费权：谁决定买不买、续不续

• 业务价值：谁直接影响核心指标

• 场景关键度：谁卡着主流程

• 落地影响：谁决定系统最终能不能被用起来

这几个维度，不一定每次都整齐划一。现实世界也不是 MECE 切完就彻底干净了。有的人既是决策者，也是使用者；有的人不付费，却掌握推广权限；有的人平时没什么存在感，但一旦反对，项目就推不动。

所以产品经理真正需要的，不是套模板式的“用户分层入门”，而是建立一种权重意识。

你要能把会议上那句很常见的话再深入一层拆开：

“用户都这么说。”

问题是，哪个用户？

是拍板方、付费方、使用方，还是被流程波及的人？

很多评审会之所以越开越乱，就是因为大家把不同层级的声音混成了一个“用户共识”，然后再拿这个共识来压方案。表面上是在听用户的，实际上已经被偷换概念了。

这也是为什么我一直对“尊重每个声音就等于懂用户”这类话保持警惕。

尊重可以是态度，但判断必须是能力。

三、B端产品里，角色冲突才是常态

这个问题在 B 端系统里尤其明显。

因为 B 端从来不是只有一个“用户”。同一个系统里，至少会同时站着几拨人，而且他们的诉求天然就不一样。

领导层关心什么？

关心汇报效果、风险可控、对上能交代、对外有展示面。很多时候，他未必天天用系统，但他会在关键节点看报表、看数据、看项目是否可控。他要的是“我能看见、能管理、能拿去汇报”。

业务主管关心什么？

关心流程能不能推进、团队效率有没有提升、问题能不能尽快闭环。他站在中间，一头要接领导目标，一头要接一线执行。他要的是“别给我制造新的管理成本”。

一线执行者关心什么？

说白了，就是少填字段、少报错、少返工、别来回切页面、别今天这么填明天又改规则。对他们来说，系统不是战略工具，而是日常劳动现场。直白点说，少干活，多摸鱼。

这三类人，都是用户。

但他们不可能天然一致。

领导可能希望字段更全、流程更严、痕迹更完整，因为这样方便管理和汇报；一线却只会觉得录入成本越来越高。业务主管可能希望系统强约束，减少团队跑偏；执行者却会觉得灵活性被锁死，出了特殊情况反而更难处理。

你如果不分层，就会陷入一种很典型的假勤奋：

收集了很多反馈，开了很多会，也记了很多问题，最后做的全是边边角角的小优化，真正影响上线成败的主流程问题反而没解决。

这不是因为你不努力，而是因为你没有先判断谁的诉求更靠近业务主航道。

所以我比较推荐大家用用户故事地图。

用户故事地图这个方法，本质上就在提醒一件事：先看用户完成核心任务的主路径，再看每一步里谁的痛点最关键、哪个环节最不能掉链子。不是所有痛点都要同时解决，而是先保住主流程。

B 端产品尤其如此。

不是“大家都不满意”最可怕。

最可怕的是，拍板的人觉得没法汇报，主管觉得推不动，一线觉得更麻烦，最后系统挂在那儿，谁都不愿意真用。

四、真正难的，不是知道要分层，而是在冲突里做取舍

说到这里，很多人都会点头：明白了，要做用户分层。

但真正难的地方，其实从这一步才开始。

难的不是知道要分层，而是当冲突真的摆在你面前时，你敢不敢承认：有些需求明知不普适，也必须插队。

这是很多产品经理最别扭、也最不愿意公开承认的现实。

比如老板临时转来一个重点客户需求。

团队一看就知道，这个需求不够通用，甚至会让系统变复杂；研发会吐槽，测试会皱眉，产品自己也明白它不是标准化最优解。

但它还是得优先做。

为什么？

因为对方握着签约、续费、标杆示范，甚至组织背书价值，不夸张地说，团队的业绩都在他手上。

你可以不喜欢这个现实，但你不能假装它不存在。

这时候如果还有人坚持说“所有需求来源都该按同样标准评估”，那只能说，你还没认清职场。

产品不是考试题，产品是资源配置。

资源配置就意味着，你要把有限产能投到影响更大的地方。这个“更大”，可能是更大规模的主流用户，也可能是更关键的一笔合同，更可能是决定项目能否顺利推进的那个组织节点。

这当然有代价。

一旦你为了重点客户插队，团队就会承受棘轮效应带来的后续压力：客户会形成预期，销售会觉得“以后也可以这样争取”，内部排期纪律被打松一次，下一次就更难守住。

所以问题不在于“要不要插队”，而在于你能不能说清楚：

• 这次为什么值得插队

• 它换来的业务收益是什么

• 对通用能力建设造成了什么损耗

• 这是不是一次性策略，还是会沉淀成产品能力

• 后续如何控制扩散

真正成熟的产品经理，不是从不妥协的人，而是每一次妥协都知道自己在换取什么。

五、C端也一样：重度发声用户，不等于主流用户

很多人以为，只有 B 端才需要这种权重判断。

其实 C 端也一样。

只是 B 端的角色差异摆在台面上，C 端的误判更隐蔽。

最典型的，就是把重度发声用户当成主流用户。

社区里最活跃的人、评论区最能写的人、私信最密集的人、愿意参加访谈的人，确实更容易被团队看见。你和他们聊久了，会产生一种错觉：他们代表了用户。

但很多时候，他们代表的只是“高参与度用户”，不是“高占比用户”，更不是“高价值主流用户”。

这两者差别非常大。

重度用户往往诉求更深、更细、更专业，也更容易提出一连串延展需求。你如果只围着他们转，产品很容易越做越重、越做越复杂，看起来功能越来越完整，结果整体留存和转化并没有明显改善。

因为大多数人根本没走到那一步。

他们真正卡住的，可能是注册第一步、首单转化、关键路径的信任建立，或者某个最基础的使用门槛。你却在给少数深度用户做高级玩法。

这就是典型的“谁声音大听谁”。

听起来像用户导向，本质上是样本偏差。

研究出身的人对这个会更敏感一点。因为你一旦做过访谈、抽样、归类，就会知道：可见，不等于重要；能说，不等于代表。

产品团队如果没有这个意识，就会把“用户反馈很多”误当成“需求优先级很高”。

这两件事，不是一回事。

六、分层之后，产品经理回应不同角色，不是态度不同，而是动作不同

说到底，用户分层也不是川剧变脸，而是为了让你的动作更准确。

不是对领导更热情、对一线更敷衍；不是对大客户秒回、对普通用户已读不回。那就真成了厚黑学。

真正该不同的，是你的工作动作。

对决策者，你要给的是结论、风险、取舍和汇报口径。

他们不需要听你把每个细节从头讲完，他们需要的是金字塔原理式的信息：先说结论，这件事值不值得做；再说依据，影响什么目标；最后说风险，代价和边界在哪里。你如果给领导塞一堆一线碎反馈，看起来很充分，实际上是在增加沟通噪音，领导直接打断，重点反而容易被忽略。

对业务主管，你要给的是方案、节奏和协同路径。

因为他们最关心的是：这件事怎么推进、要谁配合、什么时候上线、上线后团队要怎么改动作。他们需要的是可执行性，不是概念正确。

对一线执行者，你要给的是可用性、学习成本和异常处理。

别动不动就教育用户“这是为了规范流程”。你得知道，一线不是不懂管理价值，而是他们先承受了最直接的使用成本。字段为什么非填不可？报错能不能说人话？异常场景有没有退路？如果这些问题你不解决，再高明的设计理念都落不了地。

对重点客户，你要给的是预期管理和边界确认。

能做什么，什么时候做，哪些是特例，哪些不会进入标准版本，都要讲清楚。否则今天插一次队，明天就会有人默认这个口子一直开着。很多团队最后不是被需求压垮的，而是被自己没说清的边界压垮的。

对普通用户或低权重需求，也不是简单拒绝。

而是放回统一的判断框架里：业务价值多大，影响范围多广，成本多高，和当前阶段目标是否一致。排后需要说明原因，不能做就明确关闭，能观察就进入待验证池。

差异化回应，核心不是“见人说人话，见鬼说鬼话”，而是“按角色给动作”。

这才是专业。

七、产品经理最怕的，不是得罪人，而是不会取舍

很多产品经理之所以累，不是事情真的多到做不完，而是心里始终想维持一种虚假的公平。

谁的需求都想接，哪方都不想得罪，任何人的话都想表示理解。最后的结果往往是，自己成了所有矛盾的缓冲层，项目却没有抓住重点。

靠谱的人之所以总被消耗，不是因为他们做得不够好，而是因为他们不懂得拒绝。

但在产品工作里，拒绝本身没有问题。

拒绝得没有依据，才是问题。

你可以优先处理领导关心的报表，因为它影响项目能否继续拿到支持；你也可以优先处理一线主流程里的高频卡点，因为它影响系统是否真的被用起来；你还可以让重点客户需求插队，因为它关乎签约和续费。

前提是，这些优先级都能被解释。

能被业务价值解释，能被组织目标解释，能被用户影响解释，也能被落地成本解释。

一旦解释不清，就不是用户分层，而是拍脑袋。

一旦只剩“谁级别高听谁的”，那也不是产品判断，而是办公室政治。

“见人下菜碟”这句话，在产品工作里真正该学的，从来不是圆滑。

而是清醒。

清醒地知道，用户不是一个抽象整体，而是一组位置不同、权重不同、目标不同，甚至彼此冲突的角色。

清醒地知道，所谓用户导向，不是谁声音大听谁，也不是所有需求都一股脑地接。

而是你要判断：谁影响业务成败，谁决定系统能不能被买、被推、被用、被留。

产品经理的成熟，很多时候就体现在这里。

不是你听了多少声音。

而是你终于知道，哪些声音必须先听，哪些声音要继续验证，哪些声音可以暂时放下。

说到底，真正负责的产品经理，从来不是对所有人都一样。

而是对结果负责。

本文来自公众号：简谙 作者：简谙