1.2
产品经理的基础技能要求

产品经理的基础技能主要分成两大类，一是专业技能，二是通用技能。专业技能指的是需求分析、产品设计、文档撰写、产品管理等相关的技能。通用技能指的是职场人都要具备的能力，如沟通能力，本节着重介绍的是与客户、开发测试人员、设计师沟通的内容与技巧。

1.2.1　需求的落地执行能力

1.需求分析能力

产品经理直接和用户接触，只有走进你的用户，成为你的用户，才能洞察用户需求，了解用户的痛点，进而解决用户的问题。

常用的需求调研和分析的方式包括调查问卷、用户访谈、情景观察、头脑风暴、运营数据分析等，在后续的章节会展开介绍。

2.产品设计能力

产品经理最基本的技能，当然就是“产品设计”，包括流程设计、功能设计、原型设计。笔者认为，产品设计的核心就是流程设计，把现实中的业务场景转换为软件产品中的流程。

例如，在现实生活中，李明非常想吃一家粤菜馆的饭菜，但是他又不想出门，于是他准备订餐，他找到粤菜馆的联系方式后，先询问对方能否配送（可能存在距离过远的问题），如果能配送，那么进行点菜，等待送达。

上述业务场景是李明已经明确就要吃这一家粤菜馆的饭菜，那么在软件产品中，就需要先搜索商家，如果商家在配送范围内，则可以进行点菜，反之则要给出明确提示。那么，如何确定是否在配送范围内呢？软件要获取当前用户的地理位置，所以在软件产品的业务流程中，首先要获取定位，然后搜索商家，接着判断距离，决定是否进入点餐流程。

当把业务流程大体确定后，开始进行“功能设计”。功能是实现流程的具体方法。例如，在获取当前定位时，如果获取失败（如用户的手机没有开启定位功能），需要支持“重新定位”功能；搜索商家的方式可以按商家名称模糊搜索，也可以按商家分类进行筛选，这就是某一个流程节点的具体功能。

在设计功能时，可以结合用户的具体场景，思考是否可以由一个场景延伸到其他场景，才能让用户觉得产品更加贴心，使用起来更加顺手。例如，定位功能本质上是为了判断商家是否在配送范围内，除上述场景外，还可能存在给别人点外卖的情况，也可能有下班时提前点餐送到家的情况，那么定位功能就需要延伸为“手动修改位置”和“手动选择已添加的收货地址”；用户可能想不起来商家的具体名称了，但对商家的某一道菜印象深刻，那么产品就可以提供“通过商品名称，间接搜索到商家”的功能。

接下来开始进行“界面原型设计”。页面是功能的载体，界面原型简单来说就是页面的“草图”，是一种直观、低成本的沟通需求、确认需求、评审需求的方式。下面是界面原型图，读者可以先进行初步的感受。

3.行业知识

产品经理要具备一定的行业知识，才能更准确地理解业务需求。例如，汽车后市场的产品经理，至少要对汽车品牌、车型、年款等有一定的概念，对汽车保养、年检等知识有一定的了解。

产品经理积累的工作经验也是区分行业的，医疗行业、教育行业、电商行业所需要掌握的业务知识肯定是不同的，所以在更换工作时，不要短时间内更换跨度非常大的行业。但不排除有一些经验是可以共用的，例如，一款线上医疗的App，可能会包括付费咨询的功能，那么就会涉及支付、订单、财务等模块，与电商App中的这些模块在逻辑上是相似的，这些经验就可以共用。

1.2.2　文档能力

撰写各类文档也是产品经理的日常工作之一，例如，PRD文档、用户操作手册、Q＆A文档、会议纪要等。

1.PRD文档

PRD文档（Product Requirement Document，产品需求文档）与可交互式界面原型一起指导产品开发，向开发人员和UI/UE（用户体验）设计师详细说明功能技术指标。

编写PRD文档最主要的原因是：仅仅依靠界面原型无法交代清楚业务细节，开发人员和测试人员无法准确把握需求，在后期也缺少对需求细节的查询手段。关于PRD文档更详细的知识见第8章。

2.用户操作手册

用户操作手册是软件的使用说明书，从用户的视角详细描述软件功能、操作方法和用户界面。需要编写操作手册的场景如下。

（1）有些to B项目（面向企业的项目）、to G项目（面向政府部门的项目），业务比较复杂，终端用户年龄偏大，需要操作手册指导用户使用。

（2）减少运营人员的压力，把用户集中遇到的问题和解决方案整理出来，附在操作手册后面，或者单独形成一份Q＆A（Question and Answer，问与答）文档。

3.其他文档

在软件项目开发周期中，会产出各种类型的文档，例如，设计方案、实施方案中关于产品设计的部分，运营文档、验收报告、会议纪要等，也需要产品经理辅助编写。

1.2.3　沟通能力

产品经理在团队中起到承上启下的作用，良好的沟通能力能保证项目干系人之间获取和传递信息的一致性与正确性，保证团队成员之间工作流的顺畅，促进产品研发项目良性发展。

1.与客户、用户沟通

与客户、用户沟通交流时，不要说计算机行业的专业术语，同时还要尽可能了解客户、用户所在行业的专业术语，让沟通更加顺畅。

当获取第一手原始需求时，经过一系列的分析后，最终以界面原型的形式进行演示，让客户、用户直观地看到软件系统的功能架构和交互方式是否能解决自己的问题。经过反复的修改与磨合，双方最终达成一致。

我们要学会使用听故事、讲故事的方法，找到用户真实的痛点，所谓“故事”，其实就是把使用场景细致地用自然语言描述出来。

例如，教务管理系统中“批量导入学生”功能的使用场景是：把学生信息在Excel模板中填写完成后导入系统，如果没有任何问题，则导入成功。但也经常会发生Excel模板中某些数据不符合填写规范的情况，此时系统会给出明确的错误提示，告知用户哪些数据填写错误，而用户的第一反应是直接修改Excel文件中的内容，然后重新导入。

针对上述场景，在设计“批量导入学生”的功能时就要注意，当出现Excel中数据填写错误的情况时，所有的数据都不要导入，包括那些正确的数据。因为学生的身份证号、学号要求唯一，如果开始把正确的学生信息导入系统，那么按照用户的使用场景，在修改Excel后再次导入时，会提示有很多学生已经存在，这时只能在页面中手动单独添加没有导入的学生信息，反而造成了不便。

2.与开发、测试人员沟通

与开发、测试人员的沟通主要在需求评审阶段和产品开发阶段。良好沟通的前提是界面原型和产品文档清晰严谨，减少纰漏。诸如原型与文档描述不一致、异常流程处理不到位等情况，都是要极力杜绝的。

需求评审阶段，产品经理要给开发、测试人员讲解产品功能。在讲解时，要把产品的背景、愿景讲清楚，让开发人员理解为什么要做这个功能，不要让开发人员带着疑问工作。同时，开发和测试人员可能有更高明的解决方案，能够在产品体验与开发成本之间找到一个平衡点。在讲解完成后，要让开发、测试人员进行“反讲”，即按照他们的理解再次把需求和功能叙述一遍，确保理解的一致性，避免由于理解偏差导致的工期延长。

进入产品开发阶段后，不要只拿Deadline（最终期限）给开发人员施加压力，不要轻易质疑开发人员的实力，不要逞口舌之快。

3.与UI/UE设计师沟通

设计工作具有一定的创造性，很难提出标准的设计要求。例如，你可以提出“页面风格要扁平化”，这只是一个设计方向，但无法标准执行，你无法提出诸如“线性图标的像素值是多少”“阴影的参数值是多少”等精确要求。产品经理与UI/UE设计师要做到高效的沟通，需要有一定的审美能力，了解什么样的设计是好的，什么样的设计符合当前产品的特质。

产品经理要给UI/UE设计师交代清楚每个页面的使用场景，用户停留在每个页面的主要目的是什么，才能让软件的交互体验更便捷、更丝滑。

督促设计师形成设计规范，毕竟UI界面的设计不同于艺术作品，它需要在兼容美学的基础上，做到统一性、易用性、组件化。

产品经理可以对设计稿提出意见和建议，但不要过分从细节上干预设计师。例如，产品经理可以提出“这个配图不适合使用插画风格”，但尽量不要提出“把实线改成虚线”这种过于细节的建议。当然，上述说法是在UI/UE设计师至少处于行业平均水平的前提下，要充分信任设计师的专业能力，如果设计师本身经验不足，则另当别论。

1.2.4　产品管理能力

当产品的设计通过评审后，进入产品开发阶段，产品经理需要对产品的各个方面进行管理。

1.产品规划能力

我们需要先明确产品要解决的核心问题是什么，尤其是初创产品的第一个版本，一般只关注能否解决用户的一个核心痛点。按照这个基本原则，把与核心问题关联度高的需求优先开发，当产品稳步运行一段时间后，再逐步安排其他需求的排期。

产品经理也应该对接下来一段时间（如2～3个月）要开发完成哪些功能、产品要达到一个什么样的高度做到心中有数，并向团队成员公布，这样技术负责人可以全盘考虑技术上的问题，预估可能会遇到的技术风险。

产品版本的迭代不仅是发布新功能，也包括产品功能的优化与产品缺陷（Bug）的修复，可以按照紧急程度和重要程度对新版本的功能进行规划。需求优先级的具体评估方法详见3.6节。

2.进度把控能力

产品经理负责产品的整个生命周期，所以关注产品的开发进度，就像关心自己孩子的成长一样。

当前产品版本的功能有哪些已经开发完成，哪些正在开发中，哪些还未开始，哪些已经比原计划延期，产品经理一定要非常明确。可以使用“每日站立会议”的方法，了解当前开发进度。在开始每天的工作之前，全员起立，每个人快速地说明昨天的工作安排是否按时完成，遇到了哪些问题，需要协调哪些资源，需要获取哪些帮助，今天即将开始的工作有哪些，需要哪些人配合。之所以要站立发言，就是让大家言简意赅，快速说明问题，整个站立会议的时间不宜超过15分钟。

可以利用甘特图，把任务计划和完成情况进行标注，一目了然。

为了保证开发进度，产品经理要极力避免其他人员直接与开发人员提需求，保证当前产品版本的封闭性，任何新的需求都必须提交给产品经理，再由产品经理统一评估，规划新版本。但有一种特殊情况，当正在运行的线上产品发生严重问题时，可以由测试人员、运营人员或市场人员等直接与开发人员沟通，优先修复，任何时候线上产品的问题解决都是第一优先级。