业务型产品就是由具体的业务实现主要盈利，不只是互联网+，更重要的是业务的发展。笔者以电商产品为例，为我们分析了业务产品是什么、如何设计以及业务产品经理应该如何做？
业务系统如何设计和优化？
现在互联网分产品类型主要来分是to B或者to C，主要区分纬度是使用的用户。如果用户是属于消费者、个人用户则一般称为2C，如微信、网易云音乐、抖音等等；如果用户是商家、企业内部人员则称为2B，如CRM、 OA系统、商家管理后台等等。
但其实我们所能看到和常用的C端产品，背后都有着诸多的B端系统在做服务支持。就拿一个成熟的电商app产品来说，用户在客户端能够看到商品且能够购买，就需要涉及诸多系统提供服务。
你能打开app看到商品信息，首先需要供应链系统上架商品数据；商品中心系统提供商品图、商品标题、类目信息；价格系统提供价格；寻源系统提供库存；促销系统券信息。
开始下单购买，还需要会员中台校验登陆；风控系统校验风控；寻源锁定库存；订单中心计算价格，订单信息下发物流系统；物流调度配送等等。如果需要搜索订单，还要搜索提供服务；配置活动还需要cms系统；支持商户售卖商品，还有商家后台系统。
当产生退货，刚刚的正向涉及支付链路的系统还要走一遍逆向链路系统。
因为各公司的业务复杂程度不同，系统架构切分可能不同，但电商链路系统划分大同小异。其中每个大系统背后又有很多个功能和系统进行拓展堆叠，用来支撑着电商前台app下单购买和退货服务。
所以当有一种新的商品类型需要上线，就会涉及电商链路诸多系统。上架一种商品类型的需求，往往就涉及上百人的产品项目。
我们聊业务产品设计，就聊下稍微了解的电商系统吧，因为电商链路算是最复杂的业务系统了。虽然链路中各系统定位和侧重点都不一样，但产品设计思路还是互通的。现在就谈下业务系统产品设计。
在谈产品设计之前，要先聊下产品本身。一个产品重要的是盈利，我更偏向从商业模式上去区分我们所能常见的产品。
它主要分为业务型产品和工具型产品。业务型产品就是由具体的业务实现主要盈利，不只是互联网+，更重要的是业务的发展；工具类的主要是互联网类的营收，比如广告、付费增值、游戏。
电商就是明显的业务型产品（业务产品可以由B端和C端组成）。电商系统的建设和优化，不外乎两个根本目标：提高收入和降低成本。
提升收入可以在面向顾客的C端产品，而B端系统的建设和优化目标一般来说更多是为了支撑和拓展业务的发展，提升效率，减少成本。
B端系统支撑和拓展业务的发展，这个目标很关键，因为很大程度影响了团队产品设计流程，方法论也会跟工具型产品有所区别。下面所说的业务产品，也指代B端系统。
根据公司的职能架构划分，一般来说会分业务方和研发方。
业务方会有负责具体业务的人来落实业务的运营，背负指标和KPI，如采销、市场、运营。而研发方更多的是去建设和优化系统来解决业务方所遇到的问题，支撑业务的发展。
业务产品的需求的来源一般会有这么几个方面：运营（业务）、用户、领导、数据。
运营提出日常运营的一些问题，进而提出系统优化需求。
用户在使用过程中提出疑问或者产品使用遇到的异常反馈。
领导决策出某些项目需要落实。
数据驱动，通过数据上线后的反馈，洞察存在问题以及需要优化的功能。
因为一般是运营发现了业务问题，想要通过系统改善，这也是研发方产品经理的主要日常需求来源。所以就会往往有产品经理们疑惑，感觉是被运营带着节奏走。也会见到关于业务驱动还是产品驱动的讨论。
其实这种职能切分由公司决定的，至于为什么这么划分也不好去深究了。但产品经理可以发挥自己的主观能动性去影响业务，不要把自己当成需求接收的被动方，可以通过产品经理的思考引导业务方向。
比如说当接收到运营提出的需求，产品经理可以去分析需求的合理性和需求的价值，不是所有运营同事提出的需求都要满足，产品经理必须要有自己的思考。
一般来说，需求大多数是为了上线新业务或者当前业务遇到什么问题需要解决。
产品经理可以结合具体需求分析，需求分析三板斧：场景、用户、价值。
具体需求具体场景分析，不过都是围绕这三个维度去考虑，以前聊过需求分析，这里就不拓展了。但是提一下需求分析的前提，如何评估运营提出的需求是否能解决问题？评估需求价值能否达到预期量化目标？
了解业务才能知道问题所在以及有自己的判断，才能知道运营同事提出的需求是否能够解决问题而不会产生更大的问题，才能知道需求的价值而不被运营同事晃点。
对于任何一款业务产品来讲，流程是否完善形成闭环是业务运行的基础，产品经理需要了解业务，梳理流程时候才不会遗漏。
在梳理业务流程时，一方面需要审视当前业务流的合理性和优化点，另一方面需要考虑未来业务的发展和走向。只有真正深入业务才能更好地给出产品解决方案。
在了解业务之外，还要产品经理需要增加对数据的关注度。数据能够体现当前业务的问题，以及更好地辅助产品能够决策。权衡需求的价值也需要对价值进行量化，后续能够通过数据进行复盘。
抛出之前有朋友留言问到，如何拒绝运营提的不合理的需求？运营有时候会说是大老板拍板决策的，让人无力反驳。
首先，需要判断这个需求的合理性，也就是需求的价值。
因为一个业务需求往往需要牵涉到很多个系统共通完成，需求价值分析不能只是站在自己小范围角度去评判。当研发资源部足时，具体可以通过量化指标衡量，或者通过已有的上线数据分析，通过数据给出结论，证明需求的价值。
通过产品主观能动性去引导运营同事。若是分析出有更好的解决方案，运营同事也只是想业务发展得更好，可以跟业务共通沟通更换好的解决方案。
其次，如果大老板之所以拍板决定，肯定是权衡各方利弊以后决定。大老板的认知、思考点、信息面要远比底下干活的产品经理厉害。
如果你还不是参与决策层，那大多数思考的面很窄，评判不出价值。说到极端些，作为员工或者其他身份的人，最重要的是做好自己位置的事情。作为员工就是要将老板的命令执行好。
就像当年刘强东决定做自建物流，有位高管起来反对，刘强东说到：我请你来不是证明我的决策是错误的，我请你来是把我的决策落实到位、执行到位！如果有困难，你要想办法如何完成。一周后高管的位置换成了其他人。
相反，蚂蚁金服董事长彭蕾说过一句话：无论马云的决定是什么，我的任务是帮助这个决定成为最正确的决定。
四、业务系统如何设计和优化？
接收到业务需求，在已经分析需求价值后，到了具体产品规划设计阶段了。设计产品方案之前，必须要理解业务现状与发展，考虑如何结合现有系统改造和优化。
对于具体业务产品设计，可以有这么几个步骤：梳理流程、梳理架构、撰写需求。
1. 梳理流程
这个很好理解。把运营的需求和方案梳理成流程图，通过流程图去理解需求的边界性，考虑业务的异常流程以及系统异常流程，提出解决方案能够让流程形成闭环，确保功能的有效性。
2. 梳理架构
一般复杂业务产品都需要很多系统进行支持提供服务。梳理业务流程结束后就需要抽象系统模型（即输出系统流程）。而对应这些功能逻辑和数据，由哪些系统提供，这就是涉及系统架构问题。
有内部自己规划架构，有外围系统定位。产品经理需要知道梳理出的服务与功能由哪些系统给出，需要跟外围系统进行沟通排期。
比如之前遇到需求是前台客户端需要人工干预商品排序，想要展示配置项商品。因为我们商品数据来源都从搜索接。这需求就相当于一个批量查询商品数据。
但是搜索系统就不肯，搜索系统的主要逻辑在于商品的召回和排序，而不是当成数据库去查询，要查商品就去从商品中心批量查询……这就属于一个系统定位问题，当然可能会遇到功能定位不明显，一般会有对应的架构师去定夺。
即使会有架构师来划分，但产品经理知道各外围系统定位是能让自己沟通更有效，以及知道找到对应对接人。
对于自己系统的规划，业务系统一定要考虑到拓展性。
因为随着业务不断地增加，系统逻辑依赖变多。如果初期设计产品不考虑到拓展性，那就会导致后面功能不断叠加，系统重复依赖功能变多，导致后续功能难以评估影响面，以及系统维护变得复杂。这就需要产品经理能规划自己系统。
3. 撰写需求
当流程和框架确定好以后，就是将方案落实成可阅读性高的产品需求文档。好的产品需求文档也是研发团队沟通提升的前提。在撰写需求文档时候，既要考虑到可阅读性高，还要考虑产品的细节。
上面列的三个步骤只是比较重要的工作流程，真正落实时候远不止这些。从上面可以看出业务产品经理需要积累更多的是业务和技术方案的理解。当然，逻辑能力和沟通能力是所有产品经理都不可缺少的。
产品设计流程每个公司系统不一样可能会不一样，但整体思路应该相差不大。关于产品设计，产品经理最常问到的俩问题要不要懂技术和B端产品用户体验的问题？
1. 产品经理要不要懂技术
作为业务系统产品来说，我个人感觉是懂是更好的。因为我觉得懂技术能降低很多沟通成本，这也看每个公司团队合作方式。
而且业务产品不像用户产品那样，用户产品更多地考虑用户体验、用户需求，而业务产品更多的是业务如何稳定运行良好，用户也是自己公司“专业”员工，主要还是在于系统的实现以及拓展性。而这个时候更多地是考验如何实现具体产品方案。
这就需要对技术、数据、系统的理解。防止产品方案确定后，技术上实现不了或者实现对于原有的改动量太大破坏性能等等。懂技术不是说能够上手去编程，而是要对技术的理解。知道实现原理，能够简单评估可行性。
关于这个问题可聊篇幅略长，后面可以再聊。对于不懂技术的产品，这里分享下几点不成熟经验吧。
如果自己不懂了又想要开发帮忙评估。
首先要学会“舔”开发，请吃点零食喝点奶茶，让开发解释下具体应该怎么实现，在自己能理解的范围内尽量去理解。慢慢地技术理解知识储备就有了。
假如在做一个新系统功能，最好产品初期梳理流程和架构的时候，能够让开发今早参与，这样开发也好能提前知道项目和设计系统概要。
当有遇到产品评估不出来的时候，尽量拉着开发帮忙评估下影响。
2. B端产品要不要考虑用户体验
用户体验分两种：一种是操作体验，一种是视觉体验。
B端产品最主要的目标就是提升效率，减少成本。在有限资源的条件下，视觉体验影响不大，重要的是操作体验。
一般来说B端产品的用户都是公司内部人员，有一定的专业性，自己人就过了，丑点就丑点了。但是操作体验不能忽视，能够更少操作处理更多的业务问题，这样才能更多地提高人效。
除了通用的产品经理能力需要不断积累提升（逻辑力、沟通能力、权衡价值等等），作为业务产品经理，还需要提升对业务的理解和产品方案的积累。
产品经理不能只做运营的“翻译官”，将业务需求文档翻译成产品文档，这样产品经理充当了一个可有可无的传声筒角色。
沟通会存在信息漏斗，运营表述有可能只从他的角度去看待问题，实际问题没有看到或者沟通不明白，有时候理解就会偏差。
产品经理应该积极主动地去接触和了解业务，去发现业务运行过程中存在的问题，去思考产生这些问题的原因，以及业务未来的发展。才能够真正理解产品设计所要解决的问题。
产品方案主要体现在产品的规划性和拓展性。因为业务产品不像用户产品那样变化那么快，用户产品得随着用户群体和环境的变化而在迭代，而业务产品更多地解决随着业务增长而带来的问题，系统定位不会改变太大，系统发展是越来越完善和成熟。
举个实际例子，产品经理再怎么考虑系统的拓展性，也是要根据实际业务来适配的。如果这些企业不是在行业里边的数一数二的，那他们所遇到的问题，巨头当时肯定遇到过了，他们的解决方案可以参考学习。之所以大厂和巨头的产品经理会更受欢迎，就是因为见到的问题多了。
当然具体业务问题还得具体分析，巨头的方案是因为上了一定体量之后。而一个小企业业务还没有发展起来，就不要学巨头去搭建中台，先把业务流程跑通和生存下去。
产品经理应该多积累解决方案。其实产品方法论和产品思维积累到一定程度后，产品经理们之间分野的主要因素在于产品方案的积累。遇到问题相出产品方案这个比较容易，难的是在于产品方案上线后没有带来新的问题。这需要经验的积累。
最后提个遇到问题的总结，就是接手到一个新的系统和需求，如何快速上手？
很多时候我们新接触一个业务往往是没有人交接或者指导的，这就需要自己总结如何更快去上手，个人觉得有三个维度：业务场景、功能逻辑、系统接口。
（1）业务场景：咨询对接的运营同事，尽可能的先了解业务场景；作为用户去体验功能业务场景。
（2）功能逻辑：尽可能找出前同事交接文档。通过对接业务介绍了解，通过测试系统去走流程，熟悉功能点。
（3）系统接口：当功能逻辑和业务场景都熟悉了，整个流程能够梳理串联起来。需要通过接口文档或者数据库字段去了解功能实现具体逻辑。有时候还得拜托开发同事帮忙查查代码逻辑（还是零食+星巴克）。产品文档有可能出错，但代码逻辑不会。
最后从个人感觉谈谈B端产品经理的价值。B端产品经理不像用户产品那样容易做出成绩，或者说做出成绩不单单来源于研发团队，还有业务团队的合作努力。
业务产品只有在业务部门强力的配合执行中才能体现其真正的价值。再好的系统也需要具体的人去执行。
比如物流配送系统建设得再好，效率提升得再快，没人配送还是没人配送，商品一样到达不了顾客手中。每到电商大促，总需要增加客服支援，大促过后几天还需要客服支援，因为商品还没送到导致客诉很多。
还是拿电商来说，电商的核心竞争力就是在于价格和服务。价格又是在于商品供应链，你能拿到的商品是不是质量好，价格低。
对于标品的东西，如手机、电脑、电器这种，全网平台一搜，谁的价格低就能销量高，就像今年618某多的百亿补贴，苹果手机全网一搜价格摆在那，竞争力就在那。
而服务主要还是你的售前和售后问题。商品出了问题有没有保障，客服有没有及时响应处理，商品能不能退或者赔偿等等。
就像我们在做电商cps产品，目标还是提高商品的推广，这就需要淘客这类人群来推广。眼看淘客数量和推广商品数量上不去，而这关键因素还是在于供应链问题，品控和佣金。这相对于行业这么多淘客平台，而品控和佣金又不是研发团队能够解决的，做着做着就感到无助。
说了那么多可见难题，回到问题，那B端产品经理的价值在哪？
我个人觉得就是在已有的封闭问题下（条件就这么多），尽量寻找最优解。
尽可能通过产品方案来节省成本，提高效率。比如增长黑客玩法，降低获客成本和提高留存；系统流程改造，节省内部流程；智能客服代替人工处理等等。
正所谓，困难是必须要面对的，通过解决困难来体现价值。
一点思考和总结，感谢阅读。
上文如有不正，请不吝请教。欢迎评论互动~
