PM 面试里的用户分层题：先分谁，不是先想功能
一句话总结
产品面试中最危险的幻觉，是认为“用户分层”只是功能上线前的准备工作。真正的判断是：用户分层不是产品设计的前置步骤，而是产品决策本身。大多数候选人一听到“我们要做个新功能”，立刻跳进“我想到了三个用户群”，但他们在第一句话就错了。
不是“先想用户群再设计功能”，而是“分层的过程就是在定义功能”。你不是在分类用户，你是在用分层揭示需求的优先级、资源的分配逻辑和增长路径的唯一正确解。
一个产品经理的价值，不在于他能画出多少个用户画像，而在于他能用分层推翻错误共识。在Google的hiring committee上，我见过太多简历写着“用RFM模型做用户分群”，结果在白板前连“为什么先分付费意愿而不是使用频率”都说不清。分层不是分析工具，是权力工具——它决定谁被服务、谁被牺牲、谁被忽略。你不是在做用户研究，你是在做产品政治。
适合谁看
这篇文章不是给刚转行、还在背“用户画像六要素”的人看的。如果你还在用“年龄、性别、地域”做分层框架，这篇文章会直接否定你过去三个月的努力。
它适合那些已经经历过至少两轮一线公司PM面试、在case题中卡在“接下来怎么分用户”环节的人。典型读者是：有2-5年经验的产品经理，正在冲刺Google、Meta、Amazon、Stripe或Uber的L4/L5岗位，简历上写过“主导用户增长项目”或“设计分群策略”，但在模拟面试中被反馈“逻辑不够深”或“缺乏战略视角”。
你也可能是正在准备PM面试的应届生，但已经意识到“标准答案”在真实面试中完全失效——比如你在YC创业公司实习时，发现老板说的“我们的核心用户是25-35岁一线城市白领”根本无法指导任何决策。这篇文章的目标是让你在下一场面试中，当面试官问“你怎么分用户”时，不再回答“按活跃度、付费能力、使用场景”，而是直接说：“我先确认我们想解决的问题是否值得分层，以及分层后能否改变资源分配。
” 这才是硅谷顶级公司真正想听的判断。
用户分层的本质是资源分配，不是用户理解
大多数PM面试辅导教你的分层方法，本质上是用户画像的堆砌。他们告诉你“按行为分、按态度分、按人口统计分”，然后让你画出四个象限的矩阵。这是错的。用户分层的本质不是理解用户，而是分配资源。在Amazon的某次product debrief会上，团队提出要为“高频低价值用户”推出专属优惠。
L4 PM用漏斗数据证明这类用户转化率高，但GM当场打断：“我们今年的OKR是提升ARPU，不是拉新。你分的这个群体会稀释整体利润率，所以不值得投入工程资源。” 这就是现实——分层决策最终要回答的不是“谁在用产品”，而是“谁值得我们花工程师的时间”。不是所有的用户都值得被服务。不是所有的“需求”都值得被满足。
你不是在做人类学研究，你是在做商业判断。在Meta的hiring manager讨论中，有人提到一个候选人做得很好：“他上来就问，我们这个功能的目标是提升留存还是变现？因为如果是留存，我会优先看7日流失用户；如果是变现，我会看top 5%付费用户的使用断点。” 这才是对的。
分层不是起点，是约束条件的显性化。你分的每一个群，都对应着一个资源包：多少工程师、多少设计时间、多少服务器成本。如果你不能说出“为什么这个群比那个群更值得投入”，你的分层就是无效的。我见过太多PM在面试中说“我们可以先做A/B测试”，但面试官真正想听的是“我不会测试全部群，因为资源有限，我会先赌在B群，因为他们的LTV是A群的3倍”。这才是PM的判断力。
具体场景：在Google的某次PM面试中，面试官给出case：“视频平台想提升用户观看时长。” 候选人A说：“我先把用户分成新用户、老用户、付费用户、免费用户，然后看每个群体的行为差异。” 面试官点头，但没给高分。候选人B说：“我先确认‘提升观看时长’是不是正确目标。如果是广告收入驱动，我关注广告触达时长；如果是订阅转化驱动，我关注完成度高的用户。
假设目标是提升订阅转化，我会优先看‘观看了3个以上视频但未订阅’的用户，因为他们的意向明确，但卡点未知。其他群体即使时长提升，也不一定带来收入。” 面试官当场说：“这就是我们要找的人。” 区别不在工具，而在目的。不是“分层是为了理解用户”，而是“分层是为了锁定最高ROI的干预对象”。你不是在画用户地图，你是在画资源作战图。
再看一个真实数据：Uber Eats在2021年做用户分层时，发现“每周下单1-2次”的用户占总量68%，但贡献了41%的GMV。而“每周下单3次以上”的用户仅占12%，却贡献了39%。如果按传统逻辑，应该优先服务大基数群体。但团队最终决定主攻高频用户，因为他们的边际运营成本更低，且对新功能（如订阅制免配送费）的接受度更高。
这个决策背后不是数据洞察，而是资源判断——我们只有两个后端工程师能支持新功能开发，必须选最容易跑通的场景。分层不是发现需求，是排除选项。你不是在找“谁有需求”，你是在找“谁的需求能用最少资源兑现”。这才是PM面试中“分层题”的真正考点。
为什么90%的PM面试者一上来就错了
错误不是出在方法，而是出在顺序。绝大多数PM面试者一听到“用户分层”，立刻进入“分类模式”：我要用K-means聚类，我要画RFM矩阵，我要做persona画像。他们以为面试官想听的是“我会分析”。
但真实情况是，面试官在等一个更基础的判断：“你有没有先问，为什么需要分层？” 在Stripe的一次hiring committee debrief中，面试官反馈：“候选人用了很好的聚类模型，但没解释为什么不能用统一策略。他假设分层是默认动作，但现实中，大多数产品阶段根本不该分层。
” 这就是致命伤。不是“所有产品都需要用户分层”，而是“只有当统一策略失效或资源有限时，才需要分层”。你上来就分，等于默认了问题的存在，而没质疑问题本身。在Amazon的面试评估表里，有一条关键评分项：“是否挑战问题前提”。你没过，不是因为分得不好，是因为你根本没判断“该不该分”。
具体案例：一个候选人面试Google Ads的PM岗位，case是“广告主ROI下降，怎么提升”。他立刻说：“我可以把广告主分成大中小三类，分别设计策略。” 面试官问：“为什么不能用一个策略解决所有广告主？” 他愣住了。
正确回答应该是：“我先看ROI下降是普遍现象还是局部问题。如果是普遍下降，可能是市场环境或产品机制问题，分层无意义；如果是部分广告主下降，我才需要分层定位问题群体。
” 这才是逻辑起点。不是“怎么分”，而是“是否该分”。你分层的前提是：不同群体有本质差异的需求或行为模式，且这些差异大到需要不同的产品策略。否则，统一策略更高效。
在Uber的某次内部培训中，PM leader强调：“不要为了分层而分层。如果你的分层结果导向同一个功能，那你就是在浪费时间。” 比如你把用户分成A/B/C三群，最后给的都是“推送优惠券”，那分层就是伪动作。
另一个常见错误是：用人口统计或行为指标做分层，却不连接业务目标。我见过候选人说“按DAU分活跃用户”，但没说“为什么活跃用户值得服务”。在Meta的某次debrie中，一个PM提出要为“夜间活跃用户”做专属功能。被问：“他们的LTV比白天用户高吗？” 答不上来。后来数据证明，夜间用户虽然活跃，但转化率低，广告点击少。分层必须连接价值。
不是“谁在用”，而是“谁在创造价值”。在LinkedIn的growth team，他们有一条规则：“任何分层必须能映射到OKR。如果不能，不准立项。” 比如你要分“内容生产者”，必须说清这能提升多少feed quality score，进而影响多少用户留存。
分层不是分析练习，是商业论证。你在面试中说的每一个群体，都该附带一句：“服务这个群，能让我们离目标更近X%。” 否则，你就是在玩分类游戏，不是做产品决策。
如何用分层推翻团队的错误共识
最高段位的用户分层，不是用来支持现有策略，而是用来推翻错误假设。大多数PM用分层证明“我们该这么做”，但顶尖PM用分层说“我们一直做错了”。在Google Drive的一次strategy review中，团队认为“企业用户是增长关键”，因为大客户客单价高。
但一位L5 PM做了分层分析：发现SMB（中小企）用户虽然单个体量小，但留存率高、功能需求集中、支持成本低。而大企业定制需求多、销售周期长、churn risk高。
他用LTV/CAC ratio证明：服务10个SMB的ROI等于服务1个enterprise。这个分层直接改变了产品路线图——团队从主攻定制化功能，转向标准化协作工具。这才是分层的战略价值。你不是在辅助决策，你是在重置决策框架。
具体场景：在Stripe的hiring manager讨论中，一个候选人提到他过去如何用分层改变团队方向。他说：“当时团队认为‘开发者是主要用户’，所以所有功能都围绕API体验。但我分层发现，真正推动 adoption 的是‘技术决策者’——CTO或工程经理。
他们不写代码，但决定用不用。于是我重新定义用户：一级用户是决策者，二级用户是实施者。产品文档从技术参数转向ROI计算，功能发布顺序也调整。
结果adopt rate提升37%。” 面试官集体点头。这个案例的精妙之处在于：他不是用数据描述现状，而是用分层重构“用户”定义。你分的不是客观存在的人群，而是你在产品中赋予权力的角色。不是“谁在用”，而是“谁在决定”。
这种推翻共识的能力，是PM面试的顶级信号。在Amazon的bar raiser体系中，有一条隐性标准：“candidate should be able to teach me something。” 你分层的结论，应该让面试官觉得“我没想到这一层”。比如你说：“表面看，流失用户是问题，但分层后发现，主动关闭账户的用户中，80%是因为功能过剩——他们只需要基础版。
所以我们不该挽回他们，而该推出轻量产品线。” 这种反直觉判断，才是L5/L6的思维。不是“怎么留住用户”，而是“为什么有些用户离开是好事”。
你用分层暴露了产品定位的偏差。在Netflix的content team，他们曾用分层发现：高评分剧集的观看时长反而低于中等评分剧。结论：用户打分和观看行为脱节。这直接改变了推荐算法——不再优先推高分剧，而是推“观看完成度高”的剧。分层在这里不是用户洞察，是产品纠偏机制。你在面试中要做的，不是展示分析能力，而是展示“我能用数据推翻你们都相信的事”。
分层之后：如何连接功能与资源
分层的终点不是画出几个群体，而是明确“谁优先、谁延后、谁放弃”。但大多数PM在面试中止步于“我会给不同群推不同功能”。这是表面答案。真正的判断是：分层后，你如何重新分配资源？在Meta的某次tech lead interview中，PM说：“我分了三群用户，A群需要新功能X，B群需要Y，C群需要Z。” 面试官问：“工程团队只能做X或Y，你选哪个？
” 他犹豫了。正确回答应该是：“我不会同时推进。我会用分层数据计算每个功能的预期impact，然后选ROI最高的。如果X影响10%用户但提升LTV 20%，Y影响30%用户但只提升5%，我选X。” 分层必须转化为资源决策。你不是在开需求清单，你是在做优先级仲裁。
具体场景：在Google的hiring committee上，一个候选人被质疑：“你的分层很细，但Google的工程师很贵，你怎么说服团队只做一部分？” 他回答：“我用分层定义MVP范围。比如，我发 hiệntop 10%活跃用户贡献了60%的互动，但现有功能只满足他们70%的需求。
所以我建议先做‘超级用户专属功能’，用20%资源换取50%的engagement提升。其他群体后续迭代。
” 这个回答通过分层锁定了资源杠杆点。不是“所有人都要服务”，而是“谁的满足能带来最大边际收益”。在Amazon，他们叫这“single-threaded leadership”——一个leader只对一个关键群体负责，直到目标达成。分层在这里是组织分工的依据。
薪资数据：在硅谷，L4 PM的典型package是base $180K + RSU $120K/year + bonus 15%；L5是base $220K + RSU $200K + bonus 20%。
这些数字背后是资源权重——一个L5的time worth more，所以你必须证明你的分层能最大化他们的产出。你在面试中说“我要分群”，其实是在说“我能让高薪工程师做最有价值的事”。
这才是高层PM的视角。不是“功能实现”，而是“资源效率”。在Stripe，PM的performance review有一条：“did you prevent building the wrong thing?” 分层的核心价值，是用数据stop low-impact work。你在面试中要传达的，不是“我会做分层”，而是“我能用分层阻止团队浪费六个月”。
准备清单
- 明确你的目标不是“展示分析能力”，而是“做出资源分配判断”。每次练习分层题，强制自己加一句：“基于此，我会优先投入X资源给Y群体，因为Z。”
- 练习挑战问题前提。拿到case后，先问：“这个目标是否必须通过分层实现？有没有可能统一策略更高效？” 例如，面试官说“提升留存”，你问：“是整体留存下降，还是特定群体现象？”
- 掌握至少两个非传统分层维度：LTV/CAC ratio、support cost per user、feature dependency map。这些比DAU/RFM更能体现战略思考。
- 熟悉公司级OKR结构。Google的PM面试常考“如何对齐公司目标”，你要能说清分层如何服务top-down objective。例如，“如果公司目标是提升广告收入，我会优先分‘高曝光低点击’用户，而不是‘低活跃用户’。”
- 系统性拆解面试结构（PM面试手册里有完整的用户分层实战复盘可以参考），包括每轮考察重点：第一轮behavioral看决策逻辑，第二轮case看框架深度，第三轮cross-functional看资源协调。
- 模拟hiring committee视角。练习后问自己：“如果我是面试官，这个分层会让我觉得candidate能manage resources effectively吗？”
- 准备一个“推翻共识”的故事。用STAR结构讲一个你如何用分层改变团队方向的真实案例，重点在“旧共识 vs 新数据 vs 业务impact”。
常见错误
BAD案例1： 面试官：“电商平台GMV下降，怎么分用户？” 候选人：“我可以按RFM模型分：最近购买、购买频率、购买金额。高RFM用户是核心，应该推个性化推荐。” 这是标准答案，但错了。问题在于，他假设“高价值用户流失”是原因，但没验证。
GOOD版本：“我先看GMV下降是否由用户流失导致。如果是，再看流失用户的RFM分布。如果发现中RFM用户流失率最高，而他们是增长主力，那我的策略不是挽留高RFM用户，而是防止中层滑落。这可能意味着供应链问题，而非推荐算法。” 区别：不是用分层支持直觉，而是用分层定位真因。
BAD案例2： “我会把用户分成新用户、老用户，然后给新用户推引导，老用户推 loyalty program。” 这是功能导向，不是资源导向。GOOD版本：“新用户转化率当前15%，老用户churn rate 8%。
如果工程资源有限，我会优先优化新用户转化，因为提升5个百分点带来的增量用户，比降低churn带来的存量 retention 更可观。所以我先投入在onboarding flow。” 这里分层连接了资源优先级。
BAD案例3： 在Meta面试中，候选人说：“按设备分iOS和Android用户，因为行为不同。” 面试官问：“不同在哪儿？是否影响核心目标？” 他答不上。
GOOD版本：“Android用户占比60%，但支付失败率是iOS的2.3倍。如果目标是提升付费转化，我会优先解决Android支付体验，即使iOS用户ARPU更高。因为边际提升空间更大。” 分层必须带行动权重，不是分类陈列。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
为什么不能先想功能再分用户？ 因为功能是资源承诺，你必须先知道资源投给谁。在Amazon的某次debrie中，团队想推“一键重购”功能。PM先分用户，发现只有12%用户有高频复购行为。如果先做功能，会浪费3个月开发时间。
正确顺序是：先分，确认有足够高价值用户支撑ROI，再立项。不是“功能驱动分层”，而是“分层证伪功能”。你在面试中说“我想先做MVP”，但面试官想听“我先用分层判断MVP是否值得做”。例如，Google Photos曾计划推AI album功能，但分层发现只有8%用户手动建过相册，说明需求不普适，项目暂停。分层在这里是刹车机制，不是加速器。
如何判断分层维度是否合理？ 唯一标准是：它能否改变决策。在Stripe的hiring guide中，明确说：“if your segmentation leads to the same action, it’s not useful.” 例如，你按年龄分，但所有群都该推优惠券，那年龄就是无效维度。
有效维度如“支付成功率”：低于50%的群需要技术优化，高于70%的需要营销刺激。决策分叉了。
在Uber Eats，他们用“订单取消率”分层，发现餐厅端取消率高的区域，需加强运力；用户端取消率高的，需优化预估时间。同一个指标，导出两个团队动作。这才是好分层。你在面试中要自问：“我的分群会不会让工程师、运营、市场做不同的事？”
小公司没有数据，怎么练分层思维？ 用假设性推理。在YC创业公司的PM，没有完整数据，但可以问：“如果我们只有100个用户，谁最可能推荐我们？谁最常抱怨？谁付了年费但不用？” 这些定性判断也是分层。
在hiring committee中，一个候选人说：“我用支持工单分类用户痛点，发现‘集成困难’占60%，所以我优先做API文档优化，而不是新功能。” 面试官认可，因为他在资源有限下做了优先级判断。分层不依赖大数据，依赖逻辑链条。
你不需要SQL，你需要说清“为什么这个群比那个群更重要”。在早期公司，分层往往是定性的权力分配——谁的声音被听见，谁的需求被实现。这才是本质。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。