启示录
2020-06-16 10:37:50 0 举报仅支持查看
AI智能生成
读书笔记
启示录
读书笔记
模版推荐
作者其他创作
大纲/内容
第一部分:一些教训
产品失败的根源
实践与理论的鸿沟
用户愿意买单的才是好产品,用户只是喜欢却不愿买单的,没有使用的必要性
过分依赖瀑布工作方式,脱离敏捷开发
精益与敏捷开发的本质
最先解决问题,而不是放到最后
产品的定义与设计师同步进行的
产品始终是为了解决实际问题,而不是实现功能
缺少优秀的产品经理
一个领导产品团队结合技术与设计,用符合业务需求的办法,解决用户真正的问题的人
关键概念
整体产品
完整的产品概念
功能设计
技术实现
能带来的收益
如何推广等
持续发现和持续交付
一边发现刚需产品
一边由工程师交付产品
产品发现
区分哪些是好点子,哪些是坏点子
这个功能用户是否需要
这个功能用户是否知道怎么用
这个功能可以带来什么收益
原型
最低成本的产品
产品交付
打造并交付确保质量并能销售和推广的技术产品
产品-市场契合度
实实在在的产品才是好的产品
通常表现为拥有更快乐的客户、较低的流失率、缩短的销售周期、快速的增长
初创公司或新产品第一阶段最重要的目标
产品愿景
避免假大空,为了让团队保持一致的大方向
第二部分:合适的人
产品团队
遵循原则
各司其职、定义好每人的目标
互相协作、发挥每个人的优势
团队自主、每个明确的目标都可以用每个人自己的方式实现
产品经理
关键责任
产品经理对整个产品负责,决定做什么、怎么做
四个期望职责
深厚的客户知识
深厚的数据知识
深厚的业务知识和清楚利益相关者
深厚的市场和行业知识
智慧、创意和持之以恒
智慧:对世界充满好奇心,快速学习并利用新技术提升产品
职责描述
深刻的业务理解
满足业务需求,解决用户问题的方案提供
无授权领导力,向CEO看齐,同时不具备CEO的权力
产品设计师
产品发现
好的产品设计师不只让产品更美观,更能一起发现更好的产品
完整的用户体验设计
用户体验UX、用户界面UI
原型设计
用户测试
不是为了测试功能,而是测试产品是否被用户接受?为什么?哪里需要修正
交互与视觉设计
设计缺乏的三个问题
产品经理做产品设计
开发工程师做产品设计
产品经理提供交互设计(线框),然后用视觉设计器、图形设计器完成设计
合作的建议
让产品设计师参与你的一切工作
在创意设计阶段就让产品设计师参与
让产品设计师与你一同接触用户和客户,使其完全理解业务和用户
避免指手画脚,给产品设计师更多的发挥空间
让产品设计师通过迭代和渐进完成设计,而不是一开始就追求完美的设计
开发工程师
要了解他们的工作内容、清楚他们的工作强度
将产品目标与用户需求完整分享,使他们有主人翁意识
在任意阶段都需要工程师的帮助或参与,聆听不同的观点,吸纳各种方案,才能呈现好的产品
产品营销经理
辅助角色
用户研究人员
一般为定性采集
数据分析师
一般为定量分析
自动化测试工程师
人员与规模
领导角色
产品管理领导
产品设计领导
技术组织领导
产品主管
竞争力
团队发展
产品愿景和策略
执行力
产品文化
经验
能处理与CEO、CTO等高管的私下关系
技术主管
组织、领导、交付、架构、发现、传播福音
交付经理角色
组建产品团队的十个原则
P98
P98
第三部分:正确的产品
产品路线图
管理层目的
知道员工首先做的是重要的事
明确计划,关键节点推动哪些计划
大多数产品组织浪费和失败的根本原因
替代方案
关注业务结果,而不是功能产出
高信用承诺
在确定能够真正解决问题的方案和对应成本前,不轻易承诺,一旦承诺,必将履行
产品愿景
产品愿景
激励团队并确定方向
产品战略
帮助团队实现愿景,通常是分阶段的
帮助团队实现愿景,通常是分阶段的
产品愿景原则
从为什么开始
相比解决方案,请更热爱提出问题
不要害怕远见卓识
不要害怕打乱自己
产品愿景需要激励
确认并拥抱哪些相关且有意义的趋势
关注事物变化的方向
大方向坚持,细节处灵活
实现任何产品愿景都是一种信仰的飞跃
持续不断的布道
产品战略原则
一次只专注于一个目标市场或一类角色
产品战略需要与业务战略保持一致
产品战略需要与销售战略以及上市战略保持一致
关注客户,而非竞争对手
组织全体成员参与沟通战略
产品原则
产品愿景所描述的产品的实质
OKR
原则
永远不要告诉别人改怎么做,只需告诉他们需要做的事,他们便会用新颖创意为你带来惊喜
结果决定绩效,使进展的度量变得有意义
技术要点
目标(objectives)应该是定性的,关键结果(key results)需要可量化或可度量
关键结果应该是衡量业务结果,而非目标产出或任务完成
产品相关组织应该关注组织整体的目标,以及为此组建的产品团队本身的目标,不让个人目标或职能团队的目标淡化或干扰焦点
为组织寻找一个适当的节奏
通常,设定组织目标一年一次为宜,团队目标一季度一次为宜
让组织和团队的目标与关键结果数量少一点
典型的数量是一到三个目标,每个目标一到三个关键结果
每个产品团队要根据目标在跟踪当进度
通常每周一次
目标应该涵盖必须完成的任务,但不需要涵盖所有琐事
让团队对其目标有责任感
就组织如何评估或为关键结果评分达成一致
建立一个极其明确且同意的判定方法
每个产品团队的目标和进展,要保持非常透明(在整个产品和技术组织中)
高层对组织目标和关键结果负责
产品团队目标
如果你在组织中使用OKR,关键点是将OKR集中在产品团队级别上,而不是个人级别
产品目标与规模
在大规模使用OKR时,要确保组织真正一致,每个产品团队都应知道如何适应多级别的OKR,以及为此需要做什么
产品布道:推销梦想,激励团队
使用原型
让对方清楚地看到局部与整体
分享痛点
最好让对方亲自看到或体验到痛点
分享愿景
确保自己对愿景的理解,展现出是如何促成这一愿景并终于原则的过程
毫无保留地分享经验
不光是顺利的事,遇到的问题也要分享
毫无保留地信任
让团队认识到产品是团队的,不是个人的,当事情不顺利时,站出来对失误负责,并总结教训,团队会因此尊重你
学习如何给出一个精彩的演讲
不是教学,也不是测试,是为了说服别人
做好功课
越专业才越容易让别人信服
发自内心的兴奋
如果高觉不到兴奋,要么更换工作,要么更换角色
学会表现出狂热
让人看到你发自内心的兴奋,狂热具有感染力
多花时间和团队成员相处
花时间和每个人相处一段时间,去影响他们的动力、效率
第四部分:正确的过程
产品发现两大挑战
了解客户解决方案的细节需要什么
需要对很多创意进行彻底测试
测试过程要快且廉价
以期望找到能解决大部分客户的真正问题
确保交付一个超棒和可扩展的产品
需要快速学习,才能在发布产品时保持自信
产品发现的目的,解决重要的风险
价值风险
客户会购买或选择我们的产品吗
可用性风险
客户知道如何使用我们的产品吗
可行性风险
我们能打造出优秀的产品吗
业务可行性风险
这个产品对我们的业务有用吗
伦理道德角度
产品发现的原则
不能依赖客户
用心听,但不要照着做,Y模型
最重要的事情就是创造有目共睹的价值
在产品发现过程中,需要花费大量时间在寻找产品的核心价值
好的用户体验更难且更重要
功能、设计和技术本质上是互相关联的
很多创意不会奏效,奏效的也需多次迭代
以开放的心态采用各种不同的方式来解决最根本的问题
产品发现过程中的迭代,远比交付时的迭代高效,省去时间和精力
必须基于真实的用户或客户来验证创意
我们无法预测客户的反应
要在花钱花时间构建产品之前验证,而不是之后
产品发现的目标就是尽可能以最快、最廉价的方式验证创意
在产品发现过程中,验证创意的可行性,而不是之后
确保产品可行之后才打造
能尽早获得工程师的反馈,有助于完善解决方案,促进共同学习
在产品发现过程中,验证创意的业务可行性
确保产品能满足我们的业务需求
共同学习
发现技术概念分享
发现框架技术
发现工作中的基础框架,以确保一致性并识别关键风险
三种技术
机会评估,适合大多数产品阶段
业务目标
与团队的目标相对应
解决了产品的什么业务需求
关键结果
衡量成功的标准
客户问题
将重点放在客户身上,即使为公司利益,也应试图将其与最终客户利益联系起来
目标市场
特定用户或客户,可以描述为用户画像的群体
客户函件,适合大项目
从客户角度,想象一个重新设计和其带来的好处
是一种逆向工作模式/需求验证模式
初始画布,适合新产品或新业务
及早发现风险,并鼓励团队提前解决
发现规划技术
故事地图(Story Map)
二维地图,横轴是时间,纵轴是用户活动
不急于排列,每人提出自己认为关键的点,最后一起汇总形成用户地图
横向铺开用户的活动顺序,比如登录-点开商品-下单-付款-打印订单
纵向铺开用户的详细活动,如付款:
选择付款方式
跳转第三方支付
支付成功回执页面
客户发现技术
参照客户的力量
定义
一个真正的客户(不是朋友或家人)
使用了你的产品(不是试用版或原型)
付费购买了产品(不是被引诱)
愿意告诉他人有多喜欢此产品(自愿且真诚)
价值
利于明确市场、明确营销用户群
会产生出符合市场的创意和真实的产品
四种变体
为企业量身定制产品
单一目标市场
单一特定的目标市场,具有共性特点和共性需求
招募潜在的参照客户
招募6-8个参照客户,保证6个参照客户
如果招募不到6个参照客户,也许此产品不可行
关系
适用于特定客户群,而不是特定单一客户公司
最好不要让客户提前付费参与项目,会影响产品走向,很容易变成只适用于单一客户公司的项目
参照客户最好具有意见领袖特质,当他们推销你的产品时,大部分人都认为有说服力
打造平台类产品(如公共API)
关注点不是参照客户,而是参照应用程序
打造公司内部员工使用的客户支持工具
对应为6-8位受尊敬的、有影响力的内部用户/员工
为消费者量身定制产品
参照客户变为消费者(10~50名)
需要对产品创意进行更广泛的测试,通常涉及未接触过该产品的人
总结
需要投入很多精力,尤其是产品经理,但有助于打造一个客户喜欢的产品
目的不是发现接下来必须要做的产品,而是参访目标客户,发现一些必要的产品创意来生成参照客户
对于表现产品-市场契合度有突出作用,如果能够在一个特定目标市场中拥有6个参照客户(或几十个参照用户),通常意味着产品适合该市场
发现构思技术
客户访谈
重要性
产品经理最强大且最重要的技能之一
常常是许多突破性产品创意的来源或灵感
访谈需要理解的问题
你的客户是你认为的那种人吗?
他们真的存在你认为的问题吗?
现在,客户是如何解决这个问题的?
他们需要什么才能改变?
客户访谈的建议
频率
定期的访谈,而不是一次性的,可以每周2-3小时
目标
不要去试着证明什么,而要去理解和学习
招募用户与客户
确保他们来自你的目标市场,而不是随机的
地点
在他的生活环境,更能了解。便利的地方或办公室也很好,视频最次
准备
事先弄清楚你认为他们的问题是什么,并考虑如何确认或反驳这一点
参与人员
通常产品设计师(受过专业培训)、产品经理(记录、分析)、工程师(观察)
访谈
努力让访谈自然、非正式,多问开放式的问题,不要试图引导
事后
向同事汇报,看看每个人听到的是否不同
跟踪
访谈结束只是开始,还要用最新产品创意的用户测试来跟踪结果
礼宾测试技术
能快速生成高质量的产品创意<br>
同时致力于培养客户的理解能力和同理心<br>
走到实际客户身边,让他们教你他们如何工作<br>
客户不当行为的力量
允许甚至鼓励客户使用产品来解决计划和官方支持之外的问题<br>
从客户以产品没有预想到的使用方式中挖掘潜在价值<br>
黑客日
定向<br>
存在一个客户问题或已制定的目标<br>
让产品团队中的人员自我组织,头脑风暴,如果合适,用实际的用户测试他们的创意<br>
两项收益<br>
实用性,工程师参与其中,更现实<br>
文化,益于营造主人意识的团队氛围<br>
非定向<br>
人们可以去探索喜爱的任意产品创意,只要它与公司使命沾边<br>
发现原型技术
类别
可行性原型
编写足够的代码减少可行性风险<br>
用户原型
低保真<br>
交互式线框<br>
高保真<br>
实时数据原型
通过极小部分的demo去收集实际的使用数据<br>
混合原型
原型原则
以更低成本学习一些东西,而不是打造一个产品<br>
在深层次上思考问题<br>
团队协作<br>
根据需要选择保真度<br>
目的是在产品发现中解决产品风险,同时提升与工程师交流的效率<br>
发现测试技术
测试可用性
定义<br>
在产品发现过程中,使用原型测试用户是否能轻易学会使用产品<br>
关键点<br>
招募测试用户<br>
符合目标市场<br>
尽量挑选用户自然的环境<br>
测试准备<br>
尽量高保真原型<br>
一人进行一人记录一人观察<br>
原型测试<br>
声明为原型,使用户不担心伤害你<br>
尽量聆听不要诱导,避免提供帮助诱导用户进入设想流程<br>
不只听,更要观看用户的真实反映<br>
重点是深入了解用户,找出并解决原型中的摩擦点<br>
价值测试
需求测试<br>
又称假门需求测试<br>
能够收集到此需求的点击率(用户感兴趣比例)<br>
收获一份愿意讨论此需求的用户名单<br>
定性价值测试<br>
表现出发生了什么或者没发生什么<br>
与快速学习和深刻洞察力相关<br>
首先进行访谈<br>
可用性测试<br>
是价值测试的前提、基础<br>
具体的价值测试<br>
用金钱证明价值<br>
用信誉来展示价值<br>
用时间来证明价值<br>
用访问来展示价值<br>
迭代原型<br>
定量价值测试<br>
收集实际数据,并分析为什么及如何解决<br>
A/B测试<br>
邀请式测试<br>
客户发现程序<br>
分析形式<br>
用户行为分析<br>
点击路径,参与<br>
业务分析<br>
活跃用户,转化率,留存<br>
性能<br>
ASP,账单,关闭时间<br>
运营成本<br>
存储,托管<br>
进入市场成本<br>
收购成本,销售成本,项目成本<br>
情绪<br>
客户满意度,NPS,调查<br>
技术可行性测试
业务可行性测试
不同部门的业务关注点<br>
营销<br>
销售<br>
客户成功<br>
财务<br>
合法<br>
业务发展<br>
安全<br>
首席执行官/首席运营官/总经理<br>
转型技术
发现sprint技术
为期一周的产品发现工作,旨在解决产品团队面临的重大问题和风险<br>
试点团队技术
让组织摆脱路线图
过程与规模
管理利益相关者
利益相关者定义<br>
看他有没有否决权,或是能影响项目启动<br>
管理层<br>
商业伙伴<br>
财务部、法务部、合规部、业务发展部<br>
产品经理责任<br>
了解利益相关者的考虑和约束,并将其带进产品团队<br>
能够说服利益相关者,产品或你的创意有利于他们<br>
沟通产品知识
第五部分:正确的文化
优秀/糟糕的产品团队
振奋人心的产品愿景,团队主人意识。 vs 打工意识
从愿景和目标、观察客户痛点、分析实际数据获取灵感和创意。 vs 从销售和客户那里收集需求
结合关键利益相关者、客户提出方案。 vs 从所有的利益相关者收集信息
擅长很多技术,快速尝试产品创意,确定创意是否值得构建。 vs 在会议上形成优先路线图
善于聆听整个公司的聪明人的想法。 vs 团队之外的人的提议,会感觉被冒犯
产品、设计以及工程同样重要,协作。 vs 各自为战
保护品牌和收入的前提下,不断创新。 vs 等待授权
坚信他们拥有对应的团队技能。 vs 不知道什么是产品设计师
确保工程师有时间在产品发现过程中尝试原型。 vs 最后冲刺阶段才向工程师展示原型并评估
经常和客户接触,并观察他们对新创意的反应。 vs 认为自己就是客户
明白很多创意最终都不会服务于客户,可能需要多次迭代才能达到预期的创意是行不通的。 vs 仅按照路线图构建产品,且只关注会议日期和会议质量
在评估并确保有对客户和业务奏效的方案后,做出高信用承诺。 vs 只会抱怨是销售驱动型公司
对团队的工作进行测试以便了解产品如何运作且基于测试做出调整。 vs 有分析和报告就足够了
不断集成和发布 vs 在集成所有功能后才测试并发布
专注客户 vs 专注竞争对手
获取非常重要的业务成功时进行庆祝 vs 发布完产品就情况
失去创新的首要原因(没有满足的)
以客户为中心的文化
振奋人心的产品愿景
目标明确的产品战略
优秀的产品经理
稳定的产品团队
工程师参与产品发现工作
企业的勇气
被授权的产品团队
产品思维
创新的时间
失去速度的首要原因
技术债务
缺乏优秀的产品经理
缺乏交付管理
发布周期长
缺乏产品愿景和产品战略
团队成员工作地点不同,成员经常变更
没有尽早的让工程师参与产品发现工作
没有在产品发现中使用产品设计,而是工程师直接构建产品
改变事情优先级
统一的文化
构建一种强大的产品文化
持续创新文化
测试文化
开放思维文化
授权文化
技术文化
业务、客户、精明的团队三位一体的文化
技能组合和员工多样性文化
发现技术的文化
执行文化
紧迫感文化
高信用承诺文化
授权文化
责任文化
协作文化
结果文化
认可的文化
Collect
Get Started
Collect
Get Started
Collect
Get Started
Collect
Get Started
评论
0 条评论
下一页