在To B产品工作中，“业务建模”这个概念十分常见，那么，如果将“业务建模”概念转换至To C维度，产品经理可以从中获得哪些启发和感悟？这篇文章里，作者从“2023产品经理大会·北京站”的嘉宾分享内容出发，提出了他的思考和见解，一起来看。
“在工作时，老板跟我们说过不要成为一个“问题型产品”：只知道解决用户问题，不知道如何真正地预估用户需求。然而到底该如何去挖掘和解决用户的需求，网上也有很多文章，无非都是说挖掘用户场景，寻找根本需求等等，却总给人一种浅尝即止的感觉。
这次产品大会高晖老师的分享中，提到“业务建模”这个概念，让我对这个问题有了另外一个维度的思考。由于我是TOC产品，会尝试将这部分概念转化到TOC的思维上，虽然无法一一对应，但问题不大。”
高晖老师分享的内容中，业务建模指的是“基于业务导向和数据驱动的企业运营的普遍性问题的解决方案”。这是TOB的，我根据自己的理解，将文本转化为TOC，就变成了“基于业务导向和数据驱动的用户运营普遍性问题的产品方案”。
这里面我们发现，这几个部分就是“业务”“数据”“用户”。那么搭建好一个业务建模的话，就需要从这三个维度的组合。
每个公司都会有一个自己的主流导向，比如有的公司就重视数据，有的就重视用户反馈。但其实在一个健康的体系中，这几个都是缺一不可的，无论偏向哪一边，都会出现各种问题。
A. 了解业务底层逻辑
上篇文章我说过，我见过一些产品，做自己的业务做了一两年，都说不清自己的业务底层逻辑到底是啥。至于每次提到要做什么，就对着竞品从上往下抄。
这部分虽然在执行中不会出大问题，但只能解决表象，并不能真正地解决产品的根本问题。“做一个功能”很简单，但是“为什么要做”“为什么不做”这才是需要思考的。（这类我经常会遇到的一个答案就是“竞品有了”“用户要求”“用户没要求”，总觉得emmmmm）
B. 判断用户真实需求
产品经理恨不得掰开用户的脑子去看用户到底想要啥，尤其是TOC产品经理，在用户反馈中找到真实需求更是困难。我曾经做过用户呼声最高（TOP1）的反馈需求，但其实在数据表现上并没有那么突出（需要根据数据看OKR是否达标）。而业务建模则可以让我在需求阶段，更加深入的去考虑这个需求到底是否是真实的用户需求
C. 评估需求优先级
业务中最困难的就是需求排序优先级，资源有限而不得不舍弃一些。但由于需求来自于不同方，各个需求方都不退让，导致需求很难舍弃。我曾经尝试使用过行业内比较热门的需求评估公式来进行评估（下图），在实际工作中有一定效果，针对一些争议性的需求，通过该评估表格能进行一定相对客观的比较。而业务建模，则可以让需求价值更加清晰，从而客观的去评估优先顺序。
对于自身来说，学会拆解产品建模，产品才能够真正的认识自己的产品形态应该怎么做，怎么去排需求优先级，怎么去确认需求价值；对于未来从事新的业务，尤其是一些创新的，自己从没接触过的业务，产品建模能够让自己快速上手，理清业务思路，这都是一个资深产品必备的技能。
我结合高晖老师的内容，结合了自己的思考和工作经验，总结出了下面这些业务建模SOP。
高晖老师分享内容中总结，每一个业务都会有自己的价值链，价值链其实就是商业模式+盈利模式。我觉得所有产品都需要认知的是，所有的产品都是为了商业服务的，即使短时间没有要求，长期来看肯定会有要求；也许公司对于你这个业务没有盈利要求，但你的价值也许是品牌宣传，也许是用户留存，他终究也是商业模式中间的一环。
结合上面，无论你现在所处的公司宣扬的是产品导向，还是用户导向，还是数据导向，其实最终的闭环，都是“商业导向”。而只有基于商业导向，我们才能够最准确的认识到自己的产品核心价值在哪。
确认好价值链后，我们就需要搭建如何实现价值的业务SOP。业务SOP我理解分为横向和纵向，纵向是用户生命周期，横向是产品功能流程。将用户生命周期放进来，是因为我认为不同阶段的用户，产品需求是不一样的，所以需要区分开之后再组合，才能形成一个完整的产品。
首先是纵向，以我之前做过的线上教育APP为例，我们会做一个完整的用户AARRR模型（用户获取、用户激活、用户留存、用户转化、用户传播）。用于梳理用户在到最终付费转化之前，都应该会经历哪些环节，从而制定我们的产品SOP。
比如在线上教育中，会通过公域流量和私域流量来获得用户线索，然后通过免费课/免费题库做用户激活和用户留存，再通过付费课进行用户转化，低价转高价，最终再老带新，比如老用户拉新获得优惠券之类的活动。到此为止，完成用户的生命周期。
然后是横向，比如现在用户需要听一个课程，那么就需要进入APP——打开课程浏览页面——打开课程详情页面——点击付费——付费完成——进入课程播放页面，这既是一个横向的产品功能流程。
用户的横向和纵向都拆分好了之后，就可以对每个业务的单个环节进行架构拆解了。
以上面的购课转化为例，里面就包含了商城系统、订单系统、付费系统、用户管理系统、媒体管理系统等等，这部分架构都是为了“购课转化”这个业务环节服务的。
其实高晖老师也讲到了，很多业务底层其实是共通的，如果把业务比作房子，那么架构模块就是砖头。大家都是用一样的砖头，但是可以搭建出不同的建筑。那么任何业务在我们眼里，都是一块一块的砖罢了。（后续有时间会尝试针对不同主流业务做这种拆分梳理）
分享会中提到了“应用建模”和“数据建模”，我个人理解就是“功能交互”+“数据设计”，也就是客户前端和数据后端的区别。每个产品都做过，就不再去细说了。
接下来再总结一下老师分享的这几个环节转化的方法。
1）5W1H
2）事件风暴基于老师的内容，我重新去研究了一下“事件风暴”这个概念。基于业务事件而开展的一种研讨会，类似于头脑风暴。那么我们可以得到的重心在于“事件”。
事件是基于价值链梳理出来的可量化业务行为。简单总结就是谁（角色）使用了什么（输入）做了什么（命令：动作）产生了什么（输出）影响了什么（事件）。比如上面说的用户购买了一个课程，然后去听课，这里面就包含了多个事件，选课事件、下单事件、付费事件、听课事件。事件风暴梳理对比用户需求梳理，能够更加全面宏观的看到这个业务流的环节，而不是用户导向的指哪打哪。
多人讨论下，针对上面的流程，你想到了下单需要一个拼单系统，他想到了需要一个优惠券系统，我想到了如果实体商品库存不足怎么办。那么通过大家的脑暴，将所有的思路统一在一起，基于上述提到的事件将整个过程可量化、标准化，完成一个相对完整的产品架构。
事件风暴是出自于DDD（Domain-driven design领域驱动设计），DDD内容我简单研究了一下较为复杂，后续单独发文跟大家讨论。
3）生产三要素
那么，新业务如何快速搭建新矩阵，高晖老师分享了三个基本元素“生产者（使用者）”“生产模式（运作流程）”“生产关系（各个生产模式之间的关系）”。搞清楚这三个元素，就可以做好业务分析。
举例，一个在线教育APP的课程系统，生产者就是买家和卖家，生产模式就是购买和售卖，那么生产关系中，与购买耦合的有付费、订单、物流等等。上游还有货架浏览，下游退款退货功能。通过这些几个元素的组合，组成了业务模型的框架。（这部分讲的比较快，我大致理解是这样，有其他想法可以讨论）
4）能力矩阵模型
高晖老师还提到一个能力是能力矩阵模型，将产品核心模型拆分为“场景”和“职能”两个维度。而我们在实际的业务中，也可以通过这两个模型将产品进行拆解，从而更加透彻的了解自己的产品模型。（下图为会议分享的电商案例，这部分我后续也会像拆解业务架构一样尝试一下针对不同业务进行能力矩阵模型拆解）
总结，一直以来我在思考，资深的产品经理和初级的产品经理到底差距有啥，我知道是经验差距，是方法论的差距，但一直都不知道我需要掌握哪些方法论。这次分享无疑是给我提供了很多的思路，这次的学习不仅将我工作中无序的思考通过有序的模型进行了“建模”，对于我的职业技能，也搭建起了一个相对完整的“建模”。
本文由@Maple 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。