原标题：程序员漫谈产品设计

我是做技术的,对互联网产品一窍不通,更谈不上产品感觉,但这么多年和产品的配合,通过自己的观察,也没忍住对产品来一番纸上谈兵，产品经理不要指望能从中学到什么，因为会发现很多正确的废话，我无非是提供了一个程序员的观察视角而已。

假设产品为x，网络用户为u，产品的目标就是设计x，使得f(x,u)取得最大值，f可能是取日活，也可能是付费收入。x实际是无限维的，可能包括界面颜色，提示信息，免费下载数量，简化起见，可以以一维来思考这个问题。

产品的任务抽象之后，我们发现，所有的互联网产品（甚至任何产品），都可以抽象为一个寻找f(x,u)的最大值问题。问题的关键是我们不知道这个函数是什么形状，否则我们能够直接找到最大值，比如x：颜色为红色，允许免费下载6首，此时得到最大的f(x,u)，比如日活100万。由于不知道这个函数的形状，找到这个函数的最大值便是困难的，无数的产品经理为此苦苦探索，所有产品的方法论都围绕这个核心问题。以下几种方法是常见的：

爬山法。

我们不知道f的形状，为了寻找最大值，我们根据直觉找到一个点x，然后通过反复迭代调整x，以期找到f的最大值。这种方法是目前最普遍的方法，即小步快跑，逐步得到产品版本x1、x2、x3….，这些产品能够让函数f的值逐步提升。这个时候产品的直觉非常重要，一开始找到一个合适的起始点x，离山峰太远，其次在迭代开发的过程中能找到合适的△x，以使得f(x+△x,u) > f(x,u)。

但这个办法有一个严重的问题，就是会陷入局部最优解，除非这个函数是严格的凹函数。如果很幸运，这个函数是严格凹函数，那么这个方法一定能找到最优解。很多公司的产品经常陷入局部最优解，或者已经接近全局最优解，梯度很小了。这个时候的产品经理很悲催，具体如何悲崔见各大互联网公司的加班情况。

模拟退火法

爬山法的缺点模拟退火法可以解决，这个方法在一开始尝试较大的△x,大步向前，然后慢慢的改成小步快跑。这个方法的的优点是在一开始△x较大，有较大的概率找到一个较高的山峰来爬，然后在此山峰的山腰上往上爬。

该方法能大概率设计出最好的产品，但是缺点也很明显。那就是较大的△x俗称大改版需要付出成本和承担风险，没有谁知道你这次大改版是跳到了一个更高的山峰上还是跳到了一个更矮的山峰的山腰上，大改版失败的例子随便搜，比如vista。

遗传算法

大规模集团军作战方法，适用于只许成功不许失败，不计成本的产品。这个方法一开始就选择多个不同的产品原型开始x1、x2、x3，然后这些产品做交叉遗传和变异，经过很多一代的演化，最终得到最优的x。这个方法的优点是基本能找到最优解，缺点是成本高。以微信为例，就是多个团队同时开发，最终广州团队胜出。

智能方法

这是个人的幻想，不要当真。上面的三种方法都建立在函数f的形状不知道的条件下，假如我们有某种方法能提前知道函数f的形状，那么我们当然是又快又最优的设计出了产品。这种方法有没有，其实有的，但只是对个别维度有用，比如根据以往的收费情况，我们通过模型预测出定价为50元的情况下，付费是最优的。这个时候我们就不需要去不停的尝试不同的定价：20、80、45、60、48、55、50。

现实情况往往更为复杂，很多问题没有深入探讨，这里没有考虑市场、品牌、竞争对手等因素，尤其是没有考虑时间因素。尤其是时间，在不同的时间f(x，u)的形状是不同的。比如在2006年，瑞星如果启动免费策略，此时函数梯度很大，也许f(x,u)函数能取到很大，但2011年，再启动免费，已经于事无补，因为函数的形状早就变了，用户反应波澜不惊。

另外一个常见的问题就是选择了错误的函数f,比如选择日活，最后发现日活都是僵尸日活，带不来收入。在基层执行的产品经理还面临一个实际的问题，不同的领导告诉他们不同的函数，或者同一领导不同时候取不同的产品经理苦不堪言。

总之，程序员就像是一个爬行在函数曲线上的虫，产品经理就是骑在虫背上指挥的盲人，骑手的感觉决定了这次冒险的结局。以上拙见，供人一笑，抛砖引玉，共同探讨。

作者：Dr.Liu