房产经纪人提出“给公共房源加标记”，产品经理却最终做成了小程序消息提醒。从“加标记”到“发提醒”，中间藏着产品经理的核心判断链路：理解问题、分析需求、推进方案、参与验收、复盘迭代。本文通过真实案例，拆解产品经理的五项职责如何环环相扣，帮你建立从问题到结果的完整工作框架。
———— / BEGIN / ————
“在电脑端房源列表上，给公共房源加一个醒目的标记。”
房产经纪人提出这样一条需求，听起来很简单：调整样式，补一个标签，交给开发实现。但接到需求的产品经理发现，系统明明已经有一个专门查看公共房源的页面。用户为什么还要在另一个列表里找它们？
这个问题追下去，最后做出来的功能变了：团队在小程序里增加了房源转为公共房源的消息提醒。
这是一个很典型的产品现场。从“加标记”到“发提醒”，中间那段看不见的判断，恰恰是理解产品经理工作的起点。做了多年产品后，我把这份工作看成一条连续的链路：弄清用户的问题，分析需求并取舍，形成方案并推进协作，参与验收上线，再根据结果决定下一步。不同团队会有不同分工，但每一项都需要留下可供下一步使用的结论。
一、先弄清问题，再决定做什么
第一项职责，是理解用户及其所处的业务。
在这个房产系统里，房源可以按归属分为私有和公共，也可以按是否能够交易来分类。经纪人平时查找可交易的房源，因此默认列表中同时显示私有和公共房源；如果只想找公共房源，也可以切换到专门的页面。
按这个逻辑，“把公共房源标得更醒目”似乎没有解决一个新的查找问题。
关键线索藏在房源归属的变化里。
原来，系统有一条规则：经纪人超过规定时间没有跟进，私有房源就会转为公共房源，俗称“跳公盘”。系统已有消息通知，但经纪人经常外出带客户看房，很少留意电脑端的系统消息。等到发现时，自己的房源可能已经转公了。
所以，用户真正担心的是：自己的房源发生了归属变化，却没有及时获知。醒目的标签是他能想到的解决办法。
这时再比较方案，差别就清楚了。列表加标记，需要经纪人先回到电脑前、打开列表、认出房源；消息提醒则可以通过日常使用的手机告知他变化。这个案例最后把方案落到了小程序的微信消息推送上。
产品经理在这一环节要留下的，至少包括使用者、业务规则、问题发生的场景，以及已有办法为什么没有奏效。缺少这些信息，团队只能围绕一个标签的颜色和大小讨论，很难判断这件事是否值得做。
第二项职责，是分析需求，确定目标和范围。
理解了问题，也不意味着用户提出的每个相关功能都要进入本期版本。还要确定：这次准备改善哪件事，方案覆盖哪些情况，要付出什么实现成本。用户影响、业务价值与开发投入，都应进入取舍依据。
沿着房源案例往下看，“让经纪人及时获知归属变化”和“让公共房源更容易被找到”，就是两个不同目标。前者要检查通知是否触达了相应的人；后者要检查查找过程是否顺畅。两种功能可能都有用，却不能用同一套理由证明它们必须同时做。
如果本期要解决的是消息遗漏，讨论就应围绕提醒发生的时机、接收对象和相关使用场景展开。至于列表是否需要整体改版，需要另有证据支持，不能顺手扩大范围。这里是在说明如何判断取舍，原案例并未披露团队的完整排期和资源评估。
需求分析的交付物因此不能只有一个功能名称。它还要让团队知道：本期解决什么问题，为什么采用这个方向，以及哪些事情暂时不在范围内。
二、把判断变成团队能实现的方案
第三项职责，是把方案讲清楚，并和团队一起推进实现。
另一个需求来自财务人员，来自财务人员：希望电脑端的报销单据详情能够全屏显示。原来的单据在小窗口中打开，窗口可以最大化，底部有打印和取消按钮。
追问之后才发现，财务人员遇到的困难有两个：
报销审批节点很多，横向排列后，小窗口装不下，需要拖动横向滚动条才能看完整。
看完以后，财务还要把单据打印出来归档。
团队随后调整了审批节点的展示方式。例如，原先分散排列的部门审批、店长审批，可以按所属的门店层级组织显示，使审批关系更容易辨认。打印流程也增加了预览：先看预览，再确认打印。
这个案例的价值，在于方案已经落到了具体操作中：哪部分内容难读，怎样组织显示，打印前多了哪一步。只有“优化体验”四个字，设计和开发无法据此判断该改什么。
继续把这类方案交给团队实现，还会出现更细的问题。
将节点合并展示，是否仍能看见每个节点的审批状态？
展示层级变化，会不会让人误以为审批步骤也被删掉了？
预览中的内容与实际打印内容如何对应？
这些是沿方案需要进一步确认的规则，不能靠各个岗位自行猜测。
产品经理要根据问题选择表达方式：操作顺序可以用流程图说明，页面布局用原型表达，权限、状态和异常处理则写进规则。文档写得多并不自动代表方案清楚；同一个问题在原型、需求文档和会议结论里说法不同，反而容易造成返工。
协作也从这里开始。业务方确认方案有没有遗漏工作要求，设计师判断信息怎样呈现，研发评估实现条件，测试检查规则是否足够明确。讨论改变了方案，就需要把结论同步到相关材料；仍未解决的问题，也要明确由谁补充、何时给出判断。具体开几次会、怎样安排评审，要根据团队节奏调整，但“结论有人确认、变化有人同步”这件事不能省。
这一项职责最终要交付的，是团队可以据此开展工作的方案，以及实施过程中持续有效的产品判断。
三、上线前，把业务路径走完整
第四项职责，是参与验收和上线准备，检查实现是否满足约定。
上述房产案例记录了问题和处理方案，并未公开完整的验收、上线效果数据。
沿着这两个方案，可以进一步看清产品验收应该检查什么。
对于房源转公提醒，验证到“系统发出了一条消息”就结束，仍然不够。需要核对消息是否对应那条发生变化的房源、是否发给应当知晓的人，以及接收者能否从内容中理解发生了什么。触发时机和使用条件，要以团队确认的业务规则为准。
对于报销单，页面变得紧凑，也只是其中一项变化。还应按财务人员的工作顺序，查看审批关系、辨认节点状态、进入打印预览、确认打印内容。某个按钮能够点击，不等于这条工作路径已经成立。
这些检查需要产品、业务和测试共同参与。产品经理负责澄清业务预期、判断实现是否偏离方案；测试对质量进行专业验证；技术发布条件则需要研发、运维等相应负责人判断。发现问题以后，产品经理还要说明它影响哪些用户、是否阻断关键操作，供团队决定修复、延后还是调整上线范围。
上线准备中还容易漏掉两件事：使用者是否知道流程变了，产品团队是否有办法看到上线后的表现。
例如，打印流程增加预览步骤，使用说明和相关业务沟通就需要与之对应。如果上线后准备检查提醒的使用情况，所需的数据记录也要在开发时考虑，不能等到复盘才发现没有记录。验收、运营沟通、数据记录和反馈渠道，应该在上线前就逐项确认。
需求沟通时就想清楚怎样检查效果，后面才不会只剩下“功能已经做完”这一条结论。这也解释了为什么五项职责是一条相连的工作链：上线后要回答的问题，往往需要在需求阶段就留下条件。
四、回到最初的问题，判断下一步
第五项职责，是观察使用结果、复盘问题，并形成下一轮决定。
继续用房源提醒说明：提醒发送成功，只能证明发送环节完成；是否帮助经纪人及时获知归属变化，还需要结合触达、使用和用户反馈来判断。不能直接把发送量当作需求已经解决的证据。
报销单也是如此。打印预览的使用次数，能说明有人进入这个环节，却不足以单独证明财务工作更顺畅。还需要回看最初的困难：审批信息是否更容易读懂，打印内容是否符合归档需要，是否出现了新的操作障碍。
这些都是应当验证的问题，并非原案例已经公布的改善结果。若要进一步判断“节省了多少时间”，还需要上线前后的可比记录，说明观察对象和任务条件；没有数据，就不能把功能完成写成效率提升。
复盘也要分清两条线。一条看交付过程：评审遗漏了什么，需求为何变更，信息有没有同步，哪些依赖影响了上线。另一条看产品结果：实际使用与原先预期有什么差异，用户的问题有没有得到缓解。
过程顺利而结果不好，可能需要重新检查问题判断或方案；使用效果有改善，但团队反复返工，则需要修正协作与交付方式。两种情况不能用一份“项目已完成”的记录一笔带过。
回到开头，经纪人要一个醒目的标记，产品经理需要先理解他为什么提出这件事。做出提醒以后，还要继续检查提醒是否在他的工作场景里起作用。职责从一个具体问题开始，也应当在这个问题的实际变化中接受检验。
本文来自作者：Lucas
热门跟贴