产品经理的工作流程（产品经理工作流程初步分解）
产品经理虽然是互联网相干公司的职位，但是产品经理的工作流程其实是实用于各行各业的。概括起来其实是一个“想法——实现——（下次）精进”的进程，对于建筑设计行业来说，可能“想法”是一个建筑立意或者动身点，“实现”是设计计划，“精进”是下一次类似项目标优化。对于互联网行业来说，“想法”是需求，“实现”是需求变成可以应用的产品，而因为互联网产品比较传统行业，有着“迅速优化”的先天优势，“精进”则指的是此需求的更新迭代。
更详细一点说，“想法——实现——（下次）精进”应当分为四个阶段：
需求阶段
需求阶段流程分解
需求的第一步是想法。不管是大型项目，小型项目，或者是新项目，老项目更迭，需求的第一阶段都是原始的想法。想法的起源可能多种多样，可能是灵机一动的小点子，也可能只是想让现在的功效变得好用起来。
有了初步想法之后，须要肯定的是：需求动机、目的用户、目的结果。需求动机是便于在需求推动的时候不被复杂的新想法冲昏，是需求深化时候谨记的初衷。目的用户、目的结果是这个阶段须要简略定性的。当然，在这个阶段时，即使做过市场的数据调查，也是很难一下子把握住目的用户的。不过没关系，这个步骤的目的用户、目的结果的记载更多是为了追根溯源和后期迭代斟酌。
之后是初步需求。在得到了想法、动机、目的用户与结果后，我们已经可以简略的描写出想要的东西的大致的轮廓和大致的方向了。
如果须要竞品剖析，到现在这个步骤就可以着手开端了。市场上同类竞品不少，不过由于方向不同（或者说定位不同），在初步需求肯定之前做竞品剖析很有可能对方向迥异的产品研讨过深，最后徒劳无功。在初步需求肯定后的竞品剖析有助于厘清思路，并且得出需求框架。
需求框架是需求阶段的结果物。这个阶段的需求框架有了明白要做的百思特网义务，大义务下的子义务。需求本身的构造被搭建起来，主脉络清楚了，可以汇总出一份概念计划提交出去，也可以进入下一个阶段——
细化阶段
细化阶段流程分解
需求框架虽然具备了根本的功效，但是由于太过泛泛，实际上并不具备与其他合作专业相沟通的根本点。为了更加深刻的去研讨需求，需求框架须要逐步的深化成羽翼饱满的结果物。
从线框图开端切入是一个不错的选择。
线框图示意
线框图是原型的简化版，通过线框图可以把页面中的症结操作体现出来，譬如触发按钮、文本框等。线框图是流程操作的梳理进程，由于大部分公司不请求这个进程的输出物，所以这个进程仅用来梳理自己思路和团队内讨论用的。
有了线框图后，或者说有了症结操作后，接下来就可以绘制流程图和原型图了。
在绘制流程图进程中会涉及不同体系的数据传输，不同接口的断定，是从技巧实现逻辑断定层面的上的功效剖析。原型图呢，是前端的展现，更倾向于交互层面的展现。流程反应着原型，原型是流程的前端映射，这两者相互影响相互牵制，所以须要通盘斟酌，两者同时推动。
简略的密码登录流程图示意
如果埋点须要产品经理设计的话，在原型图和流程图定下来后，就可以着手埋点和漏斗模型的设计了。
接下来是高保真原型。
由于现在大部分公司已经有交互设计/ UI设计师的岗位，很多产品经理通常不再做高保真原型。大家可以依据工作的实际情形选择做或者不做，私认为，做高保真原型还是可以对用户体验有进一步的懂得的。高保真原型对于原型来说，更多的是页面展现的细化和微交互的斟酌。举个例子，原型上只须要绘制出Tab即可，高百思特网保真原型就会斟酌到，这个Tab是滑动至顶部后吸附在顶部的Sticky Tab，还是会随着页面滚动的Scrollable Tab。
几种Tabs示意
高保真原型的产出可以确保细节更加完美，实际后果更加确实，场景更加丰硕。如时光许可，各位产品经理不妨一试。
细化阶段的最后一步就是需求文档了。
需求文档根本上不同的公司会有不同的规范模版，不管需求文档的模式多么不同，最终目标就是给开发、产品、设计等相干人员浏览应用的。所以记得表达清楚不能模棱两可，如文字不便于叙述时，可添加示意图、细节的流程图等等。关于需求文档的写法，这又是一篇大课题，此处不再多言。
实现阶段
实现阶段流程分解
实现阶段也就是从需求文档完成到开发上线的进程。这个进程中，产品经理除了参与需求评审和排期百思特网外，根本只须要坚持沟通即可。事实上，只要需求文档写的详细，前期绘制流程图时与开发坚持沟通，实现阶段不须要消耗太大心力。
迭代阶段
迭代阶段流程分解
迭代是我以为的最主要的阶段。目前市场环境下，大部分需求来不及过多剖析市场、用户、类似数据便迅速上线。这时候的功效需求很可能是不能用、不好用、甚至是不合理的。迭代，就是使这个需求合理化的进程。
需求上线后，须要定期观测下数据。如果没有数据团队的话，前期也须要事件定义、对数据观测周期进行设计，如运动刚上线1小时，密集流传后30分钟、1小时等等；如一个普通的未推广的功效刚上线1天，上线3天，上线一周等等。此处可归属为数据剖析这一大类上。
有了根本的数据后，通过这些数据得到可能的几种原因（也就是定性剖析），再根据这几种原因再依次进行相应改革/ 用户问卷/ ABtest...（定量剖析），最后得到的成果就算是当前阶段比拟合理的成果了。
很惋惜的是，大部分团队都没有足够的时光和人力去支撑定性定量剖析。那么迭代阶段最好依据简略的漏斗模型和简略的用户反馈，以及竞品剖析，得到有切实履行意义的计划。如果没有足够的反馈支持着迭代方向，那还是暂时忘却迭代这事把，专心去做别的需求吧。