【头脑风暴】产品流程图

很久以前的博客，回归到官方博客来，欢迎大家拍砖

我的感觉：

作为天天和数据打交道的数据仓库工程师，接触数据多了，接触数据产品多了，多少对产品有了自己的小小体会，看到这个流程图挺有感触的。(自我感觉有产品经理的潜力，不是自恋，是要有自信：))

一个产品是需要有个“点”的，正是这个“点”迸发出一个产品的idea，而能找到这个“点”是需要功力的，暂且不说功力(因为我还没达到这个功力)，就从idea说起，一个产品最终不管成功与否，它总会落地，所以它必定要起步，起步于idea，接着就是要求证idea的价值，这个价值就是用户的需求，用户是否迫切需要这个产品，这个产品是否能给用户带来些什么。。。这个过程应该就是需求调研，调研的直接目的当然就是找到满足用户需求的核心产品功能，这两个步骤对互联网产品而言不应该是个串行的过程(可以参考david的3+1)，应该有点螺旋迭代的效果，对互联网产品，不要期许从一开始就要找到产品的全部需求，更重要的是找到idea，确定1,2个功能点就可以开始，接下来就是完善功能，补充功能，挑战在此，成就亦在此。

我是做数据的，可能对数据比较敏感，一个产品的效果监控我会有自然的第一反应，我想需要给一个产品留一个可监控的口子，以便我去审视我的产品是否达到了功能效果，在运营过程中产品是否有没有考虑到的使用情况，所以自我感觉产品的附带需求是需要有个监控产品运营情况是否良好，监控产品缺陷的后台系统。很多互联网公司目前开始重视DW，想必也是基于此吧，我们是要通过数据去发现点什么的。。。

至于帮助文档，数据产品是必须要有的，一些指标的场景说明、定义描述必须交代清楚，我们要把用数据产品的人当成一个数据白痴来对待，帮助文档就是领他进门的，这就涉及到产品易用性的问题。

在想好自己产品有哪些东西后，就要开始把这些还是比较概念性的东西具体化、明细化，这时候就到了开始着手写产品需求文档。罗马城不是一天建成的，需求文档也不要奢望一次就成功，做产品要严谨，在需求阶段要把能想到的最好想得越细越好，考虑长远点总没错的。

接下来开发团队开始担当主力，设计、开发、测试、预发布、用户体验、正式发布，哪一环都少不了，哪一环产品经理都要多多少少跟进，这时候千万不要觉得自己不懂技术就不必参与其中，别忘了这些一线的兄弟们都是为你做产品。

千呼万唤始出来，产品总算上线，这时候才是真正开始的时候，因为这时候是用户第一次接触你产品的时候，效果跟踪就显得特别重要，检验产品功能点是否满足用户需求，用户在使用过程中又出现哪些当时设计产品时没有遇见到的情况，这些都要作为产品迭代的重要依据，毕竟这是产品使用情况的第一手资料。

想得比较粗，说得比较空，作为自己的感受，也希望能成为讨论产品流程的引子，一起探讨。

你的感觉是。。。