产品规划一定程度上可以帮助产品经理更有逻辑地建设产品，提升产品后续迭代时的灵活性。那么，产品规划怎么做，才可以更加清晰明了、并实际性地助推业务？本篇文章里，作者总结了B端产品规划的相关步骤，一起来看看。

　　最近一年我的工作主要是产品定位、年度季度目标制定、绩效达成。在产品规划方面有很多实践经验和感悟，在这里跟大家分享一下。

　　首先谈一谈为什么要做产品规划。

　　不做产品规划行不行？其实是可以的，业务需要什么，我们就往系统里堆功能就完了呗。但逐渐会发现系统功能多得你自己都说不全，也不会用；客服越来越多，但还是解答不过来客户的问题；研发越来越频繁地反馈代码改不动了，没办法再加功能了；业务会说竞品早都已经有这个功能了，为什么我们没有这个功能；销售抱怨我们的产品不如竞品，不好卖。

　　产品规划的作用有以下几点，在未来一段时间：

　　有计划地建设产品能力，在细分市场长期保持产品竞争力；产品功能复杂度可控，在满足多角色需求的同时保持简易用，从而降低销售成本和运维成本；给研发架构设计一个参考，通过保障架构的扩展性，来提升产品迭代的灵活性，最终表现为对市场的反应速度。整个实操分为五个步骤，逐层递进，形成一个个迭代要建的产品能力：

　　对标市场商业化产品做产品定位。按照支撑未来三年发展的目标设计产品架构。列出未来一年需要的产品能力，形成能力清单。将用户关键行为路径与能力清单结合起来形成能力地图。按照MVP和业务需要来规划产品迭代。

　　产品定位没有那么高大上，就是很简单，你这个产品是用来给谁解决什么问题的。在B端产品中，一般就是用来解决企业问题的。而企业的问题在过去几十年过程中其实并没有实质性变化。在经营层面，企业核心问题还是市场拓展与财务健康度的问题；在运营层面，企业核心问题还是信息流资金流实物流三流合一和组织文化机制建设的问题。

　　做B端产品定位的时候切记不要自high，自认为造出来一个市场上没有的产品，其实所有的企业问题在过去几百年中都已经被明确定义过，只是不同时候的解决手段不一样。

　　下面展开讲一讲我对B端产品的一些理解。

　　上图是我在水滴产品训练营里看到的一张PPT，觉得说得挺有道理的，大家也可以把自己在做的产品往里套一套，这是最顶层的抽象了。实操层面我还是从【给谁解决什么问题】的角度给大家讲讲常见的一些产品。

　　企业里的典型角色分为销售、营销、实施、产品、技术、采购、财务。把这些角色串在一起的是企业的三流（信息流资金流实物流），这些角色共同往复着【生产产品→销售产品→回款再投入生产】的过程，为了提升这个过程的效率和质量，就会衍生出一些信息管理系统。

　　例如围绕销售这个角色，市面上定义出CRM（Customer Relationship Management，客户关系管理），提供包括销售线索管理、客户信息管理、营销资源投放、客服外呼等等能力，核心是为了提升销售角色的效率。

　　做CRM最成功的公司是Salesforce，但在Salesforce之前就有传统ERP企业在做，可以追述到上世纪80年代。近两年CRM系统在国内甚嚣尘上，但其实CRM也存在很久了，即便没有CRM，销售也在利用Excel作为CRM的替代产品来解决客户信息管理的问题。

　　例如围绕技术研发这个角色，市面上定义出DevOps（开发运维流水线），提供包括代码管理、应用部署、线上运维等一系列技术研发过程中要用到的工具，核心是提升研发在系统全生命周期的工作效率。

　　DevOps是已经存在了几十年，并且市面上已经有开源解决方案，即便没有DevOps，在研发的各个环节也有相应的工具来解决问题，只是DevOps更强调整个各环节流水线作业。

　　很多大企业内部在做信息管理系统的时候，由于技术资源比较充沛，往往会东起一个轮子西造一个造轮子，过两年再来个大合并，最后发现这玩意儿在市场上早就有了。

　　所以说做产品定位的时侯一定要看市场，千万不要认为自己造出来一个市场上没有的产品。

　　只有一种情况例外，就是在出现技术革命的时侯，解决同一个问题的手段发生了本质性变化，那么会出现一个市场上没有的产品。

　　例如传统记录信息的方式是纸质媒介，最早计算机将信息记录在打孔纸片上，后来磁信息存储技术成熟，出现了磁带、光盘等一系列革新性的产品。但大部分企业都不会走在这样的前沿。

　　产品定位最后输出的内容很简单：

　　一句话版总结产品解决的核心问题是什么？产品给哪些角色解决什么问题？每个角色进入到系统里的关键任务有哪些？为了完成这些关键任务需要的关键产品能力有哪些？产品定位环节是最难的最耗时的，后面环节相对都好做。

　　架构图也并不是什么高大上的东西，架构图就是结构化地体现第一步定义出来的关键能力，能有个上帝（全局）视角。结构化的思路有两种，一种是数据流图，通过关键数据在各个模块之间的流转来体现各功能间的关系；一种是麻将图，通过上下来体现模块间的支撑关系，通过左右来体现模块间的并列关系。

　　以下用两种方式展示了API网关的产品架构。

　　有时候我们会遇到更复杂的情况，就是这是一个多端产品，由网页端、客户端、服务端等端组成，这些端连起来才能解决客户的问题。那么画架构图的时候，就可以画多层级的架构图。第一层就先要体现这个产品到底有多少端，每个端核心能力是什么，这些端是怎么相互协作的，第二层再进一步画各个端自身的架构图。

　　云计算产品就是这样，用户至少会接触到资源管理端、命令行终端、API服务端。这种多层级产品架构图同样适用于其他复杂场景，层级也不仅限于两层。

　　但架构图有一点要求，那就是抽象能力，需要把相似的能力抽出来形成一个大的模块，需要定义模块里各项能力与其他模块统一的交互方式，最终做到高内聚低耦合，有点研发模块设计的那种意思。这个能力没什么快速提升的方法，就是在不断地思考不断地设计不断地改进过程中练出来的。

　　在这一步设计出来的架构图需要能支撑业务三年的发展，怎么样算支持住了呢，就是把业务往前推演几步，业务需要的能力在架构图里是不是都能找得到，在可见的将来这个功能模块之间的关系是不是会发生实质性变化。

　　能力清单，顾名思义，对照着架构图，把所有的产品功能逐层列举成一张清单，越细越好。

　　这张清单的作用是让产研以最接近实际需求的角度来认知所有的工作。之后的能力建设也基本是以这张表为准，一旦发现业务需要一个能力但没出现在清单里，就要及时补进去。

　　但能力清单不用拆得事无巨细，只要能管住未来一两个季度就行，按需拆解，不断完善，像点亮技能树一样一个个地建设这些能力。

　　能力地图这个事也简单，「能力」指的就是能清单中的能力，「地图」指的就是用户关键行为路径图，在行为路径上把每个环节用到的能力标出来就是能力地图。能力地图可以很直观地看出来缺的能力与用户行为的相关性，比抽象的架构图更贴近业务和用户。

　　版本规划就是有计划地建设能力，选择建设哪些能力的依据是业务需求，为了解决同一个业务需求而建设的能力就可以放在一个版本里，如果相关能力太多就把MVP摘出来先做一个版本，后面再按需完善。

　　在能力清单后面可以加两列（优先级和计划上线版本），把未来一个季度业务预期目标相关的能力标记上，这样就形成了产研团队一个季度的版本规划&工作清单。

　　做版本规划的时候有一个点需要注意，研发尽量从一开始就要按产品架构来搭系统架构，拿2~4周去打好底子，才能做到未来几年内保持快速迭代，而不是一味要求研发堆功能。

　　系统底子没打好的话，过不久研发就会提出要重构代码，业务高速发展的时候告诉你系统改不动了，不光是说万元收入的研发成本越来越高，而是你的产品跟不上市场需求影响业务收入了，要是真一不小心掉队了，哭都没地方哭。

　　本文没有讲类似于「微信是如何在十年内保持菜单不变」这种问题。我个人觉得这还是用户体验设计的范畴，一个人对产品有深刻理解，对用户行为有深刻的洞察，再有一些基本的用户体验设计经验，其实自然而然就知道该放哪几个一级入口、如何递进地引导用户使用功能、哪些属于低频功能需要收起来，最终做到产品看起来简单却十分强大。

　　同事有些人说B端重要的是业务逻辑和业务流程，不必苛求用户体验，B端用户通常会经过培训，可以承受比较高的学习成本。但现实情况是由于B端逻辑复杂性，B端产品一不小心就会变得非常难用，百十来个菜单是常事，一般用户根本不知道从何入手，如果用户不用这些工具，也就不会实际产生价值。

　　所以我个人的观点是B端产品不需要交互体验如何地炫酷，最基本的交互效果就足够，但一定要尽量帮用户把业务流程串起来，让用户能用你的工具顺利的完成工作。

　　总的来说产品规划不是一个特别难的事情，以上五个工具勤加练习，就能做好中短期的规划。

　　当然产品规划中其实还涉及一些战略选择的问题，归属于产品定位环节，例如同样做CRM，我是要做普适的CRM，还是要做医药领域专用的CRM。这种战略判断能力和常规的产品规划能力是平行的两个能力，以后专门开篇讲。

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

　　题图来自Unsplash，基于CC0协议

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