编程不是产品经理常规工作的一部分，那么为什么公司在招人的时候不会降低要求招到在核心的产品管理技能上真正优秀的人才呢？
简单的说，许多没有软件工程背景的人不能和开发人员形成牢固的工作关系。
如果产品经理疏远开发人员，得不到他们的尊重，那些优秀的产品管理技能将可能被浪费。产品管理是一种无权威的领导，将工作做好的唯一途径就是用你的愿景将团队凝聚在一起。
没有技术背景而成为伟大的产品经理是有可能的，但是你需要找到同开发人员建立强关系的方法，还要经历开发人员工作上的障碍。
下面的三个部分，我将介绍非技术出身的产品经理常犯的三个错误，以及如何避免：
认为技术人员是不会说话的程序猿
我不会说法语，但是有人会说——对此我并不吃惊。毕竟有太多精通两种语言的人。
如果我想让我的博客在法国产生作用，我应该找一个母语是法语的人翻译出来。但我并不认为翻译者对博客有着和我相等的贡献。
这正是许多非技术出身的产品经理对开发人员的看法。他们认为，开发者仅仅是简单地将想法翻译成代码。从他们的观点出发，提出想法的人才是重要的，技术人员不过是会编程的猴子。
开发人员也见过太多这样的态度，这导致了他们对产品经理相应的印象——非技术出身的产品经理不过是在办公室里“受欢迎”的哑巴MBA，他们不懂设计，也不知道如何建立伟大的产品。
如果你是非技术出身的产品经理，一定要确保自己不把开发人员当作程序猿。你或许认为你是团队中最重要的人，但是一个没有产品经理的团队依然能够运转软件，没有开发人员的团队则不能。
了解下开发人员真正在做什么，花点时间和他们聊聊天，问问他们的工作情况。问一问他们最喜欢的技术，以及他们应对过的挑战。你就能减少他们敲代码的工作量，就像减少记者码字。
对事情的难度有错误的判断力
我喜欢的一档电视节目是《舞林争霸》，身怀绝技的舞者跳着不同风格的舞蹈，从芭蕾舞到霹雳舞。当我看比赛时，尝试着猜测评委的反应。最令我惊讶的事情是，许多看起来容易的动作其实很难，许多很难的动作其实很容易。
就像跳舞的经历能够帮助你理解舞蹈动作的难度，有技术背景能够帮你获得精准的视角，来看待在工程中如何挑战不同的事情。
如果你不是技术出身的产品经理，要谨慎，避免因对困难的事情有错误的判断而犯错。许多代码看起来比实际情况容易。有时候，直截了当的方法会让产品进步变慢，这就需要一个较复杂的方法。
相反，如果你在框架设计时完成了困难的工作，许多看起来困难的事情可能就比较容易。如果你不能明白这些不同，你会陷入一些令人非常沮丧的对话。你会认为开发人员不关心设计或故意拖延。你会错失一些简单的提高，因为你没有意识到它们会很容易。
如果你没有技术背景，你依然可以培养你的判断力。注意工程师在困难的工作类型上花费的时间。当你有了新的想法，根据你以往的观察，首先自我评估这有可能用多长时间。然后，同工程师分享你的想法，并让他们估计他们将会用多长时间。
如果你们的估计并不相同，那就谈一谈这个问题。注意，不要让人听起来像是不相信他们或认为他们偷懒。你可以说，“你能不能多谈一谈，为什么这会用3天，而插入相似的功能只需要1天？我在培养看不同的事情花费多长时间的判断力。”
努力找到模型，你就会知道在你产品设计中，什么挑战是困难的，什么挑战是容易的。不要气馁，学习的决心会带你走得更远。
在你可以做的事情上浪费工程师的时间
你是否曾经用过“你帮助我搜索一下”？这是一种愚蠢的方式，表明大多数人本可以自己找到问题的答案。
这是一件相当令人失望的事情，即有些人明明可以依靠自己找到答案，却依旧在浪费你的时间。当产品经理们对他们的工程师这样做的时候，往往是他们对于自己该去学习的东西划了禁区。
这便是第三个非技术出身的产品经理易犯的错误：在你可以做的事情上浪费工程师的时间。如果你发现你的团队成员似乎很沮丧地回答你的问题或者忽视你的要求，自省下你是否可以自己来做这些事。
一种很有用的起步方式是分析数据。了解你的产品日志以及如何访问这些日志。你可能需要学习如何写SQL命令。花一天时间去学习SQL。这个时间投入是值得的，因为你可以节约工程师文字切换的时间。另外，当你能快速看到这些针对你数据问题的答案时，你能重复这些问题并深入挖掘以获取更本质的认识。
另外一个可以考虑的方面是阅读代码中的简单信息。如果你花几个小时学习如何通过团队代码库进行搜索，你可以自己解答各种各样的问题。很多团队拥有对产品经理很有用的资料库，可借此来知晓诸如列入黑名单的关键字列表或者所有运行中的测试名单。
