赞
踩
很幸运的是2019年3月份读完了这本B端产品经理必修课,今天也就是2019年11月25日整理书籍再次拿出来看的时候,自己已经身在小米,主要是我当时忘记这本书的作者就是现在的同事宽同学了,了解其人,更要从书中再去品味。
产品经理的沟通技巧:沟通、说服、谈判、演讲、辩论。
ABC理论:假设影响行为,行为最终影响结果。在沟通过程中要以结果为导向,抛弃偏见,以开放的态度与每个人沟通。
绊倒产品经理的6个绳索:
- 太在意过程。要明确目标,以结果为导向。
- 胡言乱语。要明确沟通目的。
- 不推不动。积极主动是一个好习惯。
- 不学习。多读书、看新闻、参加沙龙,不要停止好奇与学习。
- 焦头烂额:要学会时间管理,分清优先级。
产品经理:为创造价值而生。案例:《未来的传奇——波音747的故事》
第一部分 To B or not to B
如何理解B端产品?
B端产品主要分为两大类:
B端产品即要符合商业组织的战略要求,能够满足商业用户需求,将已有商业运行逻辑进行系统化、信息化、高效化处理。两类都是为企业流程效率服务,让分散的、低效的个体,更好地连接合作,发挥集成化的、系统化的更大作用。
相较于C端产品,B端产品最大的特点是:面向特定领域用户,且数量少得多,但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强,与业务的结合更紧密。
B端产品经理工作:
B端产品经理技能树:
B端产品经理职业生涯:产品专员/产品助理>产品经理>高级产品经理>产品总监
在这条职业发展路径的每个阶段关注的重点不同,要掌握的技能虽多,但不是每一种都需精通,可借鉴“二八原则”:真正重要的知识,或者在实践中被反复使用的知识,只占全部知识的20%。也就是说,20%的知识是需要反复修炼形成骨架的,剩下的80%在此基础上不断更新迭代。所以产品人要一直学习在路上。
花更少的人,更少的设备,更少的时间和空间为客户提供真正想要的东西。
第二部分 单个产品管理流程
B端产品经理的工作流程归纳为五个阶段:
- 产品规划→产品设计→产品研发→数据监控
1. 规划阶段:基于组织的目标和战略,获取并分析需求,规划B端产品的发展方向和路径
我们要从规划阶段开始设计我们的B端产品,在规划阶段,我们要开展市场调研、用户调研、产品路线规划、需求分析、需求管理等活动,这些活动分布在《用户体验要素》的战略层和范围层,即主要关注目标和实现目标的边界。
这一阶段主要是产品经理要考虑的,作为刚入门的产品小白来说,可以先从了解行业动态开始,通过“人人都是产品经理”网站、喜马拉雅“36氪”等各种途径来了解,可以在茶余饭后与同事朋友聊聊,开拓思路。
2. 设计阶段:基于需求和规划,设计产品信息架构、原型、交互、UI方案等
在设计阶段,我们要开展设计信息架构,设计产品原型、设计交互、设计UI等活动。这些活动分布在《用户体验要素》的结构层、框架层和表现层,即要在界定的边界内勾划出最终输出物大体轮廓和具体执行方案及最终的输出物—产品。
这一阶段涉及到具体执行层面,也是产品专员或产品助理应该重点关注的环节。目前阶段产品经理已经通过规划和分析需求了解到用户想做什么了,这一阶段即让概念进入产品化阶段。先不要急打开axure,我们需要先梳理出业务流程图和信息架构图,在此基础上再去进行细化,为了防止我们画原型时缺页面可以先梳理出页面流程图,最后再一气呵成完成你的原型设计。
3. 研发阶段:根据已经设计好的产品方案,设计技术实现方案及推动产品研发。
我们完成了设计阶段的工作后,将进入到研发阶段。在研发阶段,产品经理要协助研发开展产品开发工作。这个活动分布在《用户体验要素》的表现层,即关注最终的产出物—产品。虽说产品经理不需要写代码,但要承担项目管理、协助研发理清需求、协助测试开展测试以推进产品开发。
在这个过程中,需要随时随地解答技术人员对需求的疑问以及协助测试人员将优化和bug分类整理,并安排优先级进行分批处理。
4. 发布阶段:制订产品发布前的部署和培训计划,推动产品上线。
B端产品在完成研发后,将进入发布阶段。在发布阶段,产品经理要开展制定产品发布方案、发布产品的活动。这些活动分布在《用户体验要素》的框架层和表现层。即关注具体的业务流程和最终的产品。
在这个阶段前,要确认以下信息做好充分准备:
- 1.产品是否具备待上线条件,比如是否有测试报告,是否得到使用方的验收通过;
- 2.产品的操作手册和培训安排是否完成;
- 3.产品上线时间是否合适,确保不要影响其他业务的操作。其他细节这里不赘述。
5. 监控阶段:监控产品上线后的效果,收集并分析用户反馈的信息,并形成新的需求。
在发布B端产品之后,产品经理将进入监控阶段。在监控阶段,产品经理要开展制定关键指标、收集及分析反馈信息的活动。这些活动分布在《产品体验要素》的框架层和表现层,即主要关注具体的业务流程和最终的产品。在监控阶段,产品经理要使用数据来监控产品上线后的效果,以及收集用户的反馈意见,最终为开启新的单个产品管理流程做准备。
上线一段时间后,需要产品经理写上线邮件,主要目的有三个:
- 1.总结与记录:总结项目过程,未来翻查资料速度超快;
- 2.项目推动:产品上线后才是开始,需要推动、协调各方资源;
- 3.团队润滑剂:给参与者帮助你的人正面反馈。监控阶段手机的新需求和反馈进行整理分析,用于后期优化产品。
总体来说,B端产品经理主要关注3个方面:表现层、领域层、数据层。
- 表现层:即用户界面,用户直接与系统进行交互和操作;
- 领域层:是商业和业务逻辑,是核心关注点;
- 数据层:关注是系统之间的交互与数据存储,系统之间会以接口的形式传送数据,关注接口传输性能、传输内容等。
一、产品规划:调研市场→调研用户→规划产品路线→分析需求→管理需求
在规划行动方案之前,一定要记得先问自己:有什么事情我“今天”做了,可以让“明天”更好,或者至少让“明天”不会更糟。
1.调研市场:找B端竞品。
目的:分析产品可能存在的盈利点,获取行业经验和方向
需要:产品创意、行业信息
方法:商业模式画布、SWOT分析、竞品分析
指标:竞品分析报告、商业需求文档
- 明确目的。想清楚你要查询的信息,定好方向再起步。
- 与业务同事沟通。咨询业务同学竞品名字。
- 了解专有名词。如ERP、WMS,通过搜索专有名词找到可用资料。
- 找到同类SaaS产品。
- 搜索信息渠道。知乎、简书,知网、万网。
2.调研用户:倾听用户声音。
目的:分析和研究产品使用者
需要:竞品分析报告、商业需求文档、产品创意
方法:用户研究方法(问卷调研、用户访谈等)
指标:用户调研报告
- 用户的话不能全信。为了引起重视而故意夸大,害羞或怕说错话不去表达真实想法。
- 能有的功能,用户都希望有。人性贪婪。
- 明确词语含义。“我希望报表更快一点”“更快一点”就需要进一步明确。
- 尽量不要问有固定选项的问题。列选项即使没有他也会选择。不认让用户给选项打分0-10分。
- 重述用户所说。将用户的话用产品经理的语言再说一遍,让用户判断说的对不对。
- 别让用户预测。不要让用户设计产品,与未来相比用户当下的行为更有准确性。
师徒制,三段式问法:请教>刨根问底>核实
1)发现问题:你正在做什么事情?做的过程中有什么不舒服的吗?遇到了什么问题?
2)分析流程:你现在用什么方法来解决整个问题?
3)探索机会:为了更好的解决整个问题,你认为有什么方法可以帮到你?或者哪些地方可以优化下?
3.规划产品路线:缩小现在与未来的差距
目的:规划产品路线、节奏
需要:竞品分析报告、商业需求文档、产品创意、用户调研报告
方法:
指标:产品发展路线图Roadmap(实现时间、名称、目标、功能、优先级、度量标准)
有产品目标后要做好目标管理,规划行动方案,实时反馈并验收成果。
1、分析和预测需求。
产品经理首先要明确与产品成败相关的因素。要了解用户对各因素的期望。之后用现在和未来的时间维度去分析获得信息。从现在和未来的角度发现差异,目前用户从我们产品获得什么?是否让其满意?接下来用户还希望产品有哪些功能?
2、现状分析。
分析目前自己的产品处于什么状态。目前该产品与行业优秀产品有什么区别?
3、缩小差距。
- a、用头脑风暴列出为缩小差距所要做的事情。
- b、思考从目前的约束条件列出清单中可以做的事情。
- c、已经选出的事情会使产品有怎样的结果,最好能够测量。
- d、给结果排序,列出优先级及期望实现日期。
4.分析需求:用图形代言需求
目的:将需求具体化
需要:竞品分析报告、商业需求文档、产品创意、用户调研报告
方法:筛选需求(需求蛋模型)→思考需求(D×V×F>R)→解析需求(UML统一建模语言)
指标:需求说明文档
需求应有的特征:
- 痛点:好的需求犹如根治用户痛处的良药。B端产品通过调研用户基本可提炼出痛点。
- 收益:需求应有可量化的结果导向。
- 明确、可行、简单的第一步:挖掘需求就是降低需求中的含混性,使之明确。如果在需求落地成型阶段才发现含混性,这个时候的改正成本实在是太高了。
需求的变革公式:不满情绪*变革愿景*初步实践>变革阻力。对现状的不满、对变革的期盼、愿意迈出明确的第一步等其中任何一个因素没做到将导致变革失败。
- 需求的可行性=(需求的当前价值+未来价值)/(需求的实现成本+维护成本)
- 解析需求:数据驱动,行为产生数据,数据联系行为。数据流动形成数据流,从而把业务中的人联系在一起。
举例设计一个咖啡馆的管理系统
- 1、画流程图先把主要流程总结出来。
进店——点餐——下单——制作食物——送餐——就餐——结账——离店
- 2、对主要流程进行细化。如果流程图中的活动数量超过7+-2的范围,则颗粒度太细或太粗。
比如将点餐流程进行细化
- 3、实体关系图(ER图)
数据之间三种对应关系:一对一、一对多、多对多
- 一对一:顾客就餐完成后需要支付自己的账单。顾客1——1账单
- 一对多:服务员工作可以为多个顾客服务。服务员1——n顾客
- 多对多:面包、咖啡等可以被不同客人点单。菜品n——n顾客
数据对象的属性也是一类数据,用来描述数据对象,并且多个数据对象可以包含相同的属性。如何区分数据对象和属性:xx单、xx表一般都是数据对象,数据对象区别于其他实物独立存在的个体,数据对象一般能用量词“类”来形容。数据对象的属性数据可被用来增删查改,可以通过该来查漏补缺。
- 4、数据流程图
数据:表示数据流,连接数据流程图的各元素。
外部实体:外部实体表示系统之外的人或事物,它可以成为整个数据流的起点或者终点。
数据储存:存储数据的区域。在现实中,可能是单或者表格表格。
活动操作:对数据进行操作,包括数据的流入和流出。
- 5、用例图
用例是对产品功能需求的描述。
需求文档
- 1、需求名称
- 2、背景
- 3、目标与收益
- 4、功能需求。业务概念、流程展示、需求描述。
- 5、非功能需求
5.管理需求:打造简单可实践的需求池
目的:将需求具体化
需要:产品发展路线图、需求说明文档、产品创意
方法:需求收集(急诊模式)→需求设计(登机模式)→需求研发(看板模式)
指标:需求池、需求排期计划
需求的重要性:为了区分同一优先级的多个需求,可以用重要性来辅助优先级管理需求。
重要性就是对需求进行打分,分数范围是1—100分(根据5个优先级可以分成5等分),每个需求的分数是唯一的。优先做分数大的需求。
优先级和重要性一旦确定,所有的资源将向这些需求倾斜。处理跨部门的需求时,使用优先级尤为重要,但重要性的分数不能跨部门比较。
产品设计:设计产品架构→设计产品原型→设计交互→设计 UI
1.设计产品架构:设计让产品立得住的骨架
需要:产品发展路线图、需求说明文档、需求排期计划
方法: 设计信息架构(三要素:情景、内容、用户)→输出站点地图(UML)
指标: 站点地图
信息架构(收纳信息)
站点地图(原型设计起点)
2.设计产品原型:高效产出原型的方法
需要:站点地图、需求说明文档
方法: 交互设计、排版、axure 技能、
指标: 产品原型、PRD 文档
模式思维
模式,指可以重复使用的方式和方法。类似于乐高积木原理。
以厨房设计为例,厨房空间需要炉灶、水槽、食物储存区、操作台四个区域。以上四个部分距离不能太大在3m以内,操作台的范围大致在1.2-3.6m。要在一个页面上满足用户多种活动需求,比如信息查看、搜索、下载等,每种活动对应一种解决方案,这个解决方案就是模式。设计模式是由组件组成,组件是构成设计模式的基本元素。
因此设计产品原型的流程:
总结属于自己的设计模式
三种精度的产品原型展示
需求文档加上 网站地图及产品原型就为产品需求文档。
3.设计交互:让B 端产品简单易用
B端产品更加偏重于工具属性,注重帮助用户完成工作效率和效果。所以,设计C端产品的交互更像是设计一本赏心悦目的小说,设计B端产品更像是一本产品说明书,需要追求使用的高效和易学性。
4. 设计UI:如何与设计师高效沟通
跟设计师的合作注意以下几点:
尼尔森十大可用性原则
- 系统状态可见:用户能够随时获得产品反馈的信息,会让用户产生对产品的信任和安全感。
- 系统与真实世界匹配:要参考真实环境使用的单据和报表,将其映射在产品中。
- 用户掌控和自由操作:用户可以自由退防护或者结束当前任务。
- 一致性和标准化:让界面元素和操作形成一套让用户可识别、可学习的标准,并且在产品的任何地方都可以应用。
- 避免错误:需要检查一下界面的按钮是否可能产生误触。
- 直接识别比记忆好:产品要减少用户的记忆负担。
- 灵活高效地使用:要不断地提高界面使用效率
- 美观和简约的设计:设计要简明突出。
- 帮助用户识别、诊断和解决错误:着重关注给用户反馈的操作信息,且尽可能以友善的态度表达。
- 帮助和文档:需要在界面上提供必要的使用帮助,并整理出专门的产品使用文档帮助用户学习。
产品研发:项目启动→规划→执行→监控→收尾
1.项目启动
说明项目目标、阶段划分、组织结构、管理流程等关键事项
2.规划
明确研发工作内容以及各需求点的研发、测试负责人,评估研发时间,制定排期计划表
3.执行 (一个Java项目的标准开发流程)
总体设计→概要设计→详细设计→编写代码→代码审核→单元测试→集成测试→系统测试→发版上线
4.监控
对项目输出成果或者阶段性成果进行检查,看看是不是我们想要的或是缺少了什么
PS:需求看板可以有效管理各需求进度,防止需求堆积拥堵导致项目不能按时交付
5.收尾
试用、培训、维护、项目回顾复盘
项目管理
在研发阶段,产品经理需要承担起项目管理的义务,协助研发和测试同事,以推进产品开发。
项目管理的四个维度:范围、时间、质量、成本。
可对应的项目目标:多、快、好、省。
1、核心问题,什么是项目?项目是为创造独特的产品、服务或者成果而进行的临时性工作。据此对项目有三个定义。
2、项目目标,多、快、好、省在将要延期的情况下可以考虑砍掉部分功能而不要增加开发资源。
3、项目计划:
项目风险管理:
项目风险:如果发生不确认的条件和时间,会对一个或多个项目目标造成影响。
项目沟通:
原则:不论采用何种手段,邮件、微信、电话、面谈,信息的发出方一定要保证接收方能够收到并且理解信息,做出反馈。
项目推进:
推进项目的重要基石是:标准化——标准化指完成某项工作的最佳工作方法。
产品经理可以将项目过程遇到的问题及处理方法、人员配合方式、项目流程等经验或文档分享给其他项目成员,推而广之,达成大家的共识。
比如:
标准化可以避免项目再次陷入相同的错误中。沿用成功的工作方法、经验,让项目不断被顺利推进。
而在研发日常跟进中,可以采用看板模式来记录和跟进。看板管理需要注意的就是:避免某个阶段的需求出现拥堵,或者是一旦发现拥堵,要及时疏解。
需求卡片可以包含如下信息(工具Trello、Teambition)
上线前需确认的信息:
产品发布:
产品推广产品,可运用营销推广模型的核心思路:描述一个重要的问题,并让大家认同,之后介绍产品给出的解决方案。
营销推广模型分7步:
发布一款产品或者介绍一个功能并不都需要发布会的形式,产品经理可以应用简单有效的演讲框架快速打动用户。
8.1 制订数据指标及目标:产品演进的航标
- 8.1.1 数据指标的黑箱和二律背反
- 8.1.2 关键成功因素法:制订数据目标的方法
8.2 收集及分析反馈信息:整装待发
- 8.2.1 零基础快速入门SQL 的方法
- 8.2.2 与用户座谈的产品回顾会
数据监控:制定关键指标→收集分析反馈信息
1.制定关键指标
方法:关键成功因素法,输出OGSM表(如图)
定位长期目标→制定对应的短期目标→找到实现短期目标的关键成功因素(CSFs)→确定 CSFs 实施的测量方法
2.收集及分析反馈信息
产品回顾会:制定会议章程(会议邀请邮件)→展现事实(影响/问题)→集思广益(问题&方案)→决定做什么(总结行动项、负责人、deadline)→总结和公告(整理会议纪要)
产品监控数据指标:
数据监控应该监控什么才有意义,从黑箱、仪表盘和二律背反理论中我们可以得到一些启发。
我们只能输入和输出,而并不知道事物真正运行的原理是什么,比如:电商网站的输入是用户进站浏览,输出是订单。那用户在浏览网页所做的行为和决策就是黑箱。 通过研究黑箱,我们可以提升用户转化率。
通过汽车的仪表盘速度、耗油量等数据指标,随时反馈出汽车的状态。没有仪表盘的汽车随时都有失控的危险。对系统运行状态的监控也是,数据指标要尽可能覆盖全面,比如:出现问题的次数、加载时间、业务相关数据等。
二律背反指规律中的矛盾,在互相联系的两种力量的运动规律之间存在的相互排斥现象——即两种事物此消彼长、此长彼消、相背相反。
因此,我们除了关注数据指标之间的相关性,更需要找到这些处在二律背反的指标,然后进行指标配对。通过指标配对,防止过度监控或者提升一个指标而带来副作用,用另一个指标来辅助分析和监控,从而权衡出好的办法以解决问题。
德鲁克说:如果没办法计量就没办法管理。数据指标就是管理量化的表现。监控部分数据指标来监控系统的运行状态,如B端产品数据指标包括出现问题的次数、加载时间、以及业务相关数据指标。
制定数据目标思路:关键成功因素法
数据采集:
SQL是查数据和做报表的工具,建议产品经理都要学:
SQL 入门手段:
在监控指标时需要注意的细节:
制定数据目标的原则:具体、可衡量、可实现、有相关性、有截止时间。
根据关键成功因素的分析思路最终输出OGSM表。OGSM是Obiective(长期目标)、Goal(短期目标)、Strategy(策略)、Measurement(测量方法)名词的首字母。形成另一种展现形式长期目标:节省成本短期目标策略/关键成功因素测量方案行动方案减少包装成本系统推荐包装盒形状系统推荐率达到90%的指标Q1完成功能研发产品回顾会
第三部分 产品经理的自我管理
1、帕金斯定律人在做一件事情时,耗费的时间越长就会感到越累。
2、产出=活动*杠杆率越符合组织、团队战略或目标的活动越具有高杠杆率。
3、提升工作速度
不主动,工作没有重点,求大求全是产品经理的绊脚石。
4、产品力
产品经理的技能可以分为硬技能和软技能。
5. 产品力的获得途径
作者的个人情况或习惯:
以上,可以了解到作者身上几个难能可贵的品质:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。