对于从0～1的产品设计，互联网上有很多资料将步骤讲解的很清晰，但对于没有实战过的同学，往往需要“死记硬背”才能记住冗长的产品设计环节。本文的核心是通过形象的比喻，带领大家通过迁移联想的形式，从战略、管理、业务、产品这4个维度了解0～1的产品设计流程。欢迎阅读。
对于B端产品经理而言，从0～1的产品设计考验一个人的规划能力、统筹能力与产品设计能力，与日常产品迭代的方法流程具备差异，如何进行从0～1的产品设计？我针对自身经验梳理总结，希望下面的文章能够对大家有一些思路方法上的帮助。
我们可以从战略层、管理层、业务层、产品层如此四个纬度来思考。
概述：战略层思考的核心，在于理解该项目的始发点以及远景规划。
可以从以下几个方面来进行项目理解：
概述：管理层可以理解为项目管理层，在于对于项目目标的OKR方法拆解，针对于项目目标，设立关键路径，并制定里程碑计划。
战术层是项目成功的关键，因为该层面进行如同一场战争的指挥部，达到指挥调度全场战争的作用。
概述：业务层指一线执行人员的阶层，他们是这场战争的实际执行人员，其中很大一部分角色也是我们的产品的真实用户，他们是与我们的产品功能设计息息相关的一群人。
对于此场景下的从0～1产品设计，业务层的人员是我们需求收集的来源，也是产品使用效果反馈的出口。但需要注意的是，我们以及不能仅根据业务层人员提出的需求进行产品设计，我们的判断要来自于战略、战术、战役三方面评估后的结果。
对于从0～1的产品设计，互联网上有很多资料将步骤讲解的很清晰，但对于没有实战过的同学，往往需要“死记硬背”才能记住冗长的产品设计环节。本文的核心是通过形象的比喻，带领同学们通过迁移联想的形式，理解从0～1的产品设计流程。
首先，我们通过现状-目标法，来理清楚我们的思路。
我将业务流程图分为以下几种：业务主流程、分支流程、逆向流程、兜底流程。各个流程定义如下：
（1）业务主流程：指业务的核心流程，该流程的稳定运行是项目盈利的关键。对于履约性业务，核心流程可能是订单履约流程；对于平台性业务，核心流程是供给端商品上架。
对于核心主流程，识别方法，我认为可以通过以下几点：
对于满足以上3点的流程，我们可以考虑将其定义为业务主流程
（2）分支流程：指除主流程外有对应合理的业务场景的正向流程。分支流程不可忽视，因为业务场景的多样性，代表了分支流程出现的概率。举个例子：大众用户针对一个支付产品，绑定银行卡后换绑几率很小，但这就意味着我们可以不为用户提供换绑功能了吗？有些流程存在的必要，不是为了用户时时刻刻能用，而是为了用户想用时，就能随时可用。
（3）逆向流程：指正向流程对应的反向流程。举个例子，用户按照正向流程操作产品时，难免有操作错误的步骤，这时产品提供操作撤回功能。在电商业务下，用户的售后流程对于购货来说，就属于一个逆向流程。
（4）兜底流程：指当其他流程出现异常时，对于核心场景，系统自动化的问题补救流程，举例：对于奖金设置系统，当用户针对某一个订单忘记设置履约奖励金额时，我们的系统可以通过定期巡检的形式，发送消息通知，提醒用户及时补充。
每一个业务流程，都需要系统能力的支持。在这部分，产品经理可以进行头脑风暴，将最全的产品模块列出，先不区分产品建设优先级，能想出多少就列出多少。
对于产品模块我们要达到以下几个标准：
为了达到“穷尽枚举，不重不漏”的标准，我们可以采用业务流程-系统能力对应发，来督导我们思考的严谨性。举个例子，下图中，将业务流程先画出，针对每一个环节节点以及环节关联，思考需要的系统能力，依次列出。
这样做有两个好处：
除此之外，系统模块梳理环节，我们还要追求合理解耦，即：
首先，我们拆解出的模块，可粗可细，但要保证在同一个层次，比如拆单、合单是在一个层次；司机管理、商品管理是在同一个层次；第二点，我们拆解出的模块，要合理合并；比如订拆单、合单合并在订单操作类；订单修改、订单删除合并在订单管理类。
刚才梳理出了很多的功能模块，下一步我们需要对功能模块进行归类整理，并组成产品架构，如下图。系统架构的画法没有严格标准，但是具备主旨思想：首先自下而上，应从底层到表层的逻辑表达；可以分为基础设施层、系统支持层、业务应用层、门户层。
在梳理完系统架构后，我们下一步是对系统进行版本分期，对于从0～1的产品，为了快速迭代进行可用性验证，企业会选择MVP的原则。采用MVP的原则好处是可以用最小的研发成本进行产品可行性验证，根据验证结果决定下一步功能走向以及资源投入，在节约成本的同时即时纠错，提升产品成功率。
产品规划的第一版本需要实现哪些功能，笔者认为可以从以下几个角度考虑：
针对于高优先级的功能，我们可以选择第一批版本迭代；针对于低优先级但是影响第一版产品功能的需求，我们可以先通过开发侧代码写死的方式临时支持，在后续版本迭代中，将其作为页面配置化。
下面一步，是将我们的产品规划输出成文档形式，以会议形式向业务方反讲。我们在同步结论的同时，也要讲述背后思考的逻辑，这一步是通过讲述给业务方，使其根据我们的逻辑推导判断是否有不符合业务实情的方面，让业务方作为我们的“军师”进一步的纠错。除此之外，各个版本的时间规划也需要向业务方讲清楚。在会议达成共识后，形成文字佐证，便于后续有反水时，留下论述依据。
最后，就是按照版本分期结果进行产品交付了，至此，我们讲一个系统的搭建拆分成了各类更细致的需求，产品经理可以按照日常需求自承接至交付的完整流程进行产品迭代，在此不再赘述。需要注意的是，在日常迭代中，我们难免会发现当初系统架构或版本规划不合理的地方；第一版的规划不可能是完美无缺的，我们可以根据实际情况灵活调整，达到日后兼容。
总结来看，从0～1的产品设计，与日常需求不同点在于，没有了系统架构，没有了模块规划，需要产品经理从头开始进行系统规划；但相同点在于，一旦系统规划确定后，后续产品交付的工作流是一致的。
产品经理的工作自始至终伴随着“分析”和“拆解”，无论是从0～1的产品规划，还是小的优化迭代，都是对问题的理解、分析、拆解、依次解决这些步骤，底层思维是一样的。或许有些工作是第一次经历，但背后的底层思维我们已经磨练了千遍万遍，不需要恐惧。
本文讲了从0～1进行系统设计的大致流程，但每个环节里的描述很粗略，日后会专门出专题详细讲解各环节的方法，欢迎大家持续关注。
本文由@Vicky 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。