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

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

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

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

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

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

01 考虑系统边界

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

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

02 考虑系统承载能力

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

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

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

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

04 考虑极端和异常

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

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

05 考虑基础功能

为什么会想到这一点呢？

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

这三个例子，风控、权限、审核都是大多数场景必备的功能，特别容易因为太常见而被忽视，或者产品经理理所当然认为开发会直接做而没有在需求中单独说明造成功能缺失。

所以，建议基础功能在需求文档中不一定详细描述，但一定要提，哪怕只有一句话。

06 考虑生产问题处理机制

生产问题无法避免，背锅是其次，首要动作应该是及时止损并修复。建立一套完善的生产问题处理机制可以管理产品质量、提高工作效率。

例如一般出现重大问题时，可以撤出优先级低的需求，释放人力解决问题；小故障，则由产品决策，是否纳入下期版本的优化需求中。

有的团队，为了不影响已排期需求的开发进度，会安排专人处理生产问题，但生产问题处理者会花费大量时间熟知所有功能逻辑，等等。

总之出现问题时，具体走什么流程处理，是产品经理应该熟知的。

以上都属于经验之谈，还有一些会陆续发出，欢迎订阅。如果不妥，请指正，感谢。

本文由 @Holly 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。