B端产品经理，除了可以学习C端的产品思维方法外，还需要不断的从实践中总结

因为之前做过一年手机ROM产品经理（偏C端交互）、两年系统产品经理，近期面试时，经常会被问做B端和C端产品经理有什么不同。

个人看来，B端和C端的产品思维有一定共性，例如都是从用户痛点出发，以解决问题为目的。

最大的差异在于，C端用户相对感性，产品更注重极致的用户体验；B端则相对理性，更强调如何围绕业务场景和机制去高效的服务企业。

作为B端产品经理，除了可以学习C端的产品思维方法外，还需要不断的从实践中总结，形成体系，便于适应不同的业务环境。

通过两年的系统搭建，我从经验中总结了一系列套路，本文先分享B端产品提需求时，应该考虑的几个点，可以保证更高质量的需求和更高效的沟通。

01 考虑系统边界

企业内部系统可能成百上千，各司其职。B端产品经理，务必熟知系统架构，了解各系统的功能及范围，有助于快速输出解决方案，将需求提交正确的关联方。

例如功能评审时，开发方可能会互相推诿，以不应该本系统承接此业务为由拒绝需求，如果你不清楚各系统的功能边界，很难快速决策，从而影响需求进度。当然少数情况下，可以求助系统架构师。

02 考虑系统承载能力

提需求时，开发最关注的点之一就是数据量或者接口调用量。通常会让产品经理估算业务量大小，例如参加某次活动的用户峰值，从而评估并发时，系统的承载能力，如不能承载，则会考虑更优的技术解决方案。这也是为什么B端产品经理要求对数据足够敏感的原因之一。

03 考虑功能的灵活性和可扩展性

和C端一样，功能的配置项一定不能写死，以免紧急情况下无法快速发版更改。在对以下三种功能进行规划时特别需要注意：

1. 后台的页面配置项（文字、图片、链接等），支持扩展；
2. 数据接口、数据存储表格，预留字段；
3. 同一场景，多套规则并行使用时，配置开关。

04 考虑极端和异常

之前听人说过 “一句话的需求谁都会提，而产品经理需要全面考虑各极端或异常场景下应该如何处理”，如果前期没有想清楚，后续的需求评审、开发、甚至测试过程中，会有各种问题找你解决，极大的增加沟通成本。

例如：当个性化规则都无法生效时，是否存在通用规则兜底；当数据量超过一定阈值时，是否需要预警机制；当关联方系统异常时，是否设置数据缓存；当运营操作失误造成生产问题时，是否有功能支持快速补救等等。

05 考虑基础功能

为什么会想到这一点呢？

我遇到过别的功能，因未接风控系统，发放权益后被薅羊毛，造成巨大损失；因未接入审核，功能上线后不能直接使用；因未考虑数据权限，造成部门间信息泄露的。