作为一个程序员，却写如何做产品的事情，我并不是喧宾夺主，而是从开发的角度，去思考作为 PM，应该具备的技能。

相信直觉

遇到过上线新功能的时候，要求设计出 2 个方案，然后做 A/B Testing 。我没有反对 A/B Testing ，我反对是动不动就做 A/B Testing 。产品应该对自己的判断有信心，而不是做了两套方案，最后发现数据差不多，然后选择了数据稍好的版本。这中间不仅仅开发的成本要翻倍，上线后的数据收集几乎跟开发一样的成本。如此的投入缺仅仅为了好看一点数据，这样未免有点得不偿失。

A/B Testing 只是手段，产品设计的目的是了解决用户的需求，A/B Testing 只是其实一种帮助我们达到目的的方式。A/B Testing 还可以是用来验证思路的工具。快速试错，快速调整，产品思路正确与否，才是 PM 应该关注和着重思考的地方。

没错，做 A/B Testing 是个很保险的做法，选择数据好看的版本，绝对没错。可是往往很容易忽略了这背后需要的成本，产品设计、开发、数据收集、分析，这些几乎都是翻倍的成本。

作为 PM，就应该相信自己的直觉，适度使用 A/B Testing。

编程思维

程序员最喜欢的产品设计，是那些能做到思考全面的。写代码的时候，如果发现 PM 已经帮你把逻辑分支都考虑到了，不同情况有对应的处理，开发起来，不需要怎么沟通，如流水般顺畅，这样工程师绝对感激涕零。

产品的设计，要做到像代码那样严谨，是非常难能可贵，这也是为什么学过编程或者开发出身的 PM，跟工程师打起交道毫无障碍。要做到这样，需要的就是「编程思维」，它追求的是逻辑的严谨和数据的抽象能力。

逻辑的严谨，指的是要考虑不同情况的处理，所有分支不应该有交集，出现模棱两可的情况，并且并集应该是 100% 覆盖的。数据的抽象，是指产品要知道数据是怎么存储的，如果需要某些数据，要知道可能出现什么样的操作才能得到这些数据。