实现偏差：技术实施过程中，必然有些需求因为现实的局限性被耽搁或者简化实现，那么上线后第一时间需要给出小幅优化的迭代完成之前研发阶段的历史遗留问题；

反馈迭代：问题反馈通道建设对于一款新产品迭代优化初期显得尤为重要，对产品快速增量式迭代及改善用户体验的重要都是不可估量的；

产品设计流程将整条产品线上的人员都串联起来，将产品过程“数据流”化，可谓气贯长虹、如梦般丝滑。产品流程将产品从各个原本独立的实施过程聚合成一个统一的变现行为。

三、反思产品流程

这几年的产品经历，确实是属于自己的幸运——远胜于毕业之初进入BAT的机会，如果说没有最初的时光，我想可能不会有今天的这篇文章，而我也不知道自己在哪做着什么？甚至，也就少了一个产品经理与你们淌这趟“浑水”了…

最早接触产品那会，对系统性流程性的概念没有太多意识，只是停留在概念上的印象。更加清楚地说，关注节点因为自己就处在一个节点上，并且属于内部节点，还不是外部链条关键环节。该阶段关注的点，还不是宏观的流程和协作，搞好自己的一亩三分地，开奖，仅此而已。内部的衔接，上下游的通畅是照进实际产品工作的最大限度。

后期深入产品过程，逐步开始迫使我建立提点到线的产品过程，脑海中的概念越发的清晰可见。由于手头接触的产品工作，以及工作职责的增加，贯穿流程、跨部门的协作日益明显，不得不跳出眼前的局限，将目光投向其他貌似毫不相干的关联。规则约束彼此，推动事情的前进，如果没有彼此的契约精神，现实总是比你想象的难以承受，甚至直至崩溃…

如今逃离产品禁锢，开始意识到本没有什么一层不变的产品流程，一个似乎更加贴近大多数人的意识想法。而我有一点与TA们不太一样，不喜欢吐槽，喜欢做一些尝试直至些许改变。之前建立的线性和增量式过程管理遭遇的滑铁卢，新的环境显得格格不入破碎了一地。俯下身，拾掇起来，因为我深信有些是不会变的，只是打开的方式和顺序出了差错。

产品驱动的团队，产品的需求范围由产品经理敲定，而一个技术驱动的团队，产品的需求版本完全依据技术的资源/能力进行削减，既定的产品规则被肢解，很是无可奈何，任花落去。就这样认命呢？这可不是一个产品人该秉持的态度，拾起来…

无流程的尴尬并不是产品经理面对的问题，大部分团队/公司都经历着同样的煎熬，想要流程却又碍于现实，atv直播，没有流程又只能走向OUT。既有的产品流程又无法满足团队的期待，那么该做些什么？于我个人而言，是经历过这样的尴尬和阵痛的，试探性的调整了产品管理流程，终究得出一个新的尝试：碎片化的产品流程。

名词解释：碎片化，Fragmentation；去中心化，Decentralization

碎片化的产品流程提出了两个关键的理念：碎片化、去中心化，也是个人这几点对产品的概念从建立到打碎到重新建立的过程。

关键点一：碎片化

产品设计的遵循一定的范式，比如：需求管理、需求文档、原型设计、UI设计等等，无论跨入一个怎样的团队，与怎样的同事协作，这些要素都是相对不可或缺的，是产品经理最基本的输出。

然而，各自的表达方式存在明显的差异，这样的差异体现在时间和空间之上。

举个栗子，产品需求文档（PRD）的输出形式存在多样的形式，有专业的文档、有直接原型标注、甚至有直接以交流代替文档的…

因而，所属的产品流程需要被打碎，在恰当的时间、恰当的方式重新组合，甚至会做一些自适应的调整和优化，这就是所谓的碎片化。

关键点二：去中心化

传统环境下，一个公司/组织都是围绕一定的信仰/中心去运转的，互联网类的公司也无法幸免。大致分业务驱动、运营驱动、产品驱动、技术驱动，各种公司格局都是由公司所处的成长阶段决定的，而不同的格局也注定公司走向何方和做多远。

上述的经典的产品流程可以认为是产品驱动的格局下的顺序流程，很明显产品处于一个中心的位置，一切都围绕产品展开。