创业产品经理需要懂技术吗？

作为一位工程师，和一位在不断追求更好产品的设计人员。个人认为，产品经理最好是这样的：
一、精通技术。技术很容易框住人的思想，要不特别精通，能随时跳出技术的束缚，带给产品真正的提升。一般这种产品经理会出现在像 Facebook 和 Google 这种工程师能主导产品的公司，或者一些技术型创业公司。
二、不懂技术，喜欢天马行空，又能听得过工程师的建议。精于产品的设计，生命周期管理。
如果只是略懂点技术，可能（注意，是“可能”）会带来思想上的限制。一个人永远不能管得了那么多，精通得了那么多。有时候我们更需要的不是会技术又会懂产品的产品经理，而是相信伙伴能做得好，并鼓励其一起去做得更好的产品经理。
这里我觉得需要看“懂技术”是属于哪个模块的，架构，CODING，还是算法逻辑？个人认为，互联网公司的产品经理需要了解的是从需求到实现的解决方案，根据项目资源，做出最佳选择~ 更偏向综合性质吧
打个简单的比方:
产品经理相当于一个打车的，知道要去哪儿，并且知道：哪条路最短；哪条路绕一点但是最顺畅；如果哪条路限行了，该走另外一条路。。。那么，技术开发团队就相当于是司机。打车的可以不会开车，但是要到目的地，知道上面的东西，可以省钱，省时间~ 司机可以接不同的人，不同的路线，只要能走到目的地就行~
优势：
1) 在考虑产品可以有哪些功能时，自己就能确定大部分功能是否可以实现，实现的成本有多大，能不能做，而不用咨讯相关专业人员，省出很多时间。
2) 在缺兵少马时，自己还能担刀上阵折腾一把。
缺点：
1）容易跌入产品的实现细节去，而忘记自己更应该思考的是这个功能应不应该做，要做成什么样子，应该在什么时候完成，谁来做，要做的功能还有哪些—-而至于如何实现，应该交由具体的成员来做。
2）在与产品团队成员讨论功能时，忍不住想发挥下自己的技术，过多掺和到团队成员的专业领域，会令他们心里排斥，虽然很多时候他们没有很多说出来，而每个人都想发挥自己，希望证明自己所想的是对的。
扬长避短：
1）在进行技术思考时，只需要知道可不可以实现，而不应过多去考虑它如何实现。
2）将表现机会留给团队成员。在与团队成员讨论功能的实现方案时，谨记你给出的只是建议，而不是命令，除非该成员对如何实现某个功能真的一愁莫展，除非该成员是个新手或者能力太烂，又或者这个功能至关重要。
3）因为是技术已经深入技术型产品经理的基因，所以理所当然对技术会有所关注，要注意的是，不能把太多时间投入到技术（假设你的公司不是技术驱动型），在运营、营销、用户体验也要给些精力。
我认为，如果你能达到下面三个要求，懂不懂技术都无关紧要。
一，很多产品的诞生往往和技术创新有直接联系。如果你能对新技术的发展有敏锐的嗅觉，并且理解新技术可能对用户带来的价值，那么，你不需要懂技术。
二，如果你可以和开发团队流畅沟通，你能明白他们的困难，他们能理解你的表达，那么，你不需要懂技术。
三，如果你的需求从来不会以“不具备技术可行性”被开发打回，那么你不需要懂技术。
有些懂技术的人这三点也未必做好，有些不懂技术的人这三点也做得相当好，呵呵。
但从概率论上，懂技术的人会处理得相对好一点。
仅供参考。懂技术的好处Fenng已经说得很全面了，没太多可以补充的。
不懂技术是可以的！
我来说说不懂技术的情况吧：
很多产品经理不懂技术，在国外尤其常见，也有产品经理技术很老土，90年代80年代的技术早就过时无法再用了，这类产品经理需要注意什么呢？
1. 用户体验，你身为一个用户要知道我想要什么，我最需要什么，另外你千万要注意抓重点，不要总是想设计一个完美的东西，技术的时间和精力是有限的，你会苦了他们。抓到重点，把精华的部分做好就可以。这里有个小窍门，你每次确定需求后，砍掉最为不需要的20%，发现不好砍就纠结一下再看，这样会对技术好很多，切忌不要完美主义。
2. 不要改来改去，想好了，写成书面文档，再去和技术沟通，不断修改，不要等技术做好后你又因为不符合你的意思而大发雷霆。
3. user story一定要写得详细，你要永远清楚项目经理是催人干活的人，产品经理要是编故事的人。无论是增发模块还是重构，都必须要以用户故事为蓝本。同样记得砍20%，别把故事编成科幻小说。
以上都能掌握之后，你就是一个好的产品经理了，可以一行代码都不会写，但是一样能设计出好的产品。
我是开发出身，我不是产品经理，我是半个产品经理（交互设计师）；
有过开发的经验，我和开发的同事交流起来，相当舒服，我会非常尊重他们，我知道写代码的过程和感觉是怎样的，所以我认为懂一些技术，懂开发，这样会更好一点；
创新工场的刘静在HiUED的交流会上曾经说过一句话，多元化的背景对于设计师来说是相当好的，我也延伸一点，多元化的背景对于产品经理来说也是相当好的！
至于懂到什么程度，到能讲明白功能的代码实现原理即可。