【无流程】是一个现实问题，或者说是一种趋势。请记住：在那之前，你还有团队、公司…

什么使得一款产品从0到1？

差别人而言，有纷歧样的理解和笃定。如是说来，兴致万分，十分有趣。人们通常是先相信某种东西，而后再去找证据来证实本身的不雅观点。

有人觉得，技术水平是一款产品的基础条件；

有人相信，资金能力是一款产品的须要前提；

有人坚持，沟通技巧是一款产品的实现助力；

有人认为，人是一款产品的核心要素；

很多人，很多认为…

显然，我是无法辩驳上诉的任何一条不雅观点的，难道说技术、资金、沟通、人对软件毫无裨益？然而，是否有维系全部产品要素的纽带存在？

我相信，必然是存在的而且为大多数人所知。做产品以来，一直有人问我，你觉得对产品而言，最重要的是什么？坦白讲，我的内心是抗拒的，产品自己就是一个复杂的综合体不但得益于源于一个复杂的过程，岂论如何回答都无法达到一个平衡。

一、定义产品流程

产品办理流程（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、回归迭代实现偏差：技术实施过程中，一定有些需求因为现实的局限性被耽搁或者简化实现，，那么上线后第一时间需要给出小幅优化的迭代完成之前研发阶段的历史遗留问题；反馈迭代：问题反馈通道建设对于一款新产品迭代优化初期显得尤为重要，对产品快速增量式迭代及改善用户体验的重要都是不成估量的；