03 · 产品 · 下一版只留一件事
积分商城可以等，重复记账不能等
产品负责人对已上线系统的下一版本负责。上线之后，声音最大的需求往往不是伤害最大的。一期范围不归他签，使用事实来自产品运营，报障分类来自技术支持。
这一版做：一笔已支付订单只累计一次积分。退款按原订单冲回。验收看订单，不看商城皮肤。
先放着：积分商城更好看、生日券自动发。账还在重复时，这些会把问题盖住。
发布后看：重复累计从每天十几笔到零，冲回能查到原单。然后才排生日券。
产品负责人和产品经理不是同一次拍板
产品经理为第一次上线的范围负责。产品负责人接手的是已经有人每天在用的系统。岗位特点是对反馈分类，而不是把群里的句子直接排进开发。他先问四句：影响的是账、履约，还是只是不好看；一天发生多少笔；有没有绕过系统的旁路；修它会不会改变已经公示给顾客的规则。说不清笔数的想法进观察名单，观察期间用数据或支持记录补证据，不占用版本。
版本如果是缺陷、规则和想法的混合包，上线后无法判断该庆祝还是该回滚。产品负责人要求一个版本只回答一个问题。这个问题写成可数的结果：重复累计的订单数变为零，而不是「积分体验提升」。体验提升无法在发布第二天被证伪，团队就会永远停留在下一版还要再提升。
反馈从分类后的记录来，不从转发的聊天来
销售转发的微信通常只保留最愤怒的一句。产品负责人要求来源是技术支持已经分开的三类：缺陷、操作问题、变更愿望。缺陷进修复队列，用订单号复现。操作问题先改帮助或权限，不改规则。变更愿望进候选，和正在发生的伤害比较。没有分类的反馈，他退回支持，不退回开发。开发接到未分类的句子，会做成一个谁都不满意的折中按钮。
他和产品运营、活动运营的边界同样清楚。运营可以提出生日券，但不能把券的规则直接交给开发。规则要经过产品负责人：券叠加在什么订单状态、退款时券是否退回、同一会员一天能领几次。这些没写清，活动当天的事故会被说成系统不稳定，其实是规则没进版本说明。
看店通的积分：支付回调来了两次
会员系统上线两周，店长发现同一笔付款有时出现两行积分。商城改版的需求同时在排队，因为总部觉得页面旧。产品负责人抽了十四天的积分流水，按订单号分组。重复的十三笔都对应两次支付成功回调，金额相同、时间相差数秒。退款的单有的冲回了，有的没有，因为冲回逻辑只认最近一行，不认订单。
下一版因此只做两件事，而且两件事是同一条规则的两面：同一订单的支付成功只累计一次，以订单号为幂等键；退款必须找到当初那一笔累计并写冲回，禁止按会员余额直接减一个看起来接近的数。商城皮肤和生日券写进观察。发布后他看的指标不是页面停留，是重复订单数和无法关联原单的冲回数。两者连续七天为零，才允许排生日券。券如果先上，重复积分会变成顾客已经花出去的钱，更难追。
这个岗位的失败样子是路线图很长、每一版都有一点。成功的样子是业务负责人能说出上一版关掉了哪个洞。