如何从 0 到 1 设计 B 端产品？
这是一个非常好的 B 端产品入门问题。我们先从 C 端产品与 B 端产品的区别说起。理解了区别之后，再用一个我实际经历的产品搭建案例，给大家逐一讲解 B 端产品从 0 到 1 的设计搭建过程。欢迎加入 B 端产品经理的行列。
一. 人的区别：C 端与 B 端产品经理的区别
我用大家日常都会用到的电商网站来举例，在电商网站，C 端和 B 端关注的点分别有什么区别？
1. To C 关注用户行为，To B 关注业务逻辑
当用户下单时，潜藏在冰山之下的 B 端系统做出连锁反应
客服响应（客服系统）
生成订单（订单系统管理）
进行支付（支付渠道与平台财务系统联动）
减库存（仓储系统）
发货（物流系统）
C 端产品经理关注以用户为核心的动作指标
关注落地跳出率，详情页停留时间，加购率，付款率等等，以用户行为为核心的指标，再根据数据指标进行产品的改进产品体验，核心指标转化，用户留存增长。
B 端产品经理关注业务逻辑
关注客服响应逻辑、订单逻辑、支付逻辑、库存逻辑、物流逻辑，这些业务逻辑分别对应着客服系统，订单系统，财务系统，仓储系统，物流系统。
而这些系统之间是动态关联的，产品经理在设计产品时，要搞清楚上下游系统对当前设计的系统的影响，需要产品全局思维的同时，对公司各业务非常熟悉。
2. C 端产品经理本身就是使用者，B 端产品经理需要大量调研
还是上面电商平台的例子中，我们每个人都是电商平台的使用者，对在网站上购买商品的流程轻车熟路，所以对于 C 端产品来说，没有理解使用场景和逻辑的障碍，只需要专注在核心指标的改进即可。
但对于 B 端产品来说，设计搭建的每一个内部系统都对应着一群专业的业务人员及业务逻辑。如果不深入研究和实践，是无法做出好的 B 端产品的。
如果产品经理接到财务部门的需求，要搭建一套「多支付渠道对账系统」，这种需求对于新人来说，他们甚至不知道对账系统是做什么的，更是无从下手。
那么，当我们拿到一个超出我们经验范围的需求时，作为 B 端产品经理，我们要怎么做呢？
接下来我来讲讲 B 端产品的本质 —— 从业务逻辑出发，解决实际问题。
二. 产品的区别：从业务逻辑出发，解决实际问题
与 To C 的产品不同，To B 的产品一定从业务逻辑出发，解决具体问题。而这些业务问题，其实自古有之，只是承载这些问题的载体在变化。
我们用电商平台的财务系统举例，电商系统的本质其实就是「纸质账本（数据库）+一支笔（增删改查）」
纸质账本：在没有计算机之前，我们还在使用纸质账本记账时，业务逻辑非常简单，只要是采购、付租金、付工资等，就在账本上记上支出，做减法。只要是卖出商品、店铺收租等，就在账本上记上收入，做加法。这就是早期的电商财务系统，就算升级到现在复杂的系统，也只不过是这种增减的拓展，本质没有变化。
Excel（纯数据库）与电商系统（UI 可视化+数据库）：Excel 出现后，我们把账本挪到 Excel 上，开始可以构建复杂的计算逻辑，逻辑只要稍微复杂，就需要写大量的脚本公式，学习成本非常高。这之后，出现了有 UI 界面，可交互的财务系统，对于不懂技术的财务人员也可以通过点点鼠标完成复杂的财务工作流。
不论载体怎么变化，我们基本的业务逻辑没有变化，我们面对的问题也没有变化。记账还是支出，收入。对账还是第三方帐与内部账核对。只不过曾经是账房先生用毛笔记在纸质账本上，现在是全自动化计算机，记在硬盘里。本质没有任何变化。（关于 To B 产品本质，看这篇「如何设计出色的后台原型」中有讨论，这里就不展开了）
所以，B 端产品经理即要理解业务逻辑（账房先生 / 财务部）也要充分理解技术边界（纸质账本和毛笔 / 技术部），做业务与技术的桥梁，将业务逻辑转化为产品需求，将业务问题用技术手段自动化解决。抓住这个 To B 产品的核心本质，再来看 从 0 到 1 搭建 B 端产品就更好理解了。
三. 从 0 到 1 搭建 B 端产品
如前文所述，B 端产品经理以业务逻辑为核心，To B 产品以解决实际问题为核心。明白这两点之后，我们来谈谈 B 端产品的设计搭建过程。
一般 B 端产品搭建分为三个步骤，1.调研问题，2.设计解决，3.实施迭代。我们「如何搭建财务对账系统」的实例来举例说明，如何从 0 到 1 搭建 B 端产品。
1.调研问题
正如我们第一节谈到的，B 端产品经理相对于 C 端产品经理尴尬的地方是我们本身并不是产品的使用者，这使得我们在第一次面对不熟悉领域的业务需求（财务对账）时，一头雾水。怎么办呢？去实践。
轮岗实习
拿到这个需求后，我们首先要争取去财务部轮岗实习，先体验一下，在没有这套对账系统时，财务部是如何手动处理或半自动处理对账需求的，了解对账系统上下游信息链是怎样的，涉及到哪些周边系统。如果项目时间比较充裕，轮岗实习非常非常必要，在轮岗实习期间一定要做到比业务侧领导更了解业务细节，比业务员更了解业务侧未来宏观走向。
只有比业务更懂业务才能设计出优秀的 B 端产品。
业务访谈
如果没有条件轮岗，我们也可以先去调研理论信息，了解基本情况后，写采访大纲，深入的去与财务部业务人员做需求访谈。
我们应该先从财务部的领导层开始，从宏观到微观的视角观察让我们不至于一开始就陷入细枝末节中。
比如我们在访谈财务部高层领导时，可以询问远期规划，当前对账系统虽然只需要对「支付宝和微信」，但公司远期有没有计划引入国有银行支付、或国际支付 paypal 等。这使得我们能站在全局设计对账系统，有些暂时不需要的功能，我们也可以预留接口，方便后续公司业务发展升级时，快速开发。
接着访谈中层领导，站在中层领导的角度，各业务人员如何使用这套系统，整个财务的业务流程是怎样的，财务信息是怎么从上游流入财务系统，需要怎样的处理，接着，这些信息又流入的下游系统是什么？业务之间是否可以互相查看数据，权限系统应该怎么设计等问题。（权限系统搭建看这篇）
最后是各个业务模块具体执行的操作者，他们当下碰到什么问题，这些问题可以自动化处理吗？如果不能，为什么呢？比如对账系统典型的跨日交易（订单生成在当天 23:59，但支付信息却在次日 00:01）应该怎么处理，这种细节问题，如果不去实际调研，是无法坐在电脑前拍脑袋想出来的。
2.设计解决
当我们轮岗实习/业务访谈做完之后，对整个业务有了地毯式的了解，并深入理解当前业务碰到的问题，接着我们根据业务逻辑先把流程图画出来，接着我们再来思考如何解决当前发现的问题，每个问题应该放在整个业务流程中的哪一步来解决。
调研问题总结
支付宝/微信对账单无法自动抓取，目前为手动下载 CSV，在 Excel 中与内部账进行对比
第三方支付渠道的账单字段与本地财务系统字段不一致，无法直接对比
对账长短账问题，系统何时需要自动挂起问题账单，进入人工处理模块
跨日问题的自动化处理逻辑
未来可能会增加更多的第三方支付渠道
解决方案
与技术讨论，调用第三方渠道 API 抓取对账文件的难度（高优先级）
研究第三方对账文件，将字段统一起来，寻找技术自动化方法（高优先级）
对于两边账无法对平的情况，转入人工处理（中优先级）
跨日问题自动处理（低优先级）
设计多支付渠道接口逻辑（低优先级）
公司的资源是有限的，我们必须集中火力在短时间内解决能提升最大效率的问题，设为高优先级，其他问题我们可以放在第二期，第三期再来解决。
在当前例子中，自动化第三方账单抓取、自动化对账相对于其他问题来说，更重要，只要解决就能帮助业务侧极大提升工作效率，那么我们就把这种需求放在第一期中来解决。
3.实施迭代
大家还记得我们本文第二点提到的「纸质账本到财务系统」的升级过程吗？在从纸质账本到财务系统之间的的升级变化是承载信息的介质的变化，但业务逻辑的本质并没有发生变化。
所以在实施搭建设计时，我们可以沿业务侧使用者的工作流来设计系统，根据信息在对账系统中流入、处理、流出的业务流程来设计系统。
这时候，如果你懂技术，知道技术的能力边界，那么就能快速设计出一套高效又能快速被实现的 B 端产品（关于「产品经理需要懂技术吗？」这篇有讨论），然后设计好原型图，就可以与技术对接，进行具体的产品开发与实施。
对账系统第一期上线后，我们要马不停蹄的前往业务侧，快速收集使用反馈，对粗糙的第一期产品进行产品迭代，同时思考第二期产品功能，如何在适当的时间加入开发排期。如此往复迭代，最终设计出帮助业务侧提升效率，节省时间的优秀内部系统。（「如何设计对财务对账系统」里面有本案例详细的设计逻辑，有兴趣可以看看）
总结一下
调研业务侧，比业务更懂业务，发现业务逻辑中待解决的问题。
寻找解决方法，设计解决方案，顺着业务逻辑设计产品。
上线测试，发现新问题，解决问题，保持迭代。
至此，我们从 0 到 1 设计搭建了一整套 To B 产品，希望对你有所帮助，评论区一起讨论。其实整个产品设计搭建过程如果展开写，可以写非常细，这里限于篇幅，写的比较宏观粗浅，大家先有个整体印象。之后我会针对设计流程中的细节，展开详写，欢迎持续关注。
四. 扩展阅读
本文作者
蒋川，卡拉云联合创始人，B 端产品经理，专注研究企业内部效率工具实施搭建。
个人微信：HiJiangChuan，欢迎一起交流。
卡拉云面向产品与技术的企业内部工具开发平台，只要会写 SQL，即可快速上手。
如果本文对你有帮助，想了解更多，欢迎访问我们的网站「卡拉云」
版权声明: 本文为 InfoQ 作者【蒋川】的原创文章。
原文链接:【http://xie.infoq.cn/article/208410f434c743b240dc76085】。
本文遵守【CC BY-NC】协议，转载请保留原文出处及本版权声明。
我的微信：HiJiangChuan 2020.09.08 加入
卡拉云 CMO 卡拉云是一套帮助后端程序员搭建企业内部工具的系统，欢迎试用 www.kalacloud.com
评论