聊聊B端产品规划
编辑导语:B端产品是为企业业务服务的,其规划本身必须以企业业务为根本进行,有从上到下规划和从下到上规划两种模式。B端产品规划具体要怎么做呢?本文作者分享了他对B端产品规划的想法,一起来看看吧。
笔者回顾近三年的产品之路,关于B端产品的产品规划有所想法,为此想与各位产品同路人一起分享交流。
一、整体思路
大型B端产品的整体规划呈现的特点是支持业务范围越来越广、业务趋势越来越智能高效,都是以企业自身业务为核心横向、纵向发展,其大体思路如下:
- 横向规划思路: 关键系统内部流程/模块→次要系统内部流程或类似模块→整合企业内部资源→整合企业内外资源
- 纵向规划思路: 支持基础业务→计划业务→预测指导业务→自动化业务(不一定有此阶段)
在实际操作中横向和纵向发展思路是相结合的,并不一定会按照顺序规划,实际发展道路以企业自身情况为准。
二、规划方法
B端产品的整体规划并不是空穴来风,B端产品是为企业业务服务的,所以其规划本身必须以企业业务为根本进行,以笔者本身的工作经验而言,有从上到下规划和从下到上规划两种模式。
从上到下产品实际发起方是企业高层,而从下到上一般是业务部门提出的产品的规划特征,但都基本可以按照以下方式进行产品规划:
- 从业务需求出发
- 结合企业战略发展方向或项目定位
- 挖掘业务趋势
从上到下产品实际发起方是企业高层,而从下到上一般是业务部门提出的产品的规划特征。
1. 从业务需求出发
根据业务部门和实际使用的用户对象出发,找核心业务流程,锁定主要的用户角色,整理涉及到的业务单据,关键在于梳理业务优先级。
就笔者实际工作而言,一般是业务部门主动找到产研团队,提出现阶段的实际业务需求,这种情况下非常容易就能够收集到业务需求、梳理整体业务流程。以下情况需要产品经理考虑:
- 分辨业务流程是否固定,是否是该业务部门的本职业务,还是属于在短时间内由于分工不明确,业务部门强势导致的该业务为此部门负责。
- 企业内有没有其他与该业务部门有类似业务需求的部门
- 该业务与其他业务之间关系,是否涉及到企业内其他业务系统
第一点实际上是项目风险问题,如果风险较大实际上问题核心是该业务部门业务越权,并不是该业务以后真实的负责部门,所以建议不要做这个业。如果实在没办法需要做也不用谈产品规划,就尽可能简单的满足现有业务的要求即可。
第二点关注的是业务的共性与特性,如果说企业内部有相似业务需求的部门,综合一起进行需求调研看能否为他们一同提供业务支持;如果正好各自业务目标和流程共性很高,比如负责各个企业子品牌的运营团队,联合考虑整体需求,构架大型的企业中后台;如果说虽然大体上是同一个业务但特性差异大,比如线上商城销售和线下门店零售,则不要强求,分开考虑即可。
第三点考量的是以业务为基础的系统与周围系统之间的关系,有两种规划思路:
- 先独立完成内部业务再考虑与其他业务系统对接
- 从一开始就制定与其他业务系统对接再逐渐深化内部业务
采用哪种方式主要考虑项目时间、对接难度、对接系统情况,如果说需要对接的业务系统本身是一个相对而言比较稳定、有多功能接口的业务系统,则提前考虑对接;如果说需要对接的业务系统是一个容易变动、需要跨部门对接,在笔者的实际经验来说,一般选择先独立完成内部业务,同时制定好基础的数据格式方便后续对接。
2. 结合企业战略发展方向或项目定位
如果能够结合企业战略,一般这种B端产品其构建意志来源于企业高层,会是企业高层战略的支撑系统或系统之一,是从上到下的思路指导,会有一个相对明确的项目或产品定位。
这个时候根据企业战略,拆分阶段性目标,结合阶段性目标去制定产品战略。基础思路就是拆分目标成可执行的业务、模块,先核心后辅助、先支持现阶段后业务优化,规划整体的业务、模块设计路线,然后再由下至上从业务需求、用户需求出发,进行详细业务设计。
3. 挖掘业务趋势
业务趋势关键在于抓业务的发展方向,可以参考市场上的产品,但重点还是放在企业本身。在笔者实际经验中,总结了以下方法:
1)点线面构建
很多时候业务人员提出的业务需求,实际上只是他所负责的业务线上的一个点,而产品需要去挖掘整体的业务线,最终覆盖该业务部门或业务方向。
2)类似功能扩展
针对于营销平台这类型的系统而言,内部会有多款工具,其大致目标一致,去丰富达成目标的手段,可以作为前期产品规划的参考。
3)数据策略趋势
当产品执行一段时间后,将会获得比较多的数据,去规划如何利用这些数据,可以作为产品中长期的规划。
笔者在此提供一些思路:数据可以用于数据分析、数据预测、风险预防,还可以和策略结合,进行业务自动化。数据预测可以提供成本、收益、风险的指导意见,帮助管理人员进行相关的决策。
而策略驱动则是在具体的业务执行方面,能够减少人力提高效率,合理的策略能够放大收益。
4)企业内外资源结合
首先要明确不同的系统与企业外部资源的接触程度不一样,对于企业外部资源管理的需求程度不一样,不一定都要考虑企业外部资源。
其次如果需要考虑企业外部资源,其规划路线主要就是先考虑该业务主要的外部资源是什么,比如国内做CRM系统的企业,当要做SCRM的时候,优先考虑的都是微信生态一样,都是秉承先抓主力后抓核心。
三、规划实操
1. 以企业战略为核心:从上到下的产品规划
笔者本人负责过所在企业的新零售系统,是企业未来3年战略计划的主要支撑系统之一,企业未来3年的战略是企业营销数字化改革。
我司企业营销数字化改革分为三步:主营业务数字化→企业营销数字化,构建一体的品牌营销中心→销售驱动供应链改革。
新零售系统在企业战略中承担的责任是实现企业线下销售渠道数字化,因为我司线下销售合作模式仅采用直营模式,所以新零售系统的整体平台的主要使用对象是线下销售公司、经销商、门店和总部,不考虑与其他外部线下销售系统对接的情况。
在企业未来三年的战略规划下,在明确用户对象后,首先用户对象和业务进行了调研,知晓现阶段线下渠道主要的业务有:
- 销售
- 库存
- 财务
- 售后
其中销售、库存、财务(财务模块单独成立了一个大的项目组,并不在新零售系统之内)都没有相关系统,而售后则有已有成熟系统。再结合企业战略计划所以制定了如下的产品大版本规划:
- 新零售V1.0实现经销商、门店、销售公司业务信息化
- 新零售V2.0构建线下渠道运营中心,改造门店人货场
- 新零售V3.0销售末端与企业品牌供应链结合,改造企业供应链
这三个版本规划依据完全是按照企业战略去制定的,在这个基础上再结合实际业务情况去调整。然后根据大版本的规划再继续进行拆分,以新零售V1.0为例,其产品规划如下:
- 新零售V1.0销售业务信息化: 完成线下业务最小mvp:构建零售工作台,完成线下交易管理、订单管理、商品管理、退货管理模块
- 新零售V1.1仓库业务信息化: 构建进销存系统,完成库存管理、仓库管理、出库入库盘库管理模块;零售工作台添加库存查询
- 新零售V1.2基础组织业务管理: 构建终端管理后台,完成组织管理、权限管理、岗位管理、人员管理;零售工作台添加人员管理、账号管理;进销存系统添加人员管理
- 新零售V1.3完善管理后台 :终端管理后台增加订单管理、基础信息维护、库存管理、销售绩效管理(含销售任务设置)客户管理;零售工作台添加客户管理、销售绩效管理(含销售任务设置)
其主要思路是由业务到模块、由核心到次要、由先满足基础业务到更高层次的计划业务,例如在新零售V1.3中的销售任务设置实际上就是体现了对销售业务的计划,当然这个计划业务还只是最浅层的计划,如果后续系统能够根据销售人员的销售能力、历史数据、市场情况,后续给出销售绩效设置建议的话,则就到了预测指导业务的阶段。
2. 以业务需求为核心:从下到上的产品规划
笔者曾负责过所在企业的品牌营销中心,此项目就是典型的从下到上的产品规划模式。
一开始先是收到各个业务部门非常具体的业务需求,比如发短信、领红包、发问卷……当时就是根据业务部门的需求一个一个做系统,后续发现这些找我们科室的部门主要都是与营销有关的业务部门,所以我们提出不如构建一个统一的营销中心平台,用来满足大部分的营销任务。
以此,对相关的业务部门进行了调研,他们以往向我们科室提出的业务需求实际上仅仅只是其真实业务的一个环节,只是营销方式。之后我们对其业务进行了梳理,并对市场上的相关平台进行调研参考,然后制定了如下的产品规划:
- 用户数字化运营平台V1.0: 丰富运营手段
- 用户数字化运营平台V2.0: 数据驱动运营
在第一个大版本中,主要去挖掘更多的运营工具,构建基本的平台管理模块,当时小版本的产品规划就是规划的每一个产品工具的开发顺序和重构以前产品工具的顺序,再加上。
而在第二个大版本中,则是规划了4大模块:
- 运营模块
- 用户数据模块
- 市场行情模块
- 系统管理模块
第一个大版本中的模块,再到第二个大版本中都划分到了运营模块和系统管理模块中,笔者当时主要负责运营模块,其规划思路是:
- 继续丰富运营工具
- 以运营任务的角度对运营活动进行管理
- 从整体业务线考虑,从规划→执行→收集→分析→指导规划
- 关注数据流向
最后,无论是哪一种方式,B端产品都必须秉承着以企业实际业务为核心去进行整体的产品规划。
本文由 @遥遥爱唠叨 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。