我们部门名字之前是叫「Integration and AI Solutions」，但坦白来讲，过去我一直没太理解这个部门的含义，加上自己的序列一直是产品，所以始终带着 Product 的帽子，而没太在意 Solution。但最近发生的一件事，让我更理解我们的部门名，以及，想清楚了更应该做什么。

作为 RD 出身的 PM，我不自觉的会将手头在做的事情进行抽象 —— 抽象出面向对象的类，避免面条式代码。这样做很好，我们尽可能的提升我们在做的事情的可复用性（从一个具体的事项中，抽象出可以服务更多的人的需求，这也太产品了）。但，这样也很坏，因为一但没有把握好度，就会陷入到无限抽象的怪圈里。虽然产品抽象出来了，但用户的问题并没有得到解决。很显然，我曾成为后者，忙于抽象和设计产品，而不是真正的解决问题。

而走过这个阶段，我所得到的教训便是：「做事应该先 Solution，后 Product」，你需要先为用户解决问题，产生价值，再思考如何通过抽象去服务于更多的人。如果过早的开启抽象，大概率会陷入到虽然设计的很好，但不落地，不解决问题的困境当中。

用户关心的不是你的 Product ，他只关心他的问题是否得到解决， Product 只是 Solution 的一环。如果连问题都没有解决，那你的 Product 又有何用呢？

我希望我的反思能够启发大家，在产品开发和解决方案提供之间找到合适的平衡点，共同进步。

在上次写完「为什么是产品决策优先级」之后，我也和身边的几个产品同学聊了聊我的推演逻辑，他们给了我不同的输入，让我觉得，这些内容应该分享出来，既帮我厘清了思路，也帮助我看到了不一样的产品。

首先是产品 A 同学， 他的观点很简单：产品经理之所以决策优先级，是因为产品经理为这个产品的最终结果负责。这个逻辑其实是从证明的视角来看的，虽然所有人都为产品结果负责，但运营同学可以通过篇一些其他指标来证明自己的价值 —— 比如运营指标好；研发同学可以通过技术指标来证明自己的价值。唯独产品经理别无选择 —— 他成功与否的评价唯一标准便是 —— 产品自身的成功与否。产品最终承担一个产品背后的所有结果，从权责利对等的视角来看，则应该由产品 —— 这个最终承担后果的人来作出决策。

其次是产品 B 同学，他的观点比较有意思，也给我带来了不同的视角：产品经理之所以需要决策优先级，是因为价值不明确，需要“有判断力”的人来做出价值判断。他给我觉得例子是早期头条研发，早期的头条研发在整个产研链路上是比较有话语权的， 原因是产品的收益相对明确 —— 调整某个策略，能够非常明确的计算和评估出 ROI，导致最终优先级和价值回收变得非常简单粗暴 ： 按照策略的预测上能力即可。相比于简单粗暴的广告 / C 端业务，B 端的业务显得收益不那么明确 —— 产品设计出一个功能，商业化团队未必能卖出去；商业化需要的功能，从产品视角来看，未必是适合产品定位的。从产品到商业化的长周期链路，使得对于产品的决策能力要求会更强 —— 需要产品能够从海量的信息中找到什么是最重要的？找到那个必须要做的事情。

这个是个好问题：

1. 为什么是产品来决策优先级？而不是研发而不是运营而不是项目经理？这个背后的核心到底是什么？
2. 产品决策优先级的底层逻辑到底是什么？如果底层逻辑可以迁移，是不是别人也可以决策优先级？

我的答案如下：

1. 产品决策的优先级核心逻辑是信息补全，产品让渡了一部分时间去参与各种会议，来换取足够的上下文，并基于这些上下文做出决策和调整。
2. Leader 的预期是产品会被拉到各种不同的群 / 上下文里，梳理不同的信息，明确优先级，并帮助业务达成目标。
3. 严格来说，一个好的产品需要的能力挺多的，你需要有用户感知、项目经验、沟通能力等各种不同的能力，才能更好的当产品。正是这样的原因，也让产品可以成为团队中的 Connector ，对齐不同人的信息和上下文。
4. 产品决定大范围的优先级，但一些细节的优先级可以由具体执行的人来决策，毕竟要让听到炮火的人来做决策，才不会出现问题（也依赖听到炮火的人的能力）。

总结一下：

1. 产品的决策底层逻辑是信息，这个人可以是运营/产品/研发，只需要让渡时间来做这些事情，你就可以成为这个做决策的人。