作为一个技术出身的产品同学，我比较自豪的是，我不会提出一些非常离谱的需求。因为我大体上可以感知到技术的边界在哪里，但另外一个层面，我同样也会有比较严重的自我阉割的问题。
比如，如果某一个数据的要求严重超出了一般意义上的限制，我可能就会先自我阉割，认可这个事情虽然能做，但可能 ROI 划不过来，前置给了判断。但实际上，真的做不到么？未必，也可能只是我们没有去做。当然可能 ROI 上划不过来，但在产品对标和洽淡合作时，这些可能是会被客户挑战的问题：“为什么你不如 XXX”
下次做决策，要先多调研一下， 再做判断，不能让自己的技术脑完全占领了高地。
我们部门名字之前是叫「Integration and AI Solutions」，但坦白来讲，过去我一直没太理解这个部门的含义，加上自己的序列一直是产品，所以始终带着 Product 的帽子，而没太在意 Solution。但最近发生的一件事，让我更理解我们的部门名，以及，想清楚了更应该做什么。
作为 RD 出身的 PM，我不自觉的会将手头在做的事情进行抽象 —— 抽象出面向对象的类，避免面条式代码。这样做很好，我们尽可能的提升我们在做的事情的可复用性（从一个具体的事项中，抽象出可以服务更多的人的需求，这也太产品了）。但，这样也很坏，因为一但没有把握好度，就会陷入到无限抽象的怪圈里。虽然产品抽象出来了，但用户的问题并没有得到解决。很显然，我曾成为后者，忙于抽象和设计产品，而不是真正的解决问题。
而走过这个阶段，我所得到的教训便是：「做事应该先 Solution，后 Product」，你需要先为用户解决问题，产生价值，再思考如何通过抽象去服务于更多的人。如果过早的开启抽象，大概率会陷入到虽然设计的很好，但不落地，不解决问题的困境当中。
用户关心的不是你的 Product ，他只关心他的问题是否得到解决， Product 只是 Solution 的一环。如果连问题都没有解决，那你的 Product 又有何用呢？
我希望我的反思能够启发大家，在产品开发和解决方案提供之间找到合适的平衡点，共同进步。
在上次写完「为什么是产品决策优先级」之后，我也和身边的几个产品同学聊了聊我的推演逻辑，他们给了我不同的输入，让我觉得，这些内容应该分享出来，既帮我厘清了思路，也帮助我看到了不一样的产品。
首先是产品 A 同学， 他的观点很简单：产品经理之所以决策优先级，是因为产品经理为这个产品的最终结果负责。这个逻辑其实是从证明的视角来看的，虽然所有人都为产品结果负责，但运营同学可以通过篇一些其他指标来证明自己的价值 —— 比如运营指标好；研发同学可以通过技术指标来证明自己的价值。唯独产品经理别无选择 —— 他成功与否的评价唯一标准便是 —— 产品自身的成功与否。产品最终承担一个产品背后的所有结果，从权责利对等的视角来看，则应该由产品 —— 这个最终承担后果的人来作出决策。
其次是产品 B 同学，他的观点比较有意思，也给我带来了不同的视角：产品经理之所以需要决策优先级，是因为价值不明确，需要“有判断力”的人来做出价值判断。他给我觉得例子是早期头条研发，早期的头条研发在整个产研链路上是比较有话语权的， 原因是产品的收益相对明确 —— 调整某个策略，能够非常明确的计算和评估出 ROI，导致最终优先级和价值回收变得非常简单粗暴 ： 按照策略的预测上能力即可。相比于简单粗暴的广告 / C 端业务，B 端的业务显得收益不那么明确 —— 产品设计出一个功能，商业化团队未必能卖出去；商业化需要的功能，从产品视角来看，未必是适合产品定位的。从产品到商业化的长周期链路，使得对于产品的决策能力要求会更强 —— 需要产品能够从海量的信息中找到什么是最重要的？找到那个必须要做的事情。
这个是个好问题：
我的答案如下：
总结一下：