我听过、见过很多个版本的产品经理工作流程及内容，但是最让我感同身受的是这一个。
首先，拿到一个IDEA
在进入产品工作流程前，先会获得一个IDEA。这个IDEA可能来自老板；可能来自业务部门（如销售、运营、客服等）；可能来自竞品分析报告；可能来自数据分析结果；可能来自产品经理本身的心得体会等等。拿到这个IDEA后，开始进入产品的工作流程。
1. 市场调研
常用的市场调研方法有竞品分析和用户调研。
[竞品分析]
竞品分析报告的内容一般包括竞品介绍、功能板块树形结构、功能分析、交互分析、视觉分析、推广分析、运营状态分析、借鉴和规避。
公众号里回复“竞品分析”可获取案例。
[用户调研]
常用的用户调研方法有三种：问卷调查、用户访谈、行为跟踪。
问卷调查：一种定量分析方法。问卷调查不关心问的是谁，只关心问卷的数量。比如发1000张调查问卷。
用户访谈：一种定性分析方法。用户访谈会约谈指定类型的用户，针对特定人群的访谈获取想要的信息。
行为跟踪：一种用户体验优化方法。将用户独自关在一个可监视的空间，在没有工作人员帮助的情况下使用产品，观察记录用户使用过程中出现停顿思考的页面或功能，针对性的优化产品体验。
2. 需求分析
需求分析是指确定产品功能的目的、范围、定义和功能时所要做的所有工作。做需求分析时有一个非常重要的事情，就是辨别需求的真伪性。
[真伪需求]
辨别一个需求的真伪，是一个衡量产品经理的核心指标。如何在开发资源争夺的情况下，快速输出满足市场认可的产品，是至关重要的。
日后会专门写一篇如何鉴定需求真伪性的文章，这里暂不多说。
3. 产品规划
需求已经确定，但是需要做的事情很多，如何能进行合理的安排，保证产品有条不紊的推进，不能一口吃个胖子，先做什么后做什么，需要有一个规划。
产品规划一般会借助工具思维导图和RoadMap。
产品规划时切记不要做大而全。记住，产品经理只做减法！产品经理只做减法！产品经理只做减法！不可能你的v1.0就是你的最终版本。需要遵循需求拆解，小步快跑的原则。
公众号里回复“Xmind”，获取思维导图工具Xmind Zen安装程序，全功能无水印。
4. 产品设计
产品设计包括两个部分，产品功能设计和视觉设计。分别输出产品原型、需求文档和UI效果图。产品原型、需求文档由产品经理完成，UI效果图由UI设计师完成。
通常需求文档是用word写的，但是有些公司也用Axure RP写。常用的原型设计工具有Axure、墨刀等，这里强烈推荐Axure RP 9，专业工具，功能强大。
公众号里回复“Axure”，获取Axure安装程序及汉化程序等。
5. 需求评审
需求评审又叫需求宣讲。参与人一般包括项目经理、开发、测试、需求方。会议内容面向项目组内成员进行需求的详解，帮助开发测试更好的理解需求内容，并达成多方对需求一致认可的结果。
小窍门：做产品也好写需求也好，都非常忌讳闭门造车。所以在梳理需求时，就需要提前做好需求确认和技术调研，跟开发了解清楚你想做的功能是否可以实现，而非在需求评审时拿出一个谁也没见过的需求内容。否则，会造成会议主题的发散，甚至需求重改、再次评审，非常耽误时间。
6. 研发跟进
主要跟进开发的工作进度，以及开发过程中遇到的需求变更。开发过程中遇到需求变是非常普遍的问题，需求评审可以解决绝大部分的需求疑问，但难免有一些问题会随着开发的推进慢慢浮现，所以这时候需要及时跟进这些变更需求，并通知到相关人员。
PS：因为自己之前做过测试，所以对这种不能100%确定的事情会更加理解。测试其实也是一样，测试过程只能尽可能减少BUG，但是不能保证100%没有BUG。当然这并不意味着你的需求可以写的粗糙，你的逻辑可以经不起推敲。
7. 测试
这个阶段产品的工作重点是产品功能的验收，有时候需求是一个样，开发出来的又是另一个样。导致这个结果的原因是因为每个人对需求的理解程度不同，所以产品需要对开发结果进行验收，看它是不是符合当初的需求预期。如果不符合应当及时反馈出来。
验收阶段也必须协同需求方和UI设计师一起验收。需求方主要验收需求满足度，UI设计师主要验收视觉效果。
8. 上线
产品上线，看似都是技术（运维）工作，那产品在里面扮演什么角色，需要做什么呢？答案是上线计划。
上线计划一般包括上线时间、人员安排、数据准备、运营材料准备等。发布上线前需要把新功能要用到的数据准备好，以免由于数据不全或数据纰漏造成的上线后的程序BUG。上线前同样需要联合运营部门，准备好上线材料。例如活动说明，活动banner素材等等。
上线前的数据准备、运营材料准备非上线当天才着手去做，需要在上线前几天已经确定并完成。
9. 产品培训
产品上线之后需要及时对需求方或者相关的业务部门进行培训，比如：销售部门、运营部门、千万不要忘记客服部门，虽然他们可能不是直接的需求方，但是他们会收到很多的用户或客户反馈，如果对新版版本系统或功能的使用不熟悉，是没有办法第一时间解决问题的。
假如你做的是C端产品，是没有办法对用户直接进行培训的。可以在产品中加入操作指引和帮助文档来解决一部分问题。但是，C端产品最重要的还是用户体验，而非指引或文档。
10. 收集反馈
产品发布上线后，需要持续跟产品的使用反馈和效果反馈。收集反馈问题，作为产品后期迭代优化的重要依据。
迭代的流程即上述10点。
番外篇·[需求池的管理]
需求池的管理，也是产品经理的一项日常工作。最简单实用的需求池可以用excel来记录，一个需求池一般包括编号、需求名称、需求描述、提出人、提出时间、优先级、需求状态、备注等。
重点解释下以下几个词：
需求名称：一句话描述这个需求要做什么。比如：优惠券活动添加定时投放功能
需求描述：描述这个需求大概要做的事情，尽可能的举一些场景。比如：优惠券活动可以设置在未来的某个时间点由系统自动发布，精确到年月日时分秒。场景举例，十一活动，运营可以提前编辑好活动内容，设置在十月一日当天发布，而这时运营可能在休假中，不方便操作。
提出人：即这个需求的需求方。未来的需求沟通，需求确认，必须有这个人的参与。
提出时间：记录提出时间是为了提示自己，这个需求从提出到得到解决所耗的时间，如果是一定要做的，不能拖太久，否则会影响业务部门的业绩。
优先级：优先级的判断遵循时间“四象限”法，即按重要、紧急两个不同的维度。下图中“交由下属解决”可以改为“延时解决”，除非你真的有下属。可以用数字代表重要紧急程度，如1、2、3、4、5，越小的越紧急（思考为什么）。
第一个象限既重要又紧急；第二个象限重要不紧急；第三个象限紧急不重要；第四个象限不紧急不重要。
时间“四象限”法- MBA智库百科
需求状态：即这个需求当前处于的状态，一般状态包括不做、延迟解决、需求排期、xx需求v1.0.x(具体的需求版本号)、已上线等。可以按照自己的习惯命名，目的是让自己知道哪些需求是不做的，哪些需求是要做的，哪些是正在执行的，哪些是已经解决的。
备注：比如不做的原因是什么，可以陈述在这里。
[工具链接]
竞品分析：公众号里回复“竞品分析”可获取案例。
Xmind：公众号里回复“Xmind”，获取思维导图工具Xmind Zen安装程序，全功能无水印。
Axure：公众号里回复“Axure”，获取Axure安装程序及汉化程序等。
转自公众号：岩杉Shawn
