月经文来着。
我两年前曾经在板上问过这个问题，
偶尔也会有人站内信找我讨论，
所以就写了一篇文章分享自己的想法、跟大家交流交流～～～
Medium 有图有参考连结好读版：
https://pse.is/3hk2n9
懂技术当然比不懂技术好，上知天文下知地理当然比什么都不懂好。而会有人不断讨论这个问题的原因大概分为两个层面：
1. 想要转职，不知道技术知识到什么程度才能找到产品经理的工作机会
2. 已在职中，身为 PM 不确定自己技术知识够不够，还能朝哪些方面加强
将问题拆解后，我们背后真正想问的是：
- 若要成为一个及格的产品经理，对技术的了解要有多少？
- 产品经理有那么多种技能要点，技术在这所有技能中有多重要？
- 为了转职/为了职涯发展/为了让工作与沟通更顺畅，我应该优先补足技术知识、还是精进其他技能？
【文章目录】
- 产品经理什么时候会用到技术知识？
- 所谓的“懂技术”是什么意思？沟通技术的不同层次
- 怎样才算是够懂技术了？
- 如何跟工程师合作？
- 结语：产品经理技能树
这边先长话短说、下个小结，一般来说：
PM 对技术的理解，要足够跟工程师沟通、安排资源、解决问题。
也跟工程师们喊话下：
你的 PM 乱答应需求、乱订时程不一定是因为他不懂技术，
有可能只是因为他不懂得沟通与拒绝的艺术。
▍产品经理什么时候会用到技术知识？
目标：加速产品开发、确保团队在往对的方向前进
有技术知识的 PM 能够：
- 了解产品的核心技术竞争力，对于在做的产品有正确的认识
- 分辨市场上其他竞品强不强，是强在技术还是其他地方
- 在做产品决策、优先级排序、规划与协调资源时更顺利
- 跟工程师与技术单位沟通时更顺畅
拥有技术知识，让 PM 在以下工作阶段更顺利
- 研究问题、讨论解法、优先级排序（需求方、使用者、客户）
- 资源安排＆实作（设计师、工程师）
- 处理紧急 issues（整个团队）
写程式不是 PM 的工作！
有些人会有个迷思，好像 PM 必须要会写程式才能做好自己的工作。
问了一些工程师朋友和同事，PM 的技术能力要到什么程度？他们的答案是“可以跟工程师沟通就 OK”“了解技术限制、复杂度、成本之类的就很棒了”“不会写程式没什么关系啊”“写程式是我们的工作吧！”
如果你觉得学会写程式就能成为一个好的产品经理，那我会说你只是在偷懒而已。
拥有技术知识、懂产品背后的逻辑，并不代表你自己需要会写程式。会写程式当然很好，能更懂行话、也对跟工程师沟通有帮助，但与其自己实际练习写程式，我会宁愿花时间在其他地方。
▍懂技术是什么意思？懂技术的不同层次
PM 不用知道如何写程式，但要知道产品背后的逻辑与技术限制。
技术知识要能输出成为“理解能力”与“沟通能力”两个方面才有用：听得懂是第一步，能够参与讨论是第二步，有能力做出合理的判断是终极目标。
我将技术知识含量多寡以及能达到的成果分成以下几种类别。
【高】技术知识作为决策的一环
- 跟需求方讨论时，可以判断做不做得到、难易度如何、可能遇到的问题
- 排序产品与问题优先级时，能精准的将技术复杂度作为一个维度来参考
- 能够将核心技术转化成产品的核心竞争力之一
- 能够从头参与新产品、新服务的讨论，包含选择什么技术来实作、数据库架构的字段与内容、是否要找第三方的服务来串接
- 了解技术团队使用的外部服务（AWS、Sentry、CircleCI）的成本
- 了解什么是正确的时机 refactor、解决技术债（Tech Debt）、Legacy Code 的问题
【中】良好的沟通媒介
- 接收需求时，能清楚厘清问题内容，以利后续跟技术团队讨论实作可行性跟时程
- 接收需求时，能判断是否跟目前逻辑相违背、有没有 dependencies 等
- 接收需求时，能描绘出改动的范围大小，并向需求方建立正确的期待
- 讨论产品解法时，能顾虑到技术限制、技术可行性
- 与技术团队讨论时，知道该问哪些问题、听得懂对方的解释、参与讨论
- 遇到 issues 时，知道怎么回报、怎么重现 bug 并提出可能的原因
- 若需要跟第三方服务或客户串接，要看得懂技术文件，或至少知道哪一部分需要跟技术团队确认
- 在写产品文件时，能将部分技术规格也纳入其中，并搭配工程师的 Techical Spec
【初】基础中的基础
- 了解最基本的网络产品如何运作
- Daily Standup 时听得懂工程师说明他在做的事、遇到的困难
- 遇到问题时不会问错人！前端、后端、Data Team 的工作范围都不同；就算都是后端，他们负责跟维护的部分可能也不同，要能判断这块需求或问题要问谁才对
- 能够和工程师一起处理 issues & bugs
【零分】能力不足
- 听不懂工程师说的技术名词却也不会问
- 不懂得厘清需求方的问题，要来来回回问工程师很多次
- 工程师回复之后也无法好好解释给需求方，让需求方了解技术限制或 bug 发生的原因
- 规划产品时没考虑到技术问题，也没咨询过技术团队
【哎呀扣分】懂技术不是让你用来不尊重专业意见的
最忌讳的就是 PM 觉得自己懂点技术，所以就不尊重工程师的专业意见，因此自己压时程、乱答应、质疑工程师的判断。
有时候一个乍看很简单的东西，可能会因为自家产品背后混乱的 codebase 而变得难以实作，或是需要先进行 refactoring 才有办法开始开发。
每一间公司、每一个产品都会有不一样的状况，因此不要轻视彼此的专业、不要帮对方做决定，大家在能力上应该是互补的关系，而懂对方的语言的目的只是为了让内部沟通更顺畅。
另一种状况是 PM 太过关注技术复杂性。我曾经因为觉得某个东西技术上应该很难实作，所以就自作主张推掉需求，但后来才发现其实工程师能够想到其他很好的技术解法，这就是自以为懂技术的糟糕心态。
应该说，每个人各司其职、为自己的位置与角色发声才是最好的平衡。我不应该过度帮工程师担心技术的事情，而是应该带着我身为 PM 的想法与立场去沟通与搜集专业意见，同时设定好双方的期待。
PM 很常需要在中间当协调人或决策者，势必要能够听懂别人说的话、了解别人在意的事情，但不是取代其他专业同事应该要做的事。
【翻译蒟蒻】除了跟行内的人沟通，还要能够解释给外行人听
当老板、业务、客服问 PM 为什么这个做不到、为什么会发生这些 issues，你能不能用很简单的逻辑与案例解释给他听？
当一个产品需求会被拒绝，有时候是需求本身不合理、有时候是设计上的难题、有时候是技术上的限制，PM 在接收需求的时候心中就要做简单的分析，知道这些问题该问谁、问完之后有哪些因素影响团队做决定（做或不做、优先级如何），跟产品团队讨论完后再回去找需求方沟通。
遇到 issues 的时候也一样，PM 就像一台翻译机，客服回报问题，PM 整理好问题影响范围、重现方式并翻译成技术语言给工程师听；工程师找到问题后告诉 PM 背后的根本原因和可能的解决方案、PM 再翻译回去给客服听，讨论该如何跟客户或使用者沟通。
最后是关于一些常见的技术问题，团队应该要建立起共同的知识数据库，避免一样的问答不断重复发生。PM 总是帮忙工程师回答问题也不是办法，文件化并分享知识给同事才是最有效率的作法。
▍怎样才算是够懂技术了？
标准答案：看公司！看团队！
1. 最基本的技术知识
延续上面提到的技术与沟通等级，对新手 PM 来说，有【初】基础中的基础就不错了，其中的了解网络产品如何运作包含理解以下名词：
Backend、Frontend
Server、Client、Cloud、DNS
Database、SQL
FTP、API
Cache、Cookies、Session
Container、Docker、GitHub、CI/CD、Deployment
会使用 Browser DevTools 并大概知道每个区块的作用
2. 技能对应到工作需求
有些公司里面会有 Technical PM (TPM)、System Architect (SA)、Delivery Manager (DM) 的角色，在这些团队内他们会吃下很多技术相关的工作，一般 PM 对于技术知识的理解与沟通可以透过他们来协助。
但另外一些公司则可能会希望 PM 拥有一定的技术知识与背景，所以真正的问题是，我需要多少的技术知识，才能支撑我做好在这间公司、这个产品的产品工作。在面试前可以先：
- 了解这间公司的技术架构，在使用的服务等等
- 找该公司的工程师或其他职位的 JD 来看，是否懂里面所有的专有名词
- 搜寻该公司的 PM 面试题目，看看是否有技术相关题目
Ref: IGotAnOffer — Product manager interview questions (the ultimate list)
如果面试的时候有跟工程师对到，在问问题阶段也可以反问他们对于 PM 的技术能力的要求与期待是什么。如果你想进去的产业跟公司的产品技术含量高，技术背景就会是标准配备。
而每间公司、每个产品的程式架构都不一样，使用的服务、背后的逻辑也不尽相同，到了新的团队或换新产品的时候都需要重新学习跟理解。
在《产品经理就职手册：抓住四大学习重点，让你快速进入状况》中有提到，刚入职时可以请工程师带着 PM 了解目前产品的技术架构和 Tech Roadmap。
若产品经理了解技术架构与限制，也会多少对判断 Dependency 与了解可能的技术坑有帮助。针对这点可以请工程师跟你说明目前是使用什么 Tech stack、前后端如何互相呼叫、有哪些主要的 API / Service / Database，以及我们是否跟其他团队在技术层面会有高度合作关系等等。
3. 基本的捞资料、分析能力
一样根据工作所需，有些基本的捞资料、分析是 PM 会自己做的：
- 用 SQL 捞资料（知道数据库里有哪些字段、怎么存资料、关联性为何）
- 用 Crawler 爬资料
- 埋点、分析 Events、A/B Testing
▍如何跟工程师合作？
有的时候技术问题很复杂、或是程式过去是很多人共同在维护，技术知识学海无涯，工程师本人也不一定随时都知道技术问题的答案，可能会需要先花时间去看一下、研究一下才能跟你讨论。因此问问题与合作时先做功课、虚心请教、给对方足够的时间研究也是很重要的。
执行细节欢迎参考我们过去的文章：
【PM伙伴攻略】如何跟工程师合作？
【PM伙伴攻略】番外篇：工程师雷区干话大全
【PM伙伴攻略】如何与工程主管 Engineer Manager 合作？
▍结语：产品经理技能树
在 《从入门到卓越，产品经理技能检核表与职涯发展路径》中提到的“Technical Sense — 对技术理解的能力”主要集中在 Senior PM 的职涯阶段。不过在这个产业工作，多了解点技术相关知识总还是非常有帮助的。
做产品就是在商业价值、使用者体验、技术之间取得平衡，三种技能一定都会点到，但每个 PM 的兴趣和专长都不同，长远的职涯发展朝向不同方向，相对应所需的知识和技能就会有所不同。
最重要的是，PM 跟商业团队、技术团队、设计团队其实合起来是一个全方位的产品团队，大家做好份内的专业外，自己的能力能够跟团队成员互补、并持续进行知识交流是很重要的，大家要一起成长，才会变成更棒的产品团队！
以上，欢迎 PM、工程师们一起来交流，
拥有什么样的技术知识才足够成为及格的产品经理。