只推三本的话
人人都是产品经理---针对产品经理的工作职责，内容，有个大概了解和脉络，知道自己要干；
用户体验的要素--专业学习用户体验之道
掌握需求过程--专业学习怎么掌握、获得、分析、挖掘用户；
三本书互补，对岗位的各个技能的都有了解和学习。
一、产品市场
《引爆点》——产品市场与运营推广
《长尾理论》——产品市场
《魔鬼经济学》——产品市场
《影响力》——产品市场
《怪诞行为学》——产品市场与用户行为必读
二、产品设计
《用户体验的要素》——你们都懂的
《就这么简单》——用户体验科普
《锦绣蓝图》——Web信息架构必读
《Web信息架构》——Web信息架构必读
《创造突破性产品》——PM启蒙读物
《写给大家看的设计书》——UI设计必读
《应需而变，设计的力量》——培养同理心
《简单法则》——设计思想
三、团队合作
《决策与判断》——换位思考
《只有偏执狂才能生存》——情商
《演说之禅》——气场与感染力
《启示录》——团队
补充：
移动端的PM在产品设计部分关注的知识及书籍略有不同，
《移动设备交互设计》——移动交互入门
《移动应用的设计与开发》——移动产品入门
《Tapworthy（触动人心）》——IOS设计
《App Savvy》
《Mobile Design Pattern Gallery》
《简约至上》
另外目前国内的产品经理定位很多偏重于产品体验和需求把控，还有一些产品经理其实带的是项目或者产品团队，因此推荐以下几本书：
《项目管理之美》：偏重于项目管理
《掌握需求过程》：偏重于需求挖掘
《流程管理》 ：偏重于项目型团队产品经理
《网站设计解构》：偏重于Web产品经理
《瞬间之美》 ：同上
《用户体验的要素》：同上
《GUI设计禁忌》 ：偏重于客户端产品经理
《About Face 3交互设计精髓》：偏重于客户端产品经理
《用户体验度量》：有一定用户群产品的产品经理可以看
《胜于言传：网站内容制胜宝典》：资讯类网站产品经理最好看一看
《Web导航设计》：虽然偏重Web，但个人认为客户端产品经理也可以看。
书海无止尽，开卷总有益。
然而每个人负责的产品不一样，所以从需求到设计再到团队构成，知识结构是非常复杂的，大家还是需要多从实际出发来选择适合自己的书籍。
产品经理和程序员,如何避免矛盾？
同程序员不一样，产品经理主要是同人打交道，要组织处理好很多复杂的关系和工作，良好的沟通能力，组织协调能力，资源运用能力，推动和协调各部门的合作和有序进展，是一个产品经理需要具备的综合能力，所以做好产品经理并不是一件容易的事情，很多方面的素质培养是必不可少的。
协调沟通能力
产品经理要协调好各种关系，包括研发、测试、文档、市场、销售等部门的人，在保证品质的情况下如期的推出产品。任何事情都是靠人实现的，所要协调的主要是人力资源，绝不能因为要完成一个OEM的项目而占用所有测试人员的时间。不同部门的沟通并没有多大的区别，但不同部门的Leader做事方式可能不一样，因此一方面要看对方配合的程度高低，同时要学会在恰当的时候和恰当的人谈恰当的问题，只有解决好问题才能有效的将事情向前推进。尤其是在没有下属关系的情况下，人与人的互动上，要做的非常好，能够把自己的想法非常好的表达给其他人，说服这些人配合去做事。
对事务优先级的控制
产品经理的工作是相当琐碎的，要处理各种各样的关系和进度，不像其他的工作都有自己专注的方向，专业的领域。所以如何在一天之内高效的做事就显得尤为重要。
要有市场感觉
围绕市场调查、市场细分、目标市场、市场定位，通盘考虑产品、价格、渠道、促销、公关、服务这些因素是开展营销工作也是产品管理的一项很重要的工作。所谓市场感觉，更为重要的是如何能够通过市场现象去生成一些战略，而不是对方降价自己也降价，对方做广告自己就做广告。所谓战略，就是从产品定位、用户定位、价格和竞争对手入手，了解各自的强项和弱项，找到机会在哪里，威胁在哪里，并进行分析，制订未来的战略。这些素质不是通过看市场宣传和汇报就能够获得的，它需要很多的信息反馈分析，要靠经验和感觉。
具备一定的抗压性
作为一个产品的负责人，产品经理的压力是很大的。尽管在某些公司，产品的成败不一定和产品经理的收益挂钩，但如果某些方面考虑不周，做出来的母盘存在问题，造成整批产品销毁，给公司带来巨大损失，或者因为某些原因没有和一些人员沟通好或者安排好时间，结果造成问题，产品无法如期交付，产品经理还是有“罪魁祸首”的感觉，这些都是压力所在。
主动做事与合作
产品经理需要有独立解决问题的能力和动力，要把产品看做自己的孩子，怀着热情和激情去做事。这种热情决定他是主动的，而不是被动的去做事，是为了不断提升自己的价值和能力。
产品汪和程序猿
一、产品经理和程序员最讨厌的三句话
产品经理和程序员,就像一对情人，若即若离，有时还会撕逼，和谐的时候一切都好，撕逼的时候两败俱伤。
你知道程序员最讨厌的三句话是什么吗？
1、这个需求很简单，改一下就好了
2、你先大概弄一个，我看看再说
3、我先下班了，加油啊
我想任何一个程序员听到这样的话都会气炸了，不撕逼才怪，你作为程序员会如何回答这三句话？
1、这个需求很简单？你行你来啊！
2、大概先弄一个？请问先生（女士），什么叫大概？
3、你大爷的
你知道产品经理最讨厌的三句话是什么吗？
1、这个需求做不了
2、这个需求工作量太大了，估计要搞3个月
3、这个变更没时间做，往后排吧
产品经理在前端，有用户、有老板、有销售，版本发布的压力很大，听到这样的话估计心情也好不了哪去？
1、这个需求做不了？又不是我提的，还不是那个2B用户提的
2、要做这么长时间？养你们有什么用，还不如我自己来
3、变更没时间搞？随便，等老板来拍你吧。
二、产品经理和程序员本质上的差异是什么
奶爸干过程序员，也干过项产品经理，深知这两类工作的差异，各有各的不易。
总体上来看，做产品更侧重于创造和方案能力，不需要精密的逻辑，所以试错成本相对比较低，大不了改改原型，改改方案，这个成本是可承受的。
程序员的工作是非常精密的逻辑，一个看似很小的变更有可能对代码产生很大的影响，所以试错成本非常高，弄不好可能会因为需求的变化导致系统的重构，这时候程序员的挫败感是可想而知的。
三、产品经理和程序员友好相处的清单
1、产品经理收集需求后，在需求分析阶段，需要把一些不合理的需求尽量和用户沟通去掉，避免不合理需求造成产品发布时间延迟和没有必要的成本浪费，当然这需要产品经理去说服用户，不能只做用户的传声筒。
2、需求分析时，产品经理应该根据经验，敏锐的发现一些在技术层面实现有困难的需求，及时让研发介入，评估技术可行性，避免后续出现需求定下来，研发说做不了的情况。
当然这需要我们的产品经理对软件技术架构有一定了解和预判能力，你不能所有的需求都要在需求分析阶段让研发介入，这个成本也是极高的，所以要把握好这个度也是一项能力。
3、原型还是需求沟通的最好方式，这样是避免产品和研发在需求理解上有差异的最好手段，只靠写一些文字的需求说明书很难达到好的效果。
但这里面要注意一点，产品经理绘制出来的原型一般是非高保真原型，是为了更好的沟通需要，所以不能完全按照原型做，需要基于我们自己的前台架构进行定制。
4、需求评审的时候，研发可能会有一些不一样的意见，他们做了很多年的开发，会有很多好的经验，好的经验要虚心接受，不能觉得自己是产品就是老大，就是要按我说的做，这样很容易造成矛盾，求同存异，目标一致，这个是最好的结果。
5、研发说这个需求做不了的时候，有两种情况，一个是觉得这个需求实现起来比较麻烦，故意骗你；另外一种情况就是他的知识盲区，他可能确实不知道这个事能做。
产品经理需要有能力和研发进行谈判，比如采用类比法（类似的需求在其它项目上咱们就做过），比如去找架构师探讨技术可行性。
6、研发有时候评估的工作量会比较大，整个上线计划拉的比较长，产品经理可以要求研发出详细的资源配置清单，这样能清楚的看到一个需求被分解成了多少个研发任务，每个任务的起止时间，由谁负责完成。这样产品经理大概能看出任务的前后置关系是否合理？工作量是否合理等。
产品经理绝不能说，这么简单怎么要搞这么长时间，类似的话一出，绝对会激怒对方，还是要有理有据进行谈判。
如果实在无法压缩工作量，如果增加人力能解决问题的话，可以考虑找领导申请资源。如果还是不行就要砍需求或者改方案了。
7、在版本计划定好的情况，尽量不加需求，这样很容易打乱开发的节奏，如果一定要加进来，一定要和研发说清楚，这个是用户领导或者老板的强制要求，转移矛盾。如果可以的话，增加了需求尽量推迟上线计划。
8、开发过程中如果需求有改动，需要及时更新需求文档，同时发给我们的研发同学，否则只是靠嘴说一下，很可能研发的同事就不做了，所以一定要落到纸面上。
9、上线的时候要坚持和研发同事一起加班，这样大家才是一个团队，赢了一起狂，输了一起扛。
10、最后一点，就是要多交流，没有什么问题是一顿火锅解决不了的，大家关系好了，很多事情沟通起来自然容易，而且也会更信任对方，这样就万事OK了。