产品总体规划一定程度上能帮助产品经理更有逻辑地工程建设产品，提高产品先期插值时的稳定性。所以，产品总体规划怎么做，才能更加明晰明了、并莱盖地助力业务？第一集该文里，作者归纳了B端产品总体规划的相关关键步骤，一起来看看。

最近两年我的工作主要是产品机能定位、本年度会计本年度目标制订、考核制度达成一致。在产品总体规划方面有很多成功经验和体悟，在这里跟大家撷取一下。

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

不做产品总体规划行不行？只不过是能的，业务需要什么，我们就往系统里堆机能就完了呗。但逐渐会发现系统机能KMH你自己都说不全，也不会用；客服人员愈来愈多，但却是答疑不过来客户的问题；研制愈来愈频密地意见反馈标识符改不动了，没办法再加机能了；业务会说同价位早都早已有那个机能了，为什么他们没有那个机能；销售埋怨他们的产品不如同价位，不好卖。

产品总体规划的作用有几点，在未来几段时间：

有计划地工程建设产品能力，在行业龙头市场长期维持产品竞争优势； 产品机能维数受控，在满足多配角需求的同时维持固定式用，从而降低销售成本和网络管理成本； 给研制构架设计一个参照，通过保障构架的可扩展性，来提高产品插值的稳定性，最终表现为对市场的响应速度。

整个Jalgaon分为四个关键步骤，逐级环环相扣，逐步形成无数个插值汉建的产品能力：

Kanniyakumari市场商业化产品做产品机能定位。 依照支撑未来三年发展的目标设计产品构架。 列举未来两年需要的产品能力，逐步形成能力目录。 将用户关键行为方向与能力目录结合起来逐步形成能力世界地图。 依照MVP和业务需要来总体规划产品插值。

一、第二步：产品机能定位

产品机能定位没有所以矮小上，是很简单，你那个产品是用以给谁解决什么问题的。在B端产品中，一般是用以解决企业问题的。而企业的问题在往后数十年过程中只不过并没有根本性变化。在经营层面，企业核心问题却是市场开拓与财务管理健康度的问题；在运营层面，企业核心问题却是信息流信息流铜器流二流三位一体和组织文化监督机制工程建设的问题。

做B端产品机能定位的这时候当心不要自high，自认为造出来一个市场上没有的产品，只不过所有的企业问题在往后数百年中都早已被明确表述过，只是不同这时候的解决手段不一样。

上面进行讲一讲我对B端产品的一些理解。

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

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

例如围绕销售那个配角，市面上表述出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协议

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