产品管理方法论（下）：规划的逻辑 & 研发的架构

如何打破产品战略规划的神秘感和主观色彩，让其有据可依，让大家都能理解？同时，在数字化转型之下，传统的产品研发管理模式是否还能适配，需要如何转型？这是本文所阐述的两方面重要内容，篇幅较长，请耐心阅读。

【第四篇：规划的逻辑】

白日    周丹

谈起产品战略规划，很多人认为这是拍脑袋的事，或者认为这是艺术家的活。写这篇的目的是让产品战略规划这件事更科学、更严谨、更有逻辑，让更多人看得懂，理解得了。

1. 战略的核心

要支撑战略决策和承接战略落地，就要先理解战略。谈起战略，大多数人认为是神圣不可及的事，尤其被某些咨询公司冠以“高度、视野、格局”等词汇之后，战略更被认为是“肉食者谋之”高高在上的事，然而，抛却华丽和神秘的外衣，战略的核心就是讲清楚两件事**：****“**干什么事”和“怎么赚钱”，翻译成战略词汇，就是“业务闭环”和“商业闭环”，且这两件事各有三个灵魂拷问。对于业务闭环来说，需要回答三个问题：做什么？不做什么？为什么是我做（why me）？对于商业闭环来说，需要回答另外三个问题：干这事怎么赚钱？我赚哪部分钱？为什么是我赚钱（why me）？

图 8 战略的核心

这六个问题当中，这里只强调一个“不做什么”。无论做企业还是做产品，一定要有边界意识，知道自己擅长做什么，不擅长做什么，擅长的地方就努力做精，不擅长的地方就通过生态对接，然而，国内大多数企业很难守住自己的业务边界，认为这也能做那也能行，于是造成市场上大量重复且低劣的轮子。上篇提到的产品生态策略，其最大阻碍通常来自于研发部门的两句话：“这个我们也能做，那个我们也有”。不信你可以问问研发。

2. 需求究竟从何而来

当企业把上述六个问题想清楚弄明白之后，就到了怎么做的阶段，分解到产品战略规划，就是要依据战略长期方向明确相应的产品方向性需求（或称产品体系需求），进而根据产品方向性需求设计产品总体规划（或称产品体系规划）。那么，产品方向性需求究竟从何而来呢？

a. 对于这个问题，大部分人的第一答案是需求来自客户和市场。然而，长期靠客户和市场指导产品需求的通常是项目型企业，因为此类企业的业务模式就是客户说什么就做什么，客户要什么就满足什么，只要客户给钱就行，所谓的产品就成了一个个定制化项目；诚然，市场头部具备前瞻视野的客户可以提供大量有价值的前瞻性需求，但对于企业而言，并不清楚这些需求的本质以及背后原因和发展脉络，只是被动的响应这些需求，把这些需求做出来而已，企业和产品只知其然，不知其所以然，长而久之，项目型企业就逐渐沦为客户的人力外包团队；

b. 有人认为需求来自竞争对手。别人做了什么产品，产品发布了哪些功能，自己就跟着做，但长此以往，就会丧失产品的创新本质以及差异化的能力，最终导致产品同质化严重，最后不得不在低价中搏杀；

c. 还有人认为需求来自行业研究报告或者行业标准。行研报告通常是对行业现状的总结和发展趋势的预测，能写在行研报告中的，一定是已经有人在做的，并且做成的事情，对于产品跟随者而言有一定的参考价值，但能否超越早期对手，取决于对行业最前瞻方向和需求的理解认知；行业标准是业内多家企业所达成的交集和共识，事实上是所有行业产品必须满足的最小需求集合，因此行业标准只代表了产品的最低合规需求。

事实上，上述这些需求都是产品的表象性需求，那么，产品的核心需求究竟从何而来？如何才能挖掘到产品的核心需求呢？这里就引出了一个关键话题：规划的逻辑。

3. 规划的逻辑

总体规划通常分两步走。第一步是定义“演化的过程”：明确演化方向、划分发展阶段、标识属性特征，推导演化结果，即“预见未来（Foresee the Future**）”；第二步是基于“预见”的结果，定义“体系的架构”：分析内部属性、分解外部特征、构建模型框架，设计体系架构，即“定义未来（**Define the Future）”。

图 9 演化的过程

总体规划中最具挑战的其实就是定义“演化的过程”，大家一定会问，如何完成“演化过程”的推导和实现“预见未来”的能力？答案是“大胆假设、小心求证”，这个过程不仅需要感性思维的想象力，更需要理性思维的逻辑，大胆假设的想象力因人而异，不可言传，但小心求证的逻辑还是可以用模型解释清楚的，其核心思想是矛盾论**：事物是由矛盾构成的，矛盾是事物发展变化的根本原因，可以通过分析事物的矛盾要素，**推导事物的演化方向和演化结果。这里把从一个事物从节点A到节点B的演化逻辑抽象为如下三个过程：

图 10 演化的逻辑

a. 抽象

将一个事物在节点A的各种现象的关键特征进行抽象（不是总结、也不是归纳），还原其本质；

b. 演绎

基于事物的本质，对事物在节点A进行矛盾分析，找到其内部矛盾和外部矛盾，以及主要矛盾和次要矛盾。所谓内部矛盾和外部矛盾，就是影响事物发展的内部因素和外部因素，所谓主要矛盾和次要矛盾，对应的是各类因素的重要性和优先级；

矛盾是推动事物发展的根本动力，主要矛盾居于支配地位、对事物的发展过程起决定作用，因此，进一步对内外部主次因素进行分析和推导，可推演出事物接下来的发展方向和发展结果，由此可得到事物的下一个发展节点，即节点B；

c. 分形

较之节点A，节点B的内外矛盾和主次矛盾又发生了新的变化，围绕这些新的矛盾要素，一定会呈现众多全新的具体场景和表象（现象），节点B的内部要素及其各类外部场景和表象，一起构成了事物在节点B（未来的某个阶段）的内部属性和外部特征；

时时有矛盾，事事有矛盾，矛盾在事物发展变化过程中不仅会互相转化，还会不断发生变化，因此，要时刻关注各种矛盾要素自身的发展和变化，不断评估事物演化的过程和结果。重复上述过程，不仅可以完成事物从0到N的完整演化过程的推导，又可以完成各阶段假设结果的求证，此为总体规划的第一步，即“预见未来”，规划的前瞻性正体现于此。

总体规划的第二步**，基于“预见”的结果，定义“体系的架构”：分析内部属性，是指根据内因找出事物的内部逻辑构成，以及各构成之间的相互关系；分解外部特征，是指根据外因找出事物的各种外部表象和对应场景，以及各种表象和场景之间的映射关系；构建模型框架，是指根据内部关系抽象出内在逻辑模型，根据外部表象抽象出外在呈现框架；设计体系架构，是指根据内在逻辑模型和外在呈现框架重构出完整的体系架构，即“定义未来”。**

产品总体规划，也是依据上述过程，先通过演化过程的推导，得到演化结果，再以演化结果为目标对象，完成产品体系架构。回到本章节的核心问题，需求究竟从何而来，看到这里也就不言而喻了，产品的需求核心来自事物预期的发展规律以及演化结果**，正确的产品需求来自对事物演化发展的正确判断，市场和客户的需求只是事物发展到一定阶段的必然产物，是最终验证规划预判和产品需求的方式。好的产品一定是引领市场和客户需求的，它会在不远的未来“等待”客户需求一步步到来，****“等待”市场时机逐渐成熟。**

4**.** 进入市场的时机和方式

好的规划不仅能正确判断未来领域的发展方向和发展结果**，还能正确判断未来市场的启动时机，所以说，好的方向是规划成功的一半，好的时机是规划成功的另一半。**做产品的目的是为了满足市场需求，如果市场需求始终没有到来，或者市场需求高点已过，一定要好好反省规划的市场时机是否恰当。过往有非常多优秀的企业，萌生过很多有前瞻性的规划和想法，但由于误判市场时机，过早或过晚进入市场导致规划失效、产品失败、战略失败的案例比比皆是。在这里，我们依照市场生命周期，根据企业进入市场的时机，将企业划分成四种类型：

图 11 企业进入市场的时机

a. 引领者

顾名思义，企业早于市场看到了新的领域机会，它引发创造了新的市场需求，是市场需求的引领者，是新兴市场的开拓者，同时也是早期市场和早期客户的教育者，属于上述引领客户需求一步步到来，开创市场并引领市场逐渐走向成熟的先驱；

b. 洞察者

在早期市场阶段，一定会有对市场较为敏锐的企业洞察到来自新兴市场的机会，并选择快速跟进，一起推动市场从早期阶段发展到主流阶段，属于对市场发展持有洞见的早期玩家；他们捕获市场机会的方式可能来自早期市场的客户，也可能来自第三方研究机构对新兴市场的分析报告等等；洞察者也许很早也预判了同样的领域方向，只是不确定市场到来的时机，不想第一个吃螃蟹，然而一旦市场出现声音，他们就会伺机而动；

c. 跟随者

一旦市场呈现爆发趋势，跟风的企业就会越来越多，他们或抱着分杯羹的心态进来参与，或基于竞争策略被迫选择跟随，或看到市场逐渐企稳向好，市场技术日趋成熟，此时进入市场风险较小，林林总总，最终，众多跟随者共同助力快速将市场推向龙卷风暴和主街；同样，在这批跟随者当中，仍然不缺少对领域有前瞻看法的企业，他们愿意先观察着这个市场的变化以及赛道中各个赛手的表现，待上述时机成熟再以生态、投资、并购赛手等方式进入市场；

d. 滞后者

出于各种原因，总会有市场判断和市场响应较为迟缓的企业，此类企业或缺少远见、或缺少资源，或出现严重市场误判，最终丧失了市场时机，如果市场在自身业务边界之内，同时又符合战略目标，丧失机会就意味着自杀，市场竞争犹如逆水行舟不进则退，业务踏空可能面临整体被淘汰的风险；

找准市场的方向和时机很重要**，进入市场的方式也同样重要。企业或者选择躬身入局，从产品研发一步步做起，或者选择生态引入或OEM引入，还可以选择战略投资的方式介入市场，有甚者还会选择收购并购赛道上的选手进入市场，等等不同方式。每个企业对于市场机会（Opportunity****）的判断、进入市场时机（Timing）的判断以及进入市场方式（Way）的选择都不一样，取决于企业的战略方向、商业模式、风险偏好、经营策略、竞争态势、企业规模、发展阶段、资源配比、财务状况、企业文化、技术路线等等一系列因素。引领者未必能笑到最后，也可能成为先烈，洞见者未必不能将引领者取而代之，跟随者未必不能赚的盆满钵满。无论怎样，企业首先要具备规划未来领域发展方向的前瞻能力，其次再根据自身情况选择进入市场的时机和方式。**

由于篇幅有限，上述理论在这里不便通过案例和实践展开，看起来会觉得烧脑和干涩。的确，规划过程集合了一个人或一个团队的抽象思维、逻辑思维以及体系思维等综合能力，同时，还需要大量认知和经验的支撑。

**【第五篇：研发的架构】
**

白日    周丹

开篇讲过，产品研发管理的职责是依据产品体系规划的要求对每个相关产品进行详细规划，明确每个产品的具体需求并给出产品详细设计，最后根据产品详细设计研发出所需要的产品，解决产品“怎么做”的问题，其核心是对接能力和需求；传统产品研发管理所涉及的项目管理、需求管理以及团队管理大家都非常熟悉了，这里不多赘述，今天在数字化转型之下，传统的产品研发管理模式是否还能适配？需要如何转型？这是本篇所探讨的内容。

1**.** 研发管理的挑战

传统研发管理过程中广泛存在三大挑战：一是来自组织的挑战“混淆研究、开发和定制”，二是来自业务的挑战“需求响应”，三是来自人的挑战“代码艺术家”。

a. 混淆研究**、**开发和定制

我们一直在讲的“研发”，事实上包括“研究”、“开发”和“定制”三件事。先说“研究”和“开发”，“研究”关注的是领域方向创新以及核心技术公关，“开发”关注的是产品工程化，虽同属研发体系，但侧重点不同，价值提供也不同，然而大多数企业只重视“开发”和“定制”，忽略或者混淆了“研究”，没有研究，企业找不到领域的发展方向，产品会缺少创新动力，失去核心技术支撑，最终会被市场所遗弃；再说“开发”和“定制”，大多数企业认为开发就是按照用户的需求完成定制，项目型企业这样理解没有问题，产品型企业这样理解就会有问题，核心问题在于无法区分哪些是领域需求，哪些是场景需求，哪些和技术有关，哪些和业务有关。因此，如何对研究、开发和定制进行区分和定位，如何划分组织和团队职责，如何在方向、价值和目标上协同一致，这是研发管理需要解决的第一件事；

b. 需求响应

造成需求变更的原因有很多，比如原始需求不清晰，需求本身发生了变化，不断有新的需求提出，需求传递过程中出现信息偏差等等，软件行业响应需求的方式主要依靠软件工程，无论是瀑布模型、快速原型、极限编程、还是敏捷开发等等，其核心都是为了保证做出来的产品符合需求要求。传统方式下，大量的需求需要依靠文档的方式记录、保存、更新和传递，项目团队需要花费大量的时间和精力确保需求理解的准确性、完整性和一致性，然而，无论用哪种软件工程模式，最终产品和原始需求之间总会存在或多或少的差异。数字化转型之下，需求产生和需求变更的频次会呈级数增长，用户业务要具备敏捷性，具备随需而变的能力，传统软件开发和交付方式是否具备快速且准确对接用户需求变化的能力，这是研发管理需要解决的第二件事：如何快速准确响应需求？

c. 代码艺术家

做过研发管理的人都知道，每个研发团队中都会有一两个叫“张三”的关键人，只要张三在，出现重大问题就能搞得定，项目就有保证，老板就放心，一旦张三不在，项目马上就塌，老板就心慌。“张三”是让研发管理者又惊又喜且又难以拿捏的一类人，通常称之为“代码艺术家”。代码艺术家在技术领域有很深的造诣，是各类技术的带头人，也是项目的中流砥柱，但是项目的成功如果取决于代码艺术家的个人技巧和能力，而不是依靠架构和体系力量的保障，那么代码艺术家就会成为项目中的重大风险，这样的项目通常不会长久，这样研发的产品也会举步维艰。因此，研发管理需要解决的第三件事：如何使用代码艺术家？

事实上，上述个三方面挑战并不是今天高科技企业才遇到的，传统工业化时期就遇到过同样挑战，并且工业化时期的成熟工厂模式已经给出了解决方案。大家是否留意，国内大多数开发都是面向成品的开发方式，也就是说，需求描述的成品是什么样子，研发就按照什么样子进行开发；而国外大多是面向工厂的开发方式，也就是先造机床、先建产线，再把零件和流程打造好，最后完成面向成品的装配，同样的机床、同样的产线，今天生产汽车、明天生产坦克，这种方式在早期投入的成本比较大，但是工厂一旦完成，其生产效率和对接各类需求的能力会极大提升，早期手工作坊和现代化工厂的差距可以说明一切。工厂不仅是将能力和需求对接制造产品的地方，同时也是将创新和工程、技术和业务、系统和人进行解耦的一种架构方式，这种模式同样值得研发管理学习和借鉴。

2. 研发的架构

综上，研发管理可以通过以下三方面的架构调整，实现创新和工程、技术和业务、系统和人的解耦，用系统和科学的方式解决上述三方面挑战：

图 12 研发的架构

a. 组织架构**：**将创新和工程解耦

从组织上，有人要研究设计何种工厂、机床、流程、零件以及如何设计，有人要建造厂房、机床和产线，还有人要生产零件，调整流水线，最后还要有人完成组装，因此，从组织架构视角，一个研发组织可以划分成核心研究、生产开发以及定制集成三个部分。

核心研究偏向领域细分研究以及核心技术公关，是创新型组织****（Innovative Group），关注的是创新能力，最终关系到企业的领先性和竞争优势，而生产开发和定制集成偏向技术工程化****（Technology Engineering）和业务工程化（Business Engineering），是工程化组织****（Engineering Group），关注的是生产力、质量、成本、效率和交付能力等，虽然前者会给后者提供能力支撑，但二者的目标、过程和产出截然不同，因此，研发管理需要从组织架构上对创新和工程进行解耦**，把研究和开发、定制划分开。**

图 13 研发的组织架构

b. 工程架构**：**将技术和业务解耦

工厂的生产开发部门需要考虑如何构建机床和产线作为生产的基础平台，再根据定制集成的需求快速生产相关零件、调整相关流程，最后由工厂的定制集成部门把相关零件按照相关流程装配成所需的成品交付给用户。大量的基础平台工人、零件工人和流程工人不需要关心成品的样子，只有定制集成部门才需要看用户的成品需求设计图纸，然后分解所需的零件、分解装配流程、分解项目管理和质量管理等要素，最后完成成品装配。

虽然生产开发和定制集成都是工程化组织，但成熟工厂体系已经将两者进行了剥离。生产开发侧重技术工程化**（与领域需求相关，这些领域需求来自产品战略规划输出的演化过程和演化结果），负责将满足行业80%以上领域需求的技术能力封装成基础框架、基础平台、基础零件和基础流程等基础架构；定制集成侧重业务工程化（与场景需求相关，这些需求来自用户的实际业务），负责对接上述基础架构和来自用户最后一公里的实际业务需求，最终装配出成品。**

图 14 研发的工程架构

企业的生产开发**，需要由面向成品的开发，转到面向基础框架、基础平台、基础零件、基础流程等基础架构的开发，然后交付给最懂业务的定制集成人员，甚至是用户自己的业务人员，再由他们完成最终的成品装配，从而保证从业务需求到成品交付的快速对接和无损落地。上述过程的核心，是将领域需求和场景需求划分开，从工程架构上实现技术和业务的解耦，打破业务对技术的依赖，让懂业务懂需求的人直接参与业务的构建和实现，将需求快速并准确地转化为成品，想到即做到，让业务人员专注业务本身，而不用关心技术实现。**

在上述过程中，与产品相关的研发管理主要集中在生产开发环节，产品研发经理需要根据产品体系规划的要求，完成基础框架、基础平台、基础零件以及基础流程等基础架构产品的需求细化以及详细设计，由于这些产品的需求和设计与技术能力承载相关****，与用户具体场景无关，因此，产品研发经理不仅要具备高度的解耦能力和抽象能力，还要具备扎实的系统架构能力。

另一方面，对于定制集成人员或者用户自己的业务人员而言，要通过业务工程化将上述基础架构和实际业务需求快速对接完成成品定制集成，此****过程的最大挑战来自于需求结构化，原始需求是混沌的、杂乱的、没有条理的，只有将需求结构化，理清业务边界、业务构成和业务逻辑，才能实现对业务需求的准确和快速响应。

c**.** 技术架构**：**将系统和人解耦

代码艺术家擅于使用技术技巧解决难题，这种能力非常适合技术研究领域，然而在工程化领域，试图通过技术技巧解决复杂系统问题反而会引入更多新的问题，一来二去，系统复杂度反而会成倍增加，人和系统的耦合度也会越来越高；解决复杂系统问题的方式有很多，架构无疑是最科学的方法，架构的核心是解构、抽象和重构，先将复杂系统解构成多个原子构成，再抽象成简单模型，最后基于模型重构体系，架构是将复杂系统简单化的有效方式。

通过上述工厂模式在组织层面和工程层面的解耦，事实上已经把大型复杂系统解构并降维到多个简单场景和环节，对全栈型代码艺术家的依赖已大幅降低，但是在技术层面，仍然**需要通过技术架构对每个场景和环节的具体问题进一步解构和降维****，**降低问题的复杂度和难度，从而降低岗位对个人技能的要求，张三能干，李四王五也能干，从技术架构上实现系统和人的解耦，完成复杂系统对应的大量岗位只需要熟练工，而无需艺术家，这种方式不仅可以保证系统的成功，同时也将个人对系统的影响降到最低。

3**.** 数字化转型的挑战

事实上，工业化时期催生并运用了大量系统工程和管理科学的方式方法，上述三方面的架构思想也是工业化时期的产物，在今天看来并不是什么新鲜事，然而，相较成熟的工业化管理，当前的研发管理还处于相对早期的发展阶段，还存在大量作坊式的小团队，上述架构思想仍然值得我们借鉴和学习，因为接下来的数字化转型会改变传统的生产力和生产关系；就供给侧而言，数字化转型对传统研发的影响**，一定不亚于工业革命对传统工场手工业的影响，传统研发模式也一定会被数字工厂模式所取代，与数字化转型关系巨大的软件行业，一定会走上软件工业化的道路。企业要数字化转型，支撑转型的研发供给侧必先践行数字化转型，如果研发自身从组织、管理到技术都不知道如何理解和实践数字化转型，给客户谈数字化转型就是一句空话。**

【结束语】

上述五篇文章，均来自过往20多年相关工作的积累、总结和抽象，尝试以产品为金线，将企业战略规划、研发管理和市场营销三大体系的有机串接起来，并实现企业资源的优化配置。旨在让更多To B领域高科技产品企业知道如何构建并管理完整的产品管理体系，了解产品管理对一个企业的价值和意义，同时也让更多人清楚企业资源配置的决策依据，熟悉产品市场营销的一般策略，揭开产品战略规划的神秘面纱，并且打破产品研发管理的传统认知。

图 15 产品管理方法论

数字化转型的暴风雨即将到来**，既是一场革命，也是一场机遇，企业能否承受住未来的钢铁洪流，顺应时代发展的趋势，一定是让每个企业负责人或焦虑或兴奋地睡不着觉的问题。**

本文只着重介绍产品管理的体系、框架和方法，篇幅有限，相关案例和实操这里不做展开，有兴趣的朋友欢迎私下联系讨论，可公众号留言或加个人微信：PEPSI_NJ

借此，感谢我最尊敬的良师益友童宁先生，童宁先生是产品管理领域的大师，是我进入产品管理领域的带路人，他教给我很多产品管理的理念和方法，非常乐于分享自己对于产品管理的理解、观点以及实践经验，感谢童宁先生对本文核心思想和体系框架的指导和建议；其次，感谢我入行时遇到的恩师彭涛先生，虽然在一起共事只有短短几个月时间，其体系化和架构化的思维方式，在我工作二十余年中一直深深地影响着我，并让我受用至今，感谢他对本文的审阅以及宝贵意见；同时，感谢本文的合作者周丹先生，周丹先生拥有近30年的银行工作经验，在金融科技领域研究颇深，对事物的抽象能力、对本质的洞见能力，对分析的逻辑能力以及对未来的预见能力让我受益匪浅，同时为本文的关键理念、方法和模型的形成提供了至关重要的指导和建议；最后，感谢2022，这个充满变幻的一年。

余不一一。

【完】