做产品的阶段性感悟

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

东东推荐:做产品如果可以每一段时间做一个阶段性的总结,可以对反思提高自己,从中找到自己有待提高的地方,看看本文作者是怎样做产品的阶段性总结的

20090107120000-102699

在当前公司主要做了三件事:

1、组建产品团队

一个产品团队的定位和公司的现状决定了需要什么职能的人来做相应的事。一个产品想法的来源和形成往往是出自于产品策划,把这个想法可视化为产品原型或蓝图,往往是产品设计的事,产品上线时,产品的生命才刚刚开始,伴随着用户使用和产品运营,产品是不断成长的,是一个从负 到 1 再到 100 的过程。

60437-10fa5ea63a7836cf

基于公司的现状和产品的现状,现阶段,将产品团队定义为产品设计组,每个人负责一个产品,从产品策划、产品设计到产品运营,这是一个理想状态,当前的重心主要是产品策划和产品设计,随着用户的不断累积,产品运营就要提上日程,当然在产品策划阶段也是考虑到产品运营方面的事宜,但是很粗的,不会很细。

做产品的核心任务就是从用户需求出发的产品设计,并确保UI和开发按照需求设计如期实现产品。

产品团队解决了三个问题:产品从哪里来、产品怎么做出来、产品要走向哪里。

60437-719eda5328a76253

2、规范产品设计流程

这里面有个插曲:当我接手该部门的某个产品时,竟然找不到产品需求文档,只有零散的原型和用户手册,更要命的是,该部门和开发部们在财务上是独立核算的,直白来讲就是,我部门设计出来的产品要让开发部门进行开发,是需要付钱给开发部门的。当我面对这样一种情况时,我就很揪心。不再是我熟悉的扁平结构,而是部门间利益纠葛的复杂关系。具体到互联网产品的设计流程,在我进来时几乎是一张白纸,在公司内部接触到都是传统软件开发模式。

60437-ee9f2979281e6a9c

看似一个通用的流程,在我实际推行的过程中,遇到了各种限制和阻碍,为了梳理和走通这个流程,我拿一个产品整整走了大半年时间。在这期间,曾出现领导对我们所做事情的不理解:“你产品设计主要是做什么的?!”、“你设计完,就没事了吧!”,整个公司基本没有评审、跟进、并行的概念。

关于评审:基本上每个环节都是需要评审的,出市场需求文档时,需要评审;产品原型设计和需求文档,需要评审;出UI时,需要评审;前端基本完工时,需要评审;产品测试完,需要验收,评审贯穿整个产品设计流程,是为了确保走的每一步都是相关方认同的。评审的节奏:产品内部过一次,相关方过一次,领导过一次;评审环节对PM的要求:开放的心态,巧妙的说服,合理的采纳;切记:评审不是为了让参与方为你的产品设计找茬!!!如果在评审环节,PM被喷的抬不起头来,说明你的产品设计不完整、不严谨、不周全甚至反人类。

关于跟进:PM将产品原型和PRD交付给UI和开发之后,事情并没有结束,相反,产品的落地才刚刚开始,你要跟进UI设计的成果和进度,你要跟进前端开发的结果和进度,你要跟进整个开发的计划和进度,还要跟进测试的结果和进度。跟进的要点:时间(节点)、范围、质量。跟进的目的是为了确保每一个环节都是按照需求设计如期进行的。

关于并行:PM需求设计的并行,在跟进开发的过程中,开始下一个需求设计;UI设计的并行:先给到整个UI和核心界面的切片,随着前端开发陆续提供后续切片;开发和测试的并行:当开发告一段落时,比如产品正处在测试阶段,在这个开发空档,是可以去评审新的需求设计。并行的目的是为了效率最大化。

3、引导小伙伴们独立负责一个产品

简单讲,就是在我拿一个产品走通整个流程后,引导小伙伴走顺这个流程;其次是,一个产品不仅仅是一个产品网站或者一个APP,一个产品体系做下来,往往包括了好几块的设计:比如产品本身、APP、微信服务号(微网页)、官方网站、运营后台,这是个联动的设计,一开始就要考虑到所有客户端,我的要求是,你是这个产品的PM,就要一路负责到底。

在这个过程中,有三点反思:

1、流程优化

一个需求设计从评审到定稿为什么走了整整两个月,期间反反复复进行了6次修改,最让人崩溃的是,最后定稿的那个版本基本上又回到了第一版的设计。这里面暴露了三个问题:一是需求不明确,没有做好需求规划;二是自己的设计没想透彻,容易被左右;三是对于领导的变化无常,不要盲从,要有定策和技巧。

为什么一个月的开发量,三个月还没开发完?这里面又有三个问题:一是对开发计划的波动掌控不及时,跟进不到位;二是由于前期需求设计的问题,造成了需求变更或补缺,三是整个项目进度失控了,并且没有及时作出应对措施。

因此,就需要不断地优化各个环节间接力的流程,规范需求变更流程,提前预备好PlanB;通过各方沟通,不断简化部门之间的对接流程(这个产品部、开发部、市场部三者财务独立核算,各自有各自的业务,职能岗各种重复,在其他互联网公司往往是很少存在的),将行政上的流程对产品设计开发流程的影响降到最低,简单讲,就是在复杂的组织结构中,扁平化产品设计开发流程,最大化各环节或部门间的协同和并行的效率。

2、业务形态

我们经常听到这样的声音:一个互联网产品,前期就想着发展用户量,其它的等用户量起来了自然就有了,我要说的是,能够这样搞的都是巨头或者有资金实力的特权,普通公司这么玩是玩不起的,风险特别大。曾经历过一家公司,融资几千万,不到半年就玩破产了。所在公司也一直要求我们做产品的在设计之初,就要想好怎么做运营和怎么赚钱,后来,我就一直在思考这个问题,根子都出在了这个产品有没有清晰的业务形态,简单讲,就是你设计了一个什么产品,解决了用户什么问题,并且能够从服务的用户中找到可行的收入模式。

在做市场调研阶段和立项设计之前,就要想清楚你要做的这个产品的业务形态,这个是生存的基本条件。

3、产品迭代

关于产品迭代的反思,是基于公司其他部门做产品的现状和预期,先放出这几个关键词:单点突破、允许试错、小步快跑。相信大家都很熟悉,可是我所在的公司可不是这么想的,领导层往往想的是如何构建一个大的平台、大的生态系统,但是各部门经理也这么实操,我就觉得会出问题的。一个血淋淋的案例,非常的典型:一个教育信息化的产品,设计的非常巨大,投入了60W,前前后后足足花了两年才上线,投入市场不到一个月,就基本上宣告失败了,但是不甘心啊,再投入庞大的市场资源,在我的预期里,推的越快,死的越快。我们可以打个比方:我们设计产品就像设计了一个楼盘一个户型,我不需要设计成精装房,我就设计一个毛坯房,在装修阶段和用户一起实现其想要的房子。这里面,就可以延伸2个做产品经常提到的概念:用户参与,最小可行性产品。

就写到这里吧。欢迎拍砖。

本文作者:trulie;来源:简书

您的赞赏,是对我创作的最大鼓励。

评论( 2

登录后参与评论
  1. 这样的公司一般是创业公司吧

    回复
  2. 我读了两遍,写得比较实在。

    回复
加载中