产品经理的工作，直接做成流程图，更直观，也体现了产品经理的工作内容，并且把设计、研发等角色加进去，这样会比较想要，就像课上所说的那样：产品经理是个运筹帷幄的工作。
互联网公司谁最累?当然是产品经理，需求，思路，方案，验收，培训，资源，等关键节点，都需要产品经理来推动，这无疑是最累的一项工作。如何高效的有条不紊的来推动，最重要的 是有一套清晰的工作流程。
按照产品从需求到上线的线性路径来讲，这个路径就是产品经理的工作流程。工作流程中，可分为3大阶段13个芳点。前一个节点的结果将会影响到下一个 15点。因此，不仅节点的顺序不可更改，而且还需要产品经理把关好每一个节点。以下是对每一个阶段，每一个节点的详细介绍：
一、你是做什么的
对于非互联网行业的人来说，我们往往拿捏不好这个回答的度。讲太多技术又怕人不懂，讲太少的话又怕人家认为自己是行政，讲不好还会被人认为是银行柜台里那个产品经理。所以异常心累。
二、产品设计阶段
产品设计阶段是指产品从搜集需求到立项通过中间的时间段，AAA教育在这个时间段产品主要的工作就是制定一份可落赋施的方案，技术可以着手编程开发的方案。
2.1、获取需求
需求决定着产品要做什么，因此需求的重要性就不言而喻了。那么产品经理可以通过什么样的方式获取需求呢?首先产品经理可以通过竞品分析获取需求，看看竞品有哪些亮点，把别人的亮点拿过来放入到自己的产品中，这是一种获取需求的途径。其次产品经理可以通过问卷调查，向用户发放问卷调查获取用户反馈，在用户反馈中提取需求。最后产品经理的创新也是一种需求。如果产品是面向B端客户，那么B端客户会主动提出需求，产品经理只需要对B端客户提出的需求进行筛选即可。此外运营人员也会向产品经理提出需求，运营人员制定的策略有时 是产品无法实现的，此时也会把这类需求记录在案。
2.2、需求分析
需求分析就是对需求定性，紧急，不紧急，重要紧急，不重要不紧急。然后根据状态来规划版本，重要紧急优先级最高，紧急次之，然后是不紧急，最后是不重要不紧急。在规划版本中，最终重要的就是梳理好版本的边界，只是看一条条需求是很难确定版本边界的，最好的办法就是根据产品设计逻辑来进行划分版本。例如要做一个社区平台，第1版本首要的就是社区的基 本框架，基础功能，包括用户发帖，看帖，跟帖消息提醒，奖励设置，平台方帖子汇总，规则设置极大核心模块。用户成长体系，签到，内容审核等这些模块，都可以规划到后续版本迭代。因为社区平台刚开始建立，用户习惯未进行培养，用户认知不够，用户量也不大，用户体系，签到，内容审核没太大价值。所以第1版本的中心是基础核心功能的建设。
2.3、需求确认
需求确认通常是指产品迭代版本时，产品委员会对需求确认的一个过程(产品委员会可以是直接上级，上级的上级，几个产品总监)这一过程主要审查产品经理计划要做事情是否合理，方向是否正确，以此确保产品的正确性。在召集产品委员会确认之前，产品经理需要搏需求分析的结果整理成文案的形式，并说明为什么需要做这些事。
需求确认无误，接下来就是思路碰撞环节。
2.4、思路确认
思路确认是指产品委员会对产品经理设计的产品逻辑审查的一个过程。在审查前，产品经理将根据确认好的需求绘制出产品逻辑图，流程图。然后把设计思路，逻辑图，流程图整理成文案，发给产品委员会看。在思路确认过程中，产品经理讲出自己的思路，想法给产品委员会听。产品委员会听取后给出点评，建议，以便更加对产品进行完善。这是一个思想碰撞过程。
思路确认无误后，产品经理就可以绘制原型。需求清晰，思路清晰，画原型就是一个简单的过程。
2.5、方案评审
方案评审是指产品委员会对产品经理原型审查的一个过程，产品经理向产品委员会讲解原型， 产品委员会对原型进行评审，或给出建议。这其实是在检查产品经理输出方案质畺的一个过程。这个过程是非常有必要的。如果在这个节点都没能发现问题，后续发现了，将会是很丢产品部门脸面的一件事。
2.6、立项
走到此节点，代表产品经理的方案已经可以落地开发。但是还需要技术部门的配合。此节点产品经理将召集技术部的老大，产品部的老大，项目经理，前端经理等项目相关人员，一起看方案。技术部门将对方案进行评审提问
标签：经理,内容,产品
