第三章：产品设计
产品设计是一个由抽象的概念到具体形象化的处理过程，通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一个具体的物理或工具的过程，把一种计划、规划设想、问题解决的方法，通过具体的操作，以理想的形式表达出来。
由于产品设计阶段要全面确定整个产品策略、外观、结构、功能，从而确定整个产品系统的布局，因而，产品设计的意义重大，具有“牵一发而动全局”的重要意义。如果一个产品的设计缺乏具体形象的表述，那么研发时就将耗费大量资源和劳动力来调整需求。相反，好的产品设计，不仅表现在功能上的优越性，而且便于执行时理解，从而使产品的研发效率得以增强。
1、产品需求文档介绍
产品设计的最终表述的形式被称为产品需求文档，业界常常称呼为PRD文档，这是英文Product Requirement Document的缩写。产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式，主要用于产品界面设计和研发使用。
PRD文档是基于BRD、MRD的延续文档，主要是一份给执行层面的工作人员阅读的文档，这部分人群绝大多数是设计与技术人员。在这类人群中，设计师更多依赖于产品原型进行交互或视觉的设计，因此看这份文档的人主要是技术人员。相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此产品需求文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
因为阅读人类的因素，所以产品需求文档是一份没有闲话，直入主题的功能说明文档。并且产品需求文档是没有标准规范的，也没有统一的模板，每个公司都不一样和每个人也不一样，这个取决于个人习惯和团队要求。虽然产品需求文档没有明确的规范，但是目的都是一样的，必须能够明确产品的功能需求，便执行人员理解任务要求。
2、产品需求文档写作
产品需求文档是产品经过规划和设计之后的最终执行文档，因此这份文档的质量好坏直接影响到执行部门是否能够明确产品的功能和性能。
2.1、罗列信息（信息结构图）
在写产品需求文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来设计功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。
罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是使用思维导图软件(MindManager)罗列成结构图，因此我称这一步为“信息结构图”。
上图是一张以Blog系统为示例的信息结构图。信息结构图是一种接近数据库结构的图表，在罗列信息结构时，更多的是考虑信息数据，但是他并不是真正意义的数据库结构。信息结构图是提供给产品经理自己梳理信息内容的结构图，也是方便产品经理和服务端技术人员沟通数据结构的参考图，技术人员会根据这张图表的内容再结合产品原型或需求文档，然后规划和设计出真正意义上的数据库结构。
信息结构图中关于友情链接功能的信息数据只有“名称”和“链接”两个内容，但是在实际功能需求中，友情链接还有两个功能，分别是“显示或隐藏”和“是否新窗口打开”，这两个功能会在产品原型和需求文档中详细描述，但是在信息结构中是没有体现的，因为从产品层面上来说，这两个只是功能，并不是信息内容。但是在真正数据库中，友情链接的这两个功能分别也是有字段参数的，程序在读取该参数后便知道友情链接的属性，然后处理友情链接是显示还是隐藏，是新窗口打开还是本窗口打开。通过友情链接这个例子，我们就知道了在实际中数据结构和信息结构是不一样的，信息结构只是产品层面的数据内容。
无论是什么样的产品类型，无论从哪里入手，我们第一步都是先要罗列信息结构，因为信息结构图不仅是辅助技术人员创建数据库的图表，也是辅助产品人员进行产品功能规划的参考，只有对信息或数据的结构了解了，我们才能更好的设计产品。信息结构图是我们将概念想法形成结构化的第一步，也是我们接下来几步工作的辅助文档，同时在接下来的几步工作中，我们还会不断的完善信息的结构。
2.2、梳理需求（产品结构图）
当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步就要梳理产品的需求。在设计产品原型之前，我们首先要罗列出产品的功能结构，包括频道、页面、模块及元素。这一步依然使用思维导图软件，像绘制楼盘鸟瞰图一样将产品的结构绘制成结构图，因此我称这一步为“产品结构图”。
产品结构图是一种将产品原型以结构化的方式展现的图表，结构内容也如同产品原型一样，从频道到页面，再细化页面功能模块和元素。所以产品结构图是产品经理在设计原型之前的一种思路梳理的方式，并不是给其他工作人员查看的文档，通过类似鸟瞰式的结构图可以让产品经理对产品结构一目了然，也方便思考。
如上图示例，“活动大全”的产品结构依次是：产品 -> 频道 -> 页面 -> 页面元素 -> 操作 ->元素。我们换一个角度观看示例，产品结构图实际上就是一种结构化的产品原型。这样做的目的就是梳理产品结构逻辑，让我们清楚的知道产品有几个频道，频道下面有没有子频道或者有多少个页面，这些页面里又有哪些功能模块，这些功能模块里又有哪些元素。
上图以我们第一步的“信息结构图”为基础绘制的“产品结构图”，有了这份结构导图，我们可以对产品进行鸟瞰式考虑和完善，当有问题时，修改起来也比原型和文档方便很多。比如在后续规划中，我们发现文章的图片等附件上传后，管理不太方便，这时就可以在结构图中增加一个“附件管理”频道。如果我们使用产品结构图的方式，那么附件管理的功能增加和修改就会比原型工具更加便捷和效率。
产品结构图的方法同样适用于移动互联网产品的设计，并且比起Web产品更加容易梳理产品结构。
产品结构图是一种让产品经理通过思维导图的方式梳理思路的方法，通过这种方法可以明确产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素，逐步的将脑海里的想法明确梳理成结构。虽然这种方法能够明确产品的结构，但是这样的思维导图也就只有产品经理自己能够看懂，因为对于设计和技术人员这是一个抽象的表述方式，如果没有详细的讲解，是很难理解的。
产品结构图是将产品原型具体化的一种方式，只是罗列了产品的频道页面和功能，但是没有详细的进行推演，关于细化方面是否符合产品逻辑，是否符合用户体验，这些都是没有深思过的，因此我们接下来就要进行原型设计，开始具体的考虑可行性。
2.3、原型设计（界面线框图）
当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。
原型设计是帮助我们更细致的思考，并做各项需求的评估，同时也是将自己脑海里的想法进行输出的一种方式。通过原型设计后，我们就可以进行产品宣讲了，相比较于抽象的文字描述，原型则更加直观的展现产品的需求，设计和技术人员或者老板也能够更加直观的了解到产品意图。
原型设计是将结构化的需求进行框架化，因此原型也被称为线框图，具体的表现手法有很多种，相关的辅助软件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。
当到了原型设计这一步时，已经不仅仅是构思了，我们需要更加深入的了解每个页面上元素和这些元素的属性。例如按钮元素，我们就需要考虑这个按钮的功能，并且这个功能操作后带给后端和前端的反馈。；合法则和后端通信验证是否已经存在同样信息，已经存在则给出前端反馈，不存在则进入下一步，注册成功；注册成功后的反馈是跳转页面，还是弹出层提示用户完善资料，
这些都是需要更详情的考虑。当然这些更细致的思考是留在需求文档撰写时的，而此时我们需要做的就是把这些元素通过原型表现出来。
原型设计的表现手法主要有三种：手绘原型、灰模原型、交互原型。从工作效率的角度考虑，我非常建议先通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性。当方案的可行性被验证之后，我们再根据个人习惯或团队要求，通过软件工具进行更深入的设计。
① 手绘原型
因为原型也被称为线框图，因此手绘是最简单直接的方法，也是最快速的表现产品轮廓的手法。
手绘原型在初期验证想法时非常高效，也方便讨论和重构，同时也适合敏捷开发时快速出原型。
② 灰模原型
灰模原型是由图形设计软件制作而成，最常用的软件是Photoshop和Fireworks，相对手绘原型，灰模更加清晰和整洁，也适用于正式场合的PPT形式宣讲。
灰模原型也可以称之为平面原型，所以如果不会使用图形软件也可以使用Axure RP设计，相比交互原型，灰模原型只是缺少交互效果，仅仅是将产品需求以线框结构的方式展示出来，让产品需求更加规整的直观展现。
③ 交互原型
交互原型是使用原型设计软件完成的原型，常用软件是AxureRP，通常情况交互原型的设计要早于产品需求文档，是产品经理想法推演的重要一步。通过AxureRP之类的交互原型软件制作出来的产品原型，在功能需求和交互需求的表现上，几乎和正式产品是一致的，所以有时交互原型也被称为产品Demo版。
通常情况下交互原型是产品经理与交互设计师共同讨论确定，然后由交互设计师制作，但是绝大多数的公司是没有交互设计师这个职位的，因此这类工作最终是由产品经理来负责的。
以上三种方法并不是渐进的流程，而是三种原型设计的方法，具体取决于你的产品需求和团队要求。
对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了产品宣讲时让听众能够清晰直观的了解产品，避免抽象的语言描述导致听众理解困难和理解偏差。产品原型也是为了确保产品在执行过程中，是按产品经理最初设想的需求和期望完成的，因此产品经理的原型是没有很高的要求的，只要对方能够听懂看懂就可以了，所以使用手绘原型是最高效率的方法。
2.4、用例模型（产品用例图）
用例(UseCase)是一种描述产品需求的方法，使用用例的方法来描述产品需求的过程就是用例模型，用例模型是由用例图和每一个用例的详细描述文档所组成的。在技术和产品的工作领域里都有用例模型的技能知识。技术人员的用例主要是为了方便在多名技术人员协同工作，或者技术人员任务交接时，让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时，让参与者更好的理解功能的逻辑。
用例起源和发展于软件时代的产品研发，后来被综合到UML规范之中，成为一种标准化的需求表述体系。虽然用例在软件研发和技术工作中应用的非常广泛，但是在互联网产品规划和设计中，并不经常使用，互联网产品的需求表达为了敏捷效率，通常采用原型加产品需求文档。
UML是英文Unified ModelingLanguage的缩写，中文称为统一建模语言或标准建模语言，是用例模型的建模语言，常用工具是Microsoft OfficeVisio。产品用例是一种通过用户的使用场景来获取需求的方式，每个用例提供了一个或多个场景，该场景说明了产品是如何和最终用户或其它产品互动，也就是谁可以用产品做什么，从而获得一个明确的业务目标。
① 用例图
用例图并不是画成了图形的用例。用例图包含一组用例，每一个用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人，可以是其它产品、软件或硬件等等。某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。
许多人通过UML认识了用例，UML定义为展现用例的图形符号。UML并不是为描述用例定义书写格式的标准，因此许多人误认为这些图形符号就是用例本身；然而，图形符号只能给出最简单的一个或一组用例的概要。UML是用例图形符号最流行的标准，但是除了UML标准，用例也有其它的可选择的标准。
② 用例描述文档
用例图只是在总体上大致描述了产品所能提供的各种服务，让我们对于产品的功能有一个总体的认识。除此之外，我们还需要描述每一个用例的详细信息，这些信息应该包含以下内容：
用例名称：本用例的名称或者编号
行为角色：参与或操作(执行)该用例的角色
简要说明：简要的描述一下本用例的需求(作用和目的)
前置条件：参与或操作(执行)本用例的前提条件，或者所处的状态
后置条件：执行完毕后的结果或者状态
用例描述文档基本上是用文本方式来表述的，为了更加清晰地描述用例，也可以选择使用状态图、流程图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其它图形。如流程图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。
在互联网产品和设计中，用例的使用越来越少，通常有了产品原型再加上功能流程图和功能说明文档就能够将产品需求详细的表述清楚，所以也没有必须撰写用例了。但是在大公司里，往往会追求产品流程的规范性，要求撰写用例，不过在敏捷开发的时候也会采用其它更有效率的方式，不一定非要撰写用例。
前面几步我们将产品需求逐渐细化并且通过原型的方式将产品需求形象化的展现了出来，但是在产品功能的逻辑细节方面，原型就非常不直观了，所以用例是一个非常重要的描述需求过程的文档。
但是由于用例文档以文字为主，并且格式复杂，不适用于高效率的产品需求表述，所以展现逻辑流程的“功能流程图”是一个简洁直观的可替代用例文档的方式。
如上图所示，功能流程图是一种使用图形的方式表示算法逻辑的图表，因为千言万语不如一张图，通过流程图将“优惠券”功能模块的逻辑和需求非常形象直观、一目了然的展现了出来。
流程图的展现方式也不会产生“歧义性”，便于理解，逻辑出错时也非常容易发现，并且可以直接转化为程序需求描述文档。
2.6、需求文档（PRD文档）
前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节，到了这一步的时候我们已经非常清晰的了解产品需求，此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。
产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式，主要用于产品界面设计和研发使用。因为每个人的习惯和团队要求都是不一样的，所以产品需求文档没有统一的行业规范标准，无论以什么样的格式撰写产品需求文档，最终的目的都是让执行人员能够理解产品需求，根据需求完成产品。
产品需求文档的表现形式有很多种，常见的有Word、图片和交互原型这三种形式，文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。虽然产品需求文档没有标准的规范，但是有两项是必不可少的，那就是文件标识和修改记录。文档在撰写过程中，我们可以自行不断的修改完善，但是如果正式发布或交给团队其他成员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录，这样可以方便大家查看和了解改动的内容。关于文件标识和修改记录，格式都大同小异。
① Word
这是传统意义上的产品需求文档，主要有四个部分组成(具体根据产品要求进行划分)，分别是：结构图、全局说明、频道功能、效果图。
因为产品需求文档的阅读者主要是偏向于技术人员，因此文档的目的性非常明确，就是要描述产品的功能需求，所有产品需求文档没有关于市场方面的描述。
为了保证需求的执行效率，建议大家尽量减少不必要的文字，在能够让阅读者看懂并且了解产品意图的情况下，文字越少越好。这主要是因为绝大多数人是没有足够耐心认真看完产品需求文档的，因此我们要尽量减化文档内容。
①-1、结构图：
①-1.1、信息结构图：主要是辅助服务端技术人员创建或调整数据结构的参考文件
①-1.2、产品结构图：主要是辅助设计和技术开发人员了解产品的全局结构。
①-2、全局说明：
主要讲解产品的全局性功能的说明，例如网站产品的页面编码、用户角色，移动产品的缓存机制、下载机制，这类全局性功能的说明。这里我举一个移动产品的“状态维持与恢复”的例子。示例如下：
状态的维持与恢复
当用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。
①-3、频道功能：
以频道为单位，页面为子项，分别描述产品的频道、页面及页面模块元素的功能需求。示例如下：
1、频道名：频道介绍及需求说明
2、页面1：页面介绍及需求说明
2.1、页面模块1：模块功能需求说明
2.1.1、页面模块1-元素1：功能说明
2.1.2、页面模块1-元素2：功能说明
2.2、页面模块2：模块功能需求说明
在撰写功能需求时，我们需要考虑用户的流程，例如一个“完成”按钮，我们需要描述他完成后，系统要不要给出反馈提示(反馈提示是什么样的形式反馈，内容显示成什么，有没有内容需要调取数据库)，或者要不要跳转页面(跳转到哪个页面，这个页面是其他频道页面，还是这个功能的子页面，如果是子页面就需要再描述这个子页面的模块及元素内容)。
①-4、效果图：
效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。
这个示例是一个移动产品(iPad)需求文档，其中部分隐私内容已过滤隐藏，并且只保留了首页和地图找房频道的需求说明。由于工作环境没有交互设计师，所以Word文档中包含了部分交互说明。
② 图片
图片形式的产品需求文档是基于效果图的说明文件，将传统Word形式的功能需求说明标注在效果图上，这种方式经常使用在移动互联网领域，实际上是图文形式的交互需求文件，只是在此基础上更深入的描述出功能需求。
对于图片形式的产品需求文档，我们只需要另外再描述一下全局说明，其他频道页面的需求直接以图片形式展示，这种方式相对于Word文档的纯文字更加生动易读并且直观，因此有一些产品经理非常喜欢用这种方式代替Word形式的产品需求文档。
③ 交互原型
这里指的交互原型就是前面篇章讲到的原型设计，使用Axure PR之类的交互原型设计软件制作出来的产品原型非常真实和直观，并且原型软件还支持元素标注和导出Word文档，因此很多产品经理都喜欢使用Axure PR来代替Word完成产品需求文档。
当我们通过Axure PR制作出产品原型后，实际上他已经是很完善的产品Demo了，因此我们只需要加上元素的标注，在标注中说明功能需求，这样导出的HTML文件相比Word文档更直观易懂，是非常高效的产品需求说明方式。
无论你采用哪种方式撰写需求文档，最终的目的都是为了方便团队成员理解产品的意图，因此哪种方法能够避免细节黑洞，高效完成产品的设计和研发，那么这种方法就是最有效的方法。
第四章：产品管理
产品管理是公司为了管理一个产品或者产品线的产品计划、产品市场和产品生命周期所采用的组织架构。产品管理是一个非常典型强矩阵型的管理方式，工作性质包括项目管理，但并不完全等同于项目管理，主要负责在产品生命周期中对产品规划、设计、开发、运营等环节进行管理或支持的工作，负责这项工作的人被称之为产品经理。
1、产品管理介绍
从产品的需求开始到产品淘汰报废的全部生命历程被称为产品生命周期。在产品的整个生命周期中，产品经理需要打破部门壁垒，整合跨部门资源，实现面向市场的产品规划和设计，确保和企业战略的一致性。工作内容包括产品战略、产品市场、产品需求、产品规划、产品开发、产品上线等工作事项的管理。
虽然产品管理涉及的层面比较广，但是实际中产品经理的工作内容并非全是如此。业界普遍的产品管理流程是由公司高层领导确定战略规划和方向，项目负责人分解战略并细化，同时确定阶段目标，最后由产品经理负责产品需求的规划和设计，然后沟通和协调研发团队完成产品需求的开发和上线。
因此产品经理除了管理产品规划和设计之外，还需要对产品的执行进行沟通和协调，促进团队合作，驱动产品工作的正常进行。
2、需求管理
产品因需求而生，在产品的整个生命周期中，产品经理会收到来自各个方面的需求，但是每一个需求的必要性、重要性和实现成本都需要经过深思熟虑的分析和计划，避免盲目的决定需求或者变更需求，这样很容易导致工作混乱，所以产品经理首要的管理工作就是对需求进行管理。
由于人的思维是发散性的，所以往往在产品构思的过程中会出现各种新鲜好玩的想法，这些想法可能来自领导或者产品经理自己，但是这些想法往往都是和产品核心方向不相关的，但是由于这些想法能够在当时带来诱惑，因此这些不相关的需求会严重干扰了团队的精力，打乱或者延误产品原本的计划。
很多时候需求的变更或增加是因为我们面临太多选择和想要的太多，没有适当的控制自己的欲望，并以自己的喜好来决定需求，这些因素很容易导致产品没有明确的方向、团队成员疲于奔命，但是却没有实际的成果。
往往当我们拥有一个非常兴奋的想法时，此时我们只是无知的乐观，而实现这个想法则需要各个部门的配合，当随着在这个想法上花费了越来越多的时间并且开始学习所有关于这个想法的相关事务时，我们才能意识到一个未经深思熟虑的想法所带来的后果，这些因果最终很有可能将产品带入危机中。
所以在需求管理的时候，产品经理首先需要控制自己的欲望，基于产品规划的三个考虑因素和四个设计理念，重新审视产品和筛选需求的优先级，识别每一个需求的必要性、重要性和实现成本。通过深思熟虑给团队明确方向并专注，聚焦资源的支配，确保团队的精力都聚焦在产品的核心需求上。
3、目标管理
目标管理是以目标为导向，以人为中心，以成果为标准，而使组织和个人取得最佳业绩的现代管理方法。目标管理亦称“成果管理”，俗称责任制。是指在企业个体职工的积极参与下，自上而下地确定工作目标，并在工作中实行“自我控制”，自下而上地保证目标实现的一种管理办法。
3.1、产品目标管理
一个团队的执行力低，最主要的因素就是因为领导者的执行力低下，决策效率低，无法给团队传达明确清晰的目标。如果领导者没有目标管理的意识，很容易在传达需求的时候模棱两可，导致执行者对任务内容和目标不够清晰，以及对所要执行的事情的重要性理解不够，最终结果可能就是未完成或者延期完成。
目标管理并不是有了任务才有目标，而是相反，有了目标才能确定任务内容和方向，也才能对其进行有效分解，转变成各个部门以及各个人的子目标或者小目标。
产品经理作为最终执行的领导者，需要将战略和阶段目标进行更加细化的规划，让笼统的目标可以具体到版本需求，便于设计师和工程师执行，所以在工作中产品经理还要有一些项目管理的常识，细化和制定需求的实施计划，并且跟进实施进度。
运用目标管理的方法，产品经理将战略与阶段目标进行了细化，规划和设计出了产品的各个迭代版本的需求。当有了这些细化的子目标之后，产品经理就可以对其进行有效的分解，转变成各个部门或者各个人的任务和目标，此时便可以协调团队成员完成产品需求的研发。
3.2、使用目标管理
目标管理的具体形式各种各样，但其基本内容是一样的。在业界被广泛使用的“SMART原则”是目标管理中的一种方法，能够有效地进行成员的组织与目标的制定和控制，SMART原则要求制定的目标要达到五个标准：明确性、衡量性、可达成性、相关性和时限性。
① 明确性
产品需求的任务和目标一定要明确，不能够模糊。例如：“通知开会”，这就是一个笼统的目标。一个有明确性的目标应该这样表述，“6月2日下午
15:00在一号会议室召开XX项目设计方案讨论会，设计部XX项目组所有成员参与，会议时长2小时”。传达一个明确的目标才能获取最大的完成几率。
所谓明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可，或没有将目标有效的传达给相关成员。
② 衡量性
目标需要可衡量，而可衡量往往需要有数字，把目标量化。如果制定的目标没有办法衡量，就无法判断这个目标是否实现。可衡量的标准就是需要确定任务数量是多少？做成什么样才是完成？完成要花多少时间？等等。
③ 可达成性
一个目标必须是可以实现的，或者说经过努力是可以实现的。所以任务目标要是执行者能力范围内可以达到的。换言之就是目标要现实，例如让执行者去移动公司给联通手机号充值话费，这就是一个不现实的任务，不具备可达成性。
④ 相关性
目标的相关性是指实现该目标与其他目标的关联情况。如果实现了这个目标，但对其他的目标完全不相关，或者相关度很低，那这个目标即使被达到了，意义也不是很大。因为毕竟工作目标的设定，是要和岗位职责相关联的，不能跑题。
比如产品需求是研发一个iOS系统的APP，任务要求学习“iOS人机界面指导手册”以便更好的理解系统特性和设计规范，这样有助于提升APP的用
户体验。这个任务就是和目标有关联性的，但是如果任务是学习“Android设计规范”，那么就跑题了，因为学习“Android设计规范”这一任务与研
发iOS系统的APP这一目标相关度很低。
⑤ 时限性
目标特性的时限性就是指目标是有时间限制的。必须具有明确的截止期限，即一个目标只有在一定的时间内达成才有意义。给目标一个确定的完成时间，这会有助于执行者集中精力完成目标。时限性的要求可以帮助执行者避免因为日常琐事而耽误了完成目标的进度。
产品经理作为团队合作促进者、执行力驱动者、工作效率提升者，必须对目标管理有着很深的理解，在传达产品需求和任务的时候，使用“SMART原则”可以大大提升团队的执行效率，给执行者很明确的任务目标和时限。避免执行人不知道该如何执行，或者需要执行的事情有难度，难到不知道该如何下手。
4、团队沟通
产品经理作为团队中的枢纽岗位，绝大多数的时间是用于沟通的，通过沟通促进团队合作、驱动项目执行，所以掌握团队沟通的技巧非常有助于我们提升工作效率。
4.1、积极主动沟通
产品经理是产品规划和设计的直接责任人，需要多部门沟通和协调，担当团队的执行力推动者，所以在工作中要积极主动的沟通。
很多时候，团队成员因为各种因素，或是忙忘了，或是不擅长主动沟通，导致工作反馈不即时，所以产品经理在工作中有工作反馈等需求时，不要等别人给，主动要。并且在工作中要积极响应需求任务，产品规划和设计要尽量提供完善资料，不要等别人要，主动给。
4.2、换位思考沟通
产品经理需要换位思考沟通，明白各个职位的想法和知识，即时调整自己的沟通方式，要以通俗易懂的词语和对方沟通。很多时候我们以为对方懂了，其实对方听的很迷糊，所以在沟通中千万别主观的认为对方懂了，需要在沟通中互动反馈，确认对方是否真的懂了产品需求的意图。
4.3、直接跟进工作
为了避免信息传递的失真，产品经理应当直接和相应的执行人沟通。在任务分配时，由部门负责人安排工作人员，产品经理直接和相应的工作人员对接，直接跟进工作，避免信息传递失真，也保证需求和进度。
从产品原型开始，团队之间就应该保持密切的合作，产品经理确定产品的需求，明确产品要做什么，然后调动大家积累参与到产品的设计当中。从设计部获得最佳的用户体验与交互设计方案，从技术部获得最新的技术动态，以便分析能否应用到产品当中。特别是与技术部的合作更为密切，产品经理需要了解自己规划的产品原型从技术层面能否实现。同时也要跟技术人员沟通需求，了解是否有其他更优的解决方案。
4.4、明确工作任务
4.5、减少文字沟通
工作中我们或多或少会用到文字沟通，其中包括产品需求文档、任务邮件等等。但是文字的表述是远远比不上当面的沟通更有成果，所以我们要尽量避免使用文字沟通，而在文字沟通时千万别长篇大论，精简不必要的话，直入主题。产品需求尽量使用原型表述，有说明文字以标注的形式集成在原型中。
4.6、把握时间节点
在工作中我们是不希望被别人打扰的，同样产品经理在沟通时要注意把握时间点，在不打扰的对方的情况下找其沟通。最好是先发一封邮件，让对方先大概了解沟通主题。
4.7、虚心接受反馈
能力的提升是通过不断的学习、总结和检省，因此我们需要虚心接受别人反馈的建议。如果反馈不正确或者反馈是一种抱怨与指责，那么我们先发自内心的承认错误，然后检省自己并寻找问题所在，千万别互相抱怨和互相指责，这容易让问题越来越严重。
4.8、化解压力与矛盾
产品经理是团队的枢纽点，也是压力、矛盾的集中营，所以我们自己需要有一个良性的化解压力的方法，在解决自身压力的同时还要化解团队的矛盾。
解压的方法每个人都有不同，但是化解矛盾都是大同小异的。团队矛盾往往先是从抱怨与指责开始的，我们在接受反馈的时候，如果遇到抱怨与指责的时候需要清楚，这是一个毒瘤，会越长越大，最终会直接影响团队的和谐，所以我们必须要制止它的发展，避免大家陷入这样的惯性旋窝中。
抱怨与指责是双向的，别人可以迷失，但是我们作为产品经理必须要保持理性，结束抱怨与指责，主动道歉，终止抱怨与指责不断的扩大。那怕不是我们的错，但是我们是产品经理，终止毒瘤的发展是我们的职责，等待大家保持冷静后再沟通。因此产品经理需要时刻保持理性，除了虚心接受团队成员的反馈，还要努力化解和减少抱怨与指责，更不能为自己找借口，必须克服所有障碍，解决所有问题。
4.9、感谢和夸奖
产品是团队成员共同努力完成的，产品经理作为产品的负责人，需要学会感谢团队成员的付出，并且要勇于说出感谢。感谢和夸奖可以提升产品经理在团队成员中的良好印象，减少沟通障碍。
5、团队协同
一个完整的产品是由团队合作共同完成的，负责最终执行的工作人员被统称为研发团队，研发团队由产品设计、技术开发两个方面的岗位组成。产品设计人员包括产品经理、交互设计师、视觉设计师，技术开发人员包括前端、服务端、数据端、测试等方面的工程师。
在大公司里，产品、技术、设计等岗位的工作人员都被划分在各自的部门里，然后根据项目再组成虚拟小组，由项目经理或者产品经理带头执行产品的研发，所以大公司里的设计和技术等工作人员并不完全只负责一个产品项目。在小公司或者创业型团队里，可能公司或团队只有一个产品，所以大家也就共同负责这一个产品。
无论工作环境如何，产品需求的执行都会涉及到各个方面的工作沟通和协调，在产品研发的过程中，团队协同的默契度决定了工作的效率。但是在研发团队中，每个人的想法都是不一样的，默契也需要很长时间的磨合，如果我们能够了解到各个岗位工作人员的想法，那么对于减少磨合周期，提升沟通和工作的效率，无疑是一个非常好的途径。
① 交互设计师：想的是用户体验
在很多公司里是没有单独的交互设计师岗位的，通常都是由产品经理直接负责，所以产品经理等于半个交互设计师。在有交互设计师岗位的公司里，由于产品经理和交互设计师都会考虑用户体验，所以多多少少产品经理也会参与到交互设计的环节，在产品需求设计的时候很容易会和交互设计师的工作重叠，因此在工作中和交互设计师产生分歧也是常事了。
虽然产品经理比交互设计师更懂用户需求，并且对产品感觉、把握项目进度等等综合能力要强于交互设计师。但是交互设计师比产品经理更了解用户行为习惯，了解用户体验。所以在工作中，产品经理需要相信交互设计师在领域内的专业性，毕竟交互设计师是专业人士。
交互设计是一种在用户纯主观使用产品过程中建立起来的感受，用户的行为习惯除了使用设备的基础特性外，往往操作习惯都是被引导的，至于一个按钮放在A位置还是B位置，在产品需求的本质上区别并不大，相信交互设计师的决定是经过专业思考的。所以产品经理在交互设计之前，只要充分和交互设计师沟通，表明产品需求和意图，然后只要把控交互设计没有破坏掉产品的需求和意图。
② 视觉设计师：想的是风格美观
视觉设计也是一种艺术，但凡是艺术的东西，都是一种主观的行为，没有绝对的对错之分，也没有懂与不懂，只有审美与诉求点不一样而已。所以产品经理和视觉设计师之间是很难用主观或者抽象的知识去互相说服对方的，毕竟大家的视野角度不一样。
例如自行车产品，产品经理只需要把控好自行车这个产品的本质需求和意图是按照产品规划完成的即可，至于自行车的色彩风格，相信视觉设计师在色彩风格上面的美术研究要比产品经理更专业。
产品设计的本身是为用户服务的，所以视觉也是一种沟通与传达，当我们对视觉设计方案有异议的时候，我们应当充实自己在视觉领域的知识，尽量使用具体形象化的表述方式描绘视觉想法。如果产生争议，我们可以多做几个视觉设计稿，让团队其他工作人员或者用户参与设计稿的体验，收集他们的建议和反馈。
③ 技术工程师：想的是实现模型
技术人员是产品从规划设计到实现的最后一步的执行人员，负责产品需求的开发工作，所以技术人员在理解需求的时候，考虑的是需求在技术层面的实现方法，想的是实现模型。
当需求到了实现的时候，如果存在考虑不周全的细节时，就很容易造成技术逻辑不通，往往这些因素会导致需求不够完善，需要重新设计或者变更，这种情况就会造成技术人员之前工作量的浪费。
所以在和技术人员协同工作时，往往导致工作不顺的原因就在于产品需求不够细致，功能逻辑不通，这些缺失的因素，那怕是一个小改动，也许就要让技术人员耗费好长时间去修改，并且在需求新增、变更以及项目赶进度等等情况下，工作量都会落实到技术人员身上。所以我们在和技术人员对接工作时，应当从产品技术层面的实现模型考虑，为技术人员提供明确的、完善的产品需求文档，尽量减少和避免增加技术人员的多余工作量。
团队协同的基础是建立在互相尊重和信任之上的，所以在产品经理不了解的领域里，我们应当充分尊重和信任团队里的专业人士，避免使用主观的喜好进行沟通和决策。同时产品经理也要主动和团队里的各个层面的人员保持沟通，即时跟进产品实施的进度和反馈，避免产品在执行过程中偏离方向。
6、项目管理
项目管理是在限定的资源及限定的时间内需完成的一次性任务。具体可以是一项工程、服务、研究课题及活动等。这项工作通常由项目经理负责，但是由于项目经理主要关注点都是质量、安全、进度、成本等方面的，具体到产品的细节则都是由产品经理负责把握。
在很多小型或者创业型团队中，没有单独的项目管理的岗位，所以很多时候这项工作就由产品经理担当了起来。就算有项目经理的公司，由于项目经理的职责没办法细致到产品的需求和意图的细节把控上，所以关于产品的细节执行还是需要产品经理跟进。因此我们了解一些项目管理的知识，也是非常有助于产品管理。
项目管理的工作通常使用甘特图对项目计划进行管理和跟进，常用软件有Project、Execl等，我常用的是Execl软件。通过甘特图分配任务和制定计划，然后再运用目标管理的方法，向执行部门或执行人传达任务内容和目标。