第一部分 To B or not to B
1 B 端产品经理
如何理解B端产品?
B端产品主要分为两大类:
为公司的管理服务,如:HR系统、OA系统;
为公司的运营服务,如:供应链系统、ERP系统的。
B端产品即要符合商业组织的战略要求,能够满足商业用户需求,将已有商业运行逻辑进行系统化、信息化、高效化处理。两类都是为企业流程效率服务,让分散的、低效的个体,更好地连接合作,发挥集成化的、系统化的更大作用。
相较于C端产品,B端产品最大的特点是:面向特定领域用户,且数量少得多,但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强,与业务的结合更紧密。
2 B 端产品经理的职业生涯
B端产品经理工作:
B端产品经理职业生涯:产品专员/产品助理>产品经理>高级产品经理>产品总监
1.产品专员/产品助理:关注具体执行层面的协作,对产品的需求细化,以及对原型的设计和文档的整理
2.产品经理:主要关注推动产品迭代、产品的实现与效果、数据和业务、感知业务和产品的发展方向。
3.高级产品经理:主要关注商业价值和模式,以及和产品的全生命周期思考问题。
4.产品总监:主要关注战略规划、业务发展以及团队管理。
在这条职业发展路径的每个阶段关注的重点不同,要掌握的技能虽多,但不是每一种都需精通,可借鉴“二八原则”:真正重要的知识,或者在实践中被反复使用的知识,只占全部知识的20%。也就是说,20%的知识是需要反复修炼形成骨架的,剩下的80%在此基础上不断更新迭代。所以产品人要一直学习在路上。
3 以精益思想为产品方法
花更少的人,更少的设备,更少的时间和空间为客户提供真正想要的东西。
理念一:快。快时成本与效率的解决之道。
理念二:流动产生价值。长时间没开发的需求就慢慢变得不实用要定期回顾他的价值或重新设计。
理念三:采用最简单的方案。面对各有优劣方案举棋不定面对复杂流程而苦恼时,选取简单的方案是最优选择,结构简单的系统往往是最可靠的。
理念四:处在联系中的事物才能被简化。简化不是减少,将需要简化的部分在系统中进行了转移。
理念五:不害人的需求不是完整的需求。无论多坏的改变,都会有一些人收益;无论多好的改变,都会使一些人受损。在设计规则时,要多角度的考虑获益或者受损的角色。
理念六:化散乱为规律,化应急为预测。懂得预测需求,否则就会疲于奔命。
理念七:只可图示,不可言传。能用图表示的会更直观,更有助于发现问题。
理念八:让公路排满车,就是堵车。将工作焦点转移到重要不紧急的事情上去。
理念九:聚焦目标才能带来明确的结果。做产品如果想讨好所有的用户就会分散目标,变得平庸。
理念十:持续改进,不忘初心。做出的产品方案需要不断优化,同时不断回顾最初目标防止跑偏。
理念十一:细节体现专业。对事物的不断细分才能体现专业性。
理念十二:不要造永动机。思考产品要从整体思考,不要陷入细节。
理念十三:先准确,后精确。探索需求,先力求需求准确,再在此基础上精确的探索需求。
第二部分 单个产品管理流程
B端产品经理的工作流程归纳为五个阶段:
产品规划→产品设计→产品研发→数据监控
1. 规划阶段:基于组织的目标和战略,获取并分析需求,规划B端产品的发展方向和路径
我们要从规划阶段开始设计我们的B端产品,在规划阶段,我们要开展市场调研、用户调研、产品路线规划、需求分析、需求管理等活动,这些活动分布在《用户体验要素》的战略层和范围层,即主要关注目标和实现目标的边界。
这一阶段主要是产品经理要考虑的,作为刚入门的产品小白来说,可以先从了解行业动态开始,通过“人人都是产品经理”网站、喜马拉雅“36氪”等各种途径来了解,可以在茶余饭后与同事朋友聊聊,开拓思路。
2. 设计阶段:基于需求和规划,设计产品信息架构、原型、交互、UI方案等
在设计阶段,我们要开展设计信息架构,设计产品原型、设计交互、设计UI等活动。这些活动分布在《用户体验要素》的结构层、框架层和表现层,即要在界定的边界内勾划出最终输出物大体轮廓和具体执行方案及最终的输出物—产品。
这一阶段涉及到具体执行层面,也是产品专员或产品助理应该重点关注的环节。目前阶段产品经理已经通过规划和分析需求了解到用户想做什么了,这一阶段即让概念进入产品化阶段。先不要急打开axure,我们需要先梳理出业务流程图和信息架构图,在此基础上再去进行细化,为了防止我们画原型时缺页面可以先梳理出页面流程图,最后再一气呵成完成你的原型设计。
3. 研发阶段:根据已经设计好的产品方案,设计技术实现方案及推动产品研发。
我们完成了设计阶段的工作后,将进入到研发阶段。在研发阶段,产品经理要协助研发开展产品开发工作。这个活动分布在《用户体验要素》的表现层,即关注最终的产出物—产品。虽说产品经理不需要写代码,但要承担项目管理、协助研发理清需求、协助测试开展测试以推进产品开发。
在这个过程中,需要随时随地解答技术人员对需求的疑问以及协助测试人员将优化和bug分类整理,并安排优先级进行分批处理。
4. 发布阶段:制订产品发布前的部署和培训计划,推动产品上线。
B端产品在完成研发后,将进入发布阶段。在发布阶段,产品经理要开展制定产品发布方案、发布产品的活动。这些活动分布在《用户体验要素》的框架层和表现层。即关注具体的业务流程和最终的产品。
在这个阶段前,要确认以下信息做好充分准备:
1.产品是否具备待上线条件,比如是否有测试报告,是否得到使用方的验收通过;
2.产品的操作手册和培训安排是否完成;
3.产品上线时间是否合适,确保不要影响其他业务的操作。其他细节这里不赘述。
5. 监控阶段:监控产品上线后的效果,收集并分析用户反馈的信息,并形成新的需求。
在发布B端产品之后,产品经理将进入监控阶段。在监控阶段,产品经理要开展制定关键指标、收集及分析反馈信息的活动。这些活动分布在《产品体验要素》的框架层和表现层,即主要关注具体的业务流程和最终的产品。在监控阶段,产品经理要使用数据来监控产品上线后的效果,以及收集用户的反馈意见,最终为开启新的单个产品管理流程做准备。
上线一段时间后,需要产品经理写上线邮件,主要目的有三个:
1.总结与记录:总结项目过程,未来翻查资料速度超快;
2.项目推动:产品上线后才是开始,需要推动、协调各方资源;
3.团队润滑剂:给参与者帮助你的人正面反馈。监控阶段手机的新需求和反馈进行整理分析,用于后期优化产品。
总体来说,B端产品经理主要关注3个方面:表现层、领域层、数据层。
表现层:即用户界面,用户直接与系统进行交互和操作;
领域层:是商业和业务逻辑,是核心关注点;
数据层:关注是系统之间的交互与数据存储,系统之间会以接口的形式传送数据,关注接口传输性能、传输内容等。
4 规划阶段:产品设计的开始
一、产品规划:调研市场→调研用户→规划产品路线→分析需求→管理需求
在规划行动方案之前,一定要记得先问自己:有什么事情我“今天”做了,可以让“明天”更好,或者至少让“明天”不会更糟。
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等分),每个需求的分数是唯一的。优先做分数大的需求。
优先级和重要性一旦确定,所有的资源将向这些需求倾斜。处理跨部门的需求时,使用优先级尤为重要,但重要性的分数不能跨部门比较。
5 设计阶段:产品从概念到解决方案
产品设计:设计产品架构→设计产品原型→设计交互→设计 UI
1.设计产品架构:设计让产品立得住的骨架
需要:产品发展路线图、需求说明文档、需求排期计划
方法: 设计信息架构(三要素:情景、内容、用户)→输出站点地图(UML)
指标: 站点地图
信息架构(收纳信息)
信息架构三要素:情景,内容、用户。
信息架构五组件:组织系统、标签系统、导航系统、搜索系统,
组织信息:根据时间字母等对信息进行组织分类。
给信息加标签:用一个名称对大量的信息进行概括,就是给信息加入了标签,便于快速查询。
设置找到信息的路径:导航
搜索信息:搜索功能
描述信息的特征:通过各种条件筛选数据。
站点地图(原型设计起点)
各页面的层级关系。b端产品的四种基本页面类型:表单页、详情页、列表页、Dashboard页
表单页:用户向系统增加、删除、提交信息的操作页面。
详情页:展示详细信息。
列表页:向用户展示结构化的数据信息。列表页的设计大部分来自用户对实际数据的操作和展示。
Dashboard页:仪表盘,监控系统运营情况。
2.设计产品原型:高效产出原型的方法
需要:站点地图、需求说明文档
方法: 交互设计、排版、axure 技能、
指标: 产品原型、PRD 文档
模式思维
模式,指可以重复使用的方式和方法。类似于乐高积木原理。
以厨房设计为例,厨房空间需要炉灶、水槽、食物储存区、操作台四个区域。以上四个部分距离不能太大在3m以内,操作台的范围大致在1.2-3.6m。要在一个页面上满足用户多种活动需求,比如信息查看、搜索、下载等,每种活动对应一种解决方案,这个解决方案就是模式。设计模式是由组件组成,组件是构成设计模式的基本元素。
因此设计产品原型的流程:
1、根据站点地图,找到要设计的页面类型。(列表页、表单页、详情页、Dashbard页等)
2、根据页面类型对应用户操作行为,思考出各自对应的模式。
3、用组件搭建成对应的模式。各种模式的布局和组合最终形成产品原型。
总结属于自己的设计模式
1、模式名称:给自己的模式起个名称,便于管理交流。比如,搜索单据。
2、概念和价值:描述清楚这个模式是什么,即给模式下一个定义。写清楚给用户带来什么价值。
3、使用范围:该模式相关的边界条件。比如在用户登录情况下,向用户推荐常用信息。
4、模式描述:用文字图片等形式描述清楚模式由哪些组件构成及该模式是如何运行的。如:用户在输入框录入关键词时,会实时展示提示信息,便于用户选择。
5、相关模式:与这个模式相关的模式还有哪些。
三种精度的产品原型展示
低精度原型:即页面流程图,展示页面中的关键组件及页面之间的跳转流程。
中精度产品原型:像照片一样,展示包含所有组件的页面,主要展现页面布局。
高精度产品原型:详细展示原型中各个组件在不同操作下所展示的信息。
需求文档加上 网站地图及产品原型就为产品需求文档。
3.设计交互:让B 端产品简单易用
B端产品更加偏重于工具属性,注重帮助用户完成工作效率和效果。所以,设计C端产品的交互更像是设计一本赏心悦目的小说,设计B端产品更像是一本产品说明书,需要追求使用的高效和易学性。
4. 设计UI:如何与设计师高效沟通
跟设计师的合作注意以下几点:
主动学习设计知识,如:常逛逛Dribble、优设、站酷之类的设计网站,提高自己对设计的认知。同时,了解公司或团队的设计规范。
明确指出设计重点,表达顺序。明确页面中重点功能是什么,使用者在什么场景下使用,以及希望用户重点使用的界面组件和信息有哪些。
给出设计案例。可以找一些比较好的设计案例给设计师参考,指出案例中哪些元素可以参考。
尼尔森十大可用性原则
系统状态可见:用户能够随时获得产品反馈的信息,会让用户产生对产品的信任和安全感。
系统与真实世界匹配:要参考真实环境使用的单据和报表,将其映射在产品中。
用户掌控和自由操作:用户可以自由退防护或者结束当前任务。
一致性和标准化:让界面元素和操作形成一套让用户可识别、可学习的标准,并且在产品的任何地方都可以应用。
避免错误:需要检查一下界面的按钮是否可能产生误触。
直接识别比记忆好:产品要减少用户的记忆负担。
灵活高效地使用:要不断地提高界面使用效率
美观和简约的设计:设计要简明突出。
帮助用户识别、诊断和解决错误:着重关注给用户反馈的操作信息,且尽可能以友善的态度表达。
帮助和文档:需要在界面上提供必要的使用帮助,并整理出专门的产品使用文档帮助用户学习。
6 研发阶段:产品方案的实现
产品研发:项目启动→规划→执行→监控→收尾
1.项目启动
说明项目目标、阶段划分、组织结构、管理流程等关键事项
2.规划
明确研发工作内容以及各需求点的研发、测试负责人,评估研发时间,制定排期计划表
3.执行 (一个Java项目的标准开发流程)
总体设计→概要设计→详细设计→编写代码→代码审核→单元测试→集成测试→系统测试→发版上线
4.监控
对项目输出成果或者阶段性成果进行检查,看看是不是我们想要的或是缺少了什么
PS:需求看板可以有效管理各需求进度,防止需求堆积拥堵导致项目不能按时交付
5.收尾
试用、培训、维护、项目回顾复盘
项目管理
在研发阶段,产品经理需要承担起项目管理的义务,协助研发和测试同事,以推进产品开发。
项目管理的四个维度:范围、时间、质量、成本。
可对应的项目目标:多、快、好、省。
1、核心问题,什么是项目?项目是为创造独特的产品、服务或者成果而进行的临时性工作。据此对项目有三个定义。
项目有明确的开始和结束,也就是项目有明确的开始时间和结束时间。没有明确开始时间和结束时间的活动称之为运营。运营是一个通过连续不断的工作来交付成果。
项目会产生成果。最终提供用户使用的产品功能。
项目计划随着项目的开展而逐渐详细。项目会随着计划的开展展现很多之前未考虑到的细节
2、项目目标,多、快、好、省在将要延期的情况下可以考虑砍掉部分功能而不要增加开发资源。
3、项目计划:
项目风险管理:
项目风险:如果发生不确认的条件和时间,会对一个或多个项目目标造成影响。
项目沟通:
原则:不论采用何种手段,邮件、微信、电话、面谈,信息的发出方一定要保证接收方能够收到并且理解信息,做出反馈。
项目推进:
推进项目的重要基石是:标准化——标准化指完成某项工作的最佳工作方法。
产品经理可以将项目过程遇到的问题及处理方法、人员配合方式、项目流程等经验或文档分享给其他项目成员,推而广之,达成大家的共识。
比如:
项目会议纪要模板:帮助大家高效输出内容完备的会议纪要。
上线验收清单模板:让大家按照清单和步骤执行可以减少出错、提高效率。
项目工作流:明确各自角色的任务及配合时间点,团队配合更紧密。
标准化可以避免项目再次陷入相同的错误中。沿用成功的工作方法、经验,让项目不断被顺利推进。
而在研发日常跟进中,可以采用看板模式来记录和跟进。看板管理需要注意的就是:避免某个阶段的需求出现拥堵,或者是一旦发现拥堵,要及时疏解。
需求卡片可以包含如下信息(工具Trello、Teambition)
1、需求名称
2、需求的相关人:需求人、负责人、产品经理、研发工程师
3、需求类型:如需求涉及哪些系统、哪些部门等
4、需求完成时间
5、需求描述:可以附上产品文档
6、需求优先级
7 发布阶段:产品上线的临门一脚
上线前需确认的信息:
产品是否具备上线条件,比如:是否有测试报告,是否得到使用方的验收。
产品的操作培训是否完成,或者是否至少有使用说明文档。
产品上线时间是否合适。产品上线的时间点是否会影响其他业务操作,是否需要配合整体的运营计划。
产品发布:
产品推广产品,可运用营销推广模型的核心思路:描述一个重要的问题,并让大家认同,之后介绍产品给出的解决方案。
营销推广模型分7步:
背景介绍:介绍所发布产品的背景信息,比如:时间、地点、任务、事件等信息,便于大家了解背景知识,从而减少认知负担。
描述阻碍:描述用户目前会遇到的问题,并让大家认同该问题确实会给自己带来不便。
点燃希望:向大家说明这个问题有解决方案,引起打击的期待和注意。产品经理客户可以介绍这个问题的解决方案,及概念或者同行业对这个问题的解决思路。
震撼登场:抛出问题的解决方案——即发布的产品是什么。
展现价值:描述这样的解决方案和产品会给用户带来怎样的价值和收益,可以配数字,这样会更有说服力。
精雕细琢:介绍产品重要的细节、工作原理。
给出诱惑:给大家送一些福利,让大家快来体验产品。这里可以根据实际情况来选择使用。
发布一款产品或者介绍一个功能并不都需要发布会的形式,产品经理可以应用简单有效的演讲框架快速打动用户。
8 监控阶段:让产品不断生长
8.1 制订数据指标及目标:产品演进的航标
8.1.1 数据指标的黑箱和二律背反
8.1.2 关键成功因素法:制订数据目标的方法
8.2 收集及分析反馈信息:整装待发
8.2.1 零基础快速入门SQL 的方法
8.2.2 与用户座谈的产品回顾会
数据监控:制定关键指标→收集分析反馈信息
1.制定关键指标
方法:关键成功因素法,输出OGSM表(如图)
定位长期目标→制定对应的短期目标→找到实现短期目标的关键成功因素(CSFs)→确定 CSFs 实施的测量方法
2.收集及分析反馈信息
产品回顾会:制定会议章程(会议邀请邮件)→展现事实(影响/问题)→集思广益(问题&方案)→决定做什么(总结行动项、负责人、deadline)→总结和公告(整理会议纪要)
产品监控数据指标:
数据监控应该监控什么才有意义,从黑箱、仪表盘和二律背反理论中我们可以得到一些启发。
黑箱:
我们只能输入和输出,而并不知道事物真正运行的原理是什么,比如:电商网站的输入是用户进站浏览,输出是订单。那用户在浏览网页所做的行为和决策就是黑箱。 通过研究黑箱,我们可以提升用户转化率。
仪表盘:
通过汽车的仪表盘速度、耗油量等数据指标,随时反馈出汽车的状态。没有仪表盘的汽车随时都有失控的危险。对系统运行状态的监控也是,数据指标要尽可能覆盖全面,比如:出现问题的次数、加载时间、业务相关数据等。
二律背反:
二律背反指规律中的矛盾,在互相联系的两种力量的运动规律之间存在的相互排斥现象——即两种事物此消彼长、此长彼消、相背相反。
因此,我们除了关注数据指标之间的相关性,更需要找到这些处在二律背反的指标,然后进行指标配对。通过指标配对,防止过度监控或者提升一个指标而带来副作用,用另一个指标来辅助分析和监控,从而权衡出好的办法以解决问题。
德鲁克说:如果没办法计量就没办法管理。数据指标就是管理量化的表现。监控部分数据指标来监控系统的运行状态,如B端产品数据指标包括出现问题的次数、加载时间、以及业务相关数据指标。
制定数据目标思路:关键成功因素法
定位长期目标。产品经理找到组织或者团队的长期目标是节省成本。
为了实现长期目标,需要制定对应的短期目标。如在长期目标的基础上拆解出短期要完成的目标是减少包装成本。
找到实现短期目标的关键成功因素。如实现减少包装成本的短期目标可以做的工作是系统推荐使用的包装盒形状等。
确定关键成功因素实施的测量方法。找到所要实现目标所要做的事情后,需要一个标准来测量是否施行到位。如,我们使用推荐准确率达到90%的指标来监测。
数据采集:
SQL是查数据和做报表的工具,建议产品经理都要学:
SQL可能是最容易入门的编程语言。因为他书写出来的代码,完全是按照英语语法,是初中语法中最简单的部分。只要学习非常少的SQL知识,或者说是几个英语单词,就可以快速在工作中使用。
使用频率非常高。
有助于产品经理理解数据分析的思路。
SQL 入门手段:
《SQL基础教程》,这本书内容实用且基础,适合零基础的人学习,且它描绘了很多使用场景。
找一名程序员同事当老师,随时实践、随时请教问题。
在监控指标时需要注意的细节:
制定数据目标的原则:具体、可衡量、可实现、有相关性、有截止时间。
根据关键成功因素的分析思路最终输出OGSM表。OGSM是Obiective(长期目标)、Goal(短期目标)、Strategy(策略)、Measurement(测量方法)名词的首字母。形成另一种展现形式长期目标:节省成本短期目标策略/关键成功因素测量方案行动方案减少包装成本系统推荐包装盒形状系统推荐率达到90%的指标Q1完成功能研发产品回顾会
制定会议章程。会议前产品经理发送邮件包括开会目标、会议议题、时间地点、会议流程、参与人员、准备资料等。产品经理要保障会议内容简单明了,以及重要人员可以出席。会议开始后产品经理也要重申会议章程内容,让与会者明确会议议题。
展现事实。阐述与产品相关的实际情况,上线后对业务运营数据的影响,或产品出现的问题和故障有哪些?记录会议内容,控制好节奏。
集思广益。陈述完事实后,讨论找到解决方案。
决定做什么。讨论完成后产品总结会议后的行动项,以及行动的负责人和完成时间,便于会议内容的追踪和落实。
总结和公告。会议收尾时,产品经理作为主持人要总结本次会议所有参会人都同意的重要结论。散会后将结论总结为会议纪要发给相关人来备忘。
第三部分 产品经理的自我管理
1、帕金斯定律人在做一件事情时,耗费的时间越长就会感到越累。
2、产出=活动*杠杆率越符合组织、团队战略或目标的活动越具有高杠杆率。
3、提升工作速度
建立收件箱:产品经理不要被当前来的事情打断,让当前来的事情进入收件箱,然后分配时间去处理。
把场景相同的活动放在一起做:把类似的事情集中在一起做,减少任务切换的时间。
找到关键路径:产品经理在必须做的事情中可以插入可以并行的工作。
制定每天的活动计划:每天开始要预想一天的工作,哪些是重点工作,哪些是可以放到一起做的工作。但也不要把每天的工作排的非常满,导致没有时间应对紧急情况。
合理拒绝别人的猴子:对于做不了或者暂时没时间做的工作坚决说不。如果在接受事情前,没有评估好是否能保质完成,那就违背产品经理的职责。
学会番茄工作法:没工作一段时间就休息一会。
不主动,工作没有重点,求大求全是产品经理的绊脚石。
4、产品力
产品经理的技能可以分为硬技能和软技能。
硬技能包括:用户调研、产品规划、需求分析与管理、产品方案设计、数据分析等。
软技能包括:项目管理能力、时间管理能力、沟通能力等。
5. 产品力的获得途径
作者的个人情况或习惯:
喜欢看书、涉猎历史、哲学、科学、经管、互联网、技术等各个领域的书籍。
把写书列为一个长期的目标,规划了5年左右的时间。
因为B端产品经理的知识没有成型理论和体系,所以,作者立志填补这项空白。期望自己的总结和思考,为中国产品经理职业发展提供理论和实践的支持。
为了写书,查阅大量现有的互联网、经管类书籍,还有大量的软件工程类书籍,以及学术论文。
查阅资料注重追溯知识本源,了解知识的核心要义。
本书展示了作者对B端产品经理的理解,介绍了B端产品经理的工作流程、工作方法、工作场景,以及作者在工作中的经验总结。
喜欢跟研发同事散步聊产品和设计,在无拘无束的畅谈中总结自己对产品的看法和观点。
以上,可以了解到作者身上几个难能可贵的品质:
对世界充满好奇。在好奇心的驱动下,习得的知识非常宽广。
对产品工作发自肺腑的热爱。兴趣让学习、规划和实践更加纵深。
目标驱动、规划落地。目标明确,为达目标时刻准备。
喜欢追根溯源。了解知识时追求本源,学习知识时抓核心要义。
持续学习,知识内化,不断总结和输出。工作实践不断总结成经验和方法,形成自己的理论体系,揉碎成通俗易懂的生活例子阐释。
寻求好的实践经历。在好的项目、工作环境中迸发出更多的灵感和提升。
原文链接:产品读书《B端产品经理必修课:从业务逻辑到产品构建全攻略》_女王の专属领地-CSDN博客_b端产品经理必修课
原创文章,作者:奋斗,如若转载,请注明出处:https://blog.ytso.com/311099.html