《人人都是产品经理》读书笔记

写在前面：本文仅仅是根据个人阅读习惯或个人有启发之处所记录的笔记，不代表该书的重点哦>o<

对书名的解读

产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成并持续不断以主人翁的心态去跟踪、维护这个产品，那么你就是产品经理。

前言

本书说的产品，绝大多数都是在人们的需求，即用户目标和公司的商业目标之间寻找平衡。“产品经理”这个概念，已经和旧有的产品经理概念不一样了，它更多地侧重产品本身“从无到有”、“从有到优”的过程，而不是去做已经有了产品之后需要做的诸如管理产品、推广和营销产品的事情。

如表1-1所示，

• 互联网是新兴行业，三天一小变、五天一大变，所以产品需要推陈出新，尽力先入为主，占领用户，主导用户习惯，因此产品工作的重头戏在前期，从无到有，从有到优，偏重研发类创新。
• 互联网、产品软件很多产品本身是免费的，一部分产品甚至几年内都不考虑赚钱的问题，另外一些能赚钱的产品也有着更多元的盈利模式，比如免费给用户使用，但利用用户的注意力赚取第三方的广告费等。相比传统行业多是为付钱的客户做（很多情况下用户只是买产品的人而不是用产品的人），互联网大多是为使用产品的海量终端用户所做，因此互联网、软件行业的产品经理会更重视用户研究、数据分析等工作，而盈利的事情反倒交给另外的团队负责。
• 因为互联网、软件行业的产品大多数免费的，只要该产品让用户用得不顺手，用户马上就能很方便地找到另外一个替代品，所以在互联网、软件行业中，产品经理能真正体会到“用户是上帝”的感觉，辛辛苦苦做一个产品，给用户免费用，还要尽量让用户免费用得比付费的都爽。

需求

1、常见的需求采集方法主要包括以下四点：

• 用户访谈
  • 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读；
  • 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做；
  • 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面；
  • 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠结产品的实现方式；
  • 鼓励讲故事：故事是最好的帮助设计师理解用户的方法；
  • 避免诱导性的问题：典型的诱导问题是“如果有xx功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复；
• 调查问卷
  • 调查问卷与用户访谈的区别：用户访谈通常是开放式问题，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流；调查问卷通常是封闭式问题，适合大用户量的信息收集但不够深入，不适合安排问答题。
  • 调查问卷可以避免群体讨论性质的方法的弊端，因为群体中通常开始表态的几个个人观点引导了群体的观点，但存在以下问题：
    • 样本的偏差，即样本与想了解的目标用户群体出现偏差；
    • 问卷内容的细节问题，即对于重要的问卷，可以先进行小范围的试答，根据反馈修改后再大面积投放，这和互联网产品的灰度发布有着同样的理念；（灰度发布：先让少量用户看到新产品，利用他们的反馈进行修正，逐步把新产品展现在所有用户眼前）
    • 问卷开头一般放一些简单的不需思考的问题；需要思考的、较敏感的问题一般放在中间；被访者个人信息一般放最后，以免应答者在回答问卷问题时有所顾忌；
• 可用性测试
  • 可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做。主要步骤包括：
    • 招募测试用户：这些用户要尽可能代表将来真实的用户；
    • 测试过程：用户使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来；
    • 测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉，或用户在测试过程中所思考的、所做出某些操作的想法；
    • 研究与分析：产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理；
  • 常见问题与对策：
    • 如果可用性测试做得太晚（产品将要上线的时候），此时发现问题也于事无补：可用性测试在产品的各个阶段都可以做（在尚无任何成型的产品时可以拿竞争对手的产品给用户做；在产品只有纸面原型的时候可以拿着手绘的产品，加上纸笔给用户做；在产品只有页面demo的时候可以拿demo；在产品已经可以运行后拿真实的产品给用户做）
    • 可用性测试常被忽略，但即使只做一个用户，也比不做要好
    • 明确是测试产品而不是测试用户：减轻用户的压力，使得他们能像在真实环境一样来使用产品
    • 可用性测试中，可以采用“发声思维”的方法，即在使用产品的同时说出自己的思考过程；在测试过程中不要有任何的引导暗示，而只是观察和记录。
• 数据分析
  • 在数据分析时也会有一些特定的问题：我们经常误读数据。在提取数据之前，我们心中通常已有一些结论，无非是想验证它，越是技术娴熟的人越容易找到数据来证明自己心中的想法。因此解决办法就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯。

2、用户需求 VS 用户需求

• 用户需求：用户自以为的需求，并且经常表达为用户的解决方案；
• 产品需求：经过分析，找到的真实需求，并且表达为产品的解决方案；

需求分析就是从用户提出的需求出发， 找到用户内心真正的渴望，再转化为产品需求的过程。伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西。

3、需求来源于理想与现实的差距，那么减小这个差距就有三种方式：
（1）改变现状：最常用也最笨的方法，去开发某种产品
（2）降低理想
（3）转移需求：人的行为是需要需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求

4、商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判，这一点是整个需求列表中最核心的部分。但，绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。而是要按照性价比从大到小排序，优先做性价比高的产品需求。

项目

1、项目的定义：只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。

2、做产品VS做项目
（1）从生命周期的角度来看
做产品的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。而项目有特定的目标，所以生命周期较短，通常在项目开始以前就有明确的起始和结束时间，通过验收则表示项目生命周期就算完成了。因此，会有一个已经“结项”的项目，但不可能有一个已经“完成”的产品（只有不断完善中的产品，除非它被新产品替代）
（2）从具体要做的事情来看
做产品需要随着各种内外部信息的变化，不断地修正自己的判断，给出适宜的创新；项目在开始时就有明确的目标，更注重计划与控制。
（3）从产出物的角度来看
产品可以批量生产，或者提供给大量用户，相对通用；项目只进行一次，每次都是个性化的，要满足那个特定的需求。

3、产品经理VS项目经理
（1）产品经理：最重要的是创造力与判断力，决定做不做、做什么、做多少，保证其所领导的产品能够符合市场的需求并能给公司带来利润。
（2）项目经理：最重要的是执行力与控制力，决定怎么做、谁来做、何时做，保证能按照目标完成项目。

一个产品经理可能想要增加非常多的功能和特征以满足获取到的用户需求，但是项目经理却想要尽可能小地控制工作范围，以保证项目在规定时间与预算内完成。好的产品经理和好的项目经理应该能在冲突中找到平衡。

4、要写很多文档，但要注意！文档只是手段！

• BRD（Business Requirements Document，商业需求文档）：其内容涉及市场分析、销售策略、盈利预测等，通常是给大老板们演示的PPT，也就比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要为了获得认可，争取资源。
• MRD（Market Requirements Document，市场需求文档）：获得老板们的支持后，产品进入实施阶段，需要写出WRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级等。这是从商业目标到技术实现的关键转化文档。
• PRD（Product Requirements Document，产品需求文档）：对产品功能进一步细化，是PD新人写得最多的文档。文档包含整体说明、用例文档、产品Demo等。
• FSD（Functional Specifications Document，功能详细说明）：经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定。
  
  如图3-7所示：
  （1）修订历史：写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。
  （2）项目概述：简单描述项目的背景、意义、目的、目标等，描述业务领域知识，让文档作者明白这个项目是为什么做。如果此PRD没有包含项目全部需求的话，也应做相应说明这部分需求是什么，其他需求在哪里等。
  （3）功能范围：给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规则等。
  （4）用户范围：对本PRD涉及的角色、系统做出简单的说明。
  （5）词汇表：对本PRD涉及的专有词汇、术语、缩写等做出说明。
  （6）非功能需求：如性能需求、数据监控的需求等。
  （7）UC（Use Case，用例文档）部分：需要对PRD中所有的用例进行说明，给出用例的可视化表示，说明各个用例之间的关系，一般有类图、用例图、状态图几种表示。UC一般只用来描述功能需求，它不便于描述诸如产品扩展性、系统容量、人员培训等非功能需求，所以我们把非功能需求部分写在PRD的总体说明里。

5、图3-22是作者附上的其整理的PD常用的文档模板

6、评审：如果将项目中一次又一次的会议都看作评审，那么这么多评审是否可以省？
（1）产品会议：必须有，决定“做不做、做多少”非常重要。如果没有多个产品之间的资源争夺，同一个产品的不同需求也必须争夺，可以把确定需求商业价值的需求讨论会、初评工作量等工作都放在一起作为产品会议。参与者最少得是产品团队、开发、测试、销售、服务等各个部门的头，或者有话语权的接口人。
（2）Kick Off会议：最好开，鼓舞士气，可以考虑与需求评审合并为一次会议，安排在最开始的15分钟，会议结束后部分人员可以离开。
（3）需求评审：具体包括PRD、UC、Demo评审，但很少分为三次，看情况合并。
（4）设计评审：在开发人员实力很强的情况下可以省略（他们在需求评审时会问很多问题），而开发较弱、新人多、业务不熟的团队，则需要进行设计评审。
（5）TC评审：项目KO以后第二重要（仅次于需求评审）的评审，实在要省的话PD需要做更细致的验收测试。与设计评审类似，TC评审也属于纯技术的评审，商业团队一般就不参加恶略。
（6）功能评审：必须的，需要项目干系人都参加，不过经常采取线下的方式进行。
（7）发布评审：让产品经理决定是否需要。

上述这些常见的评审主要可以分为两类：“商业评审”与“技术评审”，简单地讲，商业评审决定“做不做”，是产品会议与功能评审；而技术评审决定“怎么做”，是需求、设计、TC、发布评审。商业评审与技术评审最好分开。

• 商业评审的三大决定：项目继续、重新定向、项目终止。
• 技术评审的三个决定：项目继续、有风险的继续、必须解决某问题后再继续。
  

团队

1、一个产品最终的商业化成功与否，推及一个公司的成功与否，所有的影响因素似乎都可以归结到商业、产品、技术三个方面。我们可以理解成， 这三个方面的乘积决定了产品最终成就的大小，任何一个维度上的提高对产品都大有好处，任何一个维度太弱对产品也都是致命的。

• 商业：在公司里主要由市场、销售、服务等部门来考虑，他们决定产品的销售渠道、价格策略、销售策略、服务方式等。
• 产品：包括产品设计、用户体验、产品运营等部门来考虑，他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。
• 技术：主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、bug数量等特性。

上述三方面，任何一个公司必然有其强项和弱项，它不可能也没有必要在这三方面都很强，一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗，所以更重要的是找到自己公司、或团队、或产品的那个突出的刀尖，也就是所谓公司的DNA。

2、产品设计的五个层次（内容来源于《用户体验要素》一书）
这五个层次，从整体看是抽象到具体的过程，是从概念到实现的过程，是从商业到产品再到技术的过程。但是各层之间的界限模糊，彼此交叉，而且必须反复迭代。

• 战略层：找到商业目标和用户需求之间的平衡点，深刻理解公司战略并尽可能发挥自己的影响力。
• 范围层：明确“做多少”，对于软件类产品，是确定功能范围；对于网站类产品，则是确定内容范围。先要“尽可能多地收集”需求，灵活运用多种用户研究地方法，再“尽可能多地放弃”，留下性价比最高地最有价值的需求。
• 结构层：考虑产品的各个部分互相之间是什么关系，对于软件类产品，主要工作有交互设计，对于网站类产品，主要工作有信息架构。这一阶段常见的产出物有软件的业务逻辑图、网站的站点地图等。一般来说，技术部门在这时开始全面介入。
• 框架层：在这一步才出现用户真正能看到的东西。对于软件类产品，主要工作是界面设计；对于网站类产品则是导航设计。
• 表现层：这一步的主要工作包含了视觉设计和内容的优化。

3、产品团队：游走于商业与技术之间的产品团队（工程师们把我们当作业务人员，市场销售们却把我们当作技术人员）

狭义的产品团队，具体是指产品经理及其带领的产品规划师、产品设计师和需求分析师。产品经理和产品规划师更偏向于产品前期的规划，比如产品的市场定位、各个版本发布的时间计划等，思考的焦点是商业目标和用户需求。产品设计师侧重于做功能级的设计，编写需求文档。需求分析师相比PD的工作，其主要偏实现、技术，即写UC，做系统设计

4、从概念设计到信息架构：概念设计是为内部而做的，便于大家对产品形成共识，产出概念图应该是在需求采集之后，需求筛选之前；完成概念设计之后才可以开始信息架构的工作；信息架构是为外部而做的，实现更合理地将信息传递给用户。

概念设计的关键是描述整个产品的内外关系，形式不重要，重点要表达下面两点：

• 产品与外界的关系：把产品整体看作一个系统，描述它与上下级系统、并列系统的关系，可能的话，勾勒出产品所处的产业链结构；
• 产品内部的关系：产品有多少模块、模块之间的关系如何，不用涉及数据流等细节，重点描述清楚不同的角色在系统里的关系

5、产品营销中关于产品版本细分策略的解读
（1）做功能区分，打细分市场：比如笔记本的高中低端产品、手机的各种型号
（2）为了促进销售，利用消费者心理，纯策略性地做出“炮灰版”

• “高价炮灰”：在原有版本地基础上，增加一些鸡肋功能做一个价格高出很多的“高价炮灰”，让消费者觉得商家真正想卖的那个版本特别实惠。一个特殊的例子就是在“抢市场而非赚钱”的商业目标指引下，主推免费版的同时还放出一个其实并不想卖的付费版本，以保持免费版的价值感；另有一种类似的策略属于技术性炫耀，比如汽车厂商的概念车，他们可以让产品用户心理满足以提高忠诚度。
• “低价炮灰”：删除核心功能做一个价格稍低的“低价炮灰”，让用户满心欢喜地、好似占了多大便宜似的赶紧买下那个价格稍高的、商家真正想卖的产品。

需要注意的是，做“炮灰版本”的成本要足够低，否则得不偿失。

产品战略

1、有些产品设计师经常脱离产品的战略来讨论设计的优劣，不从目的出发而去评价用户体验好坏，是很没有道理的。比如，当产品设计师们在争论某个按钮应该大还是小的时候，我们就应该从商业目的，或者说战略出发，到底时候希望引导用户点击呢，还是希望用户尽量不要点击？比如对“退出”按钮，一般我们就是不希望用户去点的。
2、关于产品战略的具体制定，在项目管理里叫“可行性分析”，其思路可以简化成下面三步：
（1）我们在哪儿：除了确定公司的“价值观、使命、愿景”之外，还有关于公司、市场、竞争对手现状的各种背景信息的采集与分析。

• 整个行业如何——市场扫描
  一个常用方法叫做PEST分析，分别分析政治法律环境（Political Factors）、经济人口环境（Economic Factors）、社会文化环境（Social Factors）、技术环境（Technological Factors）四个方面的机会和威胁。我们只有通过宏观层面的PEST分析，发现结果是乐观的，有涉足这个行业的可能，才可以继续分析下去。
  
• 竞争对手如何——竞品分析
  • 上网搜，狂搜与要做的东西相似的产品，看它们的网站，简单了解，然后试用这些产品，看看其功能列表，也会假装用户，打电话过去和对手的客服、销售套词；
  • 看行业分析报告，但需要注意的是，对于此类报告，一定要看出处，作者与机构的背景，确保报告的客观性
  • 有时候还得靠公司里经验丰富的一些“老人”来“拍脑袋”
• 自己情况如何——自我分析
  我们剖析是针对公司有什么行业积累、技术积累，有哪些缺点、不足等，想清楚“这件事为什么是我们来做？”，常用的方法是SWOT分析：优势（Strength）、劣势（Weakness）、机会（Opportunity）和威胁（Threats）。通过SWOT分析对企业内外部条件各方面内容进行综合和概括，进而分析组织的优劣势、面临的机会和威胁，从而帮助企业把资源和行动聚集在自己的强项和有最多机会的地方。

（2）我们去哪儿

（3）我们怎么去：解决这一步的问题，浓缩成两个字就是“策略”（定价策略、推广策略、渠道策略、服务策略、财务策略、技术策略等），各种正确的策略保证了我们是在“做正确的事”。

3、KPI（Key Performance Indicators，关键业绩指标）：它是在分解企业战略目标的基础上，分析并建立各子目标与主要业务的联系之后提出的。可见，KPI是企业目标得具体表现，所以不一定只是常见的营收、利润、用户数，也可以是客户投诉率、员工满意度、社会贡献等。

在指定目标的时候，需要符合SMART原则：

• S代表具体（Specific），指绩效考核要切中特定的工作指标，不能笼统；
• M代表可度量（Measurable），指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或信息是可以获得的；
• A代表可实现（Attainable），指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标；
• R代表现实性（Realistic），指绩效指标是实实在在的，可以证明和观察；
• T代表有时限（Time bound），注重实现绩效指标的特定期限；

但是，需要注意，你再怎么去客观地设计绩效体系，这个体系都无法真正地与你追求的目标划上等号，在这种情况下绩效体系越量化，越容易将团队成员带入追求绩效的数字游戏上而忽视了真正的目标。

最后

最后附上书中作者对“产品经理”这一岗位招聘信息的解读，非常真实了