在To B产品工作中,“业务建模”这个概念很常见。那么,如果把“业务建模”这个概念换算成to To C维度,产品经理们能从中获得哪些启发和感悟呢?本文作者从“2023产品经理大会北京站”嘉宾分享的内容中提出自己的思考和看法。让我们来看看。
“在工作中,老板告诉我们不要做“问题产品”:我们只知道如何解决用户的问题,不知道如何真正估算用户的需求。但是网上有很多关于如何探索和解决用户需求的文章,都是关于探索用户场景,寻找根本需求等。,但总给人一种刚停下来的感觉。
高辉老师在本次产品发布会的分享中提到了“商业建模”的概念,让我有了另一个维度去思考这个问题。由于我是一个TOC产品,我会尝试把这些概念转化为TOC思维。虽然我不能一一对应,但问题不大。”
一、什么是业务建模?在高辉分享的内容中,业务建模指的是“面向业务和数据驱动的企业运营中常见问题的解决方案”。这是TOB的。按照自己的理解,我把文字转换成了TOC,变成了“基于面向业务、数据驱动的用户操作普适性的产品方案”。
我们发现这几部分是“业务”、“数据”和“用户”。那么构建商业模式,就需要结合这三个维度。
每个公司都会有自己的主流导向。比如有的公司重视数据,有的公司重视用户反馈。但其实在一个健康的体系中,这些都是缺一不可的,无论偏向哪一方,都会出现各种各样的问题。
二、为什么要做商业建模?1.理解业务的基本逻辑。
上一篇文章里说了,看过一些产品,自己做了一两年,也说不清自己业务的底层逻辑是什么。至于每次做什么,对照竞品从上到下抄。
虽然这部分在实现上不会出大问题,只能解决表象,但并不能真正解决产品的根本问题。“做一个功能”很简单,但是“为什么做”和“为什么不做”才是需要考虑的事情。(经常遇到的一个回答是“竞品有”、“用户要求”、“用户不要求”,总感觉是emmmmm)
b、判断用户的真实需求
产品经理恨不得打开用户的思维,看看用户到底想要什么,尤其是TOC产品经理。更难在用户反馈中找到真正的需求。我做过用户呼声最高的反馈需求(TOP1),但实际上在数据表现上并没有那么突出(需要根据数据看OKR是否达标)。而业务建模让我可以更深入的考虑这个需求是否是需求阶段真正用户的需求。
C.评估需求优先级
做生意最难的就是对需求进行优先排序,因为资源有限,我们不得不放弃一些。但由于需求来自不同的当事人,每个需求者都不让步,这就造成了放弃需求的困难。我尝试过用业内流行的需求评估公式来评估(下图),在实际工作中有一定效果。对于一些有争议的需求,可以通过这种评估形式进行相对客观的比较。而业务建模可以让需求值更加清晰,从而客观的评估优先级。
2.对自己来说,学会拆解产品建模,产品才能真正明白自己的产品形态应该做什么,需求如何优先排序,需求价值如何确认;对于以后从事新的业务,尤其是一些以前从未接触过的创新业务,产品建模可以帮助我快速上手,理清业务思路,这些都是一个资深产品必备的技能。
三、如何做商业建模我结合高辉的内容,结合自己的思考和工作经验,总结了以下商业建模sop。
1.价值链老师高辉在分享内容中总结到,每个企业都会有自己的价值链,而价值链其实就是商业模式+盈利模式。我觉得所有产品需要知道的是,所有产品都是为商业服务的。即使短时间没有要求,长期肯定会有要求。也许公司对你的业务没有盈利要求,但你的价值可能是品牌推广或用户留存。毕竟也是商业模式的一部分。
结合以上,你现在所在的公司无论是推广产品导向、用户导向还是数据导向,其实最后的闭环都是“业务导向”。只有基于商业导向,才能准确知道产品的核心价值在哪里。
2.在业务SOP确认价值链后,我们需要建立一个如何实现价值的业务SOP。我理解的业务SOP分为横向和纵向,纵向是用户生命周期,横向是产品功能流程。把用户生命周期放进去,是因为我觉得不同阶段的用户对产品的需求是不一样的,所以需要把他们分开,然后再组合起来,形成一个完整的产品。
首先是垂直的。以我之前做过的在线教育APP为例,做一个完整的用户AARRR模型(用户获取、用户激活、用户留存、用户转化、用户传播)。用来梳理用户在最终支付转化之前要经过哪些环节,从而制定我们的产品SOP。
比如在线教育,会通过公域流量和私域流量获取用户线索,然后通过免费课程/免费题库激活和留存用户,再通过付费课程转化用户,低价转化高价,最后以新带旧,比如老用户拉新拿优惠券等活动。至此,完成用户的生命周期。
然后水平。比如用户现在需要听一门课程,需要进入APP——打开课程浏览页面——打开课程详情页——点击支付——付费完成——进入课程播放页面,这是一个横向的产品功能流程。
将用户进行横向和纵向拆分后,就可以拆解各个业务的单个链接。
3.业务架构以课程购买转型为例,包括商城系统、订单系统、支付系统、用户管理系统、媒体管理系统等。这部分结构服务于“课程购买转化”的业务环节。
事实上,高辉先生还说,许多商业楼层实际上是常见的。如果将业务比作房子,那么架构模块就是一块砖。每个人都用同样的砖,但他们可以建造不同的建筑。那么在我们眼里,任何生意都只是一砖一瓦而已。(以后有时间我会尽量针对不同的主流业务做这种拆分和梳理。)
4.产品架构分享会提到了“应用建模”和“数据建模”。我个人的理解是“功能交互”+“数据设计”,这就是客户前端和数据后端的区别。每个产品都做过,就不赘述了。
接下来总结一下老师分享的这些环节中转化的方法。
1)5W1H
2)事件风暴基于老师的内容,我又研究了一遍“事件风暴”的概念。基于商业事件的研讨会,类似头脑风暴。那么我们能得到的焦点就是“事件”。
事件是基于价值链的可量化的业务行为。简单概括就是谁(角色)用了什么(输入)做了什么(命令:动作)产生了什么(输出)影响了什么(事件)。举个例子,上面提到的用户买了一门课程,然后去听课,这里面包含了几个事件,比如选课事件,下单事件,支付事件,听课事件。通过梳理事件风暴,对比用户需求,我们可以更全面、更宏观的看到这个业务流程的链接,而不是指着用户往哪里引。
很多人讨论。鉴于上述过程,您认为您需要一个拼写系统来下订单。他认为你需要一个优惠券系统。我想着实物货不足怎么办。然后通过大家的头脑风暴,将所有的想法统一起来,基于上述事件对整个过程进行量化和标准化,完成一个相对完整的产品架构。
事件风暴来自DDD(领域驱动设计)。我只是简单研究了一下DDD的内容,比较复杂的,稍后我会另发文章和大家讨论。
3)三个生产要素
那么,如何快速搭建新业务的新矩阵呢?高辉老师分享了三个基本要素:生产者(使用者)、生产方式(运作过程)和生产关系(生产方式之间的关系)。了解这三个要素,就可以做好经营分析。
比如某在线教育APP的课程体系中,制作者是买家和卖家,制作模式是买卖。然后,在生产关系中,还有支付、订单、物流等等再加上采购。上游还有货架浏览,下游有退款退货功能。通过这些要素的组合,形成了商业模式的框架。(这部分比较快,这是我大致的理解。还有其他想法可以讨论。)
4)能力矩阵模型
高辉老师也提到了一个能力就是能力矩阵模型,将产品核心模型分为“场景”和“功能”两个维度。在实际业务中,我们也可以通过这两个模型对产品进行拆解,从而更加透彻的了解我们的产品模型。(下图是会上分享的电商案例。我以后会尝试为不同的业务拆解能力矩阵模型,就像拆解业务架构一样。)
Summary我一直在想高级产品经理和初级产品经理的差距是什么?我知道是经验差距和方法论差距,但我从来不知道自己需要掌握什么方法论。这次分享无疑给我提供了很多思路。这个学习不仅通过有序的模型“建模”了我在工作中的无序思维,也为我的专业技能搭建了一个相对完整的“建模”。
本文由@Maple原创发布。每个人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
本文仅代表作者本人,大家都是产品经理。平台只提供信息存储空客房服务。
主题测试文章,只做测试使用。发布者:rekoe,转转请注明出处:https://www.mulub.com/7686.html