标签频道
B端SaaS
该标签下的文章、提问与讨论帖。
【背景】 我做了 8 年 B 端 SaaS 技术 PM，最近立项一个「客户健康分预警」功能：基于客户使用频次、功能覆盖、工单情绪、续费周期算 0-100 分，低于阈值就在客户成功工作台弹预警，提示 CSM 介入。团队 2 后端 + 1 数据
【背景】 我做了 15 年技术文档，近五年帮多个 B 端 SaaS 团队搭指标体系和数据看板。最近帮一个 20 人数据团队（服务 40+ 企业客户）处理了一次口径变更：「月活跃租户」从"当月有任意 API 调用"改成"当月有 ≥3 次核心
«本文从一个 B 端 SaaS 技术 PM 的真实项目出发，把"批量操作"这个看起来"不就是个循环"的功能，拆成 7 条可执行的产品设计红线。每条红线都带一个真实翻车案例和具体参数，不是"要处理好失败"这种正确而无用的废话。» 一、现象与背
B 端 SaaS 样本量跑不够 A/B：从"拍脑袋全量"到贝叶斯决策 + 序贯停止的 4 场景实战 «一句话结论：当你的用户基数小到一个 A/B 实验跑 3 个月都攒不够 2 个标准差时，"等显著"和"看 p 值"都是伪命题。正确的姿势不是
«结论先行：「调用次数多 = 功能重要」是一个看起来对、实际上会杀错人的判据。我 3 年做 B 端 SaaS 技术 PM，2024 Q1 到 2025 Q2 复盘了 12 次功能下线决策，其中 5 次（42%）上线后 60 天内被部分回滚或
B 端 SaaS 功能下线：我管过 7 个模块退役，3 次客户投诉、1 次 38 万流失——产品决策视角的 5 步下线清单 一、现象与背景：「删一个没人用的功能」为什么比上线难 5 倍 先交代规模。我做了 15 年技术 PM，近两年带一个
【背景】 我做了 8 年 B 端 SaaS 技术 PM，最近立项一个「客户健康分预警」功能：基于客户使用频次、功能覆盖、工单情绪、续费周期算 0-100 分，低于阈值就在客户成功工作台弹预警，提示 CSM 介入。团队 2 后端 + 1 数据
背景 10 年技术 PM，目前在带一个 B 端 SaaS 的订单 + 结算模块。架构上是一个 Java 17 无状态服务（4 副本，每副本 4C/8G），200+ 租户共享同一个 HikariCP 连接池（maximumPoolSize=5
别急着"加个字段就行"：一次 B 端 API 向后兼容变更如何吃掉 3 个迭代和 2 次 P2，以及我的 5 步兼容性检查清单 一、现象与背景：一个"加字段"的变更，为什么变成了 3 个迭代的噩梦 先上一组数字。我们是一个 B 端 SaaS
【背景】 React 18 + TypeScript 5 + Vite 5 的 B 端审批 SaaS，核心表单有 12 个字段组、约 80 个输入控件。从 session 埋点看，用户平均停留 12 min，P95 达 43 min（复杂审
背景 我做了 15 年技术 PM，主做 B 端 SaaS。最近一条「按调用量计费」的核心链路要重新设计计量窗口，我卡在"粒度"这一步，三个数字摆在一起没法拍板： - 客户数：约 120 个，头部 5 个客户贡献 78% 的调用量 - 调用量
【背景】 我做了 10 年技术 PM，主做 B 端 SaaS。最近一个季度，"配置化"这个词在需求评审会上出现的频率高到让我有点生理不适——业务方说"能不能配置化一下"，研发说"可以做但要 2 周"，我夹在中间既没法说"对，做"也没法说"对
【背景】 我做了 8 年 B 端 SaaS 技术 PM，最近立项一个「客户健康分预警」功能：基于客户的使用频次、功能覆盖、工单情绪、续费周期等信号，给每个客户算一个 0-100 的健康分，低于阈值就在客户成功工作台弹预警，提示 CSM 介入
背景 我做了 15 年技术 PM，近两年带一个 8 人后端团队做 B 端 SaaS，期间立项了 4 个 LLM 功能：智能摘要、对话式搜索、客服工单改写、文档问答。立项评审都过了、都上线了，但上线 3 个月内的周活跃使用率全部低于 10%，
【背景】 我做 B 端 SaaS 产品 8 年，最近一个季度在排期评审上反复撞同一个墙：业务方（销售 + 客户成功）压一个"必须下周上线"的功能，研发评估说"直接加会引入 3 个服务的改动，P99 会变差，建议先花 2-3 周做一次小重构，
背景 我做了 15 年技术 PM，最擅长把复杂原理讲成大白话，但有一个场景我至今没有一套稳定可复用的方法：向非技术背景的业务负责人（VP / 客户方）解释"看起来很小、其实代价很大"的需求。 典型场景：业务方拍桌子说"就在订单页加个备注字段
【背景】 我做了 5 年技术 PM，最近一个季度反复撞同一个坑：我们按正常流程排期上线了一个 B 端功能（面向中台运营的配置化审批流），上线前做了用户访谈，5 个种子用户都说"很需要"。上线 6 周后看数据：功能使用率不到 4%，核心指标（
背景 10 年技术 PM，最近带一个 B 端 SaaS 的订单 + 库存模块，团队 7 人（3 后端 + 2 前端 + 1 测试 + 我）。反复撞到一个结构性拉锯： happy path 我写得很细（字段、交互、跳转），但异常态（断网、超时
文
标题
摘要