【无流程】是一个现实问题，或者说是一种趋势。请记住：在那之前，你还有团队、公司…
是什么使得一款产品能够从0到1？对不同人而言，肯定有不一样的理解和笃定。如是说来，兴致万分，甚是有趣。
有人觉得，技术水平是一款产品的基础条件；
有人相信，资金能力是一款产品的必要前提；
有人坚持，沟通技巧是一款产品的实现助力；
有人认为，人是一款产品的核心要素；
很多人，很多认为…
显然，我是无法反驳上述的任何一个观点的，无法否认技术、资金、沟通、人对产品的成功落地都大有裨益。是否存在某种客观事物能够维系一切产品要素？
我相信，TA一定存在并且为大多数人熟知。接触产品以来，一直有人问反复问我一个相同的问题——对于一款产品而言，最最重要的一点是什么？每次听到这个问题，我的内心很诚实都表现得非常抗拒。产品/软件产品本身就是一个复杂地难以理解的综合体，因为其源于一个复杂的多人协作过程，不论从哪一个维度试图解读都无法穷其万一获得平衡。
产品管理流程（Product Design Process）简称PDP，我个人特别不喜欢使用【项目管理】这个词，平时工作中能不用就绝不提及，因为我觉得项目管理倾向于项目事务管理，过分强调时效，轮廓异常清晰。愚认为产品管理是项目管理的提升、迭代，其涉及范畴足以兼容项目管理的各方面，或者准确地讲是项目管理的更高形态表现，并且拥有项目管理所不具备的新特质、新定义。产品管理是一个有温度、有情感的价值导向过程，不是锱铢必较，不是蓄意推诿，更不是闭门造车…
1、瀑布模型
软件工程提倡采用线性的工作流方式，其中应用范围最广、最有名气的莫过于——瀑布模型（waterfall model ），被称为经典生命周期（classic life cycle）。
模型定义：经典瀑布模型提出的是一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过计划、建模、构建和部署的过程，最终提供一个完整的软件产品和提供持续的技术支持服务。
是不是有一种似曾相识的感觉？好像在哪见过？是的，瀑布模型是至今为，还被很多公司所遵循，暂且忽略其自身的固有弊端，该模型真的是经典之最，没有之一。鉴于现实的压迫和解决问题的需要，实际上很少有项目严格遵循计划的瀑布模型顺序，因此后期对该模型做了不少改变，比如V模型、增量模型、原型开发模型。目前一些比较前卫/先进的互联网公司，大部分采用了【增量过程模型】的持续交付，各公司依据公司的现状按需索取，细节上可能存在些许的差异，但整体的思想和目标是别无二致的。
2、SCRUM
现代软件又提出了一个用于开发和维持复杂产品的框架 ——SCRUM，是一个增量的、迭代的开发过程。SCRUM的五个价值观：
承诺 – 愿意对目标做出承诺
专注– 把你的心思和能力都用到你承诺的工作上去
开放– Scrum 把项目中的一切开放给每个人看
尊重– 每个人都有他独特的背景和经验
勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
如果你对SCRUM有所了解，其实就能知道SCRUM的两个重要观点：敏捷开发、XP编程，让其看起来更像是一个偏向于软件开发的概念。
我认为，事实上确实是如此的，将开发人员前置需求、过程化是一个很有先见的做法。
当然，现实终究是相对比较骨感的，对人员素质和团队结构的要求都近乎严苛，而现在公司的人员简直就是流水般顺滑，因而采用SCRUM的产品管理理念的团队知之甚少。
古语有云：不以规矩，不成方圆。如果说没有一个相对范式的产品流程，那么0到1的产品过程必然是不可言喻的，而其中的关系人更是苦不堪言、无意言表。或许这正是大多数产品死在路上的重要原因，大多数技术人员对产品人员印象很差的最初来源。
下述流程是一个经典的【瀑布模型+增量模型】的复合流程，其有两个关键要点：一是流程的线性，二是执行的交叉。之前我已经在《产品经理必修课之产品设计流程[完整版]》一文中做了详细说明，下面将概述关键要点，不再赘述：
1、顶层设计
需求分析：沟通、理解
情境研究：需求调研的过程，包括：用户研究、调研，竞品分析等；
需求管理：项目管理技巧；
2、概要设计
需求建模
功能建模
流程设计
原型设计：很多产品经理只对这个感兴趣，并且占据了TA们的大多数工作时间；
信息架构：信息架构（IA）是设计信息的组织结构；
视觉设计：UI协同完成；
3、技术追踪
4、回归迭代
实现偏差：技术实施过程中，必然有些需求因为现实的局限性被耽搁或者简化实现，那么上线后第一时间需要给出小幅优化的迭代完成之前研发阶段的历史遗留问题；
反馈迭代：问题反馈通道建设对于一款新产品迭代优化初期显得尤为重要，对产品快速增量式迭代及改善用户体验的重要都是不可估量的；
产品设计流程将整条产品线上的人员都串联起来，将产品过程“数据流”化，可谓气贯长虹、如梦般丝滑。产品流程将产品从各个原本独立的实施过程聚合成一个统一的变现行为。
这几年的产品经历，确实是属于自己的幸运——远胜于毕业之初进入BAT的机会，如果说没有最初的时光，我想可能不会有今天的这篇文章，而我也不知道自己在哪做着什么？甚至，也就少了一个产品经理与你们淌这趟“浑水”了…
最早接触产品那会，对系统性流程性的概念没有太多意识，只是停留在概念上的印象。更加清楚地说，关注节点因为自己就处在一个节点上，并且属于内部节点，还不是外部链条关键环节。该阶段关注的点，还不是宏观的流程和协作，搞好自己的一亩三分地，仅此而已。内部的衔接，上下游的通畅是照进实际产品工作的最大限度。
后期深入产品过程，逐步开始迫使我建立提点到线的产品过程，脑海中的概念越发的清晰可见。由于手头接触的产品工作，以及工作职责的增加，贯穿流程、跨部门的协作日益明显，不得不跳出眼前的局限，将目光投向其他貌似毫不相干的关联。规则约束彼此，推动事情的前进，如果没有彼此的契约精神，现实总是比你想象的难以承受，甚至直至崩溃…
如今逃离产品禁锢，开始意识到本没有什么一层不变的产品流程，一个似乎更加贴近大多数人的意识想法。而我有一点与TA们不太一样，不喜欢吐槽，喜欢做一些尝试直至些许改变。之前建立的线性和增量式过程管理遭遇的滑铁卢，新的环境显得格格不入破碎了一地。俯下身，拾掇起来，因为我深信有些是不会变的，只是打开的方式和顺序出了差错。
产品驱动的团队，产品的需求范围由产品经理敲定，而一个技术驱动的团队，产品的需求版本完全依据技术的资源/能力进行削减，既定的产品规则被肢解，很是无可奈何，任花落去。就这样认命呢？这可不是一个产品人该秉持的态度，拾起来…
无流程的尴尬并不是产品经理面对的问题，大部分团队/公司都经历着同样的煎熬，想要流程却又碍于现实，没有流程又只能走向OUT。既有的产品流程又无法满足团队的期待，那么该做些什么？于我个人而言，是经历过这样的尴尬和阵痛的，试探性的调整了产品管理流程，终究得出一个新的尝试：碎片化的产品流程。
名词解释：碎片化，Fragmentation；去中心化，Decentralization
碎片化的产品流程提出了两个关键的理念：碎片化、去中心化，也是个人这几点对产品的概念从建立到打碎到重新建立的过程。
关键点一：碎片化
产品设计的遵循一定的范式，比如：需求管理、需求文档、原型设计、UI设计等等，无论跨入一个怎样的团队，与怎样的同事协作，这些要素都是相对不可或缺的，是产品经理最基本的输出。
然而，各自的表达方式存在明显的差异，这样的差异体现在时间和空间之上。
举个栗子，产品需求文档（PRD）的输出形式存在多样的形式，有专业的文档、有直接原型标注、甚至有直接以交流代替文档的…
因而，所属的产品流程需要被打碎，在恰当的时间、恰当的方式重新组合，甚至会做一些自适应的调整和优化，这就是所谓的碎片化。
关键点二：去中心化
传统环境下，一个公司/组织都是围绕一定的信仰/中心去运转的，互联网类的公司也无法幸免。大致分业务驱动、运营驱动、产品驱动、技术驱动，各种公司格局都是由公司所处的成长阶段决定的，而不同的格局也注定公司走向何方和做多远。
上述的经典的产品流程可以认为是产品驱动的格局下的顺序流程，很明显产品处于一个中心的位置，一切都围绕产品展开。
对于一个产品经理而言，这样的格局不可能一层不变，升职、跳槽都面临着角色的转变，因而打破中心化的概念，尝试多中心的理念，将不同产品碎片置于不同的场景之下，相信你会有不一样的收获。
行文小结
说到这里，我还是想问一句：为什么需要产品流程？难道说没有产品流程就不行吗？世事洞明皆学问，人情练达即文章。的确是客观存在无流程的团队获得成功的，可大多数人看到的只是成功荣耀而没有留意背后的夯实基础——产品管理流程。
产品流程（PDP）是一个人为制定的规则集合。规则之中蕴含人性的主观因素，因而并不能要求人们盲目地遵循，而是对过程的督促，而不至于达成目标的成本难以承受，可惜了过去、遗憾了未来。流程的存在就是为了解决问题，而流程本身就是最好的解决方案。
虽然流程不一定就能缔造成功的产品，但所有的优秀产品一定都源于流程（积极），要想拥有流程，首先要学会思考、付诸实践，然后尝试改变4P。人（People）、产品（Product）、过程（Process）、项目（Project）四要点构成流程的支撑，而人是流程的关键。
如果说…
或许正如所遇见的那样，【无流程】是一个现实问题，或者是一种趋势。请记住：在那之前，你还有团队、公司…
