做产品的阶段性感悟.pdf

做产品的阶段性感悟 东东推荐 ：做产品如果可以每一段时间做一个阶段性的总结 ，可以对反思提高自 ，从中找 到自 有待提高的地方 ，看看本文作者是怎样做产品的阶段性总结的 在当前公司主要做了三件事 ： 1、组建产品团队 一个产品团队的定位和公司的现状决定了需要什么职能的人来做相应的事。一个产品想法的来源和 形成往往是出自于产品策划 ，把这个想法可视化为产品原型或蓝图 ，往往是产品设计的事 ，产品上 线时 ，产品的生命才刚刚开始 ，伴随着用户使用和产品运营 ，产品是不断成长的 ，是一个从负 到 1 再到 100 的过程。 基于公司的现状和产品的现状 ，现阶段 ，将产品团队定义为产品设计组 ，每个人负责一个产品 ，从 产品策划、产品设计到产品运营 ，这是一个理想状态 ，当前的重心主要是产品策划和产品设计 ，随 着用户的不断累积 ，产品运营就要提上日程 ，当然在产品策划阶段也是考虑到产品运营方面的事宜 ，但是很粗的 ，不会很细。 做产品的核心任务就是从用户需求出发的产品设计 ，并确保UI和开发按照需求设计如期实现产品。 产品团队解决了三个问题 ：产品从哪里来、产品怎么做出来、产品要走向哪里。 2、规范产品设计流程 这里面有个插曲 ：当我接手该部门的某个产品时 ，竟然找不到产品需求文档 ，只有零散的原型和用 户手册 ，更要命的是 ，该部门和开发部们在财务上是独立核算的 ，直白来讲就是 ，我部门设计出来 的产品要让开发部门进行开发 ，是需要付钱给开发部门的。当我面对这样一种情况时 ，我就很揪心 。不再是我熟悉的扁平结构 ，而是部门间利益纠葛的复杂关系。具体到互联网产品的设计流程 ，在 我进来时几乎是一张白纸 ，在公司内部接触到都是传统软件开发模式。 看似一个通用的流程 ，在我实际推行的过程中 ，遇到了各种限制和阻碍 ，为了梳理和走通这个流程 ，我拿一个产品整整走了大半年时间。在这期间 ，曾出现领导对我们所做事情的不理解 ：“你产品设 计主要是做什么的 ？！”、“你设计完 ，就没事了吧 ！” ，整个公司基本没有评审、跟进、并行的概念 。 关于评审 ：基本上每个环节都是需要评审的 ，出市场需求文档时 ，需要评审 ；产品原型设计和需求 文档 ，需要评审 ；出UI时 ，需要评审 ；前端基本完工时 ，需要评审 ；产品测试完 ，需要验收 ，评审 贯穿整个产品设计流程 ，是为了确保走的每一步都是相关方认同的。评审的节奏 ：产品内部过一次 ，相关方过一次 ，领导过一次 ；评审环节对PM的要求 ：开放的心态 ，巧妙的说服 ，合理的采纳 ； 切记 ：评审不是为了让参与方为你的产品设计找茬 ！！！如果在评审环节 ，PM被喷的抬不起头来 ， 说明你的产品设计不完整、不严谨、不周全甚至反人类。 关于跟进 ：PM将产品原型和PRD交付给UI和开发之后 ，事情并没有结束 ，相反 ，产品的落地才刚 刚开始 ，你要跟进UI设计的成果和进度 ，你要跟进前端开发的结果和进度 ，你要跟进整个开发的计 划和进度 ，还要跟进测试的结果和进度。跟进的要点 ：时间 （节点 ）、范围、质量。跟进的目的是 为了确保每一个环节都是按照需求设计如期进行的。 关于并行 ：PM需求设计的并行 ，在跟进开发的过程中 ，开始下一个需求设计 ；UI设计的并行 ：先给 到整个UI和核心界面的切片 ，随着前端开发陆续提供后续切片 ；开发和测试的并行 ：当开发告一段 落时 ，比如产品正处在测试阶段 ，在这个开发空档 ，是可以去评审新的需求设计。并行的目的是为 了效率最大化。 3、引导小伙伴们独立负 一个产品 简单讲 ，就是在我拿一个产品走通整个流程后 ，引导小伙伴走顺这个流程 ；其次是 ，一个产品不仅 仅是一个产品网站或者一个A PP ，一个产品体系做下来 ，往往包括了好几块的设计 ：比如产品 本身、A PP、微信服务号 （微网页 ）、官方网站、运营后台 ，这是个联动的设计 ，一开始就要考虑 到所有客户端 ，我的要求是 ，你是这个产品的PM ，就要一路负责到底。 在这个过程中 ，有三点反思 ： 1、流程优化 一个需求设计从评审到定稿为什么走了整整两个月 ，期间反反复复进行了6次修改 ，最让人崩溃的是 ，最后定稿的那个版本基本上又回到了第一版的设计。这里面暴露了三个问题 ：一是需求不明确 ， 没有做好需求规划 ；二是自 的设计没想透彻 ，容易被左右 ；三是对于领导的变化无常 ，不要盲从 ，要有定策和技巧。 为什么一个月的开发量 ，三个月还没开发完 ？这里面又有三个问题 ：一是对开发计划的波动掌控不 及时 ，跟进不到位 ；二是由于前期需求设计的问题 ，造成了需求变更或补缺 ，三是整个