01 什么是产品规划?
一句话说明:产品规划即基于行业发展趋势、企业业务发展阶段,做信息系统发展路径的规划,为将来的版本规划提供大方向的参考。(PS:本文仅针对企业自研的B端信息系统)
02 为什么要做产品规划?
在项目立项、产品设计前,需要先做产品规划的原因,可以从以下三个方面去思考:
1)自顶层向下设计,避免盲人摸象
在介入一个新的项目或者从0-1的建设一个系统的时候,第一件事情肯定不是思考功能清单与产品原型。而是从顶层的产品架构思考,先建立起业务全链路和信息系统的全局观,设想系统的全貌,再从上至下拆解,思考具体的设计方案。
就好比新小区的建设,开发商拿到建设许可证之后,首要从整体考虑小区的住宅建筑规划、公用面积规划、公共设施规划、商业规划、内部路网结构规划等,然后才是建筑的结构设计、层高设计等。如果一上来就对住宅的层高、结构、样式进行设计,缺乏统筹、陷入细节,难免在对其他用地规划的时候产生冲突与遗漏,满头是包。
2)了解业务全局和重点,合理安排研发资源
要做一份符合企业发展的产品规划,前提是要对业务十分熟悉,包括业务流程中的组织架构、职能职责、关键业务节点、信息系统支持范围。当然,在做产品规划的过程中,也推动着我们进一步加深对业务的理解,这两者是相辅相成的关系。
当对业务的全局和重点有了深刻的理解之后,接下来的信息系统的落地实施,在大方向上就能明白研发资源应该重点铺设在哪些关键环节。
特别是在管理产品团队的时候,产品规划可以帮助团队快速理解系统建设的范围,未来发展的方向,在方案设计的时候提前考虑到功能的复用和解耦。
3)避免重复造轮子,浪费研发资源
重复造轮子,主要是指非从0-1 的产品。在接手新的项目的时候,梳理已有产品的架构是非常必要的,可以了解已有的功能模块,避免重复开发,浪费研发资源。推演产品规划的过程,就是一个很好的去除冗余、查漏补缺的方式。
比如笔者之前在设计内部数据安全风控的时候,监控到的风险行为需要推送站内信,告知对应的管理人员跟进、处理。在先前的产品规划过程中,发现已有消息通知中心,所以此次消息通知,只需增加对应的消息通知类型、通知对象、通知内容即可,无需重复开发站内信功能。
03 产品规划怎么做?
前文讲了不少产品规划的原因,无非是想提醒大家,不要忽视这一项工作,磨刀不误砍柴工。那么产品规划,具体应该怎么做呢?
笔者将根据自己的经验和思考,从2个维度去描述,如有遗漏或偏误,欢迎更正、补充~
从需求方看:了解企业战略、定位、所处市场阶段,定重点业务范围
在做产品的规划时,要纵观行业发展历史和发展趋势,这样对业务的未来方向有一个参考的基准线。
拿笔者公司的私域电商模式来说,我们通过广告投放获客,以公众号、个人微信、小程序等作为承接用户的日常运营,通过私域直播、朋友圈营销等方式促成用户成交。
私域电商是一个比较新的行业,在新冠疫情的大社会环境下渗透开来,逐渐发展成为了号称有着千亿规模的赛道。但是私域电商,也是从传统电商演变而来,是在公域流量红利消失后,商家转战到私域流量的大背景下诞生的,业务环节中,和传统电商有着相通之处。这些共性抽离出来,就是我们做产品规划的基准线。
例如,我们私域电商的业务模式也是线上交易,交易的核心线同传统电商一致,包括:商品、订单、支付、库存、用户、促销、物流的管理,这是做电商都避不开的信息系统能力。
那是不是传统电商有的这些能力,我们都需要满足呢?第一步的规划,我们通过对行业的分析,有了大致的了解,起码知道了要支撑业务的高速运转,成熟的信息系统是什么样子的。
接下来,我们要做两件事情,结合实际的业务情况,进一步细化我们的规划。
1)看眼前:定义业务发展所处阶段,挖掘资源投入重心
笔者公司的私域电商在女装行业属于开始比较早的,也属于细分类目下的头部玩家(相当低调)。但是在疫情持续、消费环境低迷,竞争对手日益增多,商业规模化进入瓶颈的情况下,业务在一定程度下出现了下滑。在这种情况下,公司决定将老用户的复购作为核心指标之一:把提升品牌形象,服务优质用户,提升用户的复购频次和客单价作为公司的维稳战略。
为了支撑这一战略,产品重心就要围绕用户做规划。例如:补全客户资料的完善/分析、用户画像的深度分析、用户标签建设、用户分层/精细化运营策略推广、流失用户的分析/召回策略推广,这些会是接下来一段时间的工作重点。
2)看内部:了解管理层对信息系统的期望,达成一致意见
toC 不同于toB,需求的提出者和实际的使用者,可能并不是相同的人。对于toB的信息系统,管理层作为决策者,很大程度上决定着功能能否顺利推进,大规模使用。所以在产品规划上,要与其达成一致意见。毕竟研发资源的分配,也需要争取他们的认可,也要以拿结果为目标。
3)看未来:多职级沟通,了解未来业务发展趋势,提前规划
在共性较强的地方,我们可以通过行业发展的趋势,推论公司业务未来发展的方向。但是也需要通过和各个职级、岗位的同事沟通,验证设想。再结合公司实际的业务情况,提前规划产品的方向。毕竟他们才是在一线战斗离市场最近的人,对于行业的实际状况、公司的处境有着深切的理解。
例如私域电商的流量承接,大方向上是从个人微信转到企业微信,但是公司由于运营策略等各方面的原因,并不适合做企业微信。如果产品规划围绕着企业微信做设计,就偏离了方向。
从供给端看:梳理信息化系统建设的“有无”,定产品设计边界
这里的供给,自然就是能输出产品规划的研发团队了。在调研了行业完整的产品架构,分析公司的现在及未来发展方向上,我们在大方向上做到了知己知彼,接下来需要继续细化可落地的方案,也是从 2 个维度去做 “增删改查”。
1)梳理已有的信息系统,做合并、拆分、删除
如果是进入一个新的企业或项目,我们可以寻找同事的帮助,多维度的获取产品的架构图、产品文档等资料,了解已有哪些信息系统,可以支撑哪些核心业务的运作,预判不合理的架构设计,做冗余功能合并,耦合过高的功能拆分,无效功能的删除,保持架构的简洁性。
没有产品文档或者文档缺失的情况下,就要自己多测试,多推测,找到熟悉系统的同事多请教,整理出一份属于自己的产品规划文档的基础版本。
好的产品规划,在业务模式没有发生本质的变化的时候,不应该发生架构上的变更。微信和网易云音乐的产品架构在业界就是非常有名的案例。
2)缺失的产品需求排优先级,做版本规划
既然是规划,肯定是有需求没有被满足。在梳理缺失的系统能力时,我们可以根据RICE原则做版本的规划,排需求的优先级。
- R:影响范围(Reach):这一需求会有多少人使用?使用的频次如何?尽量量化每一个指标。
- I:影响力(Impact):这一需求将产生什么影响?能提升效率、降低风险、降低成本、还是能产生直接收益?影响力多大?影响是可持续的吗?如果看不到实际的影响,或者是非常短期的影响,要么舍弃,要么评估实现成本。短期的需求但是是非常低成本的,可以酌情考虑做,不过这种需求,也没有必要纳入规划中。
- C:信心(Confidence):这一需求,我们的团队有能力能做好吗?团队的研发资源能在要求的时间范围内达标完成目标吗?例如团队擅长做搜索策略,业务提出要在2个月内做一套抖音的算法分发逻辑,那也是不切实际的。
- E:工作量(Effort):这一需求,需要投入多少资源,多久的时间做完?结合影响力评估,投入产出比是否为正?工作量过大的需求,要谨慎对待。有赞在2022年裁员风波过后,其创始人白鸦发了一封公开信,复盘得到的教训。说明其中很大一个原因是远超预期的高速增长下(30%的正常增长发展到了100%的超速增长),团队没能抵抗诱惑:“搭建了非常多的产品、技术、风控、生态中台,研发开支急剧增加。投入的增长往往可以是很快的,投入的下降却会很慢,尤其在业务链条相对toC业务来说更长的toB行业。”
小结一下,产品规划的思路包含:
04 产品规划的实体产出 -roadmap
产品规划后的实体产物就是我们常说的roadmap,即演进蓝图。roadmap的设计,对产品架构能力提出了很高的要求,是一项需要不断在实践中提升的能力。
这里分享几个笔者认为容易理解的 roadmap 设计案例。
- 按用户端划分:本图引用自杨堃老师的《决胜b端:产品经理升级之路》,作者从分销商城的前台、客户管理后台、运营管理后台三个用户端,分别规划不同业务场景下的版本内容。
- 也有在 roadmap 中加入基础的平台能力(如基础报表)、第三方应用的引入(如引入的ERP系统),产品的架构和规划蓝图有一定的交叉点。
按业务流程划分:本图来自于网络。通常从事件发生的时间/空间流程上比较符合我们的思考逻辑。作者从电商业务的采销仓配流程上入手,展示了各个流程应该具备的系统能力和对应的功能模块。如果配上版本的划分,也是一个好用的 roadmap。
05 如何在实际工作中运用好roadmap?
roadmap 一般在接手新的项目或者进入新的企业时,对于我们快速了解业务有很大的帮助。而在产品的年度规划、对boss汇报产品的思路、有大的需求版本的变更(通常是业务有较大变化)或者和团队同步OKR时,有很强的参考意义。这些场景下,可以时不时翻出roadmap来看看。
但是市场环境是多变的,企业的业务决策也要不断适应行业规则,产品规划在落地的过程中会遇到一定程度的修改,甚至推翻的问题,别忘记要保持规划的及时更新。
规划在一定程度上是基于预测进行的,只要是预测,就会产生错误,只是错多错少不一样。规划的意义,就在于帮助我们降低犯错的几率,提高命中率。(毕竟B端产品的职责之一,在于降低企业的风险。具体可以看一下笔者的另一篇文章:《B端产品,如何验证自己的价值?》)
预测的观念来自于刘宝红老师的《供应链的三道防线:需求预测、库存计划、供应链执行》,道理是共通的,可以触类旁通借鉴一下。
给作者点赞,鼓励TA抓紧创作!
来源:http://www.woshipm.com/pmd/5382103.html
本站部分图文来源于网络,如有侵权请联系删除。