用心：对自己对产品负责任
同理心：从用户角度出发
处处留心
没心没肺：脸皮要厚，不要怕人骂 同程序员不一样，产品经理主要是同人打交道，要组织处理好很多复杂的关系和工作。良好的沟通能力、组织协调能力、资源运用能力、推动和协调各部门的合作和有序进展，是一个产品经理需要具备的综合能力。所以做好产品经理并不是一件容易的事情，很多方面的素质培养是必不可少的。
产品经理要协调好各种关系，包括研发、测试、文档、市场、销售等部门的人，在保证品质的情况下如期的推出产品。任何事情都是靠人实现的，所要协调的主要是人力资源，绝不能因为要完成一个OEM的项目而占用所有测试人员的时间。不同部门的沟通并没有多大的区别，但不同部门的Leader做事方式可能不一样，因此一方面要看对方配合的程度高低，同时要学会在恰当的时候和恰当的人谈恰当的问题，只有解决好问题才能有效的将事情向前推进。尤其是在没有下属关系的情况下，人与人的互动上，要做的非常好，能够把自己的想法非常好的表达给其他人，说服这些人配合去做事。
产品经理的工作是相当琐碎的，要处理各种各样的关系和进度，不像其他的工作都有自己专注的方向，专业的领域。所以如何在一天之内高效的做事就显得尤为重要。
围绕目标市场、市场调查、市场定位、市场细分，通盘考虑产品、价格、渠道、促销、公关、服务这些因素是开展营销工作也是产品管理的一项很重要的工作。所谓市场感觉，更为重要的是如何能够通过市场现象去生成一些战略，而不是对方降价自己也降价，对方做广告自己就做广告。所谓战略，就是从产品定位、用户定位、价格和竞争对手入手，了解各自的强项和弱项，找到机会在哪里，威胁在哪里，并进行分析，制订未来的战略。这些素质不是通过看市场宣传和汇报就能够获得的，它需要很多的信息反馈分析，要靠经验和感觉。
作为一个产品的负责人，产品经理的压力是很大的。尽管在某些公司，产品的成败不一定和产品经理的收益挂钩，但如果某些方面考虑不周，做出来的母盘存在问题，造成整批产品销毁，给公司带来巨大损失，或者因为某些原因没有和一些人员沟通好或者安排好时间，结果造成问题，产品无法如期交付，产品经理还是有“罪魁祸首”的感觉，这些都是压力所在。
产品经理需要有独立解决问题的能力和动力，要把产品看做自己的孩子，怀着热情和激情去做事。这种热情决定他是主动的，而不是被动的去做事，是为了不断提升自己的价值和能力。
技术可以学习，素质却难以培养，有些素质是成功的产品经理必不可少的。
有这样一群人，他们对产品有一种本能的热爱，把自己生活中的一切事物都看成产品，怀揣对优秀的产品的热爱和尊重。这份热情是产品经理必备的素质，是他们夜以继日克服困难、完善产品的动力。这份热情能感染团队成员，激励所有人。
辨别这种特质很容易，可以让应聘者谈谈自己最喜欢的产品及喜欢的原因，聊聊不同领域的产品和他讨厌的产品，问问对方，如果有机会，他打算怎样完善自己最喜欢的产品。热情是难以伪装的，虚伪的做作容易毕露无遗。
理想的产品经理不一定来自产品的目标市场（这种情况有利也有弊），但是他必须融入目标市场。这一特质对制造大众产品的高科技企业尤为难得。我们倾向于从自己的角度去理解用户和市场。事实上，目标用户的经验、喜好、价值观、知觉能力、忍受程度、技术理解很可能与我们的大相径庭。
可以就产品的目标市场向应聘者发问，让他谈谈如何换位思考。了解应聘者对目标市场的感觉，最重要的是看对方是尊重目标市场希望融入其中，还是打算一意孤行改变用户习惯。
对国际化的产品和针对特定地域的产品来说，换位思考尤其重要。各种文化虽有共通之处，但也存在许多差异。有些差异对产品无关紧要，有些则至关重要。应该考察应聘者是否足够了解目标市场，能否区分这两种差异。
人的智力水平是无法替换的。产品管理需要洞察力和判断力，因此必须具备敏锐的头脑。勤奋当然是必需的，但从事这项工作光有勤奋还远远不够。
招聘聪明人是项知易行难的任务，结果在很大程度上取决于招聘者的能力和可靠性。常言道，“物以类聚，人以群分”，此言不虚。方法之一是测试应聘者解决问题的能力。微软令人称道的、深入而有效的面试，即是考察应聘者解决问题的能力，通常由一位或多位领域专家就一个问题对应聘者进行深入考察。面试官不关心应聘者是否知道正确答案，而看重应聘者解决问题的思路和方法（智力优于知识）。如果应聘者回答正确，面试官会将问题略作调整，询问应聘者在新情况下如何应付。重复这个过程，直到应聘者被迫处理他不知道答案的情况，说出解决方法。
每种团队角色承担的义务和付出的努力都不相同。产品经理肩负着产品的前途和命运，绝不适合贪图安逸的人担任。即便掌握了时间管理和产品管理的技巧，产品经理依然要为产品投入大量精力。成功的产品经理能拥有时间享受清闲的家庭生活吗？只要具备足够的经验，我相信可以做到。但是，如果你期望的是一周只工作四十个小时，下班后把工作抛诸脑后，那是不现实的。
成功的产品经理需要付出多少努力？在这个问题上，我对应聘者向来坦率，产品管理工作绝不能用时间来衡量，付出多少都不为过。紧急情况下临时找来的“救火队员”多半不是合适的产品经理人选。
在漫长的项目周期里，产品经理需要付出的努力和承担的义务并非一成不变。有的阶段比较轻松，有的阶段则很紧张。但是称职的产品经理对产品的关注和忧虑程度，以及愿意为之付出努力的热情是不会改变的。
在所有产品团队成员里，产品经理最能体现公司和产品的价值观。通常产品经理不直接管理团队成员，不能要求别人执行命令，所以他必须通过行动影响、说服身边的同事。这种影响基于相互的信任和尊重，要求产品经理必须是个正直的人。
产品经理是产品团队、销售团队、公司高管之间的枢纽，经常要协调处理各种问题，比如提早供货、满足大客户的特殊要求。产品经理如何处理这些难题，同事们都看在眼里。
信任和尊重需要时间培养，产品经理唯有通过工作展示自己的素质和能力，才能成为真正的团队领导。如果产品经理对待同事缺乏诚意，怀有私心，一碗水端不平，那么势必会影响整体团结的工作效率。产品经理虽然不必事事精通，但应当知道每位成员最擅长做什么，尊重大家发挥工作特长的意愿，充分信任大家。
考察一个人是否正直绝不比考察他的智力容易，考察陌生的应聘者是否正直就更难了。对那些有工作经验的应聘者，可以问问他们如何处理工作中的压力，多追问工作细节。
很多人相信经验可以让人产生自信。如果仅凭经验可以建立信心，为什么许多工作多年的产品经理却毫无自信？相反，刚刚步入社会的大学毕业生却往往充满自信（虽然这种自信通常源自对自身状况的无知）。
自信是很重要的素质。公司高管、产品团队、销售团队都需要看到产品经理的信心，确信他们投入的时间、金钱、努力不会付之东流。自信的人更有说服力，更容易成为人们愿意追随的领导者。
称职的产品经理把自己当成产品的CEO，愿意为产品的最终成败承担全部责任，绝不找借口。虽然他清楚产品按时成功上市要克服许多困难——开发难度大、开发时间长、成本过高、产品复杂等，但他明白预见和解决这些问题是他的责任。
这并不是说产品经理要事必恭亲，监督每个人的工作，而是指出现问题时他应该及时承担责任，进展顺利时他应该及时给大家以鼓励。称职的产品经理知道，虽然产品的实现离不开大家的协助，但是他应该对自己的产品创意负责。
掌握一些重要的技能是打造成功产品的关键。我相信，只要具备优秀的个人素质，所有技能都可以习得。
很多成功的产品经理是工程师出身，因为策划产品在很大程度上取决于对新技术的理解，以及如何应用技术解决相关的问题。
出色的产品经理并不需要自己发明或实现新技术，但必须有能力理解技术、发掘技术的应用潜力。
培养理解技术的能力有多种途径，可以参加培训课程，阅读相关书籍和文章，向程序员和架构师请教，参加开发团队的头脑风暴也不失为一种途径。
产品经理要优先解决重要问题。研发产品的过程中有很多干扰。能否集中注意力解决关键问题、克制不断增加功能的冲动、不受关键人物或重要客户的影响，取决于产品经理是否有足够强的自律性——不但要遵守公司制度，还要严格要求自己。
几乎所有产品都有些不那么重要的功能——这些功能对提高销量和用户满意度毫无作用。如果去掉这些功能，产品甚至会因为简单、易用获得更多用户的喜爱。
电子邮件、即时消息和手机构成的世界充满了干扰。你可能一大早就来上班，拼命工作一整天，连吃饭喝水都顾不上，深夜回到家却发现到头来没完成一件重要工作。时间都用来“救火”和处理“紧急”事件了。
熟练、迅速地区分重要任务和紧急任务，合理地规划和安排时间是产品经理必备的技能。如果产品经理无法集中精力完成真正重要的任务，那产品就难免命运多舛了。
每星期工作七十个小时、累得精疲力竭的产品经理。他们把所有的时间和精力都花在工作上，体力透支到了极限。对他们而言，最可怕的事实莫过于做的都是无用功。为此，我有意在培训课程中加入了时间管理和合理安排工作任务的内容。产品经理的时间应该用来改变现状，而不是疲于奔命参加大小会议、逐一回复邮件。有许多事情不值得做。
作为产品团队的发言人，产品经理要协调团队与财务部门、营销部门、销售团队、公司高管之间的工作——必须使用这些人听得懂的概念和术语。
我认为产品经理应该具备双语技能。这并非指中文和英文，而是指产品经理既能与程序员讨论技术，又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌。 教育培训
产品经理是要负责产品的整个生命周期的所有事物，因此产品经理需要有产品研发阶段相关的技术知识。在软件开发领域，产品经理一般是研发出身，接受过市场营销相关培训。
工作经验
产品开发及其管理5年以上工作经验，具备良好的资源整合能力、沟通协调能力和书面报告能力，具备独立解决问题的能力和较强的市场分析能力，对产品和数据运营敏感，思维清晰而有条理，能承受较大的工作压力。 对于大公司而言，产品经理是一个非常重要的角色。因为产品经理要负责整个产品的成败，所以从研发到生产到销售，产品经理都有权进行干涉。但是在小公司境遇就不尽相同，权力会相对小一些，但是产品经理对于提高自己的创新能力，选择创业是非常有帮助的。产品经理一般由产品专员发展而来。
在战略层面需要考虑的内容
在产品规划和执行层面
产品开发团队管理
产品实施和推广
因为不同公司对产品经理/产品设计师的职责要求不同，所做的事情也并不相同。但至少要达到所在公司的要求，这才是首先应该做的事情。 原型制作：Axure，Mockplus,fireworks，Photoshop，mockingbird（web）,Balsamiq Mockups,omnigraffle等，区别去其他的原型工具，Mockplus兼具审阅功能，更加方便了设计，提高了工作效率。
项目管理：PriciseProjectManagement（PPM），Project（微软产品），Todolist，Excel，Sheet，Gcalendar，Google task，trac，outlook
在线协作：SVN，Google Docs,Mockplus
测试反馈：TestCenter，QC,Jira,Bugzilla，Firebug、TestDirector、IETester
需求池管理：Mantis
团队交流：QQ，outlook，MSN，GTalk，画声（精准沟通）
工具推荐：多用下载
笔记软件：Evernote（印象笔记），Onenote（微软产品），麦库，有道云笔记，为知，轻笔记
代码编辑：Editplus，UltraEdit，Sublime Text 3，Textmate，Notepad
一、产品经理的需求来源
产品经理一切工作的本源是：需求。所以我们从需求来源开始讲起产品经理完整的工作流程。互联网需求来源一般有：
1、产品需求：产品经理通过数据分析、用户调研、竞品分析等方法验证通过的需求
2、运营等业务部门提交的需求：比如以京东为例，服饰业务部/生鲜业务部/家电事业部的运营、采销等人员出于提升业务指标的角度会提出各种需求
3、老板的需求：领导从外部合作的角度或者产品战略的角度也会给手下的产品经理提一些需求，比如我还接到过大Boss和老板娘的需求
4、Bug修复等：在工作中修复BUG是一件比较常见的事情，影响面大的BUG会走紧急修复流程，不太严重的BUG会走迭代排期。
二、需求池的管理
通过以上几种方法收集到的需求会统一放到需求池中。需求池大家可以理解为所有需求的集合（包含待确认、设计中、带排期、开发中、已上线等所有状态）。
一般来说，使用execl表格管理需求池即可，按照各种需求状态进行分类展示。
三、需求优先级
我们需求池的需求会非常多，但是每个迭代的时间是有限的/研发资源是有限的，所以导致我们只能从需求池中挑选出少量需求进行开发，从而诞生了需求优先级的概念。
一个迭代中肯定有限做优先级高的需求！
那如何排定需求优先级呢？
一般来说有两个场景：
1、从0到1设计一款产品
这种场景下的需求来源基本上都是产品需求。建议大家去了解一下KANO模型，这个场景下的需求优先级一般来说是：基本型需求>期望型需求>兴奋型需求
2、在原有产品基础上优化
这种场景的需求来源会非常广泛，可能之前讲到的4中来源都是涉及，那如何排定需求优先级呢？一般按照产品价值和实现成本两个维度。
产品价值可以分为两类：业务价值和用户价值。
价值定义：
业务价值：对应商业类产品，称为商业价值，体现在能给业务带来多少收益。
用户价值：对于使用者来说，能给他带来的价值，比如说能减少操作步骤。
在这种方法下，优先级的排序逻辑是：产品价值大实现成本低>产品价值大实现成本高>产品价值小实现成本低>产品价值小实现成本高。
四、需求确认
当梳理完需求优先级之后，我们就按照开发工作量挑选优先级高的功能组成新版本/新迭代周期的需求列表。
梳理完需求列表之后一般要跟直属领导当面沟通一版，这叫需求确认。在这个阶段要做好挨批、被怼的准备。领导会从各个维度“挑战”你需求的合理性。所以大家在需求评审前一定要多思考几遍，尽量多用客观数据去说服领导。
如果需求确认通过，会进入到产品设计阶段。
五、产品设计
产品设计阶段会包含如下几个小阶段：
1、使用产品脑图梳理产品/功能结构框架，特别是对一些逻辑复杂的新产品/新功能。
2、使用产品流程图梳理产品/功能核心业务逻辑。流程图的梳理尽量详细，各种异常场景的判断一定要在流程图中有所体现。对于涉及多个参与方业务，可能还要梳理泳道图。
3、使用墨刀/axure等原型工具输出产品原型。原型是产品逻辑的可视化表现，也是产品经理最最基本的基本功。
4、撰写产品说明文档（PRD）。PRD是产品详细逻辑的最终呈现，也是内部沟通的标准文档。PRD撰写完成之后就可以进入到需求评审阶段
六、需求评审
需求评审是指产品经理要向UI、交互、研发、测试等内部人员讲解产品逻辑，保证产品逻辑在内部传输过程中不失真。
需求评审的过程中，有4点需要注意：
1、评审的时候，先讲需求背景。即这一版本为什么要做这需求？做完以后预计会达到什么效果？让相关参与方从心理上认同做这件事的价值。
2、在讲具体需求的时候，按照对应的责任人进行拆解。比如在讲解功能A的实现逻辑时，我一般会说客户端需要完成的内容是1、2、3；服务端需要完成的工作是1、2、3；算法侧的工作是1、2、3等等。
3、存在争议的地方先记录下来，评审结束后再细化。
4、就是评审结束以后要追排期。即作为产品经理你要盯着研发Leader，设计Leader，测试Leader让他们出需求排期，以此保证项目按时上线。
七、项目管理
需求评审完成之后，项目经理（大部分公司由产品经理担任）会输出详细的项目排期表，然后项目所有相关人员会按照项目排期表有条不紊的协作。项目管理的详细流程如下：
八、数据分析
产品上线之后，产品经理要做好产品分析工作，以验证产品/功能是否达到预期目标。特别是产品上线7天后，产品经理需要想全体组员发送产品上线数据报告。
如果数据不达预期，就要进行深入的分析内在原因是什么，然后数据分析的结论很可能是下一迭代的需求来源，从而开始一个新的迭代周期。