产品经理的工作流程(产品经理工作流程初步分解)

产品经理的工作流程(产品经理工作流程初步分解)产品经理工作流程初步分解

产品经理虽然是互联网相关公司的职位,但是产品经理的工作流程其实是适用于各行各业的。概括起来其实是一个“想法——实现——(下次)精进”的过程,对于建筑设计行业来说,可能“想法”是一个建筑立意或者出发点,“实现”是设计方案,“精进”是下一次相似项目的优化。对于互联网行业来说,“想法”是需求,“实现”是需求变成可以使用的产品,而因为互联网产品对比传统行业,有着“快速优化”的先天优势,“精进”则指的是此需求的更新迭代。

更详细一点说,“想法——实现——(下次)精进”应该分为四个阶段:

需求阶段

产品经理工作流程初步分解

需求阶段流程分解

需求的第一步是想法。不管是大型项目,小型项目,或者是新项目,老项目更迭,需求的第一阶段都是原始的想法。想法的来源可能多种多样,可能是灵机一动的小点子,也可能只是想让现在的功能变得好用起来。

有了初步想法之后,需要确定的是:需求动机、目标用户、目标成果。需求动机是便于在需求推进的时候不被繁杂的新想法冲昏,是需求深化时候谨记的初衷。目标用户、目标成果是这个阶段需要简单定性的。当然,在这个阶段时,即使做过市场的数据调查,也是很难一下子把握住目标用户的。不过没关系,这个步骤的目标用户、目标成果的记录更多是为了追根溯源和后期迭代考虑。

之后是初步需求。在得到了想法、动机、目标用户与成果后,我们已经可以简单的描述出想要的东西的大致的轮廓和大致的方向了。

如果需要竞品分析,到现在这个步骤就可以着手开始了。市场上同类竞品不少,不过由于方向不同(或者说定位不同),在初步需求确定之前做竞品分析很有可能对方向迥异的产品研究过深,最后徒劳无功。在初步需求确定后的竞品分析有助于厘清思路,并且得出需求框架。

需求框架是需求阶段的成果物。这个阶段的需求框架有了明确要做的任务,大任务下的子任务。需求本身的结构被搭建起来,主脉络清晰了,可以汇总出一份概念方案提交出去,也可以进入下一个阶段——

细化阶段

产品经理工作流程初步分解

细化阶段流程分解

需求框架虽然具备了基本的功能,但是由于太过泛泛,实际上并不具备与其他合作专业相沟通的基本点。为了更加深入的去研究需求,需求框架需要逐步的深化成羽翼丰满的成果物。

从线框图开始切入是一个不错的选择。

产品经理工作流程初步分解

线框图示意

线框图是原型的简化版,通过线框图可以把页面中的关键操作体现出来,譬如触发按钮、文本框等。线框图是流程操作的梳理过程,由于大部分公司不要求这个过程的输出物,所以这个过程仅用来梳理自己思路和团队内讨论用的。

有了线框图后,或者说有了关键操作后,接下来就可以绘制流程图和原型图了。

在绘制流程图过程中会涉及不同系统的数据传输,不同接口的判断,是从技术实现逻辑判断层面的上的功能分析。原型图呢,是前端的展示,更偏向于交互层面的展示。流程反映着原型,原型是流程的前端映射,这两者相互影响相互牵制,所以需要通盘考虑,两者同时推进。

产品经理工作流程初步分解

简单的密码登录流程图示意

如果埋点需要产品经理设计的话,在原型图和流程图定下来后,就可以着手埋点和漏斗模型的设计了。

接下来是高保真原型。

由于现在大部分公司已经有交互设计/ UI设计师的岗位,很多产品经理通常不再做高保真原型。大家可以根据工作的实际情况选择做或者不做,私以为,做高保真原型还是可以对用户体验有进一步的理解的。高保真原型对于原型来说,更多的是页面展示的细化和微交互的考虑。举个例子,原型上只需要绘制出Tab即可,高保真原型就会考虑到,这个Tab是滑动至顶部后吸附在顶部的Sticky Tab,还是会随着页面滚动的Scrollable Tab。

产品经理工作流程初步分解

几种Tabs示意

高保真原型的产出可以确保细节更加完善,实际效果更加确切,场景更加丰富。如时间允许,各位产品经理不妨一试。

细化阶段的最后一步就是需求文档了。

需求文档基本上不同的公司会有不同的规范模版,不管需求文档的模式多么不同,最终目的就是给开发、产品、设计等相关人员阅读使用的。所以记得表达清晰不能模棱两可,如文字不便于叙述时,可添加示意图、细节的流程图等等。关于需求文档的写法,这又是一篇大课题,此处不再多言。

实现阶段

产品经理工作流程初步分解

实现阶段流程分解

实现阶段也就是从需求文档完成到开发上线的过程。这个过程中,产品经理除了参与需求评审和排期外,基本只需要保持沟通即可。事实上,只要需求文档写的详细,前期绘制流程图时与开发保持沟通,实现阶段不需要耗费太大心力。

迭代阶段

产品经理工作流程初步分解

迭代阶段流程分解

迭代是我认为的最重要的阶段。目前市场环境下,大部分需求来不及过多分析市场、用户、相似数据便快速上线。这时候的功能需求很可能是不能用、不好用、甚至是不合理的。迭代,就是使这个需求合理化的过程。

需求上线后,需要定期观测下数据。如果没有数据团队的话,前期也需要事件定义、对数据观测周期进行设计,如活动刚上线1小时,密集传播后30分钟、1小时等等;如一个普通的未推广的功能刚上线1天,上线3天,上线一周等等。此处可归属为数据分析这一大类上。

有了基本的数据后,通过这些数据得到可能的几种原因(也就是定性分析),再依据这几种原因再依次进行相应改造/ 用户问卷/ ABtest…(定量分析),最后得到的结果就算是当前阶段比较合理的结果了。

很可惜的是,大部分团队都没有足够的时间和人力去支持定性定量分析。那么迭代阶段最好根据简单的漏斗模型和简单的用户反馈,以及竞品分析,得到有切实执行意义的方案。如果没有足够的反馈支撑着迭代方向,那还是暂时忘记迭代这事把,专心去做别的需求吧。

老哥推广APP下载常见问题解决方法
THE END
喜欢就支持以下吧
点赞0