标准产品还是定制化？B端产品经理怎么判断

B端产品经理常被客户口中的“小需求”拖入定制泥潭。本文提出五问判断法，教你区分标准产品、配置能力、扩展机制与项目定制，将定制化转化为产品价值，而非技术债。

———— / BEGIN / ————

做B端产品，永远绕不开的一个需求就是：“这个客户很重要，需求也不复杂，就稍微定制一下。”

然后，就在这么点“稍微”中，项目逐渐失控。

一开始可能真的只是加一个字段。

做着做着，变成这个字段要单独走一套审批流程，审批完成后要生成一张特殊报表，报表只能给某几个角色看，还要和客户原来的财务系统对接。

最后，所谓的“稍微定制一下”，成功膨胀成了一个独立项目。

所以有时候，客户嘴里的“小需求”，就跟领导嘴里的“简单优化”差不多。听上去只有四个字，做起来可能就是一个季度。

这个时候，产品经理就成了夹心饼干。

售前说，大客户不能得罪。

项目经理说，合同都签了，不做怎么验收？

研发说，再这么改下去，我都不知道标准产品长什么样儿了。

行吧，每个人都有道理。

但产品经理不能说大家都有道理，那我负责把几方意见转述一遍，最后等领导拍板。相信我，领导会毫不犹豫地反问你说：那我招你干嘛？

所以，产品经理真正要判断的是：这个需求到底应该进入标准产品，做成配置能力，留给扩展机制，还是纯项目定制？

一、B端产品，本来就不可能完全没有定制

过去几年，在讨论用友、金蝶这些国内头部SaaS企业经营压力的时候，很多人会把原因归结为：大客户太多、项目太重、定制化太多。

于是一个很自然的结论是，想提高利润，就要压缩定制项目，尽量把所有客户都赶进标准产品里。

这个判断不能说错，但只说对了一半。

定制化确实很容易拉高交付和维护成本。一个客户一个版本，一套代码几十个分支，后面升级一次像拆一次炸弹，研发看了沉默，实施看了流泪。

但B端产品面对的，本来就是不同的组织。

企业规模不同，管理制度不同，组织架构不同，审批权限不同，使用的软件不同。到了G端，还有地方政策、监管口径和数据标准的差异。哪怕是公司内部自研系统，不同事业部也能把同一个流程走出几种花样。

所以无论是SaaS、私有化部署、G端项目，还是企业内部系统，都不可能靠一套完全固定的产品解决所有问题。

我以前也会本能地抗拒定制需求，觉得标准化才是产品，定制化只是项目妥协。

后来项目做多了，我会慢慢觉得，定制化不是标准产品的敌人，两者不需要你死我活。

真正的问题，不是“有没有定制”，而是团队有没有能力管理差异。

做得差的定制，会拖垮产品；做得好的定制，反而是产品理解行业、验证场景和生长能力的重要来源。

二、真正应该压缩的，是低质量定制

什么叫低质量定制？

客户提一个需求，产品不分析，项目不核价，研发直接在原有代码上开分支。做完只服务一家客户，不能复用；下次产品升级还要单独适配；负责这个项目的人一离职，后来的人连为什么这么设计都说不清楚，留下一堆技术债。

这种定制当然越少越好。

因为它只产生了一次性交付收入，却留下了长期维护成本。

但还有一些定制，表面上是某个客户先提出来的，背后其实是一个行业的共同问题。

比如一家大型集团提出，不同金额、不同费用类型要走不同的审批层级。

如果产品直接给它写死一套流程，这是项目定制。

如果继续往下分析，发现真正变化的是审批条件、节点和人员范围，那么就可以把它设计成流程配置能力。以后其他客户调整审批制度，不需要重新开发，管理员自己配置就行。

同一个需求，处理方式不同，最后形成的价值完全不同。

所以，真正应该压缩的，不是定制化本身，而是那些没有抽象、没有边界、没有合理定价，也无法沉淀成产品能力的低质量定制。

三、一个需求来了，到底怎么判断？

我通常会先问五个问题。

第一个问题：这是一个客户的特殊动作，还是一类客户的共同问题？

不要只看有多少客户提过。

有些需求只有一个客户提出，是因为它走得更快，先暴露了行业问题；有些需求很多客户都提，是因为某个页面确实难用，但并不代表它值得进入产品主干。

产品经理要找的是需求背后稳定存在的业务场景。

第二个问题：它和产品本身的核心定位一致吗？

一个报销产品增加预算控制、审批和付款能力，是围绕费用管理继续生态扩展。

但如果客户要求顺便做一套完整的人事绩效系统，哪怕客户愿意付钱，也要慎重。

不是能做的都要做，产品边界就是这样一点点被“顺便”吃掉的。

第三个问题：变化的是业务目标，还是实现规则？

不同公司报销制度看起来差异很大，但核心目标通常没变：员工提交费用，组织完成审核，财务完成付款和留痕。

变化的往往是额度、字段、审批层级、票据要求和角色权限。

目标稳定、规则变化，适合做成配置；目标本身都不同，就不要硬塞进同一个模型里。

第四个问题：这个变化能不能被隔离？

有些客户需要对接自己的财务软件、银行或者政务平台，这类需求未必适合进入标准功能，但可以通过API、插件或适配器完成。

只要扩展边界清楚，客户的特殊性就不会污染核心产品。

第五个问题：这笔账，真的算完整了吗？

定制成本从来不只是当期开发的二十个人日。

后续测试、部署、培训、运维、版本升级、人员交接都要算。做完以后由谁维护，产品升级时谁适配，客户愿意为特殊性付多少钱，也要提前说清楚。

只算开发成本，不算生命周期成本，是很多定制项目看起来赚钱、最后越做越亏的原因。

问完这五个问题，一个需求通常会有五种去向：进入标准产品、沉淀为配置能力、通过扩展机制实现、保留为项目定制，或者直接拒绝。

四、怎么把定制化也做出产品价值？

判断做不做只是第一步，更重要的是怎么设计。

还是拿报销系统来说。

员工填单、提交，审批人处理，财务复核、付款，这些是相对稳定的主流程，应该放进产品核心。

报销类型、金额上限、审批条件、字段是否必填、不同角色看哪些数据，这些是有规律的变化，适合做成配置能力。

和ERP、财务软件、银行系统的对接，每家都可能不一样，可以放进开放接口和适配层。

某家客户短期内确实存在非常特殊、又无法抽象的要求，只要不破坏主干，也算清了成本，可以留在项目层解决。

至于完全偏离产品方向、投入产出明显不成立的需求，该拒绝还是要拒绝。

这样做的价值，是把客户差异放到合适的位置。

稳定的东西进入核心产品，重复变化的东西做成配置，外部差异交给扩展机制，真正一次性的需求留在项目里。

这里还有一点很重要：不要把定制项目只当成交付任务。

大客户和G端项目愿意花钱把复杂问题摆到你面前，本质上也在帮产品做一次付费的行业调研。

产品经理应该在交付后继续复盘：这个需求里哪些是客户自己的管理习惯，哪些代表行业规则，哪些能力值得进入后续版本。

如果一个定制项目做完，只留下了一套客户代码，那它的价值确实有限。

但如果它帮团队验证了一个行业场景，沉淀出配置项、接口规范、业务模板，甚至形成新的产品模块，那这次定制就不只是赚了一笔项目费，也是在给标准产品铺路。

最后

标准产品和客户定制，从来不是非黑即白的选择。

标准化让产品能够复制，定制化让产品能够落地。B端产品经理要做的，不是坚定地站在某一边，而是守住核心产品的边界，同时给真实世界的差异留下合理出口。

一味接受定制，产品迟早会被拖成项目集合；一味拒绝定制，产品也可能永远停在一套自以为标准、实际没人能用的方案里。

压缩定制项目，只能暂时降低成本。

把定制化做出产品价值，才是真正的产品能力。

本文来自公众号：简谙 作者：简谙