“知识的诅咒”这一说法，最近读到于《让创意更有黏性》一书，最早由斯坦福大学的伊丽莎白·牛顿通过实验提出，此人随后也因此研究获得心理学博士学位。“知识的诅咒”，说的是一旦某人掌握了知识A，那么他很难从一个“无知（知识A）者”的角度去看待问题，无法理解和估计“无知者”的想法。
这一观点近似于庄子的“子非鱼，安知鱼之乐？”不同之处在于，它似乎更应当被翻译作“子乃鱼，安知非鱼者焉知鱼之乐？”
举几个例子。喜欢汪峰、白桦的八零后歌迷，无法理某些解九零后为什么如此痴迷“东方神起”以至于甘愿为了“哥哥们”而“献身”；使用 Google Groups 进行知识管理的用户，无法理解百度贴吧对某些游戏玩家而言是多么地解蛋疼；去过世博的朋友，无法理解为什么现在还有大波大波的人争相去烈日下扎堆等待三四个小时，就为了进中国馆看8分钟的人造和谐短片；依然打着光棍的宅男，无法理解刚跟女友分手的帅哥即将孤单面对七夕情人节的寂寞（虽然此时二人的 isAccompany 属性都是 false）；吃到葡萄的既得利益者，无法理解底层群众渴望共同奔小康的“酸葡萄心理”……对了，手里握着 iPhone 4 还嫌天线信号不好想要讨个说法的家伙们，你们无法理解我此刻我若能入手一部，该是怎样激动到拜春哥。
当“知识的诅咒”作用于一个共同协作、由不同专业人士构成的项目团队，那么它便很容易表现为“思维的诅咒”。所有人按照自己的专业基础和知识构成来思考，对同一个问题折射出多个角度的理解。
例如，对于新增一个功能需求，工程师会从实现可能、程序算法、性能参数等角度着手，设计师会从展现形式、风格布局、字体配色等方面考虑，运营和市场推广人员则会以用户需求、市场前景、突出卖点等因素为关注重点。
这之间往往存在矛盾。例如，市场人员认为功能X将会引领潮流，但工程师觉得目前的技术或资源支持无法达成。工程师认为辛苦开发了几个通宵的若干个新功能就要全部提供给用户，但设计师觉得简洁就是美。设计师觉得华丽的Web2.0互动效果能让人赏心悦目，但市场人员的调查报告却显示百度贴吧是中文第一大社区。工程师、设计师、推广人员一致看好的 kill features ，用户却死活不肯买账。
很多时候，我们还是应当遵循伟大革命导师的教诲，一切从实际出发。但同样有很多时候，许多矛盾并非不可调和，而只是沟通不利，产生了“思维的诅咒”。大家都依照自己的专业知识来做判断，忽略了其他人的立场和观点，并且无法理解他人为什么无法理解自己的意见。
这就要求一个同时兼具百家之长的人物站出来，协调各方关系，权衡利弊得失，通盘考虑全局，择选最佳策略。在一个产品团队里，这个人很有可能就是产品经理（PM）/产品设计（PD）。
从通常意义和实际需求来讲，PM/PD 应该是博学多识、见多识广的。Ta 需要大量接触和试用产品，同时也应当具有一定的编程功底、设计师素质、市场人员的“土狼”精神。只有灵活地在三种思维间切换，才能最客观地理解某一需求的实质和可行性，并且更好地设计和监督该需求的实现情况，最终让各方满意，以最优解的形式呈现在用户面前。
同时，一个项目有了好的PM/PD，也不一定代表项目就能成功。我总结出好的项目的成功概率公式，应当是：
项目成功概率 = （PM/PD的靠谱程度） X （PM/PD的决策权力） X （全体团队成员为实现预期而努力的程度）
一、三两个变量因子基本取决于个人的主观能动性。第二个因子（PM/PD的决策权力）则由行政制度决定，是一种客观。权力越高，据理力争的实现成功率越大，但承担风险的可能也越大。因此，对于各方意见时常无法达成统一的项目，决策者的“集权”往往是最快最有效的解决争端的方式。
当然，权力导致腐败，绝对的权力导致绝对的腐败。“集权”从历史上到现实中都不是一个值得正面歌颂的褒义词。于是，PM/PD的靠谱程度就变得至关重要了。
同样的道理也适用于判断一个国家是否真的能健康运转，长治久安。扯远了。
最后，我无法理解读完本文却依然云山雾罩不知所云的读者。在我看来，若不是我已经被知识诅咒，就是你活该被打手堵揍。