第一部分 产品价值与用户痛点

1. 点子与方案

产品经理的工作本质就是要抓住用户的痛点、实现产品的价值。

     总的来说，在产品从0到1的过程中，最先要确定的就是关于需求的逻辑是否再产品上、商业上行得通。

产品模型：设计合理性

      对于产品模型来书，首先要确定一件事：用户到底为什么要用你的产品？

      这里涉及两个方面的问题：用户是不是有需求？你到底能不能满足用户的需求？

      那怎样的的产品方案才是逻辑通顺的呢？怎样的产品模型才称得上是合理的？

商业模式：盈利的合理性

      作为产品，最根本的 意义就是给用户创造价值，以用户那里得到酬劳。

      有个非常简单粗暴的评判标准，那就是“离钱有多近”。

赚钱的方法实则大同小异：

• 广告：最大的蛋糕之一，也是最主流的商业模式
• 售卖：产品是明码标价出售的，例如 App Store，付费软件
• 增值服务：用户付费获得额外的服务，产品特性或服务中的特技
• 佣金/抽成：主要是在信息或服务对接的多方平台，比如天猫
• 企业服务：企业服务严格来说其实也是售卖的一种
  售卖内容：

1. 比别人早得到的服务，或者说时效性权利
2. 差异化服务
3. 更容易获取
4. 打赏、赞助，或者说粉丝经济
       在讲解商业模式的书《商业模式新生代》中，作者提到：商业模式涵盖了九个构件，它们可以描述公司创造收入的逻辑，分别是客户细分、价值主张、渠道通路、客户关系、收入来源、核心资源、关键业务、重要合作，以及成本结构。

环境：拓展合理性

  怎样看待延展性？大概需要了解一下问题：

• 想要进入的市场的状况是怎么样的？会发生怎样的变化？

  • 市场竞争环境
  • 相关技术
  • 相关政策
• 面向的用户如何，会发生怎样的变化？
• 产品逻辑的拓展性如何？
• 商业模式的拓展性如何？

团队：实施合理性

      作为产品经理，尤其要清楚团队资源的状况，要有客观的判断，不要只顾着做“最好的产品”，却不考虑是不是有能力做这样的产品。

”为什么是你们做“

2. 找到产品核心价值

  找到核心价值的原因：

1. 发现核心价值，能够选择综合考量下来最优的功能
2. 基于相同的核心价值设计的功能
3. 有单一的核心价值能够让用户对产品产生认知。
   用户体验要素模型：

核心价值其实就是战略层里包含的目标。

“解决问题”是产品价值所在

    张小龙提到的产品价值观：好的产品是用完即走的。张小龙其实很好的传递了一个理念，那就是产品一定要解决问题，用完即走。解决问题就是产品的核心价值。

    解决问题指的是，从根本上产品是为用户做什么。

“用完即走”并不是不要黏性

    要增强用户黏性、提高用户使用频率、提高用户的活跃度，这都是我们耳熟能详的产品设计思路。但是只关心概念上的指标的产品经理，就会把焦点放在怎样去活跃用户、吸引用户上，而且会做得比较肤浅。这样更像是用户运营，而非产品经理。

    做产品时，一定要避开“黑魔法”。不要以暂时的效果作为目标，以破坏用户的感受为代价，过于“热心”，有事没事骚扰用户，黏住用户。

确保产品真正解决问题

    用户的“量”不重要，“质”更重要。要让用户真正跟你的产品产生很强的关系，自然就要看解决问题是不是够好、够快、够准。在解决问题的时候，要确保产品真正能满足用户需求。

    没有真正解决问题的情况很多，下面列举几个：

1. 方法看似可以，但实际很糟糕
2. 方法看似可以，但可行性差
3. 方法看似可行，但问题却并不需要解决

用超预期的方式解决

    如果只是单纯地解决问题，产品肯定是有价值的，但很难说有很大价值。现在互联网竞争激烈，在这样的环境下只是“做得可以”已经不够了，还要“做得特别好”。这就要求我们在考虑产品的核心功能时，不仅要判断是不是满足了用户的需求，还要判断是不是超预期的方式满足用户的需求。

3. MVP与痛点

    MVP是埃里克 · 莱斯所著《精益创业》中提到的概念，目的是验证两件事：一是产品满足用户需求；二是产品能够创造商业价值。

    越是早期的产品（或者某个成熟产品中的新模块），越需要做得更关注产品的核心功能，实现产品的核心价值，原因有两点：

1. 产品模型的合理不能确保功能也会收到用户认可，快速投入到市场中进行验证是最稳妥的方法。
2. 产品的核心功能就可以解决用户问题，所以从理论上来说，就没有必要等到产品非常复杂、完善之后，才能吸引用户。
       在做出 MVP 之后，要考虑的就是使用 MVP 来发现用户的痛点了。PMF（Product/Market Fit），也就是产品和市场的匹配点，被称为投资教父的网景创始人马克 · 安德森提出的概念，定义它的涵义是在一个好的市场里，能够用一个好的产品去满足这个市场。这个定义更偏向从市场角度看待问题，但跟痛点的含义相仿，都是解释产品要在市场或者用户之上，找到最契合的那个点。

    PMF 理论认为，产品的增长曲线会在找到契合的这个点之后，快速增长。产品经理在这个过程中，未必是按部就班只管设计、实践，还要做好判断：现在产品处于什么阶段？它的运转是否良好？产品是否被用户承认?

设计 MVP

     一个 MVP 对产品的要求是：达到可用与最小成本的平衡。

   在实现成本和可用性上，找到平衡点，就是最关键的一步。在设计 MVP 时，推荐参考的方法如下：

• 奥卡姆剃刀法：“如无必要，勿增实体”
• 用户访谈
• 去掉可人工处理功能
• 确保只有一个功能

MVP 方法

    互联网创业者们有很多有意思的手段，以更低的成本达到了 MVP 的效果。

• 广告
  做一条描述产品内容的广告，广告形式实现 MVP 其实类似于用户访谈，不过更有说服力
• 假 MVP
  做一个视觉效果没问题的产品，但功能都是（或者部分是）假的。以此收集用户使用产品的数据。
• 线下实现
  如果线下也可以完全用别的方法实现，同样可以不考虑开发线上产品。
• 众筹
  把对产品功能的设想预售，用户只要愿意买单，那么东西就自然卖得出去。这是可以检验功能和商业价值的方法。

实现 MVP

    上面提到的 MVP 方法，大多看起来像是预热和测验，无论如何，最终 MVP 都需要实现成真正的产品的。在实现的时候，产品经理需要考虑以下问题。

• 选择平台
      APP 的创业红利期已经过去，用户手机里不愿意装太多 APP，所以对于90%以上需要客户端的 MVP 产品，建议先用小程序（微信小程序、支付吧小程序、百度小程序）。
• 选择技术实现方案
     在 MVP 实现用怎样的技术防范，产品经理还是应该做个判断的，在产品相对成熟时，当然是产品优先，效果优先。但在 MVP 的阶段，产品和技术要平衡，产品经理必须参与进来。通过调整产品方案，来尽量减少成本
• 关于外包
      对于是否要用外包实现第一个产品版本的态度：慎重。

找到痛点

    “解决了用户的痛点” 才是让用户使用我们产品的最主要因素，以及体现产品价值的关键点。

    我们可以制定一些标准来判断是不是发现了痛点。

1. 通过分析数据发现痛点

   1. 用户数据

      1. 使用频率
      2. 日活跃用户、周活跃用户和月活跃用户
      3. 用户留存

   2. 商业数据

      1. 付费转化率
      2. LTV/CAC > 3，即用户终生价值/用户获取成本 > 3
2. 通过用户反馈发现痛点
   数据分析能够定量地对痛点进行判断，而用户反馈可以定性地对痛点进行感知和理解。

MVP 不是不做产品模型的借口

    使用 MVP 是基于一个前提，核心的产品功能是需要检验的。MVP 是理论和实践相结合的方法，并不是极端理念：“ 产品功能是不需要做太多思考的 ” “用户不知道自己想要什么，除非你摆到他面前 ”。

    我们要设计出一个足够好的可用产品，至少要在产品功能上做分析，要确定它的产品模型、核心功能。在理论上成立，在实践中证明。所以不要把 MVP 早晚要经过用户检验作为不认真思考产品逻辑的借口、不去设计产品模型的借口。

第二部分 需求分析和功能设计

1. 深挖需求

    产品经理不应该只关心浮于表面的需要，而是要关心背后的真正诉求。

1.1 基于场景深挖需求

    如果你谈需求时，想到的不是具体的画面、不是知识的某个用户、不是真正发生的什么事件，而是一道道公式、各种图形，甚至某个 ”前辈“ 的经典语录，那么你对于这个需求的了解程度还是很浅的。

    我们讨论场景时讨论的本质是什么呢？

    我们要用场景来发现我们的用户是谁、他们会在什么情况下解决原有的问题、他们怎么解决这些问题的，等等。

考虑场景时讨论需求的不同：

1.2 从人性本质深挖需求

    人性是人的本性、人的感情和理智，是我们要发掘出来的需求的根本源头。它们的存在创造了需求的场景。如果我们能把我好用户在人性上的弱点，或者说在人性上存在的缺陷，那么产品就能一击即中。抓住需求的核心，而不只是停留在需求的表层。

实例：想减肥的人需求的几个层次

个人觉得，人性需求还有对于美的追求

逐利心理

     如果产品模型本身就能带来红利，那么就可以满足用户逐利的需求。

     互联网技术带来的核心优势，就在于通过信息的流通、结构化等特征，提升原来的效率，达到降低成本的效果。所以如果能够真的在某些方面产生红利，那么就可以满足用户在逐利方面的人性需求。

两性吸引力

    用合法合规的方式满足正常人都会有的色欲，也是很多产品在做的尝试。其实从广义上来说，色欲就是正常的两性关系的前置条件。

懒惰

    在很多情况下，互联网服务的确提高了效率，降低了成本。对于用户来说，会体验到越来越多方面和便捷，也满足了更多用户比较懒、不爱动、不爱思考的天性。

    占 O2O 中最大一块的一类服务就是上门服务。对于上门服务来说，最重要的就是让用户体验到更加方便的功能。

虚荣心

    虚荣心是最容易利用的一种人性：当你在逐利或者贪色的时候，你心里是最清楚的。但追求虚荣的时候，往往都是不自知的。

共情需要

    共情，Empathy，也可以翻译为同理心。体现在人性上的需求，即我们希望体会他人的生活和感受的需求。例如最近的各种真人秀、直播等。

社交货币

    人是社会动物，社交也是很基础的属性。加强沟通的效率、增多沟通渠道、丰富沟通的方式是互联网时代很容易完成的任务。单纯的沟通是基础，有效地建立起社群，或者说满足某些用户的归属感是更高一层的要求。

    另外一种满足社交方面的需求，比较难解释，用《疯传》里提到的一个概念来阐述，即社交货币。我们在社交中都要拿出一些独特的，能代表自己的品味、形象，以及社交价值的证明。比如说读了一本很高端的有特色的书，或者去过一家特别的饭店，这些都是社交货币；包括很多能言善辩、能说会道的人，他们口中的谈资，也是社交货币。

安全感

   安全感是马斯洛需求曲线层次中很底层的一部分。在使用任何产品的时候，我们都会需要特别在意安全问题。

2. 用户研究

    用户研究的目的是理解用户，是一系列方法的笼统概称。用户研究是一次获取信息的行为，而指导这个行为的是明确的目标。

    用户研究的结果也不能提供很直接的解决方案，绝大多数知识提供 “情报”，从获取的防范看包含两类，一类是用户的行为、状态，另一类是用户表达的观点和思想。从情报本身的特征来看也有两类，一类是定性的结论，另一类是定量的结论。

    常见的用户研究方法就是依据定性 / 定量和行为 / 观点这样的二维矩阵划分。

    用户研究不能单纯的认为是用户调研，用户调研就是发调查问卷。在做调研之前，要先判断自己要了解用户的什么，哪种方式是最好的，选择最准确的方法后再去做。

问卷调查

    问卷调查是老生常谈的调研方法了，也是看似最简单的方法。首先，成本很底，其次，耗费精力相对较低。问卷的设计，必须慎之又慎，设计得当的问卷可以提供给我们很多有价值的参考，但设计有缺陷的问卷的结论，可能引导我们走向完全错误的结果。

    如何进行合理的问卷调查呢？

• 确保问卷能够达到目的
  有的需求问卷可以满足，但很多需求问卷却难以满足。探讨的话题越深入，越需要有更多的交流。问卷显然满足不了这方面的需求。例如，判断 “最近用户为什么不喜欢在晚上使用我们的产品”，此时，“以用户行为数据分析” 配合 “用户访谈” 是更佳的方式。

• 问卷问题的设计合理

  • 切忌问题具有引导性。比如“你认为黄色比红色好看吗？”就不如“你认为黄色好看，还是红色好看？“更合适。
  • 切忌问题中有含糊不清的内容。例如”你觉得这个功能好用吗？“用户不清楚什么算好用。可以说”你觉得这个功能解决你 XXX 问题了吗？“
  • 对于涉及敏感话题的问题要特别注意。
  • 尽量少用问题，让用户减少思考。
  • 选择题的选项确保可靠。
  • 切忌问题过多。
  • 重要的问题可以交叉验证。

• 样本的把控
  要从两个角度去把控样本的合理性。

  1. 方法渠道的合理性。
  2. 在问卷中确认填写者的必要信息。
  

用户访谈

    要深入了解用户，只做问卷调查是不够的。而用户访谈则是可以定向深入了解某个问题的方法。

    用户访谈有很多形式，比如单人访谈、多人访谈、焦点小组等。目的也分很多种，大体而言，可以说成是了解用户群体、了解用户的需求、了解用户对产品功能的意见和探讨某个特殊主体。

• 确认访谈的目的
  访谈可以达到的目的，主要集中在用户愿意表达的观点、想法上。用户访谈很难做到量化（要做大规模的访谈耗时耗力），但可以做到比较深入、比较具体。

• 访谈的过程

  • 任何有效的访谈都需要有所准备。事前应该准备提问大纲。
  • 访谈中，表达出的浅层次需要发掘出真实的意图。
  • 对于回答方式要敏感，比如”还可以“和”特别好“在回答中都是肯定回答，但意义不同。
  • 掌握好节奏，对于某个关键观点，要重复确认。
• 样本的把控

可用性测试

    相比问卷调研和用户访谈，可用性测试（Usability Test）要利用产品实体。可用性测试是将已完成的产品 Demo 或者简易版的可用版本（比如 MVP）让目标用户体验。整个过程的重点是需要对用户的使用过程进行观察，并且对用户的使用体验有所了解。

    在时间上来说，可用性测试应当是在最简单的可用版本实现后、正常版本上线钱，有可以修整的余地。

    从内容上来说，可用性测试关注的是用户对产品的整体使用过程中出现的各种问题。包括但不限于是不是真正能解决他们的问题，使用中是否有困惑不解、反感抱怨，以及从表情和行为中流露出额其他负面情绪。

数据分析

    ”好的产品经理要对数据敏感“。现在的产品经理并没有很多检验方法，能够对需求分析的正确与否、方案设计的合理与否做验证。

    用户的行为数据，以及相关的很多反映用户情况的数据都是产品经理对自己前期工作最重要的验证手段。对于用户数据，不同产品类型的关注点也不同。普遍要关注额数据大概有以下几个。

• 启动次数
• 启动时间及持续时长
• 事件完成情况。如注册、登录或下单。
• 使用出错情况
• 用户活跃情况
• 用户属性
• 实地考察
  还有一种特殊的数据分析方法，就是A/B测试。

https://www.zhihu.com/question/20045543

用户研究的理论

      我们可以将用户研究分为定量和定性两种。

      定性的结论输出的一般是有价值的观点。比如，用户画像就是一种很有意义的定性结论。定量的结论输出的则是对数据的分析结果，重点在于怎样客观合理的统计和展现数据。

3. 用户体验

    用户体验到底是什么概念呢？

国际标准

    发布于2012年的 ISO 9241-210 标准将用户体验定义为 ”人们对于针对使用或期望使用的产品、系统或者服务的认知印象和回应“。

Peter Morville 的蜂窝模型

    Peter Morville是互联网行业知名的信息架构专家，曾被誉为“信息架构之父”，他认为用户体验包含 7 个模块。

模型内容：

• 有用性。面对的用户需求是真实的。
• 可用性。功能可以很好地满足用户需求。
• 满意度。涉及情感设计地方面，比如图形、品牌和形象等。
• 可找到。用户能够找到他们需求地东西。
• 可获得。用户能够方便地完成操作，达到目的。
• 可靠性。让用户产生信任。
• 价值。产品要为投资人产生价值。

Steve Krug 的解释

Steve Krug 在《点石成金》这本书里，提到的用户体验包括几个方面：

• 有用性：能否帮助人们完成一些必需的事务？
• 可学习：人们能否明白如何使用它？
• 高效：它们能完成任务吗？
• 合乎期望：是人们想要的吗？

Whitney Quesenbery 的 5E 原则

Whitney Quesenbery 提出了 5E 原则，认为用户体验包含五个方面，如图：

分别是：

• 有效性：实际可以等同于可用性或者有用性，就是这个产品能不能起到作用
• 效率：产品应该是能提高使用者的效率的
• 易学习：学习成本低
• 容错：防止用户犯错，以及恢复错误的能力
• 吸引力：（主要是从交互和视觉上）让用户舒适，并乐意使用

Jesse James Garrett 的五层模型

用户体验的十个原则

Jakob Nielsen提出的一些可用性的标准，也被称为『尼尔森十大可用性原则』。下面是作者基于nielsen的原则有增改。

1. Visibility of status 可见原则
2. Match between system and the real world 场景贴切原则
3. User control and freedom　可控原则
4. Consistency and standards 一致性
5. Error prevention　防错、防呆原则
6. Recognition rather than recall 协助用户记忆原则
7. Aesthetic and minimalist design 简约易读原则
8. Help users recognize, diagnose, and recover from errors 容错原则
9. Help and documentation 帮助和提示
10. Resume the scene 恢复现场原则
    参考作者原文：

http://www.woshipm.com/ucd/279350.html

第三部分 产品管理

1. 文档管理

1.1 产品经理要不要懂技术

    ”技术“ 到底是什么呢？任何产品工作中接触到的技术都应该算作产品经理 ”有可能“ 需要了解和学习的技术。包括算法、技术逻辑、数据结构、架构、整体框架等。

    产品经理一定要懂技术，具体需要懂到什么程度要看 “需要”。不同的产品经理负责的事情不同，接触到的技术也不同，所以要清楚哪些事情是需要了解的。比如做安卓操作系统的时候，我们会对原生系统提供的一些可复用的模块很熟悉，这样我们会设计出成本更低的方案。

1.2 好的文档到底是什么样的

    优质的产品文档就应该是交给技术研发的同事后，再也不用来回确认沟通的。由于现实因素这几乎不可能实现，不过我们要尽力做到可以让需要确认的情况减少。

    我们抽象出 “好的” 文档应该满足的几个条件。

1. 没有逻辑硬伤
2. 没有疏漏
3. 逻辑清晰
4. 可读性强
       对于产品经理，输入是不断跟用户产生互动，那输出就是不断跟技术研发人员产生互动。在互动中，完成需求分析、产品功能设计及协助产品实现的工作，前后两端同样重要。只关注用户的输入却不关注技术研发那端的输出就会失衡。

1.3 文档逻辑

    在功能设计中，需要有三种逻辑关系是特别清晰的。它们分别是功能框架的逻辑、业务流程的逻辑，以及功能描述的逻辑。

功能框架的逻辑

    在产品设计上划分结构、搭建基本框架，更有利于产品思路的梳理，也能够由此衍生出合适的功能。对于研发部门也有意义，他们也可以以此框架解耦开发，以防把所有功能都做得纠缠不清。

    那到底怎么才算有清晰的框架和架构呢？如何梳理？

• 拆分
  要进行整合，就要先拆分。把产品的功能（或预期有的功能）枚举出来，拆分成相对独立的模块。
• 组合
  接下来，我们就可以把刚才罗列的产品功能予以组合。整理出应有的模块划分。

业务流程的逻辑

    业务流程在这里指的是，产品所提供的功能或服务实现的具体步骤。这里可以从两个维度去分析，一是面向事件的，二是面向对象的。

面向事件

    面向事件指的是，要完成一件事可能会进行很多次操作。而在这些步骤中要整理出健全的流程，逻辑清晰且不存在缺漏。一般情况下，我们使用流程图描述面向事件的流程步骤。

面向对象

    面向对象，指的是对象的生命周期代表着一次完整的功能使用。最常见的就是订单，从产生到消失（注销）会有很多状态的情况，要考察清楚状态的转化条件和流程，通常会用状态转化图来表现。

功能描述的逻辑

    对于一个功能设计出方案，并不意味着可以逻辑完整地描述清楚，而且对于功能方案，我们无论多么谨慎也总是有存在疏漏的地方。所以在描述功能时，用各种方法尽量捋顺逻辑，把内容更有条理、更完整地描述清楚，可以避免很多问题。

   总得来说，在描述功能时有以下几点要注意：

• 完整
  尽量枚举所有的情况，并且分情况详述功能内容。最好从某个维度，比如业务的发生、进行的流程、订单状态变化的转换等关注功能变化的情况，以访漏掉什么特殊情况。
• 条件判断清晰
• 含义明确
• 叙述背景
  让逻辑链条更完整的一个好方法是叙述功能产生的背景及它要达到的目的。

2. 需求管理

    需求在不同的阶段，产品经理对这个需求要负的责任是不同的。但需求要牢牢把控在产品经理手中。我们可以把需求分为几个阶段。

2.1 获取需求阶段

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

    职级越高代表身边人提需求的可能性越大。初级产品经理，需求来源主要是用户和上级；产品负责人，需求来源还会有老板和其他相关部门；而作为老板，谁都可能提产品需求。所以在获取到需求这一刻，就必须做一个判断并记录。

    判断需求的方法如下：

1. 判断需求本身的重要性
2. 考虑需求来源
3. 了解需求背景

2.2 讨论和设计阶段

    每隔一段时间应该举办需求讨论会，整理 “需求池” ，也就是记录所有获取到需求的表单。会上要详细讨论每个需求的情况，确认以下几个事项。

• 需求的优先级
  对于需求的优先级有两种常见的排序方法。一种是基于四象限法则。另一种则是基于 KANO 模型。
• 方案的草稿
  需求有不同的解决办法，要讨论清楚到底用哪种方法解决。
• 制定负责人
  通常存在两种产品经理的需求分配制度。一种是每个人负责的需求范围要有清晰的边界，需求对应哪个模块直接分配即可；另一种是团队作战每次指定或者认领，谁都有可能接受任意需求。建议的方法是，在需求分配时大致还是按照模块分配，但在出现工作量不平衡的情况时，可以酌情调整以下，让活少的同事予以配合。
• 划分时间节点
  许多产品经理会疏漏这点，总觉得有了需求就尽快去做。但这样的结果往往是需求总是做不完。

时间节点主要时指方案完成的截止时间（Deadline）。就是当前需求能够完整提交给开发人员的时间。如果没有这个时间，对需求的管理就没有意义了。

2.3 待开发阶段

    有了确切方案后，要尽快跟研发的同事做可行性评审，这一步必不可少。如果缺少可行性评审，将会出现很多产品设计方案可行性差、需求频繁更改、产品功能不切实际的情况。

    在可行性评审上完成的是对需求的大致评估，要做的有以下几件事情：

1. 方案本身的可行性
2. 有没有更好的方案
3. 涉及的产品和技术环节有哪些
4. 方案的成本如何

2.4 开发阶段

    开发需求的次序，未必完全按照需求池里的需求优先级进行。按照需求矩阵从性价比由高到低的顺序，依次完成需求。

    在开发中，“扯皮” 的问题归纳起来有三种：需求太多，没按时昨晚；需求有改动，导致了额外工作量，引起开发人员的不满；有新的紧急需求，导致发布延期。

    导致出现这三种问题的原因如下：

1. 产品方案不完整
2. 需求方的主观改动
3. 无法预测的客观原因

2.5 复盘阶段

    需求从获取到上线走完生命周期之后，还要有一个很重要的复盘阶段，尤其是在需求管理出过故障和问题的时候。

3. 工作流中的管理

    在工作中，实现一个目的有很多方法，但往往会选择最容易想到的而不是最好的。这样就导致花了大量精力在没必要的事情上。在越健全的团队、越成熟的项目中，出现这种问题的伤害越大。

3.1 协作管理

    协作的核心在于，如何在同一个目标即 ”实现好的产品“ 下共同合作，实现共赢。作为产品经理，跟其他部门的协作在很多情况下并不存在标准的答案，问题常常出在沟通不力、交流不通畅等原因上。所以在协作上要保证的是，每次遇到问题要让大家在情理都可以接受的范围内解决掉，而不是从逻辑上证明到底谁对谁错。下面提供一些方法作为参考。

• 与技术人员的常规协作
  在前面，我们以及从需求管理的角度描述了跟技术人员之间需要协作的事项。其中可行性评审，以及后续的很多评审都是协作中的关键。

评审最重要的目的就是正式场合下的沟通，其意义在于：其一，确保产品经理对产品的要求传递给技术人员；其二，确保技术部门的意见得到了表达；第三，双方对共同认可的内容予以确认。

• 与技术人员协作的临时状况
  常规协作显然不能覆盖所有情况，临时状况也会层出不穷。所以这时候产品经理首先要安抚，不要拿 ”这不是我决定的啊“ ”你要有大局观“ 这样的话反驳同事，而是表示理解他们的情绪，帮他们想办法。动之以情，晓之以理。
• 与需求来源方的协作
  跟他们协作，主要关心的重点是需求完成的准确程度和及时程度，所以也是类似跟技术部门的协作，要在需求管理的重要节点，跟需求方同步信息，确保他们认可你的方案认可目前的进展。
• 双赢心态
  在判断事情如何解决有利时，要确保是 “对大家有利” 以及 “对产品有利”，而不是 “对我有利”。这样的心态才能确保协作的价值最大化。
• 开会
  随着会开得越来越多，也就体会到高效会议的重要性。开会时最重要的是讲规则。规则有很多种，越多人参加到的议题，越复杂的会议越需要规则。

最基本的规则有：

* 针对拟定的主体讨论，其他无关议题禁止讨论或加会再讨论
* 讲求发言顺序，不能争吵和吵闹，最好有主持人
* 禁止人身攻击，避免太情绪化的讨论
* 会议要对原定的主体输出结论，如果没有结论，要制定解决方案

• 记录
  作为产品经理，只要要对以下内容有所关注。

1. 文档
2. 会议记录
3. 想法和思路
4. 其他事项

3.2 流程管理

    有很多对产品经理工作流程的管理和改进，其价值可能远超我们的想象。用几个字描述它的价值--不要再重复造轮子了。对产品经理来说，为达到不重复造轮子的目的，有几种方法可以参考。

1. 让协作标准化和流程化
2. 减少手工劳动
3. 让一些工作可复用
4. 避免重复犯错

3.3 个人管理

    不懂对自己的事务进行管理的产品经理，绝不可能成为优秀的产品经理。

任务管理

常见陷阱：

1. 把表现出来的焦急当初任务的紧急程度
2. 把充实感当成完成任务
3. 眼光不够长远，只做半衰期短的事情
4. 不设截止日期
5. 不检视效果

知识管理

    知识管理指的是要把很多知识、信息记录在案，方便以后查阅。这是基于一个假设：我们不能记住全部所学、所见的知识。

团队管理

    其实作为产品经理的团队领导，要做到的是在专业技能上服众的基础上，掌握一定的管理技能。

第四部分 技巧和方法

1. 处理问题

    产品经理乃至各行各业的人的日常工作就是处理问题。对于更多的传统行业，“处理新问题” 的情况远远少于 “处理常见问题” 的情况。或者说再很多情况下，他们再解决问题时要花费大量的时间和精力，但并不需要在发现和发现问题上付出太多时间。

1.1 发现问题

    作为产品经理要有主动发现问题的意识。很多问题并不会让你有切身的感受，它们是最危险的问题：把产品做得一塌糊涂都不知道问题出在哪儿。

    这种潜在的问题，产品经理要发掘出来并且把它们定义清楚。如果你经常要回答别人的问题，就要知道问出一个好问题，不比回答一个问题简单。

    “学会提问才能学会思考”，我们要先明白问题在哪儿，分析清楚了再去动手，方为良策。

什么是问题？

    在工作中哪些事情算是问题，需要我们解决呢？答案是有跟我们的预期不符的状况，那就是我们需要解决的问题。任何达不到预期的事情，我们都要考虑是不是真实需要解决的问题。要能够很好地发现问题，我们应该做到以下几点：

1. 在工作中对任务要有预期
2. 敏锐地察觉到与想象不符的状况
3. 不应关心没有预期或与预期差别不大的状况
4. 问题是合情合理的吗？
5. 问题是真实存在的吗
   把问题描述清楚

    在开始提问题时不要着急把问题抛出来，要想清楚问题所涉及的内容，把问题本身考虑完整，再进行下一步的分析。

1. 考虑问题的背景
2. 考虑问题涉及的人
3. 考虑解决问题的期望
   发现问题的主动性

    没有问题也要主动发现问题，这是产品经理的基本素质。没有发现问题的主动性是 “懒” 的一种表现，这样的懒往往都是极其隐蔽的，可能是习惯被动解决问题（习惯痛了才去做），也可能是缺乏自驱力。

1.2 分析问题

抽象问题

    我们分析问题时，把复杂的问题抽象出容易理解、方便解决的本质。在产品设计中，抽象的能力更为重要，把产品解决的本质问题弄清楚会一目了然。

逻辑分析的常见问题

    “讲逻辑” 是个容易被忽视的地方。倒不是很多产品经理不懂逻辑，知识容易轻视逻辑健全的重要性，把产品经理看成相对感性的工种，以为需求分析在于 “一阵见血”，功能设计在于 “一剑封喉”。但产品经理的工作偏偏是最需要讲逻辑的。

• 混淆因果关系和相关性
• 概念有歧义或者偷换概念
• 逻辑关系混乱、不熟悉归纳演绎
• 假设错误
• 轻易断言
• 太过主观臆断
• 片面归纳
• 比喻过度
• 被统计数据欺骗

1.3 解决问题

• 拆分问题

• 解决问题
  对于解决方案，跟发现问题一样，我们要确保它是完整而可行的。所以至少要包含以下几点。

  • 问题和背景
  • 方案的内容
  • 方案的负责人
  • 方案的目标和验证方法

• 推动执行
  如果要协助别人或者需要别人协助的方案，建议做以下事情

  • 确保对方获取到所有信息
  • 了解对方的态度
  • 定期关注
  • 解决后检验效果

2.沟通

    对产品经理来说，好的沟通能力要包含以下几点：

• 能够快速、准确地理解别人表达的信息
• 能够准确、流畅地标属自己想传递的信息
• 在理解和表达中就事论事，也能照顾大家的情绪

2.1 理解

• 找到重点
• 用复述来确认
• 区别事实和观点
• 关注诉求

2.2 表达

表达重点

• 确保对方理解
• 用更形象的方式

2.3 沟通的心态

• 把批评当成信息
• 不要过度解读
• 不纠结对错，不关心输赢

3. 成长

• 好项目+好导师
• 博采众长
• 素养
• 审美
• 善意
• 有趣

4. 兴趣和热情

• 产品的责任心
• 产生兴趣

• 产品经理的自驱动

  • 接触用户
  • 成为用户
  • 找榜样
  • 分享检验