《决胜 B 端》读书笔记

这本书是团建时的奖品,原以为尔尔的一本书(原谅我看到书名“决胜”两字就想到了高考相关的感觉),查了下豆瓣评分竟然8.0,作为一本专业书8.0的评分我认为一般是值得一看的。
2019年开始转到的前线业务团队,着手业务 B 端的产品建设工作,但实际上并不好上手,尤其是身上带了大量 C 端的经验,有时感觉反而是束缚。之前做的一些 B 类的产品也和业务团队的 B 类产品完全不同,更偏技术输出型,这就导致一段时间的徘徊和大量的困惑中前进。
周末抽了一天找了个安静的咖啡馆看完这本书(恩,在家只能躺尸,完全无法进入阅读状态),虽不至于大彻大悟,但依然解决了一些困惑,也从全局上更好的审视 B 端业务型产品,尤其是 C 转 B 的后的一些问题,作者给予了自己的理解解释,虽不能百分百认同,但总体上理顺了一些,目的也就达到。

因为已经参与了半年的业务产品设计,自己有不少困惑,除了具体业务规则之类的问题,通用型的困惑先理一下:

1.业务型 B 端产品到底该如何理解?需要关注的主体是什么?
2.业务型 B 端产品与 C 端产品在产品设计上的思路差异在哪?
3.产品建设的特点和路径上有什么常用的判断原则?
4.什么是产品架构?该如何理解架构的价值?不同的架构有什么区别?架构如何才是有效的,而不只是画张大图不产生任何实际意义?


开始正篇(混杂自己理解和思路的整理)

为什么越来越多业务型 B 端产品经理的需求?

过去5~10年是 C 端产品发光的黄金年代,关键在于流量红利期的商业模式基于线上广告的轻资产模式,涉及的人员和资产的管理难度较低,业务上更多的精力都投入在如何挖掘用户痛点获取用户的使用时间(流量)。而今红利用尽,可抢夺的用户时间所剩无及,用户可挖掘心智越来越少,产品之间的功能、体验差距急剧缩小,线上流量越来越贵,流量和用户的争夺开始前往线下,涉及更多的服务人力、资产、物料等,最基础的保证业务正常运转都需要产品和技术进行支撑,进一步提高业务运转效能(尤其是在大量并发任务时)更是需要 B 类产品支持。部分传统线下企业的业务逐步需要数字化,以拓展其更大的规模化可能性,提高业务未来运转效率,这些都产生了更多的 B 端产品经理的需求。

未来可以说是模式的竞争,新的模式出现验证时,往往没有有效的通用型业务产品能够支持,这时产品经理的价值会凸现,而通用型的业务型B 类产品需求(比如沟通、OA等)也将会像 C 端产品,在通用化沉淀和行业解决方案两端需要更多的产品经理同时推进。

B 端产品经理关注的核心点

B 端产品核心关注解决某类经营管理问题,对象是企业和机构而不像 C 关注的是个体用户和群体心智。B 端产品解决的问题集中在 提高收入、提升管理/操作/业务运转效率、降低成本、控制成本等。从产品设计的角度来看效率第一、体验第二,强调抽象、逻辑,对象以及对象之间的关系(这里包含商业关系、角色关系、流程关系、资产关系、系统关系、产品关系、数据关系等)。
从产品经理自身的角度来看,未来的学习套路和壁垒:
1.所负责业务领域的管理方法论和经验、运营特点级难点
2.所负责领域的商业化解决方案(产品)及其优缺点
3.同类业务模式公司的业务特点及解决方案
4.公司业务的现状、问题痛点,明白如何将行业最佳实践结合公司的特点进行规划落地
总体而言最根本的在于痛点从企业或机构出发,当C 转 B 的把原来的用户转换为企业,消费者心智、行为分析方法等转化为企业管理方法论后,其他基本思路差不多,只不过竞品相对更不容易学习和研究,但可以找成熟一些的商业产品抽象其核心管理方法/模式与产品结合的思路,如果在成熟的大公司,还有一些很重要的就是了解现有系统的能力和相互之间的关系(尤其注意数据传递关系),因为更多的时候不是从零开始进行产品建设,而是如何拼装关联出合理的解决方案进行推进解决业务问题。
另外,之前也不是特别理解数据产品的特点,作者给出了一句话“数据的挖掘、探查、分析和价值输出才是数据产品的灵魂”,结合全书后面数据报表设计的内容,可以看出数据产品的核心是构建分析体系(用什么样管理/经营/业务分析思路)来定义分析对象问题,通过什么指标能够发现什么问题,进行产品化,最终解决某方面业务问题。这里有一篇入门级数据产品相关的文章可以看看《从设计到数据》

同时还有两个必须要知道的难点:一,不是所有业务问题都能/都适合通过产品化的手段去解决。二,B 端产品不易指标化衡量,目前自己总结的最好的方式还是将业务问题具象成某些业务上认可的关联管理指标,这些指标的提升和下降意味着这个问题被解决,会相对好表达一点产品的价值。(例如业务问题是销售团队懒散不易管理,理论上可以具象为过程指标 拜访客户数、电话沟通数和结果指标 签约数进行监督)所以指标定的对不对很多时候取决于与 Leader 层沟通的管理策略和方法,产品有时在这个环节是提供有效支持,而不是创造性破局。

B 与 C 的主要差异

需求产生的背景和动机

B:组织或者机构,解决业务问题(也可以说业务痛点)
C:个体用户,用户痛点

设计的起点

B:为解决业务问题而设计,设计的起点是业务调研,研究业务问题
C:实现公司商业模式的落地,承载着公司的商业目标,设计的起点是对商业模式本身的分析与研究,包括市场分析、客户群分析等。

MVP的选取思路

B:端产品要支持业务整体运作,所以在选取最小功能集合时,即便再简化,也要保证一个核心业务流程的运转,因此B端MVP往往是一个具备一定复杂度的系统,不可能是一个或几个功能点。
C:要聚焦用户的核心痛点,C端MVP可能只包含一两个功能点

细节设计不同

B:B端产品面临复杂的业务场景和用户场景,因此进行细节设计时,必须关注建模、抽象、角色、权限等问题;B端的复杂性比 C 端高很多,一个动作或者按钮往往代表了一系列复杂的业务处理规则,有时需要帮助文档指导用户/理解其背后的业务规则
C:C端产品面临的场景相对单一,并且使用者是相对独立的单个用户,因此不用关心角色、权限管理,而要关注用户的体验,需要在交互设计上投入很大精力。

产品运营的方式不同

B:主要进行全员宣导并培训
C:持续推广并通过快速迭代优化产品

对我个人而言,还是前面说的,作者这番的讲解,最重要的还是 用户痛点与企业痛点,用户心智/行为与管理方法/思维 的差别,这两点是之前没有认真理解到位,导致在整体产品设计过程中看似思路清晰,但实则主线思路有些偏的地方。

B 端产品的建设

一般一个大一点的业务需求,起手的套路可以是看其是否已开展。如果是未开展的业务,提供最低成本的方案进行尝试,论证有效后,再进行产品化支持。而已开展论证的的业务,则需要全面的产品化支持。
这部分如果之前不了解,推荐直接看书,讲的还是比较详细的,不多做复述,只结合自己的经历记录几个自己觉得需要注意的点

业务问题调研

业务问题调研从战略(管理层)、战术(业务 Leader)、一线员工不同的层面能够获取不同的问题指向,如果是根据问题构建一套产品,对于战略、经营策略的分析需要认真对待,直接影响解决方案和系统的建设的重点方向。为了避免需求拍脑袋出来,也需要注意深入一线,理解当前业务所面临的问题,有时一些业务 Leader 也并不十分清楚业务面临的问题,或者实际上东边问题最大,但就说西边问题大。假如在这个业务域能够像业务 Leader 一般关注各项业务运转的数据将更利于自己理解这个业务域的业务问题。

产品整体方案设计

1.关注核心业务流程,区分在现有资源和环境下哪些环节需要实现产品化,最关键的判断思路是产品化价值最大(比如操作/执行成本最高、涉及人日最高、最适合通过产品手段解决)。另外需要注意逆向流程和特殊流程可能在业务上属于高频流程而被忽略了,导致实际可用性大大降低。
2.产品定位与 C 端产品的定位有一定的差别,B 类产品的的产品主要陈述所支持业务的范围、对象和功能目标,C 类更多是基于某类用户心智/痛点击穿描述产品价值。
3.应用架构的关注的主体是和公司现有系统之间的融合关系,大多数时候我们谈架构就是产品/系统与全局的定位/功能/数据的关系如何可行又相对合理的进行布局,在涉及一套新的产品和系统时,必须考虑如何和现有系统的架构融合,不同模块之间如何衔接,当然这也就要求需要熟悉公司的系统架构,才能够快速反应出解决方案及相互关系。稍微要注意一下的是,架构很多时候还与公司的组织架构及商业关系结构相关,这也是架构的复杂性所在,而不在于仅一张大图描述系统全局。

B 端的架构

PD 的组织架构

这部分强烈推荐对“组织”这个词没有感觉的去看原书,作者详细的描述了产品经理、产品运营、业务运营在不同的组织架构下可能存在的合作利弊关系,这里引用作者的两句话作为引子

“没有最好的组织架构,只有最适应当前阶段的组织架构。通过调整组织架构,绑定利益共同体,可以解决很多业务管理问题。组织架构决定了汇报关系,进而决定了绩效考核方式。汇报关系、绩效考核方式会影响人做事的动机、行事的方式,以及个人和团队的利益。通过调整组织架构,可以把一股力量拆成互斥的几股,也可以把几股互相较劲的力量凝聚成一股。”

顺便将作者在利弊关系中所考虑的点收敛一下,从组织架构中需要能够看到的因素:

权利和义务

人力=资源,可按自己目标支配资源=权利

职责界定

模糊的职责之间,能够通过统一的汇报对象逐步理清职责关系

配合默契度

同一个汇报对象更容易形成配合关系

关键信息互通效率

独立团队之间关键信息的互通效率会降低

冲突

工作内容相似度高的两个不同汇报对象团队容易产生“冲突”

决策效率

产品设计的决策效率和业务规则的决策效率

职能的全局和客观性

当产品挂属在业务团队时,会容易丢失全局和客观性,不能发挥产品的最大价值

人力成本

有机会再看看 组织管理相关的书,不过这几个因素,已经能看出一些互联网公司“明面”上调整组织架构的用意,以及当前业务遇到一些问题,管理层后续可能会如何进行调整。当然还有很多“灰色”的因素,这里也没有足够的经验能够描述,就当是这个主题的开胃菜吧。

企业应用架构

什么是企业应用架构

企业级应用架构正是指企业的各个软件系统有机集成在一起的方式。

企业架构与其他架构的关联关系

原本这个关系用图更好表达,我偷个懒,先用文字表达。从构建实操的角度来看:
上层:业务模式–>商业对象结构和关系
中层:管理模式–>组织结构关系
下层:经营/运营模式–>角色及流程关系、系统/产品关系、资产和数据关系
所以落到一般意义上的企业应用架构—系统/产品关系、资产和数据关系,自上而下还需要分析上层和中层的业务模式、管理模式,抽象其结构。

研究企业应用架构对产品经理的价值

虽然身在职场有些年头,但确实没认真考虑过企业是如何运作的,从组织结构、权责分工到部门协作关系等等,每个词都听说过但就是没有通盘来看,就是字母与单词的关系,作者列举的一些价值也算是增长了作为产品经理的见识,同时也给出了业务型 B 端产品知识脉络延伸的方向。
1.理解企业是如何运作的
2.理解支撑企业运作的成熟产品方案
3.多个产品之间是如何协作的,有哪些解决问题的“架构式”套路
4.管理人员所具备的全局观
5.理解企业业务发展与架构演变的关系,深谙套路,能够快速形成解决业务问题的思路

在全书的最后部分,作者用一套企业发展的案例详解了 业务与组织结构、应用架构 互辅相成互相推进演变的过程,个人觉得描述的相当精彩也易于一般的产品经理理解。看完不仅能从宏观上感受三者的相互作用,也清楚的知道,应用架构不是空架,用一张大图去描绘,更多的时候是和业务的模式变化、组织结构变换相互推动去演进。一方面实现支撑业务,另一方面更好的管理业务及产品的关系。这值得不理解“架构”这个词的产品经理仔细看看。

小结

写了不少文字,但归根结底对我这个 C 转 B 的过程中产品经理而言,能起到关键思路变化的有:
1.B端需求不是看用户问题,而是看企业的问题,虽然有时候会变成解决“老板”的问题,但本质是业务发展和管理问题,需求的分析手段来自于管理方法,而不是情感认知以及用户行为,所以工作中经常提到的“业务规则”就能理解为什么非常关键。
2.数据产品/报表 的核心在于分析问题的框架,之前自己更多的出发点在于散点问题的收敛和归纳,虽然收敛的好的时候设计方案差不多,但其根本思路和思维方式是不同的。
3.所谓产品架构,经常听到,觉得很高大上又没什么实际作用,往往看到的时候只是一张大图。而实际上靠谱的产品架构是从商业模型开始经过组织架构和系统间关系抽象一层层的梳理出来的,其最关键的价值 是让产品和技术的发展更加合理,也更好的支撑公司未来的发展(使产品和技术不成为业务规模化的瓶颈,快速支撑新的业务等)
4.组织架构意味着不同团队之间权利、关系、矛盾等在当前业务阶段的优先级,没有完美的组织结构,只有适合当下发展需要的取舍。
这本书你即可以说他是入门书,也可以说他使框架理解书,按照目前的理解,一旦熟悉 B 的套路,其实比 C 的稳定性更强,产品经理的壁垒也深(前提是学习起来的成本更高,要知道很多公司的系统纯靠问自己整理才能学习,更不用说不同业务的管理方法论等)

碎碎念

大部分时候公司的业务模式决定了产品体系的发展方向,但如果最终面向消费者的业务领域(比如零售),往往都是用户价值与业务价值共舞的状态。前端通过对商业模式/用户的理解通过产品和运营手段获取低成本的流量,后端通过业务系统提高人/资产的管理效率。


Share Your Thought