编辑导语：关于“第一性原理”，在许多文章中都有提到，本文作者对它提出了自己的理解，并分析了“第一性原理”在B端产品设计中的具体运用，感兴趣的小伙伴们一起来看一下吧。

用“第一性原理”作为关键词可以搜索到无数的文章，其中不乏十分权威学术的。今天我斗胆尝试将其换到企业应用产品构建的语境中，阐述它是如何指导系统的设计。

先说下我对第一性原理的理解：第一性原理是一切系统构建的出发点，是这个系统的内在本质，它指导着这个系统的运转，是这个系统存在的意义。

很拗口哈？

例如：马斯克用电池的“配方”作为重构电池成本结构的第一性原理；公司的文化墙上的“使命”是指导公司战略以及任何战术动作的第一性原理；用户的真实心理，是你设计这个功能的第一性原理（用户故事三个要素的末尾部分）。

我个人认为“第一性原理”对产品设计有如下指导意义：

• 从用户真实需要为出发点，理解用户为什么有此需求
• 以此真实需求为出发点，拆解出问题空间（领域）
• 基于问题空间构建解决问题的空间（限界上下文）

01 从用户真实需要为出发点，理解用户为什么有此需求

这是一句正确的废话，产品经理要分析用户心理，还用说？

用户心理才是用户的真实需要，而如何保证“真实”，以及什么“程度”的真实才是我想探讨的内容。

真实，需要用到科学的思考框架；程度，则需要用到第一性原理不断下探。很绕的还有不同深度采用的思考框架还一致，容我娓娓道来。

举例之前，先强调一个道理：对于一个表象思考得越深，越接近本质，获得解决方案越有效、越持久，人类大脑所能探索出的最深层的那个“本质”就是“第一性原理”。

图1 用户真实需要分析的U型过程（红色箭头像字母“U”）

假如朋友告诉你ta失恋了，你的第一反应是什么？你可能会给出图1所示的某一种方案。

应对表象问题，最不耗大脑能量的方式是靠经验直接给出解决方案：不高兴就哭，别人惹你了，就报复。这种解决方案的好处是快，但坏处是，反弹大，容易进入“冤冤相报何时了”的恶性循环。

稍有思考的人，会接受既然木已成舟，那就放过彼此，“心病就用心药医”、“抽抽烟喝喝酒或者”、“一路向西去大理”麻痹一下“伤口”，很显然这治标不治本，注意力迟早会回来，在熟悉的线索下，往事还是会涌上心头。

思考略深的人知道，只有心理坦然接受这一切，才是真的与自己达成和解。大胆给所有人分享，坦然丢弃曾经的留恋之物，也代表着心中已经倾倒干净并坦然接受，失恋博物馆的解决方案简直不能不说是神来之笔。

思考更深的人，会用辩证的眼光看到事物的两面性：任何事物没有绝对的好与坏，而是相互伴随。化悲痛为“反脆弱”，回收恋爱的时间和精力，投入到学习、创业、公益事业中去，发挥自我价值，心诚更安。

像马斯克这样深谙第一性原理的人，远不会在表层寻找安慰，而会在生理层面的科学视角，去调整大脑皮层和皮层下神经的协同工作状态，不仅帮助失恋之人删掉记忆，还能触发愉悦的心情。

以上，从经验→心理→生理，由浅入深地思考解决问题的出发点。不难发现，思考越深，获得的解决方案越有效，越持久。这是一种追寻事物本质，寻找创新解决方案精准且有力的方法，也是产品经理能力拉开差距的关键所在。

这其中，第一性原理是如何得以体现的？

如果按照第一性原理狭义的定义，本原是所有事物运转的第一性原理，但仅限于这个定义，对于产品设计没有太多的指导意义。

我们需要将第一性原理泛化扩展，将其广义地运用到从下到上的每个层级中：当一个原理是指导着一个系统运转，或者一个系统的运转是某一个前提时，我们就可以说这个前提或规律就是这个系统的第一性原理。

图2 基于第一性原理构建上层系统的简单模型

从图1中看，本原指导着生理的工作运转，生理决定着心理的动态，心理决定着外在表象行为的体现。从本原到生理，有哲学；从生理到心理，有生理学；从心理到行为，有心理学。思维下探的深度越深，所获得的或需要的思考框架不一。

如上，对于产品设计的需求挖掘上，有如下几个帮助：

• 用户的表述背后，一定有一个本真的心理出发点，下探越深，可以解决问题的程度越深且更持久。
• 在不同的深度下，应该采用适配该深度的科学的思考框架，来科学分析，才能保证问题为真。

这一定是产品经理能力的分水岭和差距刻度。

02 以此真实需求为出发点，拆解出问题空间（领域）

获得真实需求，工作仅过半，离给出好用且成本低廉的产品，还需要对需求进行系统化地化繁为简。

此过程中，最重要的就是目标层层拆解，划分/抽象出子域，并对其职责进行定义，这个职责就是子域的“第一性原理”，它可以明确领域边界，同时也能明确领域之间的接口。

“使命”是公司这个大系统的第一性原理，是存在的意义，指导着公司战略的设计和执行。

战略系统中会拆一个分支目标——组织效能，便成为了组织架构这个子域的“第一性原理”，组织架构中还会包含挖掘用户价值、保证技术先进和系统稳定，向更多人传播产品价值，让更多人更顺畅地使用并将他们转付费的职责……这些便成为了产研部门、市场部门、运营部门运作的“第一性原理”。

以上，便是利用第一性原理，帮助我们逐层往下拆解的实例（图3）。基于“第一性原理”构建子域，目标清晰、边界清晰、接口清晰，在IT系统设计中的“单一职责”原则实则也是类似的表述。

图3 拆解实例

现实场景中，往往更多的是接收到粒度大小不一，领域含糊不清的问题/表述，这便需要我们心中坚定地用第一性原理将问题进行拆解，划分归属。

举一个我身边的例子，我们是从事供应链协同领域的企业应用服务，增长策略是：以项目方式获得核心企业，通过核心企业的能量带动诸多供应商注册与付费。

我的运营同事比较烦恼的是：最近处理系统bug（包括协调资源和处理进度跟踪）的时间占比远比客服、电销、内容等工作多很多，他困惑着这样的状态到底正确与否。

他困惑的矛盾在于：他想通过服务好核心企业，来让核心企业帮助转化供应商为用户并付费；但眼下大占比的bug处理又不太像是运营本职工作。

若对范式进行抽象：心中明确要实现某个目标，但解决方案始终感觉别扭不纯粹，这是产品经理时常遇到的问题。

问题的根源是，解决方案混杂了多件不同“第一性原理”的事，这种混杂是不伦不类的，必然别扭。

我同事的问题很好解决：运营的工作只负责客服（使用上的问题引导和讲解）、电销、内容输出等价值引导性的工作；bug的工作属于系统缺陷问题，应该由产研部门协调跟踪后，统一归口到运营部门交付给客户。

这其中的两件事分属两个“第一性原理”的系统中——产研部门和运营部门，运营部门帮着做产研的事，听着也别扭吧？

图4 “职责单一，各司其职”的解决方案

本节，用第一性原理来明确领域（包括不同层级的子域）的职责、边界以及接口，“职责单一，各司其职”的系统设计才可能结构干净、纯粹，有力的依据来源于“第一性原理”。

03 基于问题空间构建解决问题的空间（限界上下文）

从整体上说，2中所获得的“问题空间”是“解决问题的空间”的第一性原理（如图5），即“解决问题的空间”是基于“问题空间”所设计和构建。

从部分上说，问题空间分为一个个子域，每个子域有自己明确的职责，而限界上下文是用系统的方式，来实现或兑现这个职责，所以子域的职责也是限界上下文的第一性原理（图6）。

图5“问题空间”是“解决问题的空间”的第一性原理

图6“子域的职责”是“限界上下文”的第一性原理

限界上下文在拆分出的子域的清晰且简单的职责的指导下，进行解决方案设计，已经十分容易了。

只是需要再提醒一下的是：限界上下文内部，仍然可以继续拆解成更细的模型，更细模型的职责定位、边界划分，仍然适用2中所述方法。

04 结束语

本文斗胆在B端产品设计的语境下，阐述“第一性原理”给系统设计带来的启发，同时还结合“领域驱动设计”方法，穿插解释帮助理解。

希望带给你一点设计思想层面上的收获，而非“用问题阐述问题”的错觉，感谢阅读，愿我们每个人都能比昨天聪明一点点。

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

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