您的位置 : 首页 >> 经济管理电子书

决胜B端 产品经理升级之路

copyright

☞温馨提示:想直接推送电子书到手上的kindle吗~ 点击此处购买本书正版即可☜ 限时折扣,先到先得
决胜B端 产品经理升级之路
本书作者:杨堃

本书读后感· · · · · ·

公司领导对此书的评价是没有世界观,有些low。我的评价高一些,这本书不仅适用于初级入门,对中高级产品梳理自己的知识树也是不错的工具书。特别是3-6章,是精华所在,虽然每个点讲得不精深,但基本面都覆盖。全书以一套分销系统为例进行讲解,虽然失之广博,但更有利于读者领会。工作类书籍总是理解简单上手难,读者容易轻视书上的内容。但比起市面上其他基本b端产品书籍,这本书更言之有物、言之有理。

我的学习笔记

致谢写书是一件痛苦并快乐的事情,从2018年2月确认全书的内容大纲、2018年3月开始写作,到2019年1月完成初稿,然后经历了多次反复修改,直到2019年4月完成终稿,这本书的写作耗时近一年半,可以说凝聚了我的心血。 P15

决胜B端 产品经理升级之路 经济管理电子书 第1张新形式带来的新挑战是,如何通过线上渠道导入流量、提高转化率:需要通过各种运营手段,吸引有购买保险诉求的客户进入公司网站或landing page(着陆页);需要保证自己的产品界面清晰、交互友好,以实现让尽可能多的潜在客户转化为成交客户;同时通过各种策略和机制,鼓励客户帮助产品传播口碑,引入更多流量和销售线索。 P40

例如,我们熟悉的电商,对于消费者来说,只需要使用App挑选商品、下单、收取快递,退款退货也都能在App中轻松完成。 P41

常见互联网公司的盈利模式可以概括为四类,分别是广告变现、增值服务、佣金提成、买卖差价,每一类盈利模式都有自己的产品建设诉求,以及独特的运营和管理模式。 P50

同样,各家公司为了尽最大可能地利用流量,给广告主提供优质服务,也都选择自主研发广告投放和管理产品。 P51

百度、今日头条的目标客户是所有中小企业,上千人规模的电销呼叫中心团队不停地打电话寻找线索、商机,说服客户投放广告;美团、饿了么的目标客户是所有商家,上千人规模的地推团队挨街挨巷地拜访门店,说服客户进行曝光推广。 P52

决胜B端 产品经理升级之路 经济管理电子书 第2张过去,大家的固定支出可能只有水费、电费、有线电视费,现在,邮箱服务、视频服务、音乐服务、存储服务、个人助理App需要的花费,也都成为固定开销了。 P53

例如,对于外卖公司来说,配送员的效率是业务成败的决定因素之一,而配送员的效率取决于TMS的建设情况。 P64

此外,行业之间、领域之间的信息打通,全面线上化也是势在必行的,2B和2G领域的消费者和客户都希望享受更加便利、优质的服务。 P65

B端产品经理既要涉足软件设计领域,又要涉足业务运营领域,有机会接触并深入理解企业运作机制,而我们知道,无论商业模式如何创新,企业的运作机制都是相通的。 P66

技术知识储备规划、设计B端产品需要讲究体系架构、模型抽象,这和技术体系架构是一脉相承的,甚至很软件技术架构的设计思想也会体现在B端产品的设计中,例如SOA、微服务。 P71

业务与经营管理知识B端产品经理从某一个细分业务方向入手,可以收获丰富的业务知识,从业务的角度理解公司的运转。 P72

举个例子,我之前的一位同事去某电商做了配送产品经理;两年后,O2O火了,配送方向的人才紧缺,他被一家外卖公司挖去做配送产品负责人;又过了两年,同城闪送火了,因为他在配送业务领域积累了专业和丰富的经验,所以他加盟了某闪送公司,成为产品合伙人,统管产品研发和业务运营。 P73

咨询顾问现在很多互联网公司都会将自己的成熟技术方案、解决方案进行商业化包装,并向外输出,此时产品经理要承担售前咨询顾问的工作,与销售团队一起发展客户,帮助客户分析业务问题,给出解决方案。 P74

根据服务的对象,大体上可以将B端产品划分为三个方向:支持业务团队的业务平台方向、支持员工内部协同的办公协同方向,以及平台业务模式中支持供给方的商家管理方向,这三个方向覆盖了企业对内、对外所有的经营管理与业务运营工作。 P76

广义上的CRM包括从客户开发、管理、营销、服务的客户全生命周期管理;狭义的CRM是指给销售人员使用的销售过程管理软件。 P77

第一种情况不需要设计完整的产品,只需要设计一个方案,让业务以最低成本做初步尝试,论证可行后再考虑产品化支持。 P96

通过业务调研找到关键业务问题,这是设计产品解决方案的核心前提。 P97

运营迭代新系统上线后,产品经理要和业务人员一起参与产品的运营迭代工作,包括宣传、推广、使用效果分析、问题和反馈意见的收集,以及持续的迭代优化。 P100

其中,C端产品的建设流程是根据经验总结抽象出的常见流程,不同的需求和背景下的流程可能略有不同。 P102

当然,如果是一家SaaS软件公司,设计的B端产品要卖给具体客户,那么设计的起点就和C端产品一样,是进行商业分析,而不是进行业务调研。 P103

在实践中,需要结合具体情况选取合适的调研方法,例如,某业务团队一共有10人,可以很方便地对每个人都进行访谈,因此就没有必要准备调查问卷了;又如,某个项目预留的调研时间非常紧迫,因而无法安排轮岗实习。 P113

需要注意,设计良好的B端系统能够规范流程、提升效率,但这不代表所有的业务问题、管理问题都可以通过软件系统来解决。 P114

那么,面对一项并不熟悉的复杂业务,该从何处切入呢?我们可以参考典型的业务分析框架,如图4-2所示,我们按照它拆解并分析业务,就可以分析得全面、透彻,梳理出现状,总结出问题。 P115

产品经理要当一个冲在前线的人,而不是在后方拍脑袋的人。 P123

避免诱导性问题在问卷设计中,要避免诱导式的提问,例如“我们要做一个更好的个人管理功能,您会使用吗?”而要尽量采用中性描述,例如,“您使用这款产品的体验如何?”也尽量不要设置非此即彼的问题,例如“您是否喜欢我们的产品呢?”可以提供多个描述主观感受的选项供调研对象选择。 P124

管控模式通过对业务负责人的访谈,我们了解到M公司对下属部门采取了事权下放的管控模式,下属部门在遵守基本规则的前提下拥有售卖定价权、运营管理权等权利。 P130

通过梳理组织架构图可以理解人员结构和岗位设计,为系统的权限管理设计做好准备。 P131

图表采用了经典的泳道流程图,横轴代表相关的业务部门,纵轴代表涉及的业务系统。 P132

由于生鲜价格实时变化,和客户签订的商务合同又要求在商品售价的基础上按一定折扣出售,因此下单人员每次需要根据客户提报的采购清单拉取当天的商品售价,按照该客户的折扣系数表换算售卖价格,再手工改价录入订单系统。 P133

但是我们不可能一次实现全部功能,而要根据业务优先级,拆分成几期来完成,所以接下来需要做减法:确认产品的功能规划与实现节奏,就是常说的演进蓝图(Roadmap)。 P151

例如,报表管理功能可以通过定期运行SQL语句实现;价格系数设置功能的使用频率低,可以由RD在后台改数据库完成;缺少搜索、推荐功能并不会对客户下单的效率产生明显影响,因为根据调研,目前每个客户维护的SKU数量最多也不过20个。 P152

设计软件产品时必须遵循自顶向下的设计思路,这是非常重要的,相信大家已经有了初步的感觉。 P153

本章将首先介绍业务数据建模,这是对业务进行抽象的过程,合理的建模会让后续的功能设计水到渠成,而不合理的建模会导致后续设计重复返工。 P154

为什么产品细节方案设计要从业务数据建模开始呢?这是因为软件系统的模块和功能实际上就是对现实世界的对象和规则的抽象。 P155

因此,产品经理最终决定采用一套简化版的客户模型来支持一期业务,不过这个简化版客户模型完全可以在需要时升级为理想版的客户模型。 P159

根据上述规则对理想版客户模型进行简化,如图6-4所示。 P160

如果没有梳理清楚这些关系,在做功能和界面设计时必然会一头雾水、漏洞百出。 P161

可见,设计人员在设计之初就需要做好预判,虽然早期业务诉求中账号和门店是一对多关系,但是因为在现实世界中多对多关系是一种合理的存在,因此数据模型依然要按照多对多的关系来设计。 P162

反馈原则(Visibility of system status)系统应该在合理的时间、用正确的方式,向用户提示或反馈目前系统在做什么、发生了什么。 P175

在人机交互设计中,程序的沟通和表达、功能的呈现,都要用最自然的、用户容易理解的方式,避免采用计算机程序语言的表达方式。 P176

对于误操作,软件系统应该尽量提供“撤销”“重做”或“反悔”的功能,让系统迅速返回错误发生之前的状态。 P177

如果你特立独行地把个人中心放在第一个位置,或者采用奇怪的图标作为个人中心的icon,用户使用时肯定会觉得别扭。 P178

这样做一方面可以让问题更简单,另一方面可以让用户避免或减少无谓操作。 P179

列表页是B端产品中最重要、最常见、最基本的元素,并且列表页的设计非常讲究技巧,因而我们将列表页设计单独列出一节,详细阐述。 P185

我们可以对列表页进行高度抽象,因为在所有列表页上实现的不外乎增删改查操作。 P186

其次,增加某个搜索条件之后,还可以设置它的默认搜索值,例如可以对图6-22左侧虚线框中的“PRD开始日期”字段设置搜索默认值,从图中也可以看到,JIRA的日历控件功能非常强大,可以进行各种时间检索类型的设置,比如过去多久以内、多久之前、某个时间范围之间等,非常灵活。 P187

从什么维度进行汇总?这里面蕴含了观察、监控业务的视角和思路,因而汇总表的设计具有较高的难度,需要产品经理和业务人员、领导层等一起讨论决定,形成一套科学的指标体系,来准确、有效地监控业务运转中的各种情况。 P196

例如,我们需要监督并考核线下销售团队,该如何设计一套分析体系来进行合理的评估、管理呢?可能的思路是对销售过程和销售结果两个方向进行监控诊断,对于销售过程,重点在于判断销售人员的努力程度,可以进一步拆解为电话拨打量、线下拜访量、客户线索录入量等;对于销售结果,重点在于判断销售的业绩是否达标、利润率是否良好。 P197

但是,随着公司规模扩大,规范的PRD管理是非常必要的,这可以让项目开展更加有序,大大方便产品经理和研发人员的沟通,让知识传播与传承更加准确有效。 P234

特别提醒,模板中有明确的版本变更记录表格,产品经理必须严格填写变更记录表,记录文档修订历史。 P235

如果没有标识清楚,多次收到修订文件的同事会分不清哪个文档是最新的,极有可能搞错版本,造成工作错误,引起很多不必要的麻烦。 P239

懂技术的产品经理在设计产品方案时,能够在一定程度上预估技术实现的可行性和实现成本,或至少能具备基本的认知,知道什么时候、什么情况下需要和技术人员提前沟通讨论,从而保证产品设计合理可行,既能提升合作效率,也能赢得技术人员的尊重和信任。 P259

避免技术过度设计所谓技术过度设计,是指技术人员设计了没有必要的代码灵活性和复杂性,而后续的业务根本用不到这些特性,宝贵的时间和资源被浪费。 P260

决胜B端 产品经理升级之路


↓下载地址
本文版权归原作者所有,请支持正版。此处仅提供个人读书笔记 https://yigefanyi.com/jueshengbduan-chanpinjinglishengjizhilu/