我觉得这问题答案是“有技术很好，但没技术也没差”
不管是产品经理、专案经理都是PM
他们专注的点本来就该是在产品功能跟需求本身
会技术当然有助于他们可以比较明确的评估“这做不做的到”“做这个要多久”
但没技术就不能当好PM吗？也未必
重点还是PM能不能帮忙挡需求
说服User天马行空的幻想
懂得安抚RD
当起User跟RD之间的沟通桥梁
这才是PM该做的事
如果PM不能够站在RD的立场
那PM会技术搞不好更糟
“我也以前（十年前）也是有写过程式，这个应该很简单”
“我以前也写过类似的功能，给你一天的时间应该够吧”
（但可能环境的不同时间要更多）
遇到本来就不懂技术的PM你可以安慰自己人家就是没写过程式
但遇到这种写过又喜欢把以前经历套用到现在的PM你拳头才真的硬到不行
所以我认为PM应该还是专注在产品功能面上
当然可以去试着理解专案用到的架构与技术特性
但做这些事目的也是为了要在与User谈判时
提高对于需求的可行性以及时程预估的准确性
但最重要的还是PM能否担任与User之间的沟通桥梁
这才是PM在团队中最重要的任务
※ 引述《annedoo (安安)》之铭言：
: 大家好，我本身是产品经理、专案经理都做过的PM，
: 大学念的科系名字里有个“资”字但非本科生，
: 好奇身为软件工程师的各位，认为PM到底需不需要是技术背景、甚至会写程式呢？
: 我大学的时候也有程式设计的课，
: 但就是在那时候发现自己写得不快、写得不好、也没兴趣，所以很挫折，
: 因此觉得这辈子绝对不会做跟写程式有关的工作！
: 最近突然看到一个粉专（我是PM，有兴趣自己查，他们来板上发过文），
: 写了篇文章说明为什么PM需要有技术背景：
: （以下不完整节录）
: 作为一个技术出身的 PM，我会建议产品经理们真的要懂一些技术。更准确来说，PM 要懂的不是技术，而是用技术解决问题的思维。这样不仅可以帮助 PM 更好的和 RD 沟通，也帮助 PM 从更多面向思考如何解决用户需求。
:
: 什么是技术解决问题的思维，我们可以简单理解为四个要素：前端、API、后端、数据库。
:
: 举一个最常见的需求：用户注册。以四个要素分别来看的话可能会拆解成如下步骤：
:
: 1. 前端：用户输入注册资讯并送出
: 2. API：接收用户资讯，传递到后端
: 3. 后端：验证注册资讯是否合规，处理资料格式
: 4. 数据库：于 users table 写入用户资料
:
: 接着可能还会需要回传对应的结果并展示在前端等等，我们这里不作讨论。这样分解下来，每个技术环节分别要做什么就十分明确了，RD 脑内也能开始把这样的逻辑转化成程式码。
:
: 那 PM 对于技术该懂到什么程度呢？越多越好。如果一个 PM 技术力越强，RD 就会对你越尊敬。一来他们知道你跟他们有共同语言，是跟他们站在一起的；二来他们也知道，若不接受你提出的需求，你完全可以跳过他们自己动手。
:
: 最后也是最重要的，PM 如何提高技术能力？
:
: 1. 向 RD 学习：回到开头的情境，有的 PM 可能会在被 RD 拒绝后灰心丧气，甚至直接怒言相向，但这其实是一个锻炼技术思维的好机会。这时候我们可以根据上面的四要素，来和 RD 沟通是哪些环节碰到问题。对于实现不了这件事情，是因为现有架构的限制，还是说超过了技术本身的能力。于是，RD 可能会如此回复你：“因为数据库里没有这个字段，我们也就没办法展示在前端给用户看”，这才是真正的原因。一次两次后，你会发现问出笨问题的频率越来越低，你越来越常帮 RD 们挡下技术上不合理的需求，团队的关系也会变得更紧密。
:
: 2. 动手写程式：要锻炼技术能力最好的方法莫过于自己动手写程式了。其实写简单程式并没有太难，不需要买很多书来看，不需要懂计算机概论，只需要在 Youtube 上找些简单的教学来看，然后订一个题目来实作就行。
:
: 简单开始的几个步骤：
: 1. 完成开发环境的建置
: 2. 了解变量宣告、if/else 判断及 for/while 循环等基本语法
: 3. 完成一个“Hello world!”
: 4. 完成一个小题目：例如 To-Do-List
:
: （以上不完整节录）
: 1. 不知道大家认不认同这个文章的想法呢？
: 2. 在自己的经验中，PM有/没有技术背景造成了多大的差异呢？
: 3. 在了解技术这方面，有什么可以给软件业产品经理、专案经理的建议XD
: 我身边有/没有技术背景的PM都有，
: 私心认为两种都可以做得很棒，在团队内部可能也会是不同的定位取向，
: 不过自己说不准，感觉还是要合作最密切的工程师大大来分享比较实际～