产品经理需要技术背景吗？
我在拥有这种观点的人们中看到的最常见的线索出人意料地围绕团队本身。这种观点认为，技术上的产品经理可以与软件工程师建立更牢固的工作关系。如果项目经理说的是与工程师相同的语言，则相互之间的理解和尊重更容易培养。
同样，知道如何编码的产品经理可以更好地了解工程团队的能力和局限性，并且可以更好地计划需求，而不会导致团队的未充分利用或过度利用。
许多人还同意，如果产品用于技术目的，那么PM绝对应该具有技术知识。这很有道理，因为如果PM不了解需求，那么最终将危害最终产品的质量。
论点2：产品经理不需要技术背景
这个思想流派中的许多人认为，PM不需要技术背景，因为他们的工作是为最终用户提供最好的产品，而不用担心其实现方式。花费在微观管理实施上的每一刻都减少了PM聆听用户需求的时间。
没有技术背景的项目经理仍然可以学习工作中的要点。由于他们与技术团队合作，因此PM可以对架构，技术和团队速度有深入的了解是完全可行的。
另一个原因是，没有技术背景的PM不受他们认为在技术上可能的限制。例如，技术PM可能会忽略需求，因为她认为在时间限制下这是不可能的。但是，非技术性PM不会遇到这个问题，其好处是它可能导致完全创新的情况或为工程师解决挑战。
没有技术背景您可以做什么
即使您没有技术背景，您仍然可以做很多事情来“获取技术”并建立对团队的尊重。
采取步骤发展技术基础
作为产品经理，您应该渴望能够：
- Ballpark估计完成一项功能将花费多长时间（或具有足够的技术知识，可以与直接的利益相关者（即工程师或工程经理）进行适当的对话，以了解需要花费多长时间？
- 跟踪产品流程以了解基本的用户问题
- 了解可能出现的任何技术问题的潜在解决方案背后的逻辑
- 列出将受到那些建议的技术解决方案影响的产品区域（以及所有相关挑战）
时间轴估计：每当行业新手非技术性的PM问到他们应该如何处理特征时间轴估计时，我总是会提到，随着时间的流逝，很多时间都归结为模式识别。随着您与开发/设计团队的合作时间越来越长，您将开始了解以下模式：谁工作很快，谁没有工作，谁往往高估了自己的时间表，谁快速编写代码但由于频繁的错误而需要进行额外的代码审查等...
在任何项目的开始，您都应该始终努力与任何直接的涉众进行沟通，以了解他们的想法。不要扮演试图为整个团队进行估算的英雄；您可能没有关于在开发过程中可能出现的技术限制/挑战的完整背景。在项目结束时，您应该致力于反思估计的准确性。如果情况不佳，请设法了解发生了什么，并将这些数据纳入您未来的估计中。
逻辑： 了解技术问题背后的逻辑并不意味着您需要自己诊断和实施确切的解决方案。您可能要采取的第一步是了解/映射产品中的所有用户流，以便您可以更轻松地将任何用户问题追溯到潜在问题。绘制这些流程会在您的脑海中产生一个“思维迷宫”，因此，每当提出新功能/解决方案时，您就可以更容易地识别出可能会受影响的产品组件。
记住，作为一名PM，您将必须帮助对许多潜在问题进行分类。您想要做的最后一件事是成为一个无用的中间人，他只会接受错误并将错误分配给工程师，而又无法诊断可能发生的情况。这是一种失去工程团队尊重的保证方式。
不要让您的开发团队对您有这种感觉。
您希望不要再说“我不知道”，而要说“好吧，我们不知道确切的解决方法，但我们确实知道发生了A问题，从逻辑上讲，我们可以追溯到B或C开发逻辑来识别根本问题和可能的解决方案将节省您的团队时间并赢得他们的尊重。
开发技术好奇心：可以说，这最后一部分是开发技术基础的最重要部分，因为它需要内在的动力来学习更多有关技术主题的知识。我们在文章中讨论了作为新产品经理升职时应该采取的前5个步骤，但是，只要有机会（不会造成破坏），就应该与一位工程师（或几位）坐下来了解您产品的技术堆栈。
在进行任何正在进行的项目时，您应该争取腾出时间与工程师讨论实施细节，以便围绕可能出现的取舍或未曾想到的情况进行讨论。
向您的开发团队学习尽可能多的知识！
我总是建议所有非技术和技术PM都需要掌握的一件事是对SQL有一定的了解。弄清楚产品数据的存储位置，并了解产品日志的结构。这样，如果您需要提取一些数据点来运行自己的分析，则可以简单地使用SQL命令自己查询和提取数据，而不会浪费工程师的时间。
您可能想做的另一件事是开始熟悉代码库的某些部分。例如，如果您正在检查团队正在运行的拆分测试的ID，则可以简单地自己访问代码库并搜索测试。您可以尽力节省工程团队的时间，让他们专注于工作的任何事情都将受到赞赏。
最终，没有一个正确的答案。这在很大程度上取决于公司，产品和团队，每个公司可以为理想的PM强调不同的质量。
最重要的要点是，作为一名PM，您的工作就是为您的用户提供最佳的最终产品。无论是需要您更多地参与开发过程还是要更多地参与对客户行为的深入了解，都必须交付产品，并且产品必须对您的用户而言是惊人的。
