讲太少的话又怕人家认为自己是行政

2018-07-07 10:22 来源:未知

  秒速赛车笔者把产品从0到1的一次完整过程梳理出来,排除了后期优化和产品运营的范畴,得到了三大阶段:产品梳理、产品设计、产品落地。

  在产品界N多的永恒问题中,永远都有一个:你是做什么的?

  每当逢年过节,你的亲朋好友问起来的时候,你可能都为止虎躯一震。

  对于非互联网行业的人来说,我们往往拿捏不好这个回答的度。讲太多技术又怕人不懂,讲太少的话又怕人家认为自己是行政,讲不好还会被人认为是银行柜台里那个产品经理。所以异常心累。

  为此笔者总结了产品经理的完整工作流程,梳理清楚了至少有25件事,是产品经理独特的工作流程。

  希望以下内容能给大家灵感,先上脑图:

  笔者把产品从0到1的一次完整过程梳理出来,排除了后期优化和产品运营的范畴,得到了三大阶段:产品梳理、产品设计、产品落地

  三个阶段中,我们最少有25件事是产品经理必须要做的,否则会对我们的产品效果产生很大的影响,下面我们具体拆解来看。

  产品经理要找出点子,不管来源是哪里。做好点子这件事,需要我们掌握脑图技巧和风暴会技巧,产出灵活多变的点子并记录下来。

  在需求这件事上,我们要借用到心理学等方面的知识,去把点子归纳总结成为一条条明晰的需求,放进需求池待分析。

  方案这件事来说,我们要把需求池里的需求规划出雏形,看看在现有的资源环境情况下,是否适合去做,并给出粗略的方案和工作量排期。

  我们需要给出产品要达到的目标和效果,不能因为仅仅因为这个功能很酷而去做,而要看酷在哪里。

  有了目标之后,我们还要看看策略,是克制还是粗放,是谨慎还是开放。都需要我们去思索。

  清楚了目标和策略之后,我们应给出产品定义。产品定义是后期我们评估需求的核心要义。一切需求和优先级都不能违背产品定义,这也是我们的初心。

  在这几件事走完之后,我们一定会遗留一些问题短期之内难以解决,或需要试错。所以我们需要把不足记录下来,重点在后期产品迭代过程中考量。

  给出目标用户和场景,一一对应地去提出解决方案,进行推演。

  有了场景之后,融会贯通梳理出来一个用户的业务流程,再整体看一下每个环节的情况。

  场景和流程理清楚之后,请做出功能结构图。这里同样需要进行一次风暴会,这次的侧重点在方案上。

  有了整体的功能站点地图后,我们需要增加页面之间的跳转关系,以及每个页面具体内容的设想规划。

  在敲定了页面大致内容和关系后,我们需要将内容细化,这时候可能要对接需求方和用户,调研得出每个页面的真实数据情况,方便设计师给出交互稿。

  交互稿给出后要找各方确认,无误后给设计师出效果图和切图,准备进入开发。

  在拿到了需求、方案和需求文档以及前端所需的效果图等素材。