从战略、管理、业务、产品这4个维度,思考从0到1的产品设计

5 评论 5627 浏览 67 收藏 13 分钟

对于从0~1的产品设计,互联网上有很多资料将步骤讲解的很清晰,但对于没有实战过的同学,往往需要“死记硬背”才能记住冗长的产品设计环节。本文的核心是通过形象的比喻,带领大家通过迁移联想的形式,从战略、管理、业务、产品这4个维度了解0~1的产品设计流程。欢迎阅读。

引言

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

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

01 战略层

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

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

  • 这个项目为什么启动?是利润需要/风控需要/战略需要?
  • 这个项目为什么现在启动?
  • 这个项目关键目标是什么?公司要求的时间周期是什么?
  • 这个项目公司配备了什么资源?这些资源范围上充足还是遗漏?资源规模上充沛还是欠缺?

02 管理层(战术层)

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

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

03 业务层(战役层)

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

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

04 产品层(产品设计能力的体现)

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

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

  • 现状:没有一套支持新项目的系统,新项目无法运转。
  • 目标:搭建一套能支持新项目运转的系统,系统要在最小成本的基础上满足核心功能完整性。

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

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

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

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

  1. 该流程若流畅运行,是否对项目的北极星指标有贡献?
  2. 该流程若出现异常,项目的北极星指标是否一定无法达成?
  3. 该流程若不存在,其他流程是否没有存在的必要?

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

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

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

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

Step2:针对业务流程,梳理系统模块

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

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

  1. 尽枚举,不重不漏
  2. 合理耦合

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

这样做有两个好处:

  • 好处1:能让我们的输出的功能模块有严格的业务流程对应关系,对于日后功能模块优先级的取舍有可以追溯判断依据;
  • 好处2:刚才我们已经判断了各个业务流程的优先级,一般与业务主流程对应的系统能力往往更加重要,要优先建设;这对于我们后续版本规划也提供了参考思路。

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

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

Step3:根据功能模块,梳理产品架构

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

Step4:版本分期

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

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

  1. 产品主流程上涉及哪些功能?这些功能中优先级排列是怎样的?
  2. 除了主流程功能外,分支流程上涉及哪些功能?这些功能优先级排列是怎样的?

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

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

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

Step6:针对版本分期结果,依次产品交付

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

05 结语

总结来看,从0~1的产品设计,与日常需求不同点在于,没有了系统架构,没有了模块规划,需要产品经理从头开始进行系统规划;但相同点在于,一旦系统规划确定后,后续产品交付的工作流是一致的。

产品经理的工作自始至终伴随着“分析”和“拆解”,无论是从0~1的产品规划,还是小的优化迭代,都是对问题的理解、分析、拆解、依次解决这些步骤,底层思维是一样的。或许有些工作是第一次经历,但背后的底层思维我们已经磨练了千遍万遍,不需要恐惧。

本文讲了从0~1进行系统设计的大致流程,但每个环节里的描述很粗略,日后会专门出专题详细讲解各环节的方法,欢迎大家持续关注。

本文由@Vicky 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 讲得不错

    来自天津 回复
  2. 通俗易通,能和日常工作对应起来。c端也差不多这样

    来自北京 回复
    1. 比心😊

      来自北京 回复
  3. 讲的好棒呀,通俗易懂。感谢~

    来自上海 回复
    1. 加油💗

      来自北京 回复