Thursday, 30 January 2020

2020

开年

2020开年就是各种事,俄罗斯政府集体辞职、黑曼巴精神标志陨落、新冠爆发。月初就想写点什么,但很恍惚的发现脑子里面空空如也,什么也不想写。趁着难得的“寒假”,在家窝的够够的,开始几天还兴致勃勃的玩了几天游戏,可越玩到后面,就越紧张,总觉得又把时间给荒废掉了。找了部记录片《人生七年》来看,我还是那个需要引子才能转动思考引擎的主。

人生七年

9部纪录片一个系列,从7岁记录到63岁,豆瓣平均分高达9.3。虽说是纪录片,开始时以为是日常或者关键事件记录,后来发现,实际是每七年一次的访谈,更多的是关于生活、婚姻、金钱、政治、梦想/目标的思想沟通,在思维及意识层面不同阶层的孩子们随着时间和环境的变化,针对上面说的几个主题到底发生了哪些变化。我不希望讨论对错,也没有成功与失败观点,只想抽离几个自己印象很深的关键词说说自己32岁这年的理解。

自己的碎碎念

关于学习

在大学毕业后的1~2年内,我依然认为学习是人们获取职业知识和技能的一种活动,直到随着工作年限的增加,才感觉到,职业知识和技能只是面而已,没几年就会被替代(除了个别越老越吃香的长青职业外)。学习对于我而言是能够获取独立思考的能力,吸收他人的思维方式并辩证的与更多的思维方式去比对,形成自己的思维模式。而学校提供了一个场所和独立的时间,让这种碰撞发生的更加频繁,最终尽可能快的能够养成这种能力,同时意识到自己感兴趣/不感兴趣的方向。而我们这批80后所接受到的环境声音是“好好读书,赚大钱/改变命运”,硬要说都没错,但不足以支撑自己对于这件事的需要去干的解释。
大部分时候认为自己还是一个能够独立思考的人,但更多的时候发现目前的情况还不够,还需要更多的有含金量的信息摄入,至少构建出有一定抽象的思维结构后才能有效对事情进行快速判断,而今天最让自己感到焦虑的就是没法快速深入了解一个领域做到判断,往往需要调研一堆材料和思考后才能有所判断,也许是一个必经的学习过程,但也可以说是抽象的还不够。用这两年流行的说法就是,操作系统内核架构没升级,功能矩阵发展起来就会比较吃力。

关于自我

最近这几年,越来越意识到自我的重要性,一方面的是自知,自知后方能对自己的关键选择进行抉择,而非盲目自信或者盲目自卑。一点点抽丝剥茧的将自己适应环境时的缺陷、优势给挖出来,至少真实的暴露在自己的面前,能通过训练改变的改,不能改变的找其他方法规避或者补足,而不再死磕自己不擅长的东西。不大好用“天生我材必有用”一句话概括,需要的是更细致的去理解。很多时候我们能够听到的话都是被高度抽象的,但这不是真实的现实,只是一种假想或者说幻想,更多的时候,我们套在自己身上时,得明确细节是什么,环境是什么,然后才是选择。事物因抽象而简单,因细节丰富多样而复杂。

关于欲望

硬币的正反面,作为移动互联网初代这一批的产品经理,关心用户体验,富有同理心,但另一面就很容易出现一个不是很有欲望/野心的人,在大环境下其实不易拥有大的上升机会。但至少自己可以以一些确定性高一些目标结果为锚点一个个去实现,避免自己陷入缺少欲望/野心这种情况。

关于焦虑

最近两年贩卖焦虑的内容越来越多,也许是大部分确实是现实情况,但让自己也莫名的紧张起来,这种焦虑来自于对未知的不确定性。小一点的就好像每次休假时,接到公司同事的电话,往往不会有什么好事,不自然的就会“咯噔”一下。大一点的关于下一个5年的方向和目标。这个问题目前还没想清楚,也没想好怎么解决,希望21年的记录中,能对这个问题有点想法。

关于投资

这是一个我没什么发言权的领域,但依然想写,最关键的就是大钱不算、小钱打转。在这种心态下,如何有效配合自己心态的投资思路很关键,目前看,基本上认定价值,长期持有的收益还可以,而经常关心,来回操作的投资基本都没赚到什么,估计是典型的被割韭菜心态,最要命的是说不在意吧,跌起来真心疼,说在意吧,每次买入和卖出的时机都很随意,价格也比较随意,还没有好好做点事后总结。这就是之前 另外一位大佬说的在投资领域“还没学会做正确的选择”。

关于问题

问题是价值的第一源头,没有问题,也就不易产生价值。能解决多大的问题,解决问题的手段、能力、资源的价值几乎一样大。但是面对问题,很多时候不易第一反应区分开放式问题和封闭式问题。
开放式问题和封闭式问题难度完全不同,更多的时候我们要解决的应该是封闭式问题,可往往我们认为是开放问题,没有快速的把问题给聚焦、封闭起来,导致来回探索,消耗大量的时间和资源。在开放式问题下快速选择一个有结果的封闭式问题,能够有效降低问题解决的难度、资源和时间消耗。封闭问题越具体越好,将问题最终转化为工程型问题。这个思路可以说是2019年对自己最有价值的一个思路了。

总体上而言,2019发现了自己不少的问题,有的是需要调整的,有的是需要规避的,但缺少了一点更加“强壮”的感受。团队内对2020进行展望讨论时,对生活的期许尽没有想出来,在这个方面确实有点浑浑噩噩了。好在还有三天假期,看看书,再引导引导自己进入思考模式。

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

碎碎念

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


Friday, 22 February 2019

我所理解的产品、服务、解决方案

今天和朋友讨论到这三个概念,很多时候我们因为更明确概念而知道边界和下手的策略
这里记录下我当前所想到的理解:
1.产品服务 价值大于 产品经理服务
产品经理服务=业务方:你给我安排一个产品经理来解决我的问题
产品服务=业务方:你给我提供一个产品支持我的业务,解决我的问题

2.针对问题的确定性差异区分产品与服务
服务=产品+人工运营->提供问题解决的确定性,确定性由服务方保障
产品服务=产品+用户->能够解决问题,但确定性由双方共同保障
解决方案=多产品+多种人工运营+用户->共同解决某个大类下的多个问题集合

3.解决方案
本质:人(内部运营、外部用户)+产品(子项能力+交互操作)针对问题的不断打包和重组,重组的根基在于问题,而重组的思路在于场景、流程和人的职责划分

设计好的解决方案需要不断反复抽象、拆解(包括问题、流程、场景、产品、人的关系),大部分时候产品、能力的重组好理解,而人的问题难理解、需要一定的对人理解的经验,导致解决方案中容易缺失一部分,形成问题的确定性。

Thursday, 13 December 2018

一篇非典型读书笔记

在所谓大公司做事两年半了,开始慢慢了解一些大公司的所谓生存之道。
一直没想明白两个问题:为什么经常在一些会议或者撕逼现场出现原则丢失蒙逼的状态,为什么对产品动作的判断丢失了最重要的决策依据(相比老板的判断)。
之前的理解很粗暴:脑子经常不好使、容易短路。大公司政治环境因素复杂,并不适合自己做出判断。在这个理解下其实已经有一些逃避的态度了,或者说默认。只想着专心做产品本身,当然这没什么不好,只是最近在反思的时候发现思路上的一点调整,很多事情就霍然开朗。

Continue Reading

Monday, 8 October 2018

顺大势而为与顺己势而为

又有一段时间啥也没写了,不是没有想写的东西,只是一旦写起来就停不下来,又觉得挺耗时间(好吧,不会说情愿花三天时间把斗破苍穹给看完了)。

今天下班后,与同事聊到一个问题,也是之前经常反复的一个点。都说要“顺势而为”,很多时候说的是顺大势而为,也就是时刻紧追大环境的变化找到最能够借力的机会点。可越了解自己的时候就会约明白自己其实是一个“顺己势而为”的角色,也就是追逐的是自己的点,当这个“己势”与“大势”不太匹配时,就会需要耐得住寂寞,继续挖掘“已势”同时寻找其与“大势”之间的契合点,微调方向,而不是从根上否定“已势”去追逐“大势”。

Continue Reading

Saturday, 28 April 2018

一次内部产品启动沟通小结

最近团队调整,想要重新做一款内部平台(是一个先期假设),老板要求一个月内描述清楚这个产品,并对内进行沟通。
这就带来两个关键词“内部平台产品”“沟通”,做习惯了对外的产品,你会发现其实内部产品的描述是另一种风格,思考基本框架虽然相似,但面临的问题和挑战却有一些不同,导致一开始找不着北。

当然我也可以说其实整个过程和做产品很像,只是我们自己很多时候没有意识。

Continue Reading

Thursday, 7 December 2017

管理课程学习记录

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

Continue Reading

Tuesday, 15 August 2017

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

前记

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

Continue Reading

Saturday, 4 March 2017

一次迟到的低绩效

2016年对自己而言挺特别的,换了城市,换了工作,买了房子,搞了装修。
说起来,每一件事都能让我这种事事都想做好的人倍感压力,由于很多时候过于理性,反而让自己沉溺其中某些细节,而忘记了什么最重要(很多时候甚至不是忘记,而是选择性忽略,忽略那些难度更高的事情)。

很自然,也很有预期的在工作中获得了一次低绩效,心理其实有数也接受,但往往在预期的时候并没有真实面对时那般窘迫。

说起来,这大半年的工作确实也是在晃晃呃呃中渡过,一方面找不到自己的价值和成就感来源,一方面不了解业务本身又沉不下去,抓不住关键点后又被一些琐事缠身,阶段性总会将精力投入到一些更简单但也很耗时的事情中去,真本身就会产生明显的问题。

Continue Reading

Monday, 23 January 2017

猴年最后一天班

年前最后一天班,不想参与任何项目只想好好收收心,去想想这大半年的得失。有时候想事情总是从得失出发显得挺功利的,但为了越来越清楚自己是谁,功利就功利吧。

Continue Reading