从会做需求到会判断问题：开发者的产品思维练习

最近给自己安排了一组练习：不改任何代码，只读一份投放业务的数据，尝试回答几个业务问题。练习还没结束，结论不多，但有三次判断被我自己推翻又重建。这篇先把过程记下来，以及我目前对"产品思维"的理解——它比我想象的朴素得多。

先说清楚：我远没有"转型"成功，甚至不确定"转型"这个词对不对。目前能确认的只有一件事：产品思维不是会写 PRD、会画原型，而是能把事实、假设、证据、决策拆开。发现一个错误概念并修正它，本身就是产品能力的一部分。

第一次修正：两个数字不能直接相除

看到"订单创建失败"这个指标时，我的第一反应是：这是最高优先级。理由看起来也成立——下单失败直接伤害体验，伤害体验就伤害留存。

好在我停了一下。按开发的习惯，我会立刻拿"失败数 ÷ 下单数"算一个失败率，再按大小排优先级。但数据口径没确认之前，这个除法不成立：

• 分子是什么？是"创建失败的次数"，还是"失败过的订单数"？
• 分母是什么？是页面点击、提交请求，还是服务端接单？
• 统计在哪个阶段？前端上报、网关，还是业务库？
• 同一个用户重试三次都失败，算一次还是三次？

这四个问题，任何一个答案不同，"失败率"都可能差出量级。没有口径的失败率，拿它排优先级，等于用一个随机的数做重要的决定。

回头看我最初的直觉，它并不是全错，而是层次放错了。"失败伤害体验、体验伤害留存"是一条假设链，不是事实——链上每一环都需要证据，而我当时手里只有一个展示数字。直觉可以决定我先看哪里，但不能直接决定我先做什么。

最后我做的事是把优先级判断挂起，把确认口径列为下一步——口径还没有被确认，只是排进了待办。"挂起"这个动作对开发来说挺反本能的：看到红色的异常数字，手会比脑子先动。但业务侧的思考顺序确实不同：先确认这件事到底有多大、影响谁，再决定要不要现在动它。

第二次修正：下钻维度不是因果链，绝对金额不是结论

第二个练习是排查"纯空耗"。按这次练习里的已知定义，它指消耗 > 0 且新增收入 = 0 的广告计划所产生的消耗。

我最初的排查思路很"链路化"：监测链接出问题 → 汇总给投手。写完自己都觉得单薄，补成了：业务/媒体 → 监测链接 → 广告计划 → 广告组 → 投手。这里要收紧一个说法：它不是一条严格的因果链，而是一组分析和下钻的维度——从业务/媒体整体，逐层钻到监测链接、广告计划、广告组，最后落到投手。

补全维度的价值在于：空耗可能发生在任何一层，而每一层的解释都只是待验证的假设。业务侧是不是规则筛掉了大量流量？监测链接是不是有断点导致转化回传丢失？计划和广告组是不是配置问题？在证据把这些假设区分开之前，它们谁也不比谁更可信。维度画不全，归因就会天然偏向自己最熟的那一层——对我来说就是监测链路，这本身就是一种偏见。

但补全维度只是第一步，真正改变结论的是指标的选择。我最开始只盯着"空耗了多少钱"这个绝对金额，后来意识到它几乎没法用：

• 大业务天然金额大，按金额排序，永远是头部业务在"浪费"；
• 要看空耗率，才能在不同业务之间横向比较；
• 要拆到计划数、单计划空耗，才能判断是普遍问题还是个别计划失控；
• 要算它占总消耗的比例，才知道这个问题值得投入多少精力。

更重要的是，指标不是终点。拆完数字，还要解释空耗的形成机制：是出价策略的问题、素材衰减、受众过窄，还是监测链路断了导致转化没被归因？不解释机制，数字再准也只是一个现象。

第三次修正：IAA 不是"免费投放"

这次最基础，也最尴尬。我看到 IAA 这个词，没有查任何资料，按字面联想理解成了类似"免费投放"的意思，并带着这个错误概念往下推了一段。错误概念的麻烦在于它不会报错——不像代码会抛异常，它会安安静静地参与后面的所有推理。

翻指标说明才发现：IAA 是 In-App Advertising，应用内广告收入。和它相对的通用概念是 IAP（In-App Purchase，应用内购买）。不过要说明：这次页面上和广告收入并列的另一项是付费/充值收入，我没有进一步确认它的口径和构成，所以只说"广告收入和付费收入要分开看"，不强行给那一项贴上 IAP 的标签。

有意思的是，纠正概念之后，"两类收入分开分析"这个结论依然成立——但成立的原因变了。不是因为"流量免费"，而是因为变现模型不同：收入公式、回收周期、关键漏斗、对投放信号的依赖方式都不一样。结论侥幸没错，推理过程全错。这种"结论对、理由错"的情况最危险，因为它会在下一次类似场景里悄悄带偏判断。

我目前的最小思考框架

三次修正有一个共同点：每次被推翻的都不是结论本身，而是"从观察到判断"的中间环节。我把它整理成一个最小框架，顺序不能省：

事实 → 假设 → 证据 → 决策 → 验证

• 事实：原始观察到、未经解释的东西。"后台展示的订单创建失败数"是事实；"失败数在上升"和"订单失败伤害了留存"都不是——前者我没看趋势，后者是假设。
• 假设：对事实的解释。可以有多个，并列写出来，不要急着选定一个。
• 证据：能区分假设的信息。口径、维度拆解、对照，都是证据。
• 决策：基于证据选动作，包括"暂不处理"和"先去补数据"。
• 验证：决策之后，用什么信号确认做对了。

拿订单失败的例子走一遍，大概是这样：事实是"后台展示的订单创建失败数量"——注意，只是一个展示数字，不含趋势；假设可以并列写出好几个——真实失败偏多、统计口径和我理解的不一致、重复重试放大了计数、上报链路出了问题；证据是下一步去确认分子分母、阶段和去重逻辑；决策可能是"先补口径再评估"，也可能是"暂不处理"；验证则是明确下一次看什么信号来确认这个决策没错。

这个框架不新，很多方法论里都有它的影子。但对开发来说，真正难的是前两步：我们太习惯把"看到的现象"直接当事实，把"第一个能解释通的故事"直接当结论。

开发者的优势和惯性

练习中我也盘点了一下自己带过来的东西。

优势是真实的：

• 对链路和系统边界熟，知道数据在哪产生、在哪可能丢；
• 习惯结构化表达，拆解问题接近肌肉记忆；
• 对实现成本有直觉，评估方案时不容易画饼。

惯性也是真实的：

• 看到异常，第一反应是"修"，而不是"先确认它有多大、影响谁"；
• 容易把第一个自洽的解释当结论。工程问题通常有更快的反馈：类型、测试、日志会很快告诉你想错了；业务判断的反馈慢得多，口径也更隐蔽，自洽在这里只是入场券；
• 习惯拿到确定答案再动手，但业务侧经常要在信息不全时先给方向，再用验证收口。

这些惯性不算缺点，在工程场景里它们都是优点。问题是业务判断换了一套规则，同一套反射弧会帮倒忙。我自己在这次练习里三条全中：第一次差点直接把失败问题排到最高，第二次把第一个自洽的解释当成结论，第三次差点带着错概念走完整个分析。

接下来

这组练习还在继续，我也不确定它最后会把我带到哪。能确定的是，这三次修正让我对"判断"这件事比以前谨慎了一点：谨慎不等于慢，而是知道哪些环节最容易自欺，然后在那些环节上多花一分钟。

我把过程沉淀成了一份可以反复填写的产品思维练习手册，里面有只读安全边界、口径核对清单、优先级检查、根因维度、决策日志和复盘模板。它目前还很薄，打算每次练习后往里补一点。

如果你也是开发、也想练这个，我的建议只有一条：找一个真实的业务问题，忍住不立刻下结论、不急着把它写进需求，先把口径问清楚。第一次忍住的感觉很别扭，但值得。