深圳市腾讯计算机系统有限公司校招产品经理（专业面）面试经验——求职精灵（finsight.work）

这题的关键不是选一个多高级的产品，而是让面试官看到你观察产品的路径。我会按「产品定位—目标用户—具体场景—痛点证据—方案—指标」六步讲。

产品选自己真正高频使用的，别选只用过两次的。先一句话说清定位和核心用户，再落到一个具体场景：我在什么时间、想完成什么任务、卡在哪一步。

痛点要有证据。可以是自己的操作路径，也可以是应用商店评论、社群里反复出现的抱怨，最好能说明它影响的是核心用户的主流场景，而不是边缘需求。

方案要具体到交互层面：入口放哪、文案怎么写、默认值是什么，然后给出预期指标，比如某一步的转化率、次日留存、相关功能渗透率。

最后主动补一句风险：这个改动会不会影响另一类用户，需不需要灰度。面试官往往就在这里继续追问。

我会用 OSM 模型回答：先定目标，再定策略，最后落到指标。

第一步明确目标和阶段。同一款产品在不同阶段北极星完全不同：冷启动看激活和留存，成熟期看变现效率。上来就报 DAU 和 GMV，说明没想过产品现在最该解决什么。

第二步把目标拆成策略。比如目标是提升留存，策略可以是提升内容供给质量、优化推荐分发、增加互动机制。策略必须是产品能施加影响的动作，不能是「等大盘变好」。

第三步为每个策略配指标。北极星只留一个，其余是过程指标：获客看 CAC 和渠道转化，激活看核心功能使用率，留存看次日和 7 日留存，变现看付费率和 LTV。

最后补两个原则：指标之间要有因果关系，过程指标要能解释北极星；同时避免互相打架，比如广告收入拉高但时长下降，就要设约束条件。

我会先讲清朋友圈的产品逻辑，再给方案，不然容易变成功能堆砌。

朋友圈的核心是熟人关系链下的轻量表达和互动，约束条件很强：不能破坏熟人社交的隐私边界，也不能让产品变得过重。当前的主要矛盾是发布意愿下降——很多人不是没内容，而是担心被特定的人看到、担心没人回应。

方案一，降低发布的心理门槛。把可见范围做成发布页的一级选项，提供「同事不可见」「仅密友可见」这类可复用的分组模板，减少每次发布的决策成本。

方案二，提供更轻的表达方式。比如分享正在听的歌、正在看的文章、一个状态标签，让用户不必配图写字也能完成表达。

方案三，优化广告体验。控制插入频次，提升相关性，给用户明确的关闭和反馈入口。

指标上，发布渗透率、人均发布条数、互动率、广告负反馈率一起看；同时评估对广告收入的短期影响，说明你愿意用什么换什么。

竞品分析的目的不是罗列功能，而是找到差异化机会。我会分四步。

第一步先明确目标。是为了功能参考、战略定位，还是向管理层做决策支持？目标不同，分析深度和产出完全不同。

第二步圈定范围。直接竞品是同赛道同人群的产品，间接竞品是在某个场景上争夺同一批用户的产品，标杆竞品则是不在同赛道但某方面值得学。三类都要有，但重点放在直接竞品。

第三步用统一框架对比：目标用户重叠度、核心功能广度与深度、商业模式、用户口碑、增长曲线。每一项都要落到证据，比如应用商店评分、版本更新记录、投放素材、社区吐槽。

第四步提炼洞察并指向行动。产出应该是「对手强在哪、弱在哪、我们的机会是什么、先做哪一件事」，而不是一份功能对照表。

最后补一句：不盲目抄。竞品做某个功能是因为它的阶段和资源，我们的优先级要回到自己的北极星指标。

我会按「发现—验证—设计—推动—上线—迭代」讲一个完整闭环，重点放在我做的判断。

发现：需求来自数据异常或用户访谈。比如邀请功能的转化率只有 2%，远低于同类产品，我去访谈了 10 个流失用户，发现流程要 5 步、还要等验证码。

验证：先估算天花板，再决定投入。用现有数据算如果转化率提到行业中位能带来多少新增，值不值得做；不确定就先做 MVP，小流量验证。

设计：明确功能边界，写清做什么、不做什么，画出主流程和异常流程，同步埋点方案，避免上线后没法衡量。

推动：研发资源永远不够，我会把需求拆成必做和可延后，先保证核心链路；跨团队依赖提前对齐排期。

上线：看激活率、完成率、留存，设一个观察期，不达预期先定位是入口、交互还是需求本身的问题。最后给结果和复盘，哪怕失败也说清学到了什么。

我不把它当成二选一，而是先找交集，找不到再定底线。

第一步，判断冲突的性质。是短期收入与长期体验的冲突，还是产品定位本身的冲突。前者可以设计，后者要回到战略层面取舍。

第二步，找双赢方案。以广告为例，用户不想看广告、平台需要收入，解法不是简单减广告，而是提升相关性，让广告变成有用的信息；以付费为例，用 Freemium，把基础功能做扎实，把高级能力做成付费点，而不是把刚需锁起来。

第三步，设底线。当相关性做不到时，控制频次和打扰强度，宁可少赚一点，也不能让用户因为一次糟糕体验卸载。

第四步，用指标约束。把 NPS、卸载率、投诉率作为门槛指标，和收入一起看，避免团队只盯短期 GMV。

最后一句话点题：用户价值是商业价值的前提，但不是所有用户价值都能立刻变现，产品经理要做的是排序，不是站队。

我认为好的 PRD 标准是「让不参与讨论的人也能独立执行」。具体看六点。

一是背景清楚。为什么现在做、解决谁的什么问题，要有数据或访谈支撑，不能只写「提升体验」。

二是用户故事明确。谁在什么场景下完成什么任务，用一句话说清角色、动作和价值。

三是边界清楚。写清本期做什么、不做什么，防止开发过程中需求蔓延。

四是交互完整。主流程、异常流程、空状态、权限都要有，配流程图或原型，别让研发猜。

五是埋点方案。上线后看哪些指标、怎么定义、在哪些节点埋，PRD 阶段就要定。

六是验收标准。可衡量、无歧义，比如「3 步内完成邀请」而不是「体验流畅」。

最后补一句：PRD 是协作工具，不是交差文档，写完要拉着研发、设计、测试过一遍。

资源永远不够，所以我不会一上来就抱怨排期，而是先改项目的形状。

第一，缩范围。把大项目拆出一个能独立验证价值的最小版本，用两周、一个人能做完的粒度去谈，比要三个月、三个人容易得多。

第二，借能力。先看公司内部有没有现成组件或中台能力，能复用就不重造，把研发成本降下来。

第三，用数据换资源。先做小流量试验，拿到转化率、留存的实际提升，再拿结果去要更多投入。没有数据的争取，本质上是靠人情。

第四，找盟友。识别哪些团队也从这个项目受益，联合立项、联合汇报，优先级自然上去。

最后是沟通方式：跟研发讲清楚为什么做、做完对谁有价值，而不是只传需求。产品经理没有直接管理权，能依靠的只有判断力和信用。

我把产品感拆成四个可观察的能力。

第一，对体验的敏感度。拿到一个产品，能快速说出它服务谁、主路径是什么、哪一步让人卡住，而不是只说好不好用。

第二，对用户行为的预判。设计一个功能时，能想到用户会怎么误用、会产生什么副作用，提前设计约束。

第三，从模糊需求里提炼真问题。用户说要批量删除，真实问题可能是信息太多找不到重点，解法可能是分类和搜索，而不是加一个删除按钮。

第四，对细节有标准。文案、默认值、空状态、错误提示，都要经得起推敲。

怎么练？我的方法是固定拆解产品，每周一个，写清定位、主路径、关键决策和可改进点；再配合用户访谈和真实项目，把判断拿去验证。产品感不是天赋，是大量观察加复盘之后形成的直觉。

我会先判断这是不是一个真问题，再决定继续投入还是止损。

第一步，确认数据本身可信。埋点对不对、口径有没有变、观察周期够不够，很多「不达预期」其实是统计问题。

第二步，拆原因。把差距拆成三层：曝光不够、转化不行、需求不成立。曝光问题看入口和触达，转化问题看交互和文案，需求问题看用户是否真的在意这件事。

第三步，做假设并验证。每次只改一个变量，用 AB 实验看效果，避免同时改五处导致无法归因。

第四步，设定止损线。提前约定观察周期和判断标准，比如两轮迭代后核心指标仍无显著提升，就考虑下线或换方向。

最后是态度：下线一个没价值的功能不是失败，把资源一直压在沉没成本上才是。面试官想听的是你敢不敢做这个判断。