大家通常提到的产品经理，除了全权负责产品的 PM 外，还包括产品设计师、用户体验产品经理、后台产品经理、需求分析师等。
从行业角度看，也可以分为技术型产品、设计型产品、运营导向产品的 PM。再细一点划分，还可以分出电商产品、社交产品或搜索产品的 PM。
BRD: Business Requirements Document，商业需求文档。
MRD:Marketing Requirements Document，市场需求文档。
PRD:Product Requirements Document，产品需求文档。
注：以上词汇为网络查找得出的解释，如有误，请指出，谢谢。
文档管理
好的文档能够减少、甚至免除在开发过程中技术人员跟产品经理的沟通，文档的作用是为了高效地传递产品经理对产品功能的描述并予以记录。了解技术，以更好地设计功能和协作，了解多少视具体情况而定。
满足条件：
1. 没有逻辑硬伤。
2. 没有疏漏。
3. 逻辑清晰。
4. 可读性强（有可能被误解的名词最好在文档开头予以解释）。
文档逻辑
在功能设计中，需要有三种逻辑关系是特别清晰的：
1. 功能框架的逻辑：如何梳理清晰的框架和结构？方法：拆分 -- 组合。
把产品的功能（或预期有的功能）列举出来，拆分成相对独立的模块，这是第一步。
接下来，就可以把刚才罗列的产品功能予以组合。大致分成几个模块。
2. 业务流程的逻辑：业务流程--产品所提供的功能或者服务实现的具体流程步骤。这里可以从两个维度去分析，一是面向事件，二是面向对象。
（1）面向事件：指的是，要完成一件事可能会进行很多次操作。而在这些步骤中要整理出健全的流程，逻辑清楚且不存在缺漏。我们一般使用流程图来描述面向事件的流程步骤。
（2）面向对象：指的是对象的生命周期代表着一次完整的功能使用，最常见的就是订单，通常会用状态转化图来表现。
有兴趣的可以学习一下面向对象的编程思想，也许会对很多功能的实现有更深的理解。
3. 功能描述的逻辑
（1）完整：尽量列举所有情况，并且分情况详述功能内容。相关情况比较多、描述的内容比较复杂，就用表格展示。
（2）考虑到所有影响点。
（3） 条件判断清晰。在什么条件下有什么功能，在怎样的条件下触发怎样的特殊功能都要罗列清晰。这里可以参考编程语言中很常见的 if/else、while、switch 等几种逻辑描述。
（4） 含义明确：不要用模棱两可的词来描述，也不要用未定义清楚的词（如缩略词）造成混淆。
（5） 叙述背景：让逻辑链条更完整的一个好方法是叙述功能产生的背景及它要达到的目的。
需求管理
从需求的生命周期能够勾画出整个产品设计到实现的流程。需求管理的几个阶段：获取需求阶段 -- 讨论和设计阶段 -- 待开发阶段 -- 开发阶段 -- 复盘阶段。
职级越高代表着身边人提需求的可能性越大。初入行的产品专员或助理主要是得到被安排的任务；初级产品经理，需求来源主要是用户和上级；产品负责人，需求来源还会有老板和其他相关部门；作为老板，谁都有可能提需求。获取到需求的这一刻，需要做一个判断并且记录。
判断需求的方法：
1. 判断需求本身的重要性。
2. 考虑需求来源。需求来源会表明一些事情，要慎重思考。
3. 了解需求背景。没说清楚原因、不说清逻辑、不是实际遇到的需求，这些没弄清背景的需求，没有必要记录。记录的时候，格式为“问题+方案”。
每隔一段时间应该举办需求讨论会，整理“需求池”，也就是记录所有获取到需求的表单。详细讨论每隔需求的情况，确认以下事项：
1. 需求的优先级。
常见的有两种排序方法：四象限法则和 KANO 模型。
判断是否重要时，可以参考这样的排序（重要程度由强到弱）：
· 不做，会造成严重的问题和恶劣的影响
· 做了，会产生巨大好处和极佳效果
· 跟核心用户利益有关
· 跟大部分用户权益有关
· 跟效率或成本有关
· 跟用户体验有关
判断是否紧急，可以参考以下排序（紧急程度由强到弱）：
· 不做，错误会持续发生并造成严重影响
· 在一定时间内可控但长期会有糟糕的影响
· 做了，立刻能解决很多问题、产生正面影响
· 做了，在一段时间后可以有良好的效果
2. 方案的草稿：需求有不同的解决方法，要讨论清楚到底用哪种方法解决。讨论出大概的方向、以及粗略的方案，再跟相关业务部门或需求方确认。要确保大家共同认可了某个方向后，再继续推进。
3. 指定负责人：两种方法 -- 每个人负责的需求范围要有清晰的边界，需求对应哪个模块直接分配即可；或团队作战，每次指定或者认领，谁都有可能接手任意需求。在需求分配时，大致还是按照模块分配，出现工作量不平衡时，酌情调整，让活少的同事予以配合。不管怎样，都要指定负责人，对需求负责，产品上线后出了问题也要承担责任。
4. 划定时间节点：方案完成的截止时间，就是当前需求能够完整提交给开发人员的时间。另外，如果是要跟相关部门再确认、需要对用户调研及要统计各种数据再做判断，还要有调研或讨论完成的时间。建议最长时间不要超过一周。及时更新需求状态给需求方。
一定要和研发的工时做可行性评审，否则将出现产品设计方案可行性差、需求频繁更改、产品功能不切实际的情况。首先要看方案本身的可行性，在技术方案上是不是能够完成？要和技术部门一起评估，注意细节。其次，要看看有没有更好的方案。第三，要看看设计的产品和技术环节有哪些，要让技术人员来判断哪些人需要知情和参与评估。第四，看方案的成本如何。
复盘的主要目的是防止问题再次发生。
要点：每个需求为什么在目前的位置和状态，应了如指掌；需求的各种变化、调整和意外，应同步到整个团队。
工作流中的管理
1. 协作管理：
与技术人员的协作：可行性评审中，我们要确保 PM 对产品的要求传递给了技术人员，确保技术部门的意见得到了表达，以及双方对共同认可的内容予以确认。对于较大的需求，即较复杂的功能，可以多做几次评审。若出现临时状况，如增加或修改需求、或提前上线，也要安抚情绪、帮他们想办法，陪同加班等，要主动解释背景（最好是详细的并且有理有据的解释）。
与需求来源方的写作：对方主要关心的重点是需求完成的准确和及时程度，所以要在需求管理的重要节点，跟来源方同步信息，确保他们认可你的方案和目前的进展。
开会：会议通知邮件要写清楚会议的主题和内容，以及大家需要提前准备的阅读材料。此外，还要尽可能地与重要参与者事先做一下沟通。
记录：需求描述文档或需求文档（建议把完整的产品功能描述文档整理好，产品有迭代时在上面做记录）、会议记录（记下主要的讨论节点和最终认同的结论）、想法和思路、其他事项。
2. 流程管理：如果存在别人做过的框架和脚本，就不要花时间自己再去写，重复别人的工作了。
如何不重复造轮子？
（1）让协作标准化、流程化，大家恪守同样的规范。当你意识到很多问题正在重复出现，很多协作沟通的规范能带来显而易见的好处时，就应该是尝试制定规范的时候了。
（2）减少手工劳动。
（3）让一些工作可复用（可重复利用在别的地方）。
（4）避免重复犯错。
犯错的原因：由于疏漏所致，指没有意识到、没有想到会出问题（解决方法：通过制度或流程机制）；信息不全面、知识不完备（解决方法：不断学习）；没有责任心；能力无法胜任（考虑是否补充更多专家或有经验的人进入团队）。
3. 个人管理：不要掉进一些陷阱里。
（1）把表现出来的焦急当成任务的紧急程度。
（2）把充实感当成完成任务。
（3）眼光不够长远，只做半衰期短的事情。半衰期长指带来的收益可以持久地对我们产生影响；而短则是短暂、甚至一次性地对我们产生影响。
（4）不设截止日期。
（5）不检视效果。
此外，我们还要进行知识管理，把很多知识、信息记录在案，方便以后查阅。相关工具：Evernote、有道笔记等。推荐书籍：《领导梯队》。
处理问题
发现问题 -- 分析问题 -- 解决问题（不断循环往复）
发现问题：推荐书籍《学会提问》
跟我们预期不符的状况，就是我们需要解决的问题。要很好地发现问题应该做到：
1. 在工作中对任务要有预期。2. 敏锐地察觉到与想象不符的状况。3.不应关心没有预期或与预期差别不大的状况（无法确定情况究竟怎么是对的，那就按照目前的方式先进行下去，视结果调整方法，而不是不断在没有预期的情况下去提问题）。预期只要认定是合理的就不应该轻易变化。4.问题是合情合理的吗？5.问题是真实存在的吗？
把问题描述清楚：开始提问时不要着急抛出问题，要想清楚问题所涉及的内容，把问题本身考虑完整，再进行下一步分析。
1. 考虑问题的背景（所处的时间、环境以及相关联的信息）。
2. 考虑问题涉及的人（把相关的人列出来并且确认之间的关系要害，才能够在后续分析和解决问题时得出靠谱的方案）。
3.考虑解决问题的期望（对定量的问题，要有量化的指标；对于定性的问题，也要有具体的对于“好”的定义）。
主动发现问题：发现问题出在哪里，尝试解决，或者协助别人解决。
分析问题
抽象问题：把复杂的问题抽象出容易理解、方便解决的本质。
逻辑分析常见的问题：混淆因果关系和相关性；概念有歧义或者偷换概念（用词尽量中立）；逻辑关系混乱、不熟悉归纳演绎；假设错误；轻易断言；太过主观臆断；片面归纳；比喻过度；被统计数据欺骗。
解决问题：推荐书籍《如何阅读一本书》
当你解决不了一个复杂的问题时，就要试着拆分这个问题，不断拆分，直到你觉得每个小问题都是自己能够解决的程度再去解决，解决之后再组合，整个复杂问题也就解决了。可以按层次、步骤、逻辑拆分成一个个小的问题，单独来看就没有那么可怕了。
解决问题的方案应包含以下几点：
1. 问题和背景：为什么要做这件事？做这件事的所有逻辑的缘由是如何的？是在什么情景下提出的？
2. 方案的内容。
3. 方案的负责人：由谁负责？为什么由他负责？
4. 方案的目标和验证方法：方案要达到怎样的效果才可以？如何验证？
推动执行
如果是个人能解决的问题，那么解决方案要推动自己执行；如果要协助别人或需要别人协助的方案，建议：
1. 确保对方获取到所有信息（要让对方清除整个方案的背景、内容和相关信息）。
2. 了解对方的态度。
3. 定期关注。
4. 解决后检验效果。
注：文中提到一个词“OKR”，一种互联网常用的目标管理工具，通常作为 KPI 的替代品。Google、LinkedIn 都在使用。
