Friday, 30 August 2019

《决胜 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 的稳定性更强,产品经理的壁垒也深(前提是学习起来的成本更高,要知道很多公司的系统纯靠问自己整理才能学习,更不用说不同业务的管理方法论等)

碎碎念

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


Thursday, 7 December 2017

管理课程学习记录

拖了半年才上公司内部新 Leader 管理课程,第二天结束时就感觉上晚了。
很多案例和课上讨论的问题都在实际的工作中出现过,很多困惑也会与 自己的Leader 经常沟通,但可能是思维方式和性格特征的问题只见木林不见森,难以换个视角从局上看待管理上的问题。

Continue Reading

Tuesday, 15 August 2017

《年轻管理者手册》读书笔记

前记

逐渐走上管理岗位,对于越来越多的管理问题以前一直没有意识,实际工作中非常吃力。虽然老板也经常会和自己沟通该如何处理某些问题,但始终不得法,也许是直来直去的理性思维缺少了感性基础,特别是对人,对业务的理解。很想找到一套可以尝试去理解并且模拟的方法,最起码『开悟』也行。这本两个小时左右就能读完的书很显然不能解决所有问题,但依然还是有些感觉。和我一样不明真像的职场人可以看看。

Continue Reading

Saturday, 9 July 2016

《优秀到不能被忽视》读书笔记

前段时间出差,和朋友聊起关于职业发展和规划的问题,晚上正巧就在自己的kindle中发现一本《优秀到不能忽视》,索性花了两天时间读完。
读完后再次脑洞大开,想要记录下来,虽然文中的很多内容对我而言不适用(基本属于书中所述的少数人群),但还是很有启发,特别是身边亲戚朋友聊到职业的选择与规划的问题经常不知从哪里下手,而我个人的经验和经历又比较特殊不具有普遍的实操价值(正如作者所言)。当然,这本书如同常见的『西方世界』翻译而来的书一样,大量的案例论证、需要有点知识背景的名词、略蹩脚的翻译,读起来并不轻松愉快,所以我同样也希望这篇读书笔记能够屡清思路,看起来更接地气也更易懂一些。

Continue Reading

Tuesday, 22 March 2016

《零售的哲学》阅读笔记

如之前的开篇中所述,这两本书的阅读笔记我会拆开来写,铃木敏文老爷子主要是用基本的事业发展时间线辅以相对应的主题。我这里按照自己的理解重新整理一遍罢了,更像是专题的方式
需要明确的前提是,全书讲述的是一种“永续经营”的思考,所以并不适合短线操作或者投机,某种程度上也会带着理想主义色彩。如果有机会你也看到这本书,只要注意别认为所述的都是“真理”即可,只是作者自己的领悟和经验,优秀的部分,自己经过思考咀嚼后再转化更为恰当。

Continue Reading

Wednesday, 11 November 2015

《别让猴子跳回背上》读书笔记

与其说这是一本书,不如说是一本小册子,读的是电子版的,只有300来页。最早是两年前听同事说起过这本书,只是一直没有找着合适的时间读。管理方面的书一直读的少,也不是很清晰管理为何物,这本书算是开个头吧。
整本书只解释一个问题:为什么会出现上级领导忙到吐血而下级工作人员无事可干或者乱做一团(其中为什么乱做一团的部分相对比较片面,还需要更多的理解)。解释这个问题的目的在于让管理者拥有更多的可支配时间,发挥其应有的价值。

Continue Reading

Sunday, 9 August 2015

《转换率优化之道》读书笔记及产品演变的一点感悟

电商的最核心数据就是转换率,这些年电商的基本模式也越来越清晰,甚至听说过,电商已经成为了传统行业。
最近做的一个电商项目,转换率不高,简单思考后发现能够改进的地方不少,但是又特别散,总觉得没找到思考的主心骨。这就找本靠谱的书看看,扩充下自己的思考范畴。
作者基本事无巨细能够想到的对转换率有影响的方面都讲了,不过一本书的内容本身是有限制的,挺多部分并没有讲细致,只是提了一句有这么个方面,至于怎么做或者什么思路,还需要自己多下功夫了。
对我而言,全书最核心的部分在于用户已经抵达着陆页后的这部分,主要是一个基本的思维框架。

Continue Reading

Tuesday, 14 July 2015

《引爆点》读书笔记

同事屡次推荐,说是信息传播的入门篇。当然也由于自己的工作中和信息传播关系越来越紧密,花了一周时间翻了两遍。
虽然作者写书时主要针对的是口头信息传播,但实际上是相通的,可以联想到各种互联网上传播的事件,对照来理解。
全书主要就讲述了三个基本信息传播法则,其中个别人物法则中,三者是有一定的逻辑关系的,可以重点从信息的源头缕一下。

Continue Reading

Sunday, 24 May 2015

《腾讯方法》阅读笔记

对腾讯还是有些好感的,面上看起来这是一家什么都在抄的巨头公司,但经历过创业公司后站在商业的立场上看这一切都是可以被理解,甚至它本身可能就是一种基业常青策略。
腾讯在产品经理的圈子里备受推崇,导致我对《腾讯方法》这样一本在豆瓣评价8.1分的书有不少期待。比如他们的产品团队是如何建设的?需求是如何管理的?产品是如何打磨的?等等
虽不确定书中内容是否100%纯天然不含防腐剂,但提炼下应该还是能找到些真金的。

Continue Reading

Sunday, 8 February 2015

《走出电商困局》读书笔记

最近很少能读到让我做如此多批注的书了,黄若做为横跨传统零售、电商、投资三界的前辈,对电商问题的本质理解很清晰。这本书虽然是2013年对电商行业的描述,但现在看来依然有醍醐灌顶的感觉,解释了我一个个的困惑。
整本书结构类似文集,有些零散,我这里按照自己的理解重新组织一些结构以方便阐述和说明:电商、电商周边、管理与职业。

Continue Reading