读书笔记 | 从点子到产品 (下)

原书作者：刘飞
笔记整理：简水
请关注微信公众号：产品经理简水
续上篇

5 用户研究

1. 用户研究的目的是理解用户，不关注产品功能只关心用户。方式方法是使用成型的用户研究方法，发掘用户需求，研究用户行为，评估用户的满意度，获取与用户相关的数据和信息。

2. 用户研究要有明确的目标。

3. 用户研究的结果不能提供直接的解决方案，只是提供情报。

4. 用户研究的方法：1）观察用户的行为和状态；2）听用户表达的观点和思想。

5. 用户研究有定性的结论，也有定量的结论。常见用户研究的划分：定性or定量，行为or观点。

6. 用户调研之前，要先判断自己要了解用户的什么，哪种方式比较好，然后选择合适的方法开始。

7. 有缺陷的问卷，出现的结论可能会引导到错误的结果。例子：情趣行业的用户调研，通过调研发现用户中没有女性。这明显是不合常理的，最后发现女生填写问卷时，给出的是错误的答案，说自己是男生。

6 用户体验

用户体验关注让产品友好的满足用户的需求。让用户使用产品时，更方便、舒适和快捷。

常见的可用性原则：

1 可见原则

内容可见（需要出现的信息都会出现）、状态可见（加载中，等待用户操作）、变化可见。不好的体验是用户找不到信息，不知道当前什么情况，不明白发生了什么。

2 场景贴切原则

产品功能符合用户的使用场景。例子：滴滴司机版，字体很大，按钮位置特别，页面利用率不高。但司机开车的时候使用起来很方便。

3 可控原则

用户对产品能够很快了解，方便控制产品的状态，用户有足够的自由。例子：iphone的home键，一键回到桌面。

4 一致性

产品具有统一的规范（称呼、按钮位置、字体、颜色）和处理逻辑。

5 防错、防呆原则

给用户足够多的提醒和设计，防止用户犯错，或者用户呆住了不知道怎么继续。错误提示要让用户知道什么意思，即使出错了，也要告诉用户接下来怎么办呀。例子：选择日期的界面，使用灰色，用户不知道怎么选择。

PS：用最常用的交互界面就行，不要别出心裁了。

6 协助用户记忆的原则

不要让用户去想，产品给够足够的信息。例子:订单的确认页，把用户要购买的东西列出来，用户在支付前不用回想自己到底选了什么东西。mac os删除图片时，直接提示要删除几张图片。

7 简约易读原则

界面足够清晰、简单；文案内容应当简易，可读性强。不要太花哨的界面，用户看着感觉太复杂，不知道从何下手。

8 容错原则

在用户犯错时，进行提醒。例子:文本编辑时的撤销功能；Gmail的邮件删除的撤销功能；锤子手机发短信的撤销功能。

9 帮助和提示

10 灵活高效原则

例子：微信发送照片，可以自动把刚拍照的照片自动浮现出来。

11 恢复现场原则

例子：微信看公众号文章，退出再回来，会返回离开时的位置。

12 文案

产品经理接触的文案，不多，但足够关键，一定要慎重对待。文案不要用文艺的语言，一定要通俗易懂。文案长度一定要剪短，能有多短就有多短，不要啰嗦。文案不能有歧义。文案要让小白用户检验，一定要直白、通俗易懂。如：请公司楼下的保安看看文案好不好。

总结：

任何产品任何功能都还有优化空间，好产品只是当前时间、资源和市场环境下的最优匹配产物。只要有时间、精力，一定要不断思考，让产品变得更好！

7 文档管理

7.1 产品经理要不要懂技术

1. 产品经理的分类，各个公司是不同的。有技术性、设计型、运营型、项目管理型等等。

2. 产品经理要了解公司产品的技术架构，至少知道用了什么语言、什么数据库、服务器是怎么样的、什么系统等等。技术型的产品经理还要了解算法、技术逻辑、数据结构、架构和整体框架等内容。

3. 产品经理要懂技术，但懂到什么程度就要看具体需要了。

4. 产品经理了解技术是为了更好的设计产品以及协作，不是帮技术的同事完成工作。

7.2 好的PRD文档是怎么样的

检验方法：能够减少甚至免除在开发过程中，技术人员与产品经理沟通的文档，就是好的文档。

PRD文档的几个要求：

• 没有逻辑硬伤。不会前后不一致。

• 没有疏漏。缺失功能也是常见的失误。

• 逻辑清晰。内容太零散，开发看了会不知道从哪里下手。判断逻辑模糊，开发就更不知道怎么实现了。

• 可读性强。应该用图表，就不要只写字。专业名词要提前在文档开始的地方解释清楚。

产品经理有责任让团队的所有人都对产品有统一认识。产品经理也要不断的和技术人员产生互动。

文档形式不重要，最重要的是能让开发人员看懂。

文档的完整性、逻辑性比文档的可读性、美观程度更重要。

7.3 文档逻辑

产品经理的工作：想清楚、讲清楚、做出来。文档就是讲清楚的关键载体。

PRD文档的三个逻辑：功能框架逻辑，业务流程的逻辑，功能描述的逻辑。

7.3.1 功能框架的逻辑

1、产品复杂之后，必须在功能框架上清晰。如：淘宝这种产品，一定要有清晰的功能框架，方便大家协作完成功能。

2、梳理功能框架的方法：

1）拆分。将产品功能拆分为独立的功能模块，这些功能模块涵盖了产品的所有功能。

2）组合。将零散的产品功能模块，进行分类组合，形成几个组合。

3、梳理功能框架的意义，方便产品和开发工作的分工、协作开展工作。

7.3.2 业务流程的逻辑

1、业务流程是产品提供功能或服务的具体流程步骤。

2、业务流程的分析有两个维度，面向事件和面向对象。

3、面向事件的业务流程分析：

1）将一件事分为多个步骤和操作，每个步骤要做的事情，产品提供的功能和服务。

2）一般使用流程图描述。

4、面向对象的业务流程分析：

1）使用状态转化图表现。

2）把完整的状态转化列清楚，查看状态是否有缺漏，状态是否合理；确认逻辑是否完备。

7.3.3 功能描述的逻辑

描述功能的原则：

• 完整。枚举所有的情况，分情况说明功能内容。

• 考虑到所有的影响点。任何改动都是牵一发而动全身，需要对全局有足够了解和谨慎，才能避免出现问题。

• 条件判断清晰。不要给出含糊的判断条件。

• 含义明确。名词一定给要出具体的含义，不要用别人看不懂的名词。

• 叙述背景。描述一个功能产生的原因，以及要达到的目的。

8 需求管理

需求的生命周期是整个产品设计到实现的流程。需求管理是产品经理的重要工作。需求在不同的阶段，产品经理的责任和具体工作是不同的。

功能是需求的表现形式。

产品经理对于自身相关的需求状态要了如指掌。出现偏差要第一时间发现，千万不要等最后出现问题再来解决。

需求的变化、调整和意外，一定要同步到整个团队。

8.1 获取需求阶段

需求的来源有很多，业务越复杂，需求就越复杂。

产品经理的级别越高，收到需求的可能性越大。产品助理，直接接到任务。低级产品经理，用户和上级提需求。高级产品经理，老板和其他部门提需求。老板，谁都可以提需求。

获得一个需求时，要做一个简单的判断和记录。判断需求的方法：

• 需求的重要性。主要从影响面来分析。

• 考虑需求的来源。老板的需求。用户的需求，是否目标用户？

• 了解需求的背景。原因不明的需求，不记。逻辑不清的需求，不记。不是实际用户的需求，不记。

8.2 讨论和设计阶段

需求讨论会，整理需求池。确认以下事项：

8.2.1 需求的优先级

1、重要or不重要+紧急or不紧急。

不做这个需求的后果是什么？

做了这个需求的好处是什么？

2、KANO模型，将需求对于的功能分为’惊喜型’、’期待型’和“必要型”。优先满足后两种功能，然后不断用第一种功能激活用户的激情，促使用户的传播。

8.2.2 方案草稿

例子：O2O解决刷单的问题。有多种解决方案，事前提醒，事中限制，事后惩戒。具体使用哪种方案，需要依据方案草稿进行讨论。

8.2.3 指定责任人

两种需求分配的方式:按照产品模块划分，按照事情划分。按照产品模块划分，优点：清晰，界限明确，缺点：工作量不平均。按照事情划分，工作量倒是比较均衡了，但产品就乱了。

需求要指定责任人，上线后出了问题由责任人承担，形成制度可以提升产品质量。

8.2.4 时间节点

1、需求方案要有明确的deadline。

2、产品经理要向需求方同步需求的状态，排定的优先级和时间节点。

8.3 待开发阶段，需求方案的可行性评审

1、方案本身的可行性。技术上能否实现？

2、有没有更好的方案？

3、设计的产品和技术环节有哪些？

4、方案的成本如何？

8.4 开发阶段

1、开发需求的次序，未必按照需求的优先级进行，也会兼顾需求的性价比。

2、按照需求优先级+需求的成本，计算需求的性价比排序。按照性价比高低开发需求。

3、一个迭代周期的需求确定后，关闭需求。原则上这个迭代周期不再接收新需求。

4、开发需求中容易遇到的问题：

1）需求太多，一个迭代周期无法完成，造成需求挤压。

2）需求变更，造成额外工作量。

3）有紧急需求插队。

5、产品问题的原因：

1）产品方案不完整。开发过程中，发现产品方案的逻辑或功能有问题，导致程序员需要找产品经理再讨论明确。这个问题的出现可能是需求分析时不彻底，讨论需求方案时不认真，或可行性评审时被疏忽了。

2）需求方主观改动。

3）无法预测的客观原因。

8.5 复盘阶段

需求完成后，尤其是在出现问题时，一定要对整个过程进行复盘。复盘不仅仅是为了追究责任，更是为了防止同类问题再次发生。

9 工作流中的管理

产品经理的工作不是标准化的，没有统一的范本。最终的目标是把产品做出来。实现一个目标有很多个方法，往往大家会选择最容易想到，但不是最好的办法。

9.1 协作管理

沟通能力很重要。但仅仅依靠沟通解决不了问题。团队要协作工作，协作是每次遇到问题在大家情理可以接受的范围内解决掉。

9.1.1 与技术人员的协作

1. 评审会。产品概念的可行性评审，产品方案的PRD评审，都是需要与技术人员完成的日常协作。

2. 出现状况的协作。需求变更、上线时间提前等，产品经理要想办法安抚好技术的同事，解释原委，一同想办法解决问题。

3. 技术的困境。有时会出现技术人员无法解决的情况，产品经理需要帮忙协调资源，共同定位问题。这样可以加深与技术人员的战斗友谊，形成良性循环。

4. 双赢。产品经理也不要老是想着说服开发人员，感觉只有这样才是胜利。如果产品经理老是凭借口才和狡辩，开发人员会对产品经理产生不爽，后续就没有办法开展工作了。

9.1.2与需求方的协作

需求方关心需求完成的准确程度和及时程度。产品经理需要注意和需求方同步信息。如果出现问题，产品经理要及时安抚并对需求方做出解释。

9.1.3 开会

会前要做好准备。会议要高效，关键是在会前的准备。

1）会议的内容、主题准备好，发会议通知时就要发出来。

2）会前的沟通。会议前先与重要参与者沟通会议的内容，提前达成共识。

3）会议过程要讲规则。有主题，有秩序，禁止人身攻击，有结论。

9.1.4 记录

1. 记录各个环节的沟通结论，以防出问题后扯皮。

2. 记录对于产品的思考过程和结果。否则过段时间就想不起来了。

3. 记录内容：

1）文档。再小的需求也要有文档，至少也要写在邮件里。大部分团队的产品文档都不全，这样导致无法了解产品的全貌。

2）会议记录。任何会议都要有会议记录。

3）想法和思路。有了产品的想法和思路，要记录下来，防止忘记了。

4）同事说的需求，技术人员提到的方案，圈内人分享的数据等，最好都记录下来。

9.2 流程管理

对产品经理工作流程的管理和改进，其价值可能远超我们的想象。

9.2.1 让协作标准化和流程化

防止“大公司病”，中小团队采用大公司的协作流程和方式，很多时候是不合适的。

当同样的问题重复的出现，而且使用简单的规范可以解决时，就要尝试指定规范来解决问题了。例子：口头需求变为需求管理流程。需求由邮件提出，需求提出者和需求接收者都是固定的接口人，需求状态每周固定时间发布，延期需求要发邮件告知原委。

9.2.2 减少手工劳动

使用工具解决手工操作的问题。

例子1：需求管理工具，从excel到google DOCs，再到专门的需求管理软件。解决需求的多方协同、搜索、定时提醒的问题。

例子2：产品经理需要不同维度的统计数据，可以使用一些现成的脚本直接提取。

9.2.3 让一些工作可复用

做产品原型时，将元素和模块做成可以重复利用的。

文案的逻辑、警告、提醒和解释等内容，形成规范。

9.2.4 避免重复犯错

遇到问题时解决问题很重要，但避免下次再犯同样的错误更加重要。

错误的原因：

1）由于疏漏导致；

2）由于信息不全面；

3）没有责任心导致；

4）由于能力不够无法胜任导致。

9.3 个人管理

有的人失去了别人的管理，就会变成无头苍蝇，不知该做什么。

任务管理中容易出现出现的问题：

1）把焦急当成优先级

2）把充实感当成完成任务

3）眼光不够长远，只做眼前的事情

4）事情没有截至日期

5）不检查效果

知识管理。我们不能记住全部所学、所见的知识，因此我们需要把许多知识和信息记录下来，方便以后用到的时候查阅。

团队管理。专业能力服众。具备一定的管理技能。
全文完


请关注微信公众号：产品经理简水
感谢支持！

扫码关注公众号