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

什么使得一款产品从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、顶层设计

需求分析：沟通、理解

情境研究：需求调研的过程，包括：用户研究、调研，竞品分析等；

需求管理：项目管理技巧；

需求建模

功能建模

流程设计

原型设计：很多产品经理只对这个感兴趣，并且占据了TA们的大多数工作时间；

信息架构：信息架构（IA）是设计信息的组织结构；

视觉设计：UI协同完成；

项目追踪：产品实现进程的管控，确保产品的按时按量上线；

产品验收：不论理念还是业务逻辑设计上都是需要产品去把控的；