产品思维与产品经理的责任

你花三天做好新手引导，发布没有报错，首关完成率却没变。代码已经交付，产品工作算完成了吗？如果接着加奖励、排行榜，是否就在向前推进？

本篇帮助你决定：下一步该增加功能，还是检查功能到用户价值之间断了哪一环。 以下连线游戏情境为虚构教学示例。

为什么上线只是中间一步

一个引导功能想让玩家更容易独立开始，至少要经过几次转换：玩家遇到引导，理解它，把理解转成动作，动作带来预期体验。接口返回成功，只说明其中一个技术环节成立。

假设引导出现在玩家已经退出的页面之后，改文案再精美也没触达问题。如果玩家只是在照着箭头拖动，首关完成也未必意味着他理解规则。如果把题删到没有选择，独立完成增加了，解题的乐趣却可能减少。每一步都需要自己的证据，不能靠前一步自动推出后一步。

因此，把工作拆成下面四层，才知道自己究竟完成了什么：

用户结果也不只是一项数字。首关完成率提高时，同时看后续自主选择、困惑和退出原因；否则可能把“完成更容易”误认为“体验更值得玩”。

工程师通常接到的是“做一个引导”，但这句话已经预先选了方案。更早的问题是：谁不会开始，卡在操作还是目标，哪种改动最能区分原因？这部分是发现。选定服务人群、当前目标和版本边界，是定义。把规则与反馈组织成玩家能经历的过程，是设计。

方案仍要实现、发布并在异常时保持可信，这是交付；发布后根据证据修订解释，是学习。它们连在一起，才构成产品责任。一人团队不必设置五个岗位，但要给五种问题留下检查时间。外包美术也同样如此：完成一张图，还需要确认授权、真机可读性和修改成本。

游戏交付的价值可以是放松、探索、胜任感和社交表达，未必是节省时间。你要先说明希望带来哪一种体验，才能判断“玩家玩得更久”究竟是投入，还是被阻碍了。

可以把产品推理写成一条待检查的链：“因为观察到……，我们猜测……，所以尝试……，如果解释正确，应看到……”。

例如，模拟观察发现玩家在长说明页退出。可能是说明难懂，也可能加载慢、入口吸引了不匹配人群，或玩家临时被打断。先检查加载和实际阅读行为，再决定是否用一笔操作示范替换说明。若有效，预期不只是按钮点击增加，还应看到无需口头帮助的操作与后续理解。

这样写的作用是把解释暴露出来：你能说清哪个观察会让自己改选。它不是为既定开发方案补一句听起来合理的理由。

如果等整套系统写完才让玩家试玩，一旦核心体验不成立，外围功能都可能返工。先用能回答关键问题的材料发现问题，再交付已确定的改动，可以降低一次押注的范围。

并行也有代价：频繁改假设可能打断实现。因此要区分“本版已经承诺的质量”与“下版仍待研究的方向”。例如本周可靠地交付存档修复，同时观察下周要解决的回访动机。未知可以保留，已交付的用户承诺不能靠研究中搪塞。

这套拆分适合发现链条缺口，不保证每个结果都能精确测量。早期人数少，长期体验变化慢，收入还受渠道和季节影响；此时记录任务观察、成本与不确定性，比编一个精确提升比例更诚实。

紧急修复崩溃、资质要求和隐私缺陷时，也不必先证明它们能提高留存。它们可能是继续交付的必要条件。相反，一个实现很难的新系统，不能仅因技术挑战大就获得优先级。

练习：选一个过去做过的功能，分别写出投入、输出、用户结果与经营影响，再给每个相邻层次补一句“要成立，还需要什么”。证据不足处标未知，提出一种能改变下一步决定的补证方式。下一步读战略与定位。