从战略管理业务产品这4个维度,思考

2023/11/26 来源:不详

对于从0~1的产品设计,互联网上有很多资料将步骤讲解的很清晰,但对于没有实战过的同学,往往需要“死记硬背”才能记住冗长的产品设计环节。本文的核心是通过形象的比喻,带领大家通过迁移联想的形式,从战略、管理、业务、产品这4个维度了解0~1的产品设计流程。欢迎阅读。引言对于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:针对版本分期结果,依次产品交付最后,就是按照版本分期结果进行产品交付了,至此,我们讲一个系统的搭建拆分成了各类更细致的需求,产品经理可以按照日常需求自承接至交付的完整流程进行产品迭代,在此不再赘述。需要注意的是,在日常迭代中,我们难免会发现当初系统架构或版本规划不合理的地方;第一版的规划不可能是完美无缺的,我们可以根据实际情况灵活调整,达到日后兼容。05结语总结来看,从0~1的产品设计,与日常需求不同点在于,没有了系统架构,没有了模块规划,需要产品经理从头开始进行系统规划;但相同点在于,一旦系统规划确定后,后续产品交付的工作流是一致的。产品经理的工作自始至终伴随着“分析”和“拆解”,无论是从0~1的产品规划,还是小的优化迭代,都是对问题的理解、分析、拆解、依次解决这些步骤,底层思维是一样的。或许有些工作是第一次经历,但背后的底层思维我们已经磨练了千遍万遍,不需要恐惧。本文讲了从0~1进行系统设计的大致流程,但每个环节里的描述很粗略,日后会专门出专题详细讲解各环节的方法,欢迎大家持续

转载请注明:
http://www.3g-city.net/gjyyf/5372.html
  • 上一篇文章:

  • 下一篇文章:
  • 网站首页 版权信息 发布优势 合作伙伴 隐私保护 服务条款 网站地图 网站简介

    温馨提示:本站信息不能作为诊断和医疗依据
    版权所有2014-2024
    苏ICP备17026855号-2

    今天是: