引言

对于B端产品经理而言，从0～1的产品设计考验一个人的规划能力、统筹能力与产品设计能力，与日常产品迭代的方法流程具备差异，如何进行从0～1的产品设计？我针对自身经验梳理总结，希望下面的文章能够对大家有一些思路方法上的帮助。

我们可以从战略层、管理层、业务层、产品层如此四个纬度来思考。

01 战略层

概述：战略层思考的核心，在于理解该项目的始发点以及远景规划。

可以从以下几个方面来进行项目理解：

这个项目为什么启动？是利润需要/风控需要/战略需要？

这个项目为什么现在启动？

这个项目关键目标是什么？公司要求的时间周期是什么？

这个项目公司配备了什么资源？这些资源范围上充足还是遗漏？资源规模上充沛还是欠缺？

02 管理层（战术层）

概述：管理层可以理解为项目管理层，在于对于项目目标的OKR方法拆解，针对于项目目标，设立关键路径，并制定里程碑计划。

战术层是项目成功的关键，因为该层面进行如同一场战争的指挥部，达到指挥调度全场战争的作用。

03 业务层（战役层）

概述：业务层指一线执行人员的阶层，他们是这场战争的实际执行人员，其中很大一部分角色也是我们的产品的真实用户，他们是与我们的产品功能设计息息相关的一群人。

对于此场景下的从0～1产品设计，业务层的人员是我们需求收集的来源，也是产品使用效果反馈的出口。但需要注意的是，我们以及不能仅根据业务层人员提出的需求进行产品设计，我们的判断要来自于战略、战术、战役三方面评估后的结果。

04 产品层（产品设计能力的体现）

对于从0～1的产品设计，互联网上有很多资料将步骤讲解的很清晰，但对于没有实战过的同学，往往需要“死记硬背”才能记住冗长的产品设计环节。本文的核心是通过形象的比喻，带领同学们通过迁移联想的形式，理解从0～1的产品设计流程。

首先，我们通过现状-目标法，来理清楚我们的思路。

现状：没有一套支持新项目的系统，新项目无法运转。

目标：搭建一套能支持新项目运转的系统，系统要在最小成本的基础上满足核心功能完整性。

Step1：我们需要调研业务，了解业务涉及的各个角色，以及业务流程图。

我将业务流程图分为以下几种：业务主流程、分支流程、逆向流程、兜底流程。各个流程定义如下：

（1）业务主流程：指业务的核心流程，该流程的稳定运行是项目盈利的关键。对于履约性业务，核心流程可能是订单履约流程；对于平台性业务，核心流程是供给端商品上架。

对于核心主流程，识别方法，我认为可以通过以下几点：

该流程若流畅运行，是否对项目的北极星指标有贡献？

该流程若出现异常，项目的北极星指标是否一定无法达成？

该流程若不存在，其他流程是否没有存在的必要？

对于满足以上3点的流程，我们可以考虑将其定义为业务主流程

（2）分支流程：指除主流程外有对应合理的业务场景的正向流程。分支流程不可忽视，因为业务场景的多样性，代表了分支流程出现的概率。举个例子：大众用户针对一个支付产品，绑定银行卡后换绑几率很小，但这就意味着我们可以不为用户提供换绑功能了吗？有些流程存在的必要，不是为了用户时时刻刻能用，而是为了用户想用时，就能随时可用。

（3）逆向流程：指正向流程对应的反向流程。举个例子，用户按照正向流程操作产品时，难免有操作错误的步骤，这时产品提供操作撤回功能。在电商业务下，用户的售后流程对于购货来说，就属于一个逆向流程。

（4）兜底流程：指当其他流程出现异常时，对于核心场景，系统自动化的问题补救流程，举例：对于奖金设置系统，当用户针对某一个订单忘记设置履约奖励金额时，我们的系统可以通过定期巡检的形式，发送消息通知，提醒用户及时补充。

Step2：针对业务流程，梳理系统模块

每一个业务流程，都需要系统能力的支持。在这部分，产品经理可以进行头脑风暴，将最全的产品模块列出，先不区分产品建设优先级，能想出多少就列出多少。

对于产品模块我们要达到以下几个标准：

为了达到“穷尽枚举，不重不漏”的标准，我们可以采用业务流程-系统能力对应发，来督导我们思考的严谨性。举个例子，下图中，将业务流程先画出，针对每一个环节节点以及环节关联，思考需要的系统能力，依次列出。

这样做有两个好处：

好处1：能让我们的输出的功能模块有严格的业务流程对应关系，对于日后功能模块优先级的取舍有可以追溯判断依据；

好处2：刚才我们已经判断了各个业务流程的优先级，一般与业务主流程对应的系统能力往往更加重要，要优先建设；这对于我们后续版本规划也提供了参考思路。

除此之外，系统模块梳理环节，我们还要追求合理解耦，即：

首先，我们拆解出的模块，可粗可细，但要保证在同一个层次，比如拆单、合单是在一个层次；司机管理、商品管理是在同一个层次；第二点，我们拆解出的模块，要合理合并；比如订拆单、合单合并在订单操作类；订单修改、订单删除合并在订单管理类。

Step3：根据功能模块，梳理产品架构

刚才梳理出了很多的功能模块，下一步我们需要对功能模块进行归类整理，并组成产品架构，如下图。系统架构的画法没有严格标准，但是具备主旨思想：首先自下而上，应从底层到表层的逻辑表达；可以分为基础设施层、系统支持层、业务应用层、门户层。

Step4：版本分期

在梳理完系统架构后，我们下一步是对系统进行版本分期，对于从0～1的产品，为了快速迭代进行可用性验证，企业会选择MVP的原则。采用MVP的原则好处是可以用最小的研发成本进行产品可行性验证，根据验证结果决定下一步功能走向以及资源投入，在节约成本的同时即时纠错，提升产品成功率。

产品规划的第一版本需要实现哪些功能，笔者认为可以从以下几个角度考虑：

产品主流程上涉及哪些功能？这些功能中优先级排列是怎样的？

除了主流程功能外，分支流程上涉及哪些功能？这些功能优先级排列是怎样的？

针对于高优先级的功能，我们可以选择第一批版本迭代；针对于低优先级但是影响第一版产品功能的需求，我们可以先通过开发侧代码写死的方式临时支持，在后续版本迭代中，将其作为页面配置化。

Step5：输出产品规划文档，与业务方达成一致

下面一步，是将我们的产品规划输出成文档形式，以会议形式向业务方反讲。我们在同步结论的同时，也要讲述背后思考的逻辑，这一步是通过讲述给业务方，使其根据我们的逻辑推导判断是否有不符合业务实情的方面，让业务方作为我们的“军师”进一步的纠错。除此之外，各个版本的时间规划也需要向业务方讲清楚。在会议达成共识后，形成文字佐证，便于后续有反水时，留下论述依据。

Step6：针对版本分期结果，依次产品交付

最后，就是按照版本分期结果进行产品交付了，至此，我们讲一个系统的搭建拆分成了各类更细致的需求，产品经理可以按照日常需求自承接至交付的完整流程进行产品迭代，在此不再赘述。需要注意的是，在日常迭代中，我们难免会发现当初系统架构或版本规划不合理的地方；第一版的规划不可能是完美无缺的，我们可以根据实际情况灵活调整，达到日后兼容。