编辑导读：在开发一款产品前，首先要做好产品规划，确定产品定位和业务方向，为将来的版本规划提供大方向的参考。那么，如何做好产品规划？本文作者对此展开了分析，希望对你有帮助。

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行业。”

小结一下，产品规划的思路包含：

1. 从需求方看：了解企业战略、定位、所处市场阶段，定重点业务范围
2. 从供给端看：梳理信息化系统建设的“有无”，定产品设计边界

04 产品规划的实体产出 -roadmap

产品规划后的实体产物就是我们常说的roadmap，即演进蓝图。roadmap的设计，对产品架构能力提出了很高的要求，是一项需要不断在实践中提升的能力。

这里分享几个笔者认为容易理解的 roadmap 设计案例。

• 按用户端划分：本图引用自杨堃老师的《决胜b端：产品经理升级之路》，作者从分销商城的前台、客户管理后台、运营管理后台三个用户端，分别规划不同业务场景下的版本内容。
• 也有在 roadmap 中加入基础的平台能力（如基础报表）、第三方应用的引入（如引入的ERP系统），产品的架构和规划蓝图有一定的交叉点。

按业务流程划分：本图来自于网络。通常从事件发生的时间/空间流程上比较符合我们的思考逻辑。作者从电商业务的采销仓配流程上入手，展示了各个流程应该具备的系统能力和对应的功能模块。如果配上版本的划分，也是一个好用的 roadmap。

05 如何在实际工作中运用好roadmap?

roadmap 一般在接手新的项目或者进入新的企业时，对于我们快速了解业务有很大的帮助。而在产品的年度规划、对boss汇报产品的思路、有大的需求版本的变更（通常是业务有较大变化）或者和团队同步OKR时，有很强的参考意义。这些场景下，可以时不时翻出roadmap来看看。

但是市场环境是多变的，企业的业务决策也要不断适应行业规则，产品规划在落地的过程中会遇到一定程度的修改，甚至推翻的问题，别忘记要保持规划的及时更新。

规划在一定程度上是基于预测进行的，只要是预测，就会产生错误，只是错多错少不一样。规划的意义，就在于帮助我们降低犯错的几率，提高命中率。（毕竟B端产品的职责之一，在于降低企业的风险。具体可以看一下笔者的另一篇文章：《B端产品，如何验证自己的价值？》）

预测的观念来自于刘宝红老师的《供应链的三道防线：需求预测、库存计划、供应链执行》，道理是共通的，可以触类旁通借鉴一下。

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

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