启示录（第二版）：如何创造用户喜爱的产品
2021-06-24 22:25:28 1 举报AI智能生成
登录查看完整内容
为什么谷歌、脸书的产品全世界数以亿计的用户都喜欢？你可能不知道，它们的产品开发模式与大多数公司很不一样。在本书中，科技产品管理领域的思想领袖马丁？卡根给读者带来了生动的大师课：如果要创造出用户喜爱的产品，如何搭建结构？如何安排人员？如何授权？如何高效组织？也就是说，如何发现用户喜爱的产品，并且把它交付出来。
作者其他创作
大纲/内容
启示录（第二版）：如何创造用户喜爱的产品
客户访谈
你的客户是你认为的那种人吗？
他们真的存在您认为的问题吗？
现在客户是如何解决这个问题的？
他们需要什么才能改变？
建立定期的客户访谈频率
尽快去理解和学习
招募用户与客户
在他们的家乡寻找客户
事先弄清楚，你认为他们的问题是什么病？考虑一下你将如何确定或反驳这一点？
谁应该参加，产品经理，产品设计师团队中的工程师
访谈
向同事汇报情况，看看你们是否都听到了同样的事情，是否学到了同样的东西？
礼宾测试技术
它能快速生成高质量的产品创意，同时致力于培养客户的理解能力和同理心，这对于激励团队并交付强有力的解决方案非常重要
理念就是我们亲自为客户服务
礼宾测试需要走到实际的用户和客户身边，让他们教你，他们是如何使用工作的，这样你就可以学习如何完成他们的工作，并为他们提供一个更好的解决方案
客户不当行为的力量
尝试评估市场机会，选择潜在的具有丰富利润且存在巨大痛苦的领域
看看技术或数据能实现什么，并将其与巨大的痛苦结合起来
允许其甚至鼓励客户使用我们的产品来解决我们计划和官方支持之外的其他问题
黑客日
定向和非定向
在非定向的黑客中，人们可以去探索他们喜欢的任何产品创意，只要他与公司的使命稍微有点关系就可以
对于定向的黑客日存在一个客户问题，或已经制定的目标
第二个收益是文化
可行性原型
用户原型
实时数据原型
混合原型
原型原则
原型有很多种形式，选择哪种最佳的原型取决于正在处理的特殊的风险，以及产品类型
所有形式的原型都有明确的特征和收益，五个关键原则如下
任何形式的原型，首要目的都是以低成本学习一些东西，而不是打造一个产品
认识到任何形式的圆形的关键好处，就是强迫你在一个更深层次啥思考问题，而不是仅仅讨论或记录一些东西
原型也是团队协作的强大工具
对一个原型，来说有很多不同程度的高保真
原型的主要目的是在产品发现过程中解决一个或多个产品风险
可行性原型技术
算法
性能
可扩展性
容错
使用团队以前未使用过的技术
使用团队以前从未使用过的第三方组件或服务
使用团队以前从未使用的遗留系统
依赖其他团队，新的特性或相关变化
用户原型技术
产品发现中最强大的工具之一，是一种模拟
存在各种各样的原型，有一些用户原型保真度较低
创建用户远秦的工具很多，有不同的类型设备，有不同的级别的保证度
我们有更好的技术来验证价值，所以了解用户原型不适合什么也是很重要的
这是产品团队中最重要的技术之一，因此，创建各个级别的用户原型所需的技能和经验是非常值得你的团队去积累的
实时数据原型技术
在花费时间和金钱构建一个实际可扩展和可交付的产品之前，我们需要在发现过程中收集好这些数据
实时数据原型比最终产品小得多，并且在质量性能和功能方面也大大降低
真实用户会使用实时数据引擎进行工作，这会产生真实的数据分析，我们可以将它与当前的产品或我们的预期进行比较，从而了解这种新方法是否更好
混合原型技术
我们探讨过纯粹模拟的用户原型
用于解决技术风险的可行性原理，用于收集数据或统计学上显著性检验的实时数据运行，以检验一个产品或创意的有效性
产品发泄的过程，实际上就是在尝试解决分配到手的业务问题的同时，迅速将好的创意从一堆不好的创意中分离出来
用户或客户会选择使用，还是购买价值？
用户能搞清楚怎么使用吗？可用性
我们能构建出这个产品吗？可能性
产品方案对我们的业务是否有长期效果？业务长效性
测试可用性
可用性测试是典型的最成熟和直接了当的产品，发现测试形式已有多年历史
如果公司拥有自己的用户研究小组，则请竭尽全力确保他们能为团队花更多时间
招募用户进行测试
如果你按我之前描述的那些建立了客户房建的项目，那么很可能你已经不再需要做其他事情了
如果有用户的电子邮件地址列表，可以从中筛选
你可以在公司网站上招募志愿者
你可以置身于用户聚集的任何地方
如果要求用户到你所在的地址，你可能需要为他们所花的时间作为补偿
测试准备
我们常用高保真度的用户原型进行可用性测试
在测试之前，要先明确任务级，通常这些是显而易见的
我们要让一个人管理可用性测试，另一个人负责记录
另一个非常有效的场景是客户的办公室
原型测试
当你首次进行真实的可用性测试时，请务必向测试对象讲明，这是一个原型，一个非常早期的产品，创意并不是真实的
看看他们能否从圆形的登录页上看出你做了什么，尤其是吸引了他们，对他们有价值
测试时要尽可能的保持用户处于使用模式，而不是批评模式
在测试过程中，要学会的主要技能是保持安静
用户没有任何问题
用户挣扎和抱怨了很久，但最终通过了
用户大失所望的放弃了
要避免提供任何帮助或以任何形式的指导用户
行为表现的像鹦鹉一样，这在很多方面有帮助
从根本上说，我们试图了解目标用户如何思考这个问题，并找出圆形提供的模型中与用户思考问题的方式不一致，或不兼容的地方
从用户的肢体语言和态度上能够得到大量信息
重点是要更深入的了解和客户，当然还要找出并解决原型中的摩擦点
价值测试
客户并非一定要买我们的产品，用户也可以选择不使用某些功能
许多公司和产品团队认为他们需要做的是提供具备相应功能的产品，却不明白为什么产品低价出售仍然滞销
客户必须认识到你的产品确实更好，才能激发购买产品的积极性，并克服从原来方案中迁移的困难和阻碍
需求测试
定性价值测试
定量价值测试
需求测试技术
造成时间精力浪费和无数创业公司失败的最大原因之一是当团队设计，并构建了产品，接着测试可用性可靠性性能等完成了，他们认为应该完成的一切，然而，当产品最终发布时，却没有人购买
需求测试技术被称为假门需求测试，思路是我们在用户体验中设置，我们认为应该设置的按钮或功能菜单
相同的基础概念适用于整个产品
定性价值测试技术
定量测试告诉我们发生了什么或没发生，但不能告诉我们为什么发生，以及如何纠正这些情况
定性测试不是为了证明什么，证明是定量测试的目的
首先进行访谈
可用性测试
具体的价值测试
用金钱来证明价值
用信誉来展示价值
用时间来证明价值
用访问来展示价值
迭代原型
定量价值测试技术
电信测试都是关于快速学习和深刻洞察定量技术，都是关于收集证据
AB，测试
邀请测试
客户发现程序
分析作用
了解用户和客户的行为
衡量产品进度
证明产品的创意是否有效
说明产品决策
激励产品工作
技术可行性测试
我们知道怎样构建产品吗？
我们的团队是否有技术来构建产品？
我们有足够的时间来构建产品吗？
我们是否需要改动任何架构来构建产品？
我们手头有构建产品所需的所有组件吗？
我们了解构建产品所涉及的依赖关系吗？
产品的性能可以接受吗？
它可以扩展到我们需要的规模吗？
我们是否有测试和运行所需要的基础架构？
我们负担得起发布的成本吗？
测试业务可行性
构建出一个客户喜欢，并且工程师能够开发交付的产品，实现它困难的很多产品没能做到这一点
营销
销售
客户成功
财务
合法
业务发展
安全
首席执行官，首席运营官，总经理
奈飞的产品经理Kate Arnold
通过提供订阅服务，让人们注册一个月，并提供不限量的影片，他确实够好，事实上，人们确实改变了他们的消费行为，固定的月费和不限量的影片听起来很划算
坏消息是奈飞为他们自己制造了实实在在的困扰
他们有30天的免费试用时间，这位团队赢得了额外时间
我们一直在谈论发现成功产品的技术，但是产品团队和公司运营新的技术，并以不同的方式工作，说起来容易，做起来难，认识到这一点很重要
一个非常明显的例子是从唯利是图的产品路线图驱动，以产品为中心的团队转变为有实力，以业务成功衡量的产品团队，代表着一种重大的文化转变以及控制权，从管理层到团队成员的转移
发现sprint技术
旨在解决你的产品团队正面临的重大问题或风险
谷歌他们的模式通常是花一周的时间与初创公司合作，手把手教他们如何做产品发现
在为期一周密集的发现工作中，你以及你的团队可能会发现十种不同的产品，创意和方法，目的是解决一些重要的业务问题
当团队有一些大的且非常重要的或难以处理的事情时
当团队要学习，如何做产品发现时
当事情进展太慢，团队需要重新调整进展时
试点团队技术
在一个组织中，有些人喜欢变化，有些人希望先看到别人的成功案例，有些人需要更多的时间来消化变化，而有些人则讨论变化，他们只有在被迫改变时才作出改变
在更广泛实行之前，先将变化推广到组织中的一小部分
寻找一个产品团队，作为志愿者，并尝试一些新技术
试点团队与其他团队的目标相比，实现的怎么样？或许过去的情况相比怎么样？
为了最大化试点团队取得好结果的可能性，我们会仔细考虑参与人员工作地点以及自主权
让组织摆脱路线图
许多产品团队想摆脱产品路线图，但是他们的组织比较老派，沉迷于其中，因此不知道如何向前推他们的组织
在运行完工后，一定要突出对转化率的影响
如果效果达不到预期，那么请向每个人强调
要使得这个工作奏效，就要认识到为什么利益相关者特别喜欢路线图
他们希望能看到你正在做的事情，并保证你正在做的是最重要的事情
他们希望能够规划业务，并知道关键的事情何时会发生
团队要致力于领导层决定的优先业务目标，透明的分享我们的关键结果
公司保护其资产的一种方法是为了减少错误或风险，通常会对事情如何完成进行计划，并标准化流程
建立产品生产的管控非常容易，然而这会阻断创新
管理利益相关者
对于很多产品经理来说，管理利益相关者可能是他们最不喜欢的事情了
利益相关者定义
在很多公司，几乎每个人都觉得自己对产品有发言权
检验一个人是否有是利益相关者的使用方法，就是看他是否有否决权
管理层
商业伙伴
财务部门
法务部门
合规部门
业务发展部门
产品经理责任
产品经理有责任去了解各个利益相关者的考虑和约束，并将其带进产品团队中
产品经理需要说服力，相关者自己不仅了解这些问题，而且承诺提出的解决方案，即为客户服务，也利于他们
成功的策略
成功管理利益相关者，意味着他们尊重你以及你的贡献
产品经理与利益相关者之间最常犯的错误就是产品经理构建好，解决方案之后才向利益相关者展示，并且由于产品经理对约束条件的理解，不充分，时常出现问题
另一个常见的严重错误产品经理与利益相关者意见不统一
产品经理和利益相关者之间基本上就是建立一种合作的相互尊重的个人关系
PPT，展示不适合测试业务可行性
设置小组的时候并不是设置成强大的产品论坛
很多公司一些利益相关者可能不了解产品的用途，甚至可能感到自己的角色受到威胁，对此会敏感
要有一个非常强大的产品文化，这种文化在公司的地位非常重要
在面试的时候明确这一点
沟通产品知识
创业公司分享我们学到的东西很方便，因为产品团队基本就是一个公司
大方向上的学习收获对于更广泛的分享非常重要
能够让各个产品团队随时了解其他团队学习，收获到了什么
这种技术鼓励产品团队聚焦大方向的收获，而不是那些对客户或业务没有真正影响的次要事情
重要的是组织要理解和发现创新是为了不断地运行这些快速的实验，并从结果中学习
在文化上，产品组织要在学习和工作方式上做到透明和无私
苹果的产品经理Camille Hearst
从早期用户使用到成为大众产品，涉及很多不同的工作，包括产品市场营销以及两者的结合
前景很大，挑战也很大
整合也能让团队瞄准一个非常具体的角色，有助于推动和这个角色具体的接触
优秀的产品团队和糟糕的产品团队
创业公司在资金耗尽之前，总是力争吸引投资者的眼球
规模较大的公司很难复制它们早期的创新
有些团队无法持续增加业务价值
管理层对于想法变成现实，需要花费多长时间没有信心
工程师对他们的产品经理非常愤怒
优秀的团队和糟糕的团队重要区别
优秀的团队会有一个振奋人心的产品愿景，他们带着传教士般的热情去追寻它
优秀的团队通过他们的愿景和目标观察客户痛点，分析用户使用产品生成的数据，以及不断寻求应用新技术来解决实际问题，获取灵感和产品创意，糟糕的团队会从销售和客户那里收集需求
优秀的团队，知道他们关键的利益，相关者是哪些人？知道这些利益相关者的约束条件，他们致力于提出，不仅对用户和客户有效的解决方案，而且还在约束的条件下，对业务同样奏效
优秀的团队擅长很多技术，可以快速尝试产品创意，已确定哪些倡议真正值得构建
优秀的团队喜欢与来自整个公司的聪明人进行头脑风暴式的讨论
优秀的团队认为产品设计以及工程同样重要，他们会在功能，用户体验以及底层技术之间相互协作支持
优秀的团队在保护收入和品牌的前提下，不断尝试新创意
优秀的团队，坚持他们拥有对应的团队技能
优秀的团队能够确保他们的工程师每天都有时间在产品发现过程中尝试原型
优秀的团队每周都会直接与他们的用户和客户接触，以便更好地了解他们的客户
优秀的团队，知道他们最喜欢的创意中有很多，最终都不会服务于客户
优秀的团队在评估请求，并确保他们队友客户和业务奏效的可行方案后，会做出高信任承诺
优秀的团队会对他们的工作进行测试，以便立即了解他们的产品如何运作，并且能够基于这些测试做出调整
优秀的团队不断集成和发布，他们知道持续的小版本迭代，能够为客户提供一个更稳定的解决方案
优秀的团队专注于他们的客户
优秀的团队在获取一个非常重要的业务成果时才进行庆祝
失去创新的首要原因
许多组织在规模扩大时失去了创新能力，这无疑会打击管理者以及产品团队成员的信心
以顾客为中心的文化
振奋人心的产品愿景
目标明确的产品战略
优秀的产品经理
稳定的产品团队
工程师参与产品发现工作
企业的勇气
被授权的产品团队
产品思维
创新的时间
失去速度的首要原因
技术债务
缺乏优秀的产品经理
缺乏交付管理
发布周期长
缺乏产品愿景和产品战略
团队成员工作地点不同，团队成员经常更换
没有尽早将工程师纳入产品，发现工作中
没有，在产品发现中使用产品设计，而让工程师直接构建产品
改变事情优先级
统一的文化
构建一种强大的产品文化
公司是否能够持续创新，为客户提供有价值的解决方案
如果你不能将创意变成一个可生产，可发布的版本交付给客户，那么再好的创意也没用
拥有优秀的创新文化，到底意味着什么？
测试文化
开放思维文化
授权文化
技术文化
业务客户清明的团队，三位一体的文化，
技能组合和员工多样性文化
发现技术的文化
紧迫感文化
高信用承诺文化
责任文化
协作文化
结果文化
认可的文化
来自顶尖科技公司的教训
1、每一个优秀产品的背后
实践和理论之间存在巨大的鸿沟
任何人如果告诉你不难的话，他一定不是要帮你的忙
2、技术驱动型的产品和服务
技术驱动型产品不需要完全数字化
很多优秀的案例都是线上和线下体验的结合
如今的多数产品正在向技术驱动转型
没有意识到这点的公司未来的发展将受到影响
3、初创型公司：达到产品-市场契合点
在技术界通常有三个阶段的公司
初创型公司
尚未达到产品-市场契合点的新产品公司
还在为提供能够驱动可行业务的产品而努力
把专注力放在产品上
成长型公司
成熟型公司
4、成长型公司：规模化直至成功
如何有效的成长和扩大规模
如何将早起的成功经验应用到新的、相近的产品和服务中去，同时尽快发展核心业务
5、成熟型公司：始终如一的产品创新
优秀的技术产品公司知道他们需要始终保持产品创新
为客户和行业创造价值
一旦一家公司达到上市公司的规模，整个行业有很多受益于它的人，会想方设法来保护公司已经创造的产品
很少有人有意愿，或是有能力将公司引导至新的方向
当公司尚在蓬勃发展之时，愿景可能清晰而令人兴奋
大公司确实可以被效仿，但是需要做出巨大改变才能做到这一点
6、导致产品失败徒劳的根源
一切从创意开始
无论创意来源于何处，总是有涉及不同商业环节的一整套流程的工作需要我们去完成
创意，商业案例，路线图，需求，设计，构建，测试，发布
一、他能创造多少收益或价值
二、它将花费多少资金或时间？
提出需求的目的是与设计师和工程师沟通需要构建的内容
创意的来源开始
我们的创意至少有一半是没用的
客户对我们的创意并不像我们自己那么兴奋
有时客户会喜欢他，但构建起来比想象中的要复杂
即使是被证明具有潜力的创意，通常也需要几次迭代，直到能提供必要的业务价值，这个创意才算实现，但我们常说时间就是金钱
产品管理更多的是收集需求，并为工程师们文档化
工程师通常是最好的创意来源
7、精益与敏捷开发的本质
大多数产品公司在实际操作中，所谓的敏捷开发，并不是真正意义上的敏捷开发
解决掉风险，而不是放到最后
价值风险，客户是否会购买它
可用性风险，客户是否知道如何使用我们的产品？
可行性风险，我们的工程师是否可以运用他们的时间，技能，以及我们拥有的技术来创建我们所需要的产品
业务可行性风险
产品的定义和设计是否交叉进行的，而不是先定义产品，再设计产品
一切的核心都是解决实际问题，而不是功能实现
8、关键概念
整体产品
实现功能需要的技术
呈现功能性的用户体验设计
我们如何通过这个功能来赚钱？
如何吸引并获得用户？
线下体验
持续发现和持续交付
好的创新中有很多都源自工程师的参与比例，绝不在少数
产品经理和设计师也是日常的协助交付
产品发现
产品发现是产品管理，用户体验设计以及工程实现的紧密合作
产品发现的目的是快速区分哪些是好点子，哪些是坏点子
用户会为我们的产品买单吗？
用户知道怎么使用我们的产品吗？
我们的工程师能够实现这款产品吗？
利益相关者会支持这款产品吗？
原型
产品交付
产品和产品市场契合点
实实在在的产品才是产品交付的成果
产品愿景
最小化可行的产品
MVP应该是一个原型，而不是产品
合适的人
9、优秀产品团队遵循的原则
在优秀的产品公司里，你会发现，尽管由于每个产品的独特性，他们的场景并不一样，但是他们都有一些非常重要的相似点
传教士般的团队
我们需要传教士一般的，而非雇佣军式的团队
团队组成
团队权力和责任
他们有权提出实现那些目标的最佳解决方案，并对结果负责
团队规模
比团队的绝对规模，更重要的是平衡所需要的技能，以便确保打造合适的产品，以及用正确的方法来打造产品
团队汇报结构
在产品团队里，产品经理不是任何人的老板
团队协作
团队位置
团队范围
团队工期
团队自主为什么可行？
合作建立在关系之上，产品团队就是在培养团队成员之间的关系
为了创新，人们需要专业知识，而产品团队的持久性，让它们能足够深入，以获得专业知识
在产品团队模型中，整个团队需要理解业务目标以及业务场景，而不是仅仅去打造别人认为可能有价值的东西
10、产品经理
产品经理可以将问题和决策逐个甩给CEO
他把所有的利益相关者召集起来开会，然后让后者来决定事情要怎么做
产品经理真的可以胜任工作
实事求是的说，产品经理因是公司最具才干之人
关键责任
他们的问题，痛点，渴望以及他们的想法，对于商业的产品，他们如何使用如何决定购买
定性学习了解为什么我们的用户和客户按照他们的方式行事？
定量学习了解他们在做什么？
深厚的数据支持
深厚的业务知识
深厚的市场和行业知识
需要带给团队的四个关键职责
深厚的客户支持
深厚的业务知识及清楚利益相关者
产品经理确实需要或能够学习必要的领域专业知识
一个新的产品经理，通常需要2到3个月，专心致志的深入工作，才能跟上进度
智慧创意和持之以恒
成功的产品经理一定在智慧创意和持之以恒上堪称模范
有助于成功的最重要的事情
成为了解你的用户和客户的专家
努力与重要的利益相关者和业务合作伙伴，建立牢固的关系，说服他们两件事：一，你了解他们经营中的约束；二，你只会带给他们这些约束下有效的解决方案
成为关于你的产品和行业的无争议的专家，并慷慨的分享知识
努力建设和培育与产品团队，其他成员的强劲协作关系
产品经理简介
产品管理与其他学科完全不同
像CEO一样，产品经理必须深刻理解业务的方方面面
脱颖而出的方案，不是来自用户，客户或销售
真正的领导力是区分卓越与一般优秀的产品人的重要组成部分
11、产品设计师
完整的用户体验设计
用户如何了解代产品？
我们如何搭载第一批用户并向其揭示新功能
用户在不同的时间段如何与产品交互？
还有其他什么点正在争夺用户的注意力
一个月的用户与一年的用户有什么不同？
我们如何诱导用户对产品产生更高的认同？
我们如何创造满足感？
用户如何与其他人分享自己的体验？
用户如何享受线下服务？
产品的感知响应能力如何？
原型设计
用户测试
交互和可视化设计
产品设计缺失
一个产品经理尝试做产品设计
产品经理部提供设计，而是向工程师提供非常高级的用户故事
产品经理提供交互设计，然后使用视觉设计器或图形设计器进行可视化设计
12、工程师
对于一个成功的产品经理来说，最重要的关系可能莫过于与你团队中的工程师的关系
每天与工程师直接交流讨论
在下面发现的过程中，为了你从事的项目征求他们的想法
工程师们会让你澄清一些，他们正在生产与交付的产品的相关问题
工程师的士气很大程度上取决于产品经理
13、产品营销经理
产品营销人员是我们打造成功产品的关键合作伙伴
有一个优秀的产品营销合作伙伴，并不会减少产品经理交付一个成功产品的责任
14、辅助角色
用户研究人员
要真正弄明白这些研究人员提供的实际价值，就要记住学习是共享的
自动化测试工程师
15、谷歌的产品经理Jane Manning
他们用一种公式将每次展示支付的价格与广告的效果点击率相乘，而不仅仅是根据支付的价格来确定展示位置，以便展示效果最好的广告
再牛的产品也有一大堆，有说服力的理由，让他可能没有机会被构建出来
领导角色
关于成长的最大挑战之一就是理解整个产品是如何结合在一起的。
产品管理领导。
无论是产品主管还是产品经理负责人，对于拥有庞大而复杂的业务，特别是有很多老业务的公司来说，都是重要的角色。
产品设计领导。
公司中最重要的角色之一是负责整体用户体验的人员。
产品之间有很多的交互且相互依赖，还要了解业务，用户和客户，因此至少得有一个巨人区域审查产品中用户可见的每个细节。
技术组织领导。
首席技术官，技术主管以及架构师，负责系统的整体结构。
整体考虑领导角色
产品负责人，设计负责人和技术负责人作为个体是非常有价值的。将他们整合到一起才能发挥真正的价值。
产品主管角色。
竞争力。
对于任何一个产品高管来说，最重要的职责就是培养出一个包括产品经理和设计师的优秀团队。
要确保招聘一个有能力开发别人的人来担当这个职位。
产品愿景与策略。
产品愿景就是那些驱动并激励公司在跌宕起伏中支撑公司维持下去的东西。
产品高管需要辅助首席执行官。
执行力
组织越大，越难证明自己超强的技能，尤其是在利益相关者管理以及内部布道方面。
产品文化。
优秀的产品组织会有一个非常优秀的团队，坚定的愿景以及有效的执行力。
优秀的产品文化意味着团队理解，持续快速测试和学习的重要性。
经验。
关系。
产品主管要处理好与其他主管的私下关系，尤其是首席执行官和首席技术官。
技术主管角色。
即使是最伟大的产品创意，如果你不能付出实践并发布，它就只是想法。
一个伟大的CTO的特点是作为产业和产品的战略推动者，持续不断地为技术禅精竭虑，其总体目标是破除技术壁垒，以及为引领产业和产品扩大可能性。
组织。
领导。
交付。
确保组织能够将高质量的产品快速，可靠且重复的投放到市场。
架构。
确保架构能为公司和的竞争与繁荣而具备功能性，扩展性，可靠性，安全性和性能。
CTO需要纵观全局，成为统领技术战略的领导者，而不只是关注某些部分。
发现
确保高级工程师在整个产品发泄过程中非常活跃并作出重大贡献。
传播福音。
CTO将担任公司组织的公司发言人，在与研发合作伙伴和用户的互动中展示领导力。
无论何事，互相帮助，从长远来看，将创建真正有效的产品整体组织，从而发现并交付成功的产品。
交付经理角色
交付经理是一种特殊类型的项目经理，任务是致力于为团队消除障碍。
如果公司没有交付经理，不管实际上用了什么头衔来称呼，那么这项工作通常落在传媒经理和工程经理身上。
组建产品团队的原则
如何将产品分割到多个产品团队中，这是每一个规模较大的产品组织都会遇到的问题。
向投资策略看齐。
我们可以逐步淘汰掉那些失去价值的产品，并且我们通常可以减少对现金牛产品的投资，以便能够在将来对收入和增长来源做更多的投资。
最小化依赖关系。
大的目标是最小化依赖关系。这有助于团队快速迭代更加独立
所有权和自治权。
产品团队最重要的特征之一是我们需要传教适当的团队，而不是雇佣军。
充分利用杠杆。
产品愿景与战略。
团队规模。
像架构看齐
在实践中，许多组织组建产品团队的主要原则就是结构化。
团队是否重视架构
团队一直在抵制架构。
团队之间的相互依赖关系似乎不成比例。
向用户或客户看齐。
向用户或客户看起对产品和团队来说都有非常实际的好处。
每个产品团队可以对特定类型的客户深入研究，而不是让他们去了解所有类型的客户。
向业务看齐
结构在不断的变化。
要知道，产品组织的最优结构是在不断变化的。
组织的需求会随着时间而变化。
团队技能层次
富有经验，可以做出优秀选择的团队。
团队成员有正确的目标但是缺乏经验去做出好的决策
一个初级团队无知无畏行的，没有一些关键的培训。这些团队很可能在无意中造成严重的问题
Adobe 的产品经理Lea hickman
伟大的公司会在其他竞争公司让他们深陷困境之前先自我变革
不要忽视客户和销售人员，从原来的拥有软件，到通过租的方式访问软件的情感转变
有些人需要比其他人更多的时间来消化这种转变
新的整体大于各部分的总和
本书的一个关键主题是关注结果，而不是输出，要知道典型的产品路线图都是关于输出的，而优秀的团队需要提供业务结果
管理层知道公司很多部门都需要产品部门提供东西，然而很少有员工能够做所有需要的事情
产品路线图的问题
我们至少一半的产品创意是行不通的
有时顾客对这些创意并不像我们自己一样兴奋(没有价值)
有些顾客确实想使用这个产品，并且付诸实践，但是它太复杂了(缺乏易用性)
客户可能确实喜欢这个创意，但是事实证明，开发这个创意需要投入很多成本(缺乏可行性)
有时是我们遇到了严重的法律财务或业务限制，阻碍了解决方案的启动(缺乏业务可行性)
即使这些创意被证明是有价值的，易用的，可行的，可以启动的，通常还需要多次迭代，才能使其达到管理层所期望的业务价值，但时间就是金钱
真正优秀的产品团队，他们的不同之处在于如何处理这些事实
强大的产品团队理解并接受这些老人的事实，而不是否认他们
我们要解决根本问题，而不仅仅是交付一个功能
路线图的替代方案
公司的管理层想确定团队首先要做的是业务上最有价值的事情
由于公司管理层在经营企业，有些情况下，他们需要做出时间承诺，而路线图就是他们能够看到和追踪那些承诺的基础
对于科技产品有两个方面提供了业务环境
产品愿景和战略
业务目标
告诉团队，他们需要完成什么任务以及结果衡量方法，并让团队自己找出解决问题的最佳方案
极大的减少新客户上手时间，一个可衡量的关键结果就是新客户的平均上手时间小于三小时，无论解决方案的想法来自何处，或者这个人有多聪明，通常最初的方法都无法解决
旧的路线图的两个驱动因素
首先要做的是业务上最有价值的事情
偶尔需要给出一个严格的时间承诺
团队觉得他们可以按照任意，他们觉得最合适的方式来解决问题时，积极性会高很多
仅仅通过交付需要的功能和项目团队，并不能摆脱困境
无论解决方案的想法来自何处，或者这个人有多聪明，通常最初的方法都无法解决
这些都在讲关注，结果而不是产出
很多创意都不会像我们希望的那样奏效，而那些奏效的创意通常需要经过几次迭代才会被认为在商业上是成功的
在做出承诺之前，产品团队需要花一些时间进行产品发现，然而，对交付时间和交付成果作出承诺，以便其他同事才能高效的完成工作
产品愿景与产品战略
产品愿景并不是一个规范
他的主要目的就是传达愿景，激励团队以及利益相关者，投资人，合作伙伴和潜在客户帮助实现这一愿景
优秀的技术人员会被鼓舞人心的愿景所吸引，他们想做一些有意义的事情
产品战略
试图立刻取悦每一个人，几乎会导致取悦不了任何人，所以我们最不应该做的事情就是一开始就设立一个庞大的，且需要多年努力才能实现的愿景
有时候产品战略会基于地理位置，我们会按照一个计划的顺序来处理世界上不同的地区
有些产品战略会基于某种逻辑和重要性的顺序，实现一组关键的具有里程碑意义的事情
我们的目标是构建实际可交付的，让那些制造业客户成功的最小化可行产品，有关其他类型的客户和市场的想法，留待将来再考虑
对于一个被授权可以高度自主的去做任何有益的事情的团队，他必须对组织更大的背景有深刻理解
产品愿景和产品战略的区别类似于优秀的领导力和优秀的管理之间的区别
产品愿景原则
从为什么开始
相比解决方案，请更热爱提出问题
不要害怕，远见卓识
不要害怕捣乱自己，因为你不这样做，别人也会这样做
产品愿景需要激励
确认并拥抱那些相关且有意义的趋势
关注事物变化的方向，而不是原来的方向
大方向坚持细节处灵活
实现任何产品愿景都是一种信仰的飞跃
持续不懈的布道
产品战略原则
一次只专注于一个目标市场或一类角色
产品战略需要与业务战略保持一致
产品战略要与销售战略以及上市战略保持一致
关注客户，而非竞争对手
组织全体成员参与沟通战略
产品原则
产品战略描述了你实现产品愿景的路径，而产品原则描述了你想打造的产品的实质
你是否选择按原则行事？这取决于你的目的
永远不要告诉别人该怎么做事？只需告诉他们需要做的事，他们便会用他们的新颖创意为你带来惊喜
关于如何授权和激励人们，让他们拿出最好的结果
结果决定绩效
使进展的度量变得有意义
okr技术
OKR技术是一种管理，聚焦和矫正的工具
目标应该是定性的，关键结果需要可量化和可度量
关键结果应该是衡量业务结果，而非目标产出或任务完成
公司的管理设计以及技术组织应该关注组织整体的目标
为组织寻找一个适当的节奏
让组织和每个团队的目标与关键结果数量少一点
每个产品团队都要根据他们的目标来跟踪当前进展，这一点至关重要
目标不需要涵盖团队所做的一切琐事，但应该涵盖团队必须完成的任务
无论如何都要让团队对其所要达成的目标有责任感
就组织如何评估或为关键结果评分达成一致
建立一个极其明确且统一的判定方法，怎样的关键结果能够达成高度一致的判定标准？而不是随意指定的某个目标
针对每个产品团队正在努力实现的目标和当前进展情况，要保持非常透明
高级管理员对组织目标和关键结果负责
产品团队目标
随着一个组织规模的扩大，采用o kr工具的必要性也越来越大
如果你在组织中使用okr的话，关键就是将OKR集中在产品团队级别上
把个人的注意力集中在他们的产品团队目标上
当公司规模扩大后，就非常有必要确立愿景和业务目标
产品目标与规模
对于初创型公司或小型组织，每个人都有必要知道其他人在做什么？以及为什么要做这个？
对于大型组织产品团队需要更多帮助
随着公司规模扩大，通常会有一定数量的产品团队来支持其他的产品团队
你的目标一旦确定，就会有一个非常关键的协调过程
随着规模扩大，很难知道产品团队正在努力实现哪些目标，以及他们目前取得的进展，组织规模越大，所需的高完整性承诺清单就越长，就越需要积极去管理和跟踪
在许多的规模组织中，一般有多个业务部门在这种情况下，我们期望有公司级别的OKR，但也要有业务部门的okr产品团队也会加入其中
每个产品团队都应该知道如何适应多级别的okr，以及他们为此需要做什么
产品布道
产品布道就是推销梦想，它有助于人们展望未来，被激励人们去创造未来
使用原型
分享痛点
分享愿景
毫无保留的分享经验
毫无保留的信任
学习如何给出一个精彩的演示
做好功课
发自内心的兴奋
学会表现出狂热
多花时间和团队成员相处
BBC的产品经理Alex Pressland
编辑不习惯在不同的场景中创建内容并交付
过去的法务也不适用于经过IP设备进行传播
这不仅仅是一个关于用技术解决问题的故事，也是一个关于意志力的故事
了解客户解决方案的细节需要是什么
我们需要确保交付一个超棒和可扩展的产品，我们的客户可以依赖这个产品，持续获得可靠的价值
团队在发布产品时要有信心
产品发现的原则
产品发现的目的是解决如下重要的风险
客户会购买或选择使我们的产品吗？价值风险
客户知道如何使用我们的产品吗？可用性风险
我们能打造出优秀的产品吗？可行性风险
这个解决方法对我们的业务有用吗？业务可行性风险
不能依赖客户或高管或利益相关者告诉我们打造什么产品
最重要的事情是创造有目共睹的价值
产品可以凭借可用性和性能坚持一段时间，但如果没有核心价值，实际上就是一无所用
尽管工程实践很难，企业重要，但是做到好的用户体验，通常更难，对于产品的成功也更加至关重要
功能设计和技术本质上是相关联的
我们的很多创意并不会奏效，那些奏效的创意也需要很多次的迭代
我们必须基于真实的用户和客户来验证我们的创意
产品中最常见的陷阱之一是我们自以为能够预测客户对产品的实际反应
产品发现的目标就是尽可能以最快最廉价的方式来验证我们的创意
我们需要在产品发现的过程中，而不是之后验证创意的可行性
如果开发人员在开发产品的最后阶段才了解产品创业，那么注定会失败
我们需要在产品发现过程中验证我们的创意可行性
业务可行性包括财务市场营销，包括品牌和市场进入策略，销售法律业务发展和高级管理人员
共同学习
发现技术概述
发现框架技术
发现规划技术
发现构思技术
发现原型技术
发现测试技术
识别出那些没有太多风险的创意是非常重要的
测试可行性
测试价值
转换技术
我们如何构建产品发现工作的基础框架，以确保一致性并识别关键风险
确保团队在整体目标刻画上保持一致
定位产品发现工作中需要解决的重大风险
财务风险，我们能否负担起这个方案
业务发展风险，这个方案是否适用于合作伙伴？
营销风险这个方案是否符合公司品牌？
销售风险，销售队伍是否制定了相应的策略？
法律风险，从法律或合规角度，方案能否实行
道德风险这个方案，我们是否应该去做？
评估一个机会，有很多种方法，有的公司需要严格的分析，而另一些公司则只需要产品团队来判断
机会评估是为大多数的产品工作设计的，从简单的优化到功能设计，再到中等规模的项目都包含在内
客户函件是为大型项目或计划设计的，常常有多个目标以及较复杂的预期产出
初始画布用于新产品线的建立或新业务的开展
35机会评估技术
这项工作解决什么业务目标？
如何度量成功？
这项工作解决了客户什么问题
我们关注哪些客户？
关键结果
客户问题
目标市场
客户函件技术
对于规模较小，比较典型的项目，机会评估通常就足够了
产品团队很容易陷入他们计划构建的产品特性中，而没有真正考虑这些特性，对客户的真实价值
如果你的团队对此感到不兴奋，也许不值得一做
初始画布技术
数十年来，人们制定了详尽的商业计划，来强调这些话题，并试图解决他们
你可以将初始画布运用在更简单的工作上，尤其当有新的产品经理就职的时候
优先处理最大的风险，至少理论上如此
风险是主观判断的，很难量化
大部分产品工作面临的主要风险是价值风险
如果之前创建了画布，那么你肯定知道解决方案中几乎没有什么稀罕的内容
故事地图技术
本质上它们是一种框架和规划技术，同时也有助于产品创意
用户故事地图是一种二维地图，纵轴是用户活动，横轴是时间，大部分的用户活动随着时间从左到右松散排列
当我们最终完成发现工作并交付时，地图中的故事就会直接进入产品的代办事项中
客户发现技术
在产品组织中打造那些能够维持业务的产品，是我们的工作
参照客户的力量
没有参照客户销售团队就很难知道真实的产品到底是什么市场，到底在哪里？
学习这项技术，需要投入大量精力，主要是产品经理这块的投入
为企业量身定制产品
打造平台类产品
打造公司内部员工使用的客户支持工具
为消费者量身定制产品
单一目标市场
一旦我们有了最初目标市场的参考客户，我们就可以继续扩展产品，以满足下一个目标市场的需求
招募潜在的参考客户
寻找那种对我们想要创建的解决方案感到痛苦，并几乎绝望的潜在客户
通常情况下，产品经理与产品营销经理紧密合作，才能找到合适的产品
关系
对潜在客户的好处是他们得到的是实际的投入，而不是口头上的支持，而且最重要的是得到了真正适合的解决方案
深入研究客户，找出它们行之有效的解决方法
如果你正在处理一个重要且困难的问题，那么想要参与的客户会非常多
你需要确保客户真的来自你的目标市场，且不要超过一个目标市场，这样做的好处是聚焦
平台API产品
客户支持工具
消费者产品
在市场营销方面，当消费者决定购买或使用产品时，他们可能不会将参考客户是做业务推销员
总结
虽然这需要投入很多精力，特别是对产品经理，不过这种强大的技术有助于确保你打造一个客户喜欢的产品
微软的产品经理Martina Lauchengco
虽然有一个公共的代码库，也许是一个值得追寻的目标，但如果结果不是很好的产品，就不算是真正的成功
在面对巨大的压力情况下，为了客户做正确的事情是多么的困难，但这恰恰是一个强大的产品，经理所能想出的办法
很少有人既擅长营销，也擅长产品及两者一于一身的人是非凡的
一般来说，让产品团队去解决实际的业务问题，而不是解决已有方案，产品团队做好自己的工作，并且经常亲自与用户以及客户交互，那么得到数量足够多，品质足够好的产品，创意并不是问题
0 条评论
回复 删除
下一页
