《产品经理必知必会》丨NOTES
本书讲了什么
在Web 和移动开发周期越来越短的今天，决定成功的不仅仅是对项目层面属性的关注。如何在众多应用中脱颖而出，如何让网站黏住访客？本书作者、出身设计师的产品经理Kristofer Layon 将告诉你产品制胜的关键因素，指导你做出超乎用户期望的卓越产品。
作者什么来头
Kristofer Layon，资深产品设计师、产品经理，目前任职于移动产品开发公司Red Stamp，负责产品管理和用户体验设计。个人网站：kristoferlayon.com。
序
产品迫使你做出以下决定：你想要什么，你需要什么，以及你愿意投入什么（时间，金钱，精力）。每次遇到新产品时，你都会做复杂的成本效益分析。作为制作产品的人，你的目标是让人直截了当的决定购买并使用你的创意。不论身处哪个行业，采用何种形式，文化背景如何，目标受众以及如何定价，决定产品成功与否的都只有一个因素，那就是它的目的。目的是某件事物存在的原因，是你的产品试图解决的问题。目的将预期用途，预期收益和预期意义组合在一起，目的是值得拥有和使用的价值。大多数收人欢迎的产品团队，都有一个占主导地位的品质，即引起共鸣。共鸣是一种感受别人感觉的能力，设身处地从别人的角度看世界。
引言
作为一名WEB或移动项目的设计师或开发者，你已经很懂规矩：
它能被访问吗？它是否符合客户的品牌和设计指导方针？它是否看起来不错，有着简单愉快的用户体验？
文案写作是否遵循了良好的内容策略？CSS,HTML,JavaScript或其它代码是现代的并符合标准吗？
如果是网站，采用了自适应设计支持不同大小的屏幕吗？网站或应用通过了可行性测试了吗？
用于跟踪用户行为的分析代码是否放在了正确的地方？
是否有社交媒体整合以及其他策略，来确保人们容易找到并使用网站或应用？
是否有发布和维护计划，确保站点和应用能准时上线，而且不会在发布后就出现状况？
产品管理是什么？
你的产品旨在让客户实现什么？目标阐述清晰吗，理解到位了吗？
这些目标是否涉及交付内容，或者还包括促进交易？
如何确认交付及交易成功执行？
哪些组织内部成员有兴趣了解有关交付和交易的数据？
你如何将数据传递给他们，传递频率如何？
如何确定他们就是关心用户行为的合适人选？组织中其他人也需要了解用户行为吗？
衡量交付或交易成功的手段是什么?
项目设计师和开发人员了解这些成功的衡量手段吗？
组织的领导层了解取得这种成功所需的创意和技术方案吗？
当大家为设计开发和管理工作忙得不可开交的时候，谁来管理这一切？
产品管理与我何干？
产品管理是设计，开发和业务紧密相连的部分，是维恩图重叠的地方，即最重要和最关键的部分，创意，技术和业务人员需要相互了解与合作。
第一章 产品是什么
产品是被生产和销售的
我们通常认为产品是一种拥有品牌名称并能以一定价钱获取的物件，因此对每一件产品无论其为何物，与之相连的都有创造或生产的过程，以及通过交易取得后续使用的获取过程。
如果处置得当，制造和销售流程应该产生一件成功的产品，如果产品不成功那就改进制造和销售流程，通过调整来改进质量并获取成功的过程就称之为产品管理。
产品销售与体验有关
公司的共同点是它们都有商品在销售—无论它们销售的是什么。凡是需要投资来设计和创造，设计客户体验或能对公司成功产生影响的，都应该被视为产品。当设计出网站或移动应用时，创建了用户体验时，网站或应用就成为把其他主要产品带向市场的重要一环，而它本身就是一种体验与影响力都可以被管理的产品。
网站和应用也是产品
设计或开发网站，移动应用或其他交互体验，其实就是总体的组织战略和用户体验的重要组成部分。
做一名反映的实践者
从事产品管理工作的主要职责之一是协调团队和组织内创意，技术和业务部门之间的鸿沟。产品管理属于反应性实践，你需要研究其他部门的影响力，并将这些协同工作带来的成功或失败全面地反馈给组织。当既有的科学无法回答所有的问题或者无法解决手头的难题时，新的学科就会应运而生，以发现，定义并解决新问题。产品管理有助于确保组织以反映性的，目的明确的方式来利用设计和开发资源，并聚焦在产品层面上。一个具备反映性的组织要竭力创建那些能满足客户需求并为组织带来成功的数字产品，通过在设计开发过程中对工作保持反映性，并且与客户确定并沟通价值，团队才能以更有价值的方式获得成功。
产品管理将创意与业务对接
产品管理是沟通组织需求与创意及技术解决方案的重要桥梁，旨在将数字产品置于使用产品的客户和利益相关者的框架中。管理产品类似于为一家乐团编制演奏曲目和策划系列音乐会。和乐队指挥一样，项目经理对每个项目的成功实施有着不可或缺的重要作用。但如同音乐机构的艺术总监研究并创建演奏曲目来满足观众的兴趣和品位一样，产品经理需要调研并创建产品的定义和策略，以满足商业机构客户的需求。
小结
产品是物品或服务，它被设计并开发出来，用以满足顾客的需求。
即便是免费的产品田也通过促进主要产品的购买或其他交易解决了市场需求，此类产品的一个极佳案例是商店，它通过设计购物体验来促进其他主要产品（商品）的销售。
成功的产品可以取悦客户，赚取利润或帮助企业实现其他战略目标，还要对其业务影响及用户满意度负责。
产品管理是一个高度反映性的活动，因为它连接着创意，技术，业务和管理实践，产品管理的目标是超越客户的期望，这需要对网站和移动应用如何影响人与组织的交互方式有一定的认识和评估。
有了产品管理，人们会从更好的角度了解交互项目的背景与发展状况。若分开考虑，单个的项目可以提高特定产品的功能或服务，但从产品的角度来说，项目又可以被视为一系列的迭代改进，目的在于增加客户和组织的价值。
产品价值可通过客户满意度和组织的成功来衡量，借由产品价值，组织战略以及创意和技术团队当前的工作会不断得到改进。
第二章 理解市场和客户的期望
市场与需求
商品能否出售以及以何种价格成交受到许多因素制约。这无关卖家的想法—重要的事买家怎么想，这就是市场，客户需求和期望的影响力。对潜在买家而言，房屋的价值并不是由房主花了多少钱或多少精力来决定的。房屋对买家的价值不是由房主掌控的，价值是由旁观者（顾客）眼里的价值—对呈现在眼前的商品，他所感受到的好恶，以及感觉这个价码值或不值。
客户定义价值
价值是由客户及其喜好决定的。你对网站设计或代码的想法无足轻重，考虑市场需求才是关键，我讨厌这样说，但这是事实，在确定产品的实际价值方面，你的意见无关紧要。你有多爱自己的工作，花了多少精力，这些在计算实际的市场价值时都无关紧要，这个世界充满了需求和欲望，你的网站和应用要满足这些期望。产品需要满足市场需求，因为客户决定了产品价值。
市场与供给
市场并不只是受客户需求的驱动，同样重要但却骑着相反作用的因素是供给关系。即使买家很喜欢你的房子，如果类似房屋的供应量较大，对市场上某个房子的需求便会下降。由于市场上还有许多其他物业可选，买家根本不需要为某个物业承担高昂的价格。在砍价或放弃的选择上，市场供应给了顾客更多的灵活性。
当你决定开发网站或移动应用以解决市场问题时，要对该问题的其他解决方案心中有数，而且要对竞争对手心中有数。
请回答以下问题：
如果存在其他与你公司类似的机构，他们的网站或移动应用使怎样的？会和你公司的相似吗？
如果你们的产品非常相似，怎样能脱颖而出？比如内容，设计，功能等。
如果竞争对手经常更新产品，你将如何与之竞争？你能赶上他的步伐吗？
你的机构或客户是否对产品期望过高，而忽略了如何保持核心业务的竞争力？
除了网站或移动应用，是否有其他途径帮助你的组织获取成功？
在着手自己工作之前花时间观摩很多网站的目的不只是为了引发思考，要考虑把这些信息纳入你的数据储备，将相似的地方突显出来虽然不无裨益，但突显那些差异化之处，可能会让你受益更多。
定期做市场侦测，将竞争分析结果以容易理解的方式分享给那些你打算告知的人们，这些都能培育你在市场上的信誉。可以利用哈维球图来比较不同产品的详细信息。
谁是客户
内部客户：包括高层领导，营销总监，其他部门总监，客服人员及其他直接与外部客户打交道的人，这些人会从个人职责的角度看待业务或产品的作用。因为经验，关注领域或专业领域的缘故，每个人看待事物都有独特的视角。如果涉及的产品没对高层的战略产生影响，可能就是在浪费时间。
外部客户：网上调查，电话调查，面谈。
聚焦市场问题
与其让人们想象使用一款还不存在的产品，不如让他们阐明问题所在，而这些问题是产品应该解决的，即所谓的市场问题。聚焦市场问题是在按正确的方式设计，确定市场存在哪些问题，然后着力解决这些问题。真正的设计师为了解决问题服务他人，取悦自己的创作应该归为爱好。
小结
理解市场需求或人们需要解决的日常问题很重要，以创造性的，切实可行的方式解决这些问题会带来巨大成功。
如果你的喜好和市场期望不符，从个人价值角度出发进行创意或技术工作就会很危险。
了解市场问题需要与真实用户进行面对面沟通或者通过电话交谈。
第三章 撰写用户故事
从用户需求中提取目标以指导设计和开发团队的工作，最好的方法是编写故事，用户故事用精简的语句描述了人们对产品的使用方式有什么期望。
创建用户故事的基本原则
以第一人称撰写。
用户故事的目的是让设计人员，开发人员，业务分析人员以及其他人员理解客户的心态。措辞应该是这样的：作为A公司的客户，我能……通过这样开头，一个用户故事告诉你“你是谁”以及“你想做什么”。它可以帮助你从客户的角度看问题，更好的理解客户的生活以及组织是如何努力为他们提供服务的。
使用日常用语
用户故事不仅是构建或增强产品的开端，而且在整个过程中，还具有持续不断的参考价值。使用日常用语方便参与者沟通。日常用语应该表述出人们如何利用你的产品。用户故事必须把重点放在如何以清晰简洁的方式实现产品的目标上。
避开新奇的或技术性的解决方案
用户故事最大风险之一是内容容易过于新奇或偏技术。用户故事不应该包括新奇的和技术性的解决方案，它们需要保持纯粹，专注于人，而非那些技术性目标。
专注于一般的，基本的目标
应该着眼于常见的，不受时间影响的目标，尽量让用户故事具备持久性，且尽量不受平台和技术变化的影响，当解决方案所处的环境发生变化时，不要让这种变化在不经意间影响你对客户问题的看法。
用户故事
作为XYZ IOS应用的用户，你需要能够通过你的iPhone将注册数据提交给SquishySoft数据库。
作为ONE公司的一名客户，我需要能够通过我的智能手机将自己的家庭地址提供给该公司。
卓越用户故事三要素
产出
产出用基本的，非技术化的用语描述了客户希望通过你的网站实现什么，即交易或交互本身。“作为A的用户，我可以从图书管理员那里得到帮助”得到帮助本质上是非技术性的，构成了产品的基本要素，称之为产出。你应该确认这些任务是否在线下已经存在，从而验证一个用户故事的产出是否是基础的且非技术化的。问问自己客户是否可以不借助产品来做同样的事情。
成效
成效描述了用户希望通过完成你的网站或移动产品中的一个任务来实现什么。“作为A的用户，我可以从图书管理员那里得到帮助，进而使我学会在研究论文里用正确的格式引用文献”联系图书管理员是重要的事情，重要之处在于：这些任务能让用户完成别的事情，达成一个目标。衡量一个设计成功与否时，不仅要追踪产出，还会希望了解产出带来的成效。将成效融入用户故事可以让产品团队专注于真正重要的事情—帮助人们完成目标。
影响
尝试将用户故事解决的问题的影响融进故事里去，尤其是对委托机构或者客户的影响。“引用文献，取得更好成绩”必须有一个具体的原因解释上级为什么投资于一项功能，性能或者改进产品。
优秀完整的用户故事包括产出，成效和影响，撰写这样的故事能让产品团队，公司领导以及客户明确那些对他们来说有意义的目标。如果团队经常提及用户故事并牢记于心，这些目标会在产品开发整个过程中得到贯彻。
小结
采用第一人称口吻，用户故事是为了让你理解客户心态以及他们想要做什么。
用大白话以及非技术性语言写作，让表述清晰明确，专注于客户和组织的需求。
不要让用户故事设计具体的创意或技术解决方案，而要让故事专注于明确的阐述问题，这是它们唯一的目的。
让用户故事保持生命力，避免提及那些可能会变化的事物。使用宽泛的概念，让故事适合多种情景，提高灵活性。
明确指出每一个用户故事的产，结果和影响：顾客需要什么?顾客要通过做这些事得到什么结果？为什么顾客关心这些结果？这个问题的答案可以帮你定义产品团队的最终工作价值。
第四章 产品改进策略的分析及优先级判定
一旦你有一个可以信任的机制，并形成了排序的习惯，如果偶尔要为没完成的事情道歉，你也会有明确的理由来说明为什么其他任务要更优先。
马斯洛的人类需求层次理论
1.生理需求：人类的基本需求，包括呼吸，进食，饮水，休息，排泄与繁殖。
2.安全需求：包括人身安全，精神安全和心理安全。
3.社交需求：关乎情绪的稳定和幸福感，友情亲情爱情。
4.自尊需求：涉及更广泛的外部接受度，这种接受赋予人们更多的自尊与自信。
5.自我实现的需求：正是有了高层次的需求—道德，创造力和解决问题的能力，才将我们跟其他物种区分开来。
在推进到更高级别的需求之前，你必须满足最低层次的要求。
产品级别的层次结构
想想你的产品符合马斯洛需求层次的哪一层。明白这一点应该可以帮助你为产品用途和用户满意度设定期望值。
属性级别的层次结构
1.生理需求：在移动设备上访问网站，查看导航等同于呼吸和进食的需求。
2.安全需求：阅读是一种深入持久的活动，牵涉到线上最普遍的内容形式—文本。能够浏览文本是一个好的开端，但以某种方式让文本大小，缩放比例和格式清晰易读会更好。
3.社交需求：包括通过响应和分享来解除内容。首先要解决可视性，然后解决可读性，并确保人们能够通过适用手机的样式和社交媒体响应和分享。
4.自尊需求：性能是网络上信心和信任的最佳来源之一。
5.自我实现的需求：对数字产品需求的最后一级可以概括为一个词：喜悦。
客户支持的重要性
不管什么类型的产品或服务，如果没有提供一个简单的方式让我们与该公司联系以获取支持或进行投诉，这就是最糟糕的产品体验。人性化的服务意味着要为顾客提供一个与你沟通的方式，确认收到了他们的邮件，并回应咨询。
Kano模型
对顾客而言，产品的每一个属性的价值并不是等同的，因此改进每一样产品属性并不一定会让顾客满意度变得更高。
基本属性
基本属性是基本的根本的，是产品绝对必不可少的属性，如果一个基本属性缺失，产品就无法正常工作。（手电开关）
性能属性
性能属性可以通过广泛的性能或有效来体现。（灯泡亮度）
愉悦属性
有时也被称为兴奋属性，通常并不在顾客与其或假设的范围内，而且它们也不是核心期望。（手电颜色，手感）
因为手电是用来照亮物品的，所以这些细节不是绝对必要的，但正确的颜色或易于握住的特性，可以让顾客更愉快的使用手电筒。
不同的属性不同的结果
1.缺少基本属性是产品面临的最大问题，但只能提供基本属性只能带来较低的产品满意度。
2.性能属性往往因顾客而异。所谓性能是人的主观感受。
3.提供性能属性或愉悦属性并不能弥补基本属性的缺失。（不要以为缺失基本功能，你可以进行其他的改善来分散客户的注意力，性能属性和愉悦属性的改进只有在产品功能完整的情况下才有效。）
4.今天的性能特性和愉悦特性可以迅速变成明天的基本特性。
5.让Kano属性可视化。将现有的或计划中的属性以图表的方式展示，可以帮你了解是否在正确的时间把注意力放在正确的用户故事上。
确定Kano属性
分析一辆车很容易确定，方向盘是基本属性，油耗是性能属性，敞篷车顶是愉悦属性。但对于新产品或者产品改进，如果你还不确定哪些属性会被顾客认定为基本属性，性能属性和愉悦属性，又该如何确定Kano属性类别呢？
询问顾客两个问题，首先问问他们如果添加某项功能，他们的感受是：满意，中性或不满。然后问问他们如果这个功能没有了会作何感想：满意，中性或不满。以下是他们的回答如何对应Kano产品属性。
基本属性：产品具备这项特性时，顾客持中性态度，但如果这项特性缺失顾客会非常不满。
性能属性：产品具备这项特性时，顾客持满意态度，但如果这项特性缺失顾客会非常不满。
预约属性：产品具备这项特性时，顾客持满意态度，但如果这项特性缺失顾客态度是中性的。
小结
马斯洛需求层次理论帮助你了解人们需要什么，以及如何逐步满足这些需求。
马斯洛需求层次理论可以帮你为开发产品安排优先事项。
性能属性是线性的：此类属性提供得越多越好，客户满意度越高。
愉悦属性是那些出人意料的属性，不要因为性能属性或者愉悦属性忽略了基本属性。
顾客的期望会迅速改变：一项让人喜出望外的愉悦特性到明天可能成为性能特性，下一年变成基本特性。
第五章 完成最简可行产品
执行项目的传统方式：创建最佳的设计和方案，然后在现实约束下尽可能地去执行，同时希望尽快完工从而尽量减少项目花费。在开工前对项目做最充分的规划和估算，就是所谓的瀑布式开放方法。
侧重于小批量的工作产品管理方法，将要改进的部分分成许多小块，在进行更多的工作前，先和用户一起对每一块进行测试和验证，不断重复这个过程。要实现这一点，你要习惯于每次完成较少的工作，并向用户发布较少的成果。你需要接受最简可行产品（minimum viable product,mvp）这个理念。
什么是最简可行产品
最简可行产品未必指那些向客户发布的实际产品，它们可以被定义为各种内部里程碑。最简指的是制作，测试和验证下一个改进或设计理念时的改动最小。MVP背后的基本思想是定义少量你可以完成的工作，而不是纠结于大量永远也完成不了的工作，100%完成10%的工作，比完成100%工作的10%强。MVP不是你想要完成的东西的最简陋版本，它实际上是达到成功的最小量，对成功的要求是不容置疑的。MVP的目的是为了学到一些重要的东西，并帮助你证明团队的哪些设计理念或假设是正确的。
白板会话
要想针对拟开发产品或功能收集数据，与几个客户一起在白板上描绘想法是一种有效的方式。考虑到所需要的投资：一两个小时，一些记号笔，这显然是一个耗费极低的MVP。MVP的要点是用最少量的工作来最大化产品的价值。
原型设计
1.非正式的原型设计
对原型设计来说，最简单经济且浪费最少的方法就是使用纸张，小索引卡面模拟手机，大卡片模拟Pad。用纸张进行原型设计将草图绘制带到一个新水平，甚至可以开始进行用户界面交互设计。
2.正式的原型设计
具体使用何种工具制作原型取决于预算，以及在产品开发周期的不同阶段，图案度希望以何种方式呈现想法并获取反馈。创建正式原型最明显的风险是所耗费的时间，制作原型耗费的工作越多，后期要改变的可能性就越低。因此只有当你创建了大量非正式模型，并做了许多的选择和决策工作之后，再来使用真实和高精度的原型。
总之，只有当你想实现以下想法时再制作正式的原型：
在发掘创意以及向用户验证时，确实需要那种级别的原型来探索设计和交互细节。
为设计者和开发者证明和演示设计与交互模式。
在低精度非正式原型无法解决问题时，用来验证假说或者解答疑难问题。
构建部分功能
你无须为产品完成，测试并发布一个完整的解决方案，这个过程需要慢慢实现，你可以先构建一个局部的功能。
发布的功能
你必须确定推出工作成果的具体时间，否则完美主义倾向就会折磨你，那样你将永远没信心将成果交付使用。
获取有关最简可行产品的反馈
开发原型并非是把产品的工作方式可视化，那样只不过是纸上谈兵。开发原型意味着更多—只要你有东西可看，不妨让其他人也看看，并请他们把想法告诉你。
与用户进行非正式谈话
获取用户反馈最简单的方式是坐下来跟他们聊聊，向他们展示草图或纸质原型，或者跟他们做一个白板会话。要养成尽早且频繁的向别人展示自己的想法不容易，你会觉得自己在别人面前暴露了要多东西，这种心态和积习大概是由于我们认为设计是一门艺术，为了把活干好将自己封闭起来通常会有用。但不要让这种心态使你认为创意和工作进展都需要遮遮掩掩，经常与客户谈论你的工作可以让你知道自己的想法是正确的，从而降低风险，增加成功的可能性。
调查
线上调查适合那些你无法当面交流的人。从一个简短的调查中所了解到的内容是惊人的，使用不到十个问题，你就可以收集到关于客户偏好和优先事项的大量信息。
以下是调查客户的一些技巧：
1.若想了解具体信息，不要羞于提出具体的问题。
2.如果你处在获取相关信息的早期阶段，过于具体则可能会大大限制你的选择，尤其是在处理一个存在多种选择的功能或内容时，这意味着团队有太多可以着手工作的地方。这种情况下，询问受访者一些宽泛的问题并尝试得到具体的答案，（你喜欢食物吗），后续跟进可以给他们提供一个开放式的问题，（说出两个最喜欢的食物），对于第二类问题，如果只给他们几个可选条目，会导致排除了很多可能性。相反，给他们一个可以输入自己想法的文本框，则会带来更广泛的反馈。
3.争取每屏不超过四个问题，问题总数不超过四屏。在每屏问题回答完后，屏幕会显示又有25%的调查已经完成了。
4.一定要通过邮件感谢那些完成调查的人，通常在设定的最后期限之后的数日内发送这些邮件。
5.与人分享你的调查数据。客户的意见总是比你自己的要重要，通过了解顾客得到喜好，你再去争取产品改进时遇到的阻力会变小。
卡片分类法
卡片分类是将一对想法或选择排序，试图从中找出线索。每张卡片上记录一个想法或特性，或者使用类似Trello这样的网络工具来实现。进行卡片分类的传统方式有以下几种：
1.优先排序：如果你有很多某个类别的用户故事的想法，卡片分类可以帮你将这些条目在这个分类中排序。
2.分组：通过分组让一对条目更有条理。
卡片分类有助于对大量可能没有明显逻辑分类或顺序的条目进行组织处理，让用户来排序，或者由他们来安排或分组，这总会让你明白一些以前没有注意到的东西。
现场可用性测试
和实际的客户坐在一起，观察他们在你的面前能否正确使用MVP（无论它是一个非正式原型，正式原型，还是已经部分完成的功能，哪怕参与的只有几个人）。
在线可用性测试
当你在进行在线可用性测试时，尽量做那些会在面对面交流时所作的事。对待测试过程尽可能如同你在现场一样，使用工具记录结果或让其他团队成员加入线上测试。
基于实验室的可用性测试
在实验室里做一次产品可用性评估显得尤为重要，这种形式可以让团队更详细的做准备，并提前制定好计划应付可能发生的一切。借助实验室和权威人士的帮助会为结果平添几分权威性，但要考虑花费。
小结
总是从最简可行产品MVP的角度考虑你的工作。
在用户体验设计的最初阶段，判断利用白班是否足以展示想法，并获取用户和利益相关者的反馈。
如果白板不再适用，考虑适用基于计算机的建模工具来构建更复杂的原型。
在你真正需要开始验证设计细节和具体交互环节之前，不要开发正式原型。
开始为解决方案构建尽可能少的代码，仅仅做出MVP就够了，尽可能多的继续向用户和利益相关者验证你的方案。
通过多种方式收集用户反馈，非正式谈话，卡片分类，调查，现场以及在线可用性测试调查。
第六章 对成功进行过衡量
Web分析或移动分析能提供大量有关数字产品使用情况（产出）的数据，但这只是起点。
回归用户故事
衡量成功的第一步是回归到你的用户故事中去，你可以检查构成用户故事的三个关键要素：产出，成效和影响。要从两个角度评估：对组织内部及外部两种客户所产生的影响。
外部客户
产出
测量帮助功能的使用次数，最合乎逻辑的方式是使用Web分析或移动应用分析，记录下帮助功能里的几个关键互动的使用情况。但对衡量成功而言，衡量产出只是个开端。
成效
可以问用户一个简单的是非题，或者让用户对接受的帮助服务进行评分，多花些时间收集与成效有关的数据总是有益的，它会帮你把一项功能如何成功的故事讲得更好。
影响
使用调查手段可以了解帮助功能对客户的影响，但结论或许不那么可靠。被满足的用户觉得好，没被满足的觉得烂。有时候客户本身并不能提供最好的反馈意见，这种情况下，转向内部客户可以为你正在寻找的信息提供补充。
内部客户
有些需求无法从客户角度来明确表达或衡量，可以从内部客户（同事）的角度来评估产出，成效和影响。
产出
对于初学者来说，检查沟通渠道的两端绝对不会有什么坏处，以防请求没有被接受。对于交互全程进行检查有助于生成更精确的图景，了解某项功能如何产出希望的结果。
成效
通过调查学生来了解图书馆帮助功能在为他们撰写论文提供了多大支持，了解此类成效问题上，询问学生不是最好的办法。因为这要求学生向那些他们承认需要帮助的事物上发表意见，这些学生怎能胜任呢？在这种情况下，对内部客户进行成效衡量可能要比对外部客户的衡量更加完整。同样，将内外部客户反馈进行对比最有效。同时采纳两种反馈，可以将关于产品成功的故事讲述得更加完整。
影响
上述食物有一个更加客观的评价—分数。如果可以衡量诸如分数这类更精确的目标，为什么不这样做呢？对任何机构来说，一旦涉及敏感的客户数据，沟通过程都会变得非常棘手，所以这类请求往往需要花费大量时间，产品管理的关键就是在不同的公司角色建立起关系。
在收集有关产出，成效和影响的信息时，你会积累很多信息：各种数字，基于分析的报告，好评及投诉等。是否应该把所有信息和大家共享？答案是否定的，共享信息还是要谨慎的。
小结
回顾你在用户故事里建立的，用来指导团队产品工作的产出，成效和影响，一路上有什么改变吗？
从衡量产品功能或服务的产出开始，人们在按照你期望的方式使用吗？你的产品分析能对用户行为进行正确追踪吗？如果对如何衡量产出有疑虑，那就尽快纠正这个问题。对产出的不当衡量会将评估的其余部分置于风险中。
一旦你确信如何记录一项功能的产出，接下来就该确定该产出是否能带来预期的成效。
不要止步于对成效的衡量上，这项工作的最终影响是什么？产品对机构整体战略作出了哪些贡献？
评估团队工作的成功时，要多多咨询内外部客户。将产品管理与创意和技术工作相关的各种反馈综合在一起，从而完整阐述该工作是否为组织传递了价值。
第七章 沟通产品成功
尽早离开办工桌，更多去了解产品。这句话同样适用于对产品性能的沟通过程—不要让信息只是停留在分析软件，电子表格和电子邮件中。
将产品数据可视化
保证你的团队可以得到有关数字产品成功的信息，如果数据不可见，就无法吸引到正确关注，或直接被忽略。
接纳与使用
追踪使用产品的用户数量是网络分析和移动分析的出发点。定期将数据进行可视化，能让你发现趋势中的奇特之处或问题，并迅速做出反应。报告独立用户时要记住以下细节：
使用相同的时间间隔。分析软件可以让你尝试各种设置—查看每天每周每月的独立用户，观察这些数据在不同时段的变化。与他人一起观察数据确保用户趋势和其它关键指标是真实的，保持若干变量在报告中的一致性，因此如果有人将这份报告的数据跟之前的报告进行比较就能得出清晰准确的结论。
保留重要的背景资料。仅基于过去的趋势数据做出的预测被证明是不准确的。
产品满意度
应用商店评级是最容易获得的产品满意度数据。我始终对好评和差评都持保留态度，我认为花时间来评价一个应用的人通常属于两个极端阵营。持温和看法的人往往没有动力去评分。能听到抱怨始终是有价值的。坏消息只是意味着有改善的机会，可以将此作为团队和组织所要应对的创意和技术挑战。
不同平台的用户
当你管理的是移动产品时，要对用户所使用的设备和移动操作系统进行追踪和报告。可视化这类信息时，往演示文稿中插入一两个饼图，效果会更好，饼图使数据易于理解。
沟通可视化数据的原则：实事求是，直截了当，善用工具，突出重点，删繁就简。
撰写产品报告
每周产品报告
1.目的。提出关键问题以获取继续前进所需要的信息。
2.受众。考虑到每周发送频率很高，你不希望把产品周报发给组织里的每一个人。关键是限制发送的范围，不要让过多细节以及过高的发送频率将公司高管淹没。
3.注意事项和建议。
专注于三四项内容。太多信息会降低影响力，让人们不愿阅读你的报告。
在报告里好坏两方面消息都要说。全是好消息，看起来没什么好努力的了。全是负面消息则会让人失望。
报告坏消息，可以增加一个注释，说明你会如何应对。
在你的路线图文档上提供一个链接，让人们了解项目每周更新的背景情况。
以发送或抄送的形式将收件人罗列出来，这样每个人都知道有谁参与其中，从而鼓励后续的疑问及评论以透明的方式进行
季度产品报告
季度报告应以一种较长且详细的方式向更加广泛的受众群体传达产品进展信息。
1.目的。侧重于长期趋势（使用率和满意度是要分享的最重要信息），适合于：分享极具竞争力的产品信息，对已发布的重要产品增强进行评论，以及传达有关产品路线的变动。组织可以通过多种文档共享方式来发布季度报告。（share point）
2.受众。在电子邮件中添加免责声明，表示收件人可以联系你选择不接收报告，或者要求把某些人加入收件列表。
3.注意事项和建议。
用漂亮的图形和其他视觉效果让季度报告引人入胜。
当讨论一项新功能或改进时，截图突出变化所在。
在产品性能和产品规划之间寻求平衡，也写一下自己的表现。
在致谢部分加上姓名，尤其要加上那些表现卓著者。
如果需要其他人或部门帮忙就直说，为每一个参与者设定期望，让产品获得成功。
竞争力分析
基于客户反馈和内部指标，以及与竞争者的同类产品乃至不同产品比较，竞争力分析生成的文档或演示文稿能让大家思考你的数字产品是否成功。有价值的竞争力分析甚至不必严格限定在实际的竞争者身上。
竞争者导向分析
以竞争者导向分析会将你和竞争者的异同点进行比较，让你在竞争对手产品的背景下展示产品性能。他们的产品是否在某方面略胜一筹？此类要素有可能改变你的产品策略，这取决于你想通过何种方式将自己的产品差异化。通过这种分析，就能让你对不同的方法进行比较，并通过所掌握的情况最终形成自己的产品路线。（哈维球）
功能导线分析
竞争者导向分析红，你会就一系列特性和功能对一组竞争者进行分析，从而找到相似和不同之处，但在功能导向分析中，你首先基于功能和性能设定一些标准。它可以帮助你确定你的产品是否是首个包含次增强功能的产品，它还能帮你决定如何着手开发这项增强。
目的
无论选择何种方式来分析竞争形式，都要对与回报相伴的风险做到心中有数。通过竞争进行分析和沟通，你提供了额外的背景信息，并提升了团队专业知识，特别是与利益相关者有关的部门。要尽可能多的了解背景信息，以制定出色的决策。不要失去自己的视角，如果过于纠结竞争对手的行为，他们如何以及为什么这么做，就存在一定风险。竞争分析固有的局限性在于，你很少有机会了解竞争对手的产品战略和产品路线图。就增强某项功能或新功能而言，你无法对超越其他对手做出无懈可击的论证，因为他们可能也在同一时间谋划着同样的事。富有创造力的人总会在不同的地方在同一时间里不知不觉的发明类似的东西。
小结
应该经常性的将周报告及每个季度报告的关键数据分享出去。
即使你做的是一个广泛的产品分析，也要确保你分享给他人的度量是一致的。要让人们能快速对当前和以前的度量进行比较，而且比较的是同一样东西。
分享可以反映客户行为的一系列数据，考虑用户以及他们随着时间推移采用产品的情况，不同平台或设备的使用情况。
尽量将成果和影响的可视化效果包括在内。
将竞争力分析包括在报告中，让人理解你对产品的想法和建议如何让组织脱颖而出。竞争力分析是创意的来源。
考虑撰写产品周报及季报。周报简明扼要，发给有限的受众。季报内容会更详细深入，受众更广一些。
第八章 放手去做
提醒你的上级，将设计和开发工作瞄准解决市场问题可以把风险降到最低，你对顾客的了解和共鸣越高，就越能配合他们的需求和期望。
当前的工作中腾出时间进行产品管理。
考虑一下你对一下几种情况的接受程度：
在用户确认某个创意不错前就考虑为产品开发排定优先顺序。
让团队设计一些东西但并不知道这个设计是否会解决客户的现实问题。
在不确定团队的工作能否改善组织的流程，关系，或者财务状况之前，就让他们着手编程。
这样会浪费自己和团队的时间，时间是宝贵的，优先排序，设计和代码都是昂贵的。定期问自己这样的问题有助于形成一套常规程序，包括收集用户数据，将思路原型化，让你的团队信心满满的向前迈进，无需担心太多风险。
国际产品管理日
要建立一个清晰的常规程序颇具挑战，这个程序需要包括撰写用户故事，为积压的产品改进事项设定优先顺序，与用户保持联系，衡量产品成功以及分析竞争态势。最好每周预留一天专门用来研究市场问题，定期为自己安排一些有针对性的产品管理时间。
强调你从客户那里得到的市场数据越多，就拥有更多的信息来做出良好的产品设计和开发决策。
你跟整个团队的人就产品谈的越多，就越能更好的让设计和开发符合公司战略和计划。
让他人参与到产品管理工作中
定期完成产品管理工作的另一个重要方面，是不要想着凡事都自己做。多人一起工作对完成某些任务更加有力，比如采访用户了解产品的使用情况以及改进想法，同时增加工作乐趣。
让其他人参加产品管理能更好的体现和理解工作价值。
让其他人参加产品管理任务可以为团队创造良好的氛围。
为他人创造一个新的产品管理职位
留意那些擅长帮你排忧解难的同事，如果他们擅长产品研究，竞争分析，访谈或调查客户，或者是分析数据，考虑将产品管理作为他们主要的工作重点。如果你是总监或部门经理，具备创造一个产品管理职位的能力，就有机会让产品管理工作得到跟过关注。（总监会看这书么?汗）
撰写产品经理职位描述
跟任何职位一样，产品经理的职位描述会因公司而异，甚至会因产品而异。不要把这个样本当真理，而是用它来帮助你准备自己的描述。
强调一点，产品经理本身是个以人为中心的工作，要能和客户产生共鸣，敏锐发现市场问题。
虽然用户体验设计是有点模糊的领域，但也要尽量选择熟悉此领域的候选人，最好兼备创意和技术背景，以及实际管理经验。
找出那些擅长把事情做好，并能将工作成果传达出去的人。
为自己创建或找到一个新的产品管理职位
我原来做营销和设计，后来进入了网站和移动应用开发领域。一路上我学到的许多重要的东西来自可用性实验或者客户调查，因为我能观察到普通人如何跟网站或移动应用交互。在我名片上印上产品经理之前的若干年，我一直在做产品管理的事。等我更多的意识到自己在做什么并担任产品经理之后，我才知道如何把这个工作做得更好。
开始研究别人要你做得事情并提供一些备选方案。告诉别人，他可能并不是真的想要A，问他是否考虑B或C。
小结
不要指望产品管理工作会自行发生。在日程安排上为产品管理留出时间，并严格执行。
帮你的产品团队或组织内部的其他人做同样的事，如果你领导产品管理工作，就邀请他们一起来做。
雇人从事产品管理工作的话，确保把从设计到写作再到分析的各种职责包括在工作描述中。
创建一个以产品为导向的文化，让每个人都有兴趣并有机会接触到那些使用你的产品的人。
附录 产品设计研究
A/B测试
如果你正烦恼于不知如何在两个看上去差不多的方案中打破僵局，那就把这两个电子或者原型直接摆在用户面前，看哪一个能更有效的满足或超过他们的需求。如果你不想把两个版本同时呈现在用户面前，可以先将一个版本上线一到两周，然后用另一个版本代替它。
启发式评估
由专业评估师对产品进行审查，以确定该产品时否符合普遍接受的用户界面设计原则。最好在对用户进行可用性测试前完成这个评估。这样你花时间跟别人测试的那些方案就会被认为达到了可用性可接受的标准。
1.系统状态的可见性：以及时和易于理解的方式将正在发生的事项告知或更新给用户。
2.系统与现实世界之间的匹配：使用自然语言和标签，而非较为模糊的基于系统的术语。用平实的语言与人沟通。
3.用户控制和自由度：以一种能确认用户得到控制的方式设计体验。特别需要使工作流程简单易懂，并在流程中纳入易于向前和向后追查的步骤。
4.一致性和标准：避免使用不同的术语表述同一个事物或者使用相同的术语表述不同的事物。
5.防错机制：如果存在用户错误的可能性，将这一点考虑在内并减少错误发生几率。
6.识别而不是回忆：让细节，介绍和选项可见并易于回想。将一些重要东西隐藏会强迫用户记住这些信息的位置。
7.灵活性和利用效率：针对重复或高级用户制定或促进产品使用。
8.美学和简约设计：避免内容或设计细节过于精细。
9.帮助用户识别错误，诊断错误，并从错误中恢复：使用清晰自然的语言来确认错误的情况，并向用户解释下一步该做什么。
10.帮助和文档：最好的设计需要极少的文档，甚至不需要文档。复杂产品文档不可避免，让任何信息都能轻松找到，让信息简洁明了并把它分解成细小的步骤。
角色模型
如果你发现有些东西是客户间共有的，可以考虑使用角色模型根据这些特征来描述典型的客户或客户群。角色模型的目标是用一页信息来代表一个典型的用户，即用户的简单印象。尽可能多的包括人物的目标，任务或需求，以及在更长的一个流程中需要实现什么。
跟踪策略
花较长时间观察用户在典型的一天中的生活，要观察的远不止她和产品的互动以及结果，留意她所处的环境，还要记录她的情绪，她是否成功了但仍不满意？很多小细节稍后可以为你积累起大量的产品知识。
用户旅程图
用户旅程图是一个综合文件，涵盖了从上面这些方法中了解到的所有信息。是一个可视化的文件，但在一开始可以用白板或即时贴这种更实用的方法。好的用户旅程图是个活文件，会随时间推移积累更多细节，使用用户旅程图的前提是用户在接触一个组织及其产品时，有一系列想要实现的目标。在产品规划和设计过程中参照用户旅程图可以帮助团队专注于解决用户故事。
