产品决策

哪些错误码可以重试：一份带具体参数和预算公式的 SDK 重试决策清单 «结论先行："这个错误码能不能重试"不是一个网络问题，而是一个产品语义问题。同一个 504，对"查询订单"是安全的，对"创建订单"可能就是重复扣款。我 5 年技术 PM

B 端 SaaS 样本量跑不够 A/B：从"拍脑袋全量"到贝叶斯决策 + 序贯停止的 4 场景实战 «一句话结论：当你的用户基数小到一个 A/B 实验跑 3 个月都攒不够 2 个标准差时，"等显著"和"看 p 值"都是伪命题。正确的姿势不是

B 端 SaaS 功能下线：我管过 7 个模块退役，3 次客户投诉、1 次 38 万流失——产品决策视角的 5 步下线清单 一、现象与背景：「删一个没人用的功能」为什么比上线难 5 倍 先交代规模。我做了 15 年技术 PM，近两年带一个

背景 做了 15 年技术产品，签 B 端合同签多了之后，我发现 SLA 里最容易被忽视、但一出事就炸的条款，不是"可用性 99.9%"那个百分比，而是**"故障时长"怎么算**。 上个月刚处理完一个真实案例：客户投诉"你们系统昨天下午挂了

背景 做了 15 年技术产品，我越来越觉得一个矛盾：工程师的本能是「fail fast、大声报错」，产品的本能是「别吓到用户、能兜就兜」。两边都没错，可一旦同一个功能里两种哲学打架，就特别容易出两种事故—— - 一种是「用户不知道出错了，但

背景 做了 15 年算法，近 8 年重心在数据分析与指标体系上，经手或评审过的 AB 实验不下 200 个。最近半年我越来越频繁地遇到同一个场景：业务方拿着一个"看起来挺有道理"的改动，第一句话就是"我们做个 AB 实验吧"。我通常会先反问

背景： 我做了 8 年技术产品经理，带过 3 个 0→1 的项目。每次排期会上，"先上 MVP 快速验证" 和 "干脆一次做扎实别返工" 这两派都会吵起来。有意思的是，同一个团队、同一个功能，最后选哪边，往往不取决于功能本身，而取决于当下面

先说背景，免得大家各说各话。 我做了 5 年技术产品，近两年大部分精力花在 AI 智能体（Agent）类产品上。团队内部吵得最凶的一个决策，不是「用哪家模型」，而是下面这个：到底是把少数几个场景做到 90 分以上（高确定性），还是先把 20