想做好产品经理这一岗位首先需要有产品经理的自我定位，其次需要做好整个项目流程的工作；当然，如何高效沟通是产品经理非常重要的一个工作技能，对工作效率有非常大的影响。接下来，让我们看看作者是如何做的吧~

刚刚接触产品经理的同学，或多或少都会因未知产生恐惧和迷茫，所以需要提前做好准备工作，以后的学习之路将会轻松许多。

本文为个人基于网络或书籍阅读之后的个人总结，将在文末标明原文出处，仅作为个人学习总结。

首先，要说明下此处立人设并非在公司设立一个虚假的、违背个人意愿的人物形象。比较贴切的说，应该是做好一个产品经理，除了工作技能上的要求，我们自己需要对我们的思维和习惯首设置一个目标，从而做到灵肉合一、内外兼修。

一个大型成熟的产品，往往会被拆分为不同的小的产品线，然后每个产品经理去负责一个小的产品线。所以要求每个产品经理首先要熟悉自己负责的产品线，是其他产品线和本线沟通的重要桥梁和关键对接人。

其次，要对自己负责的产品线负责，相较于直接竞品、间接竞品、潜在竞品，本产品线该如何改善、提升，做到最优。

最后，在熟悉自己的工作内容之后，以点带面，上升到公司的业务层面去思考如何提升整体利益，修炼自己对接更大项目的能力。

不同的阶段，有不同的自我定位，不过这个过程也需要循序渐进，逐步上升，不能急功近利。

对于个人能力的提升目标方面，应该着重关注执行力、沟通力、项目管理能力三大块，其中执行力包含了需求分析、产品设计、推进项目开始到上线过程的方方面面。

这三大块内容是作为产品经理最基本的基本功。

产品往往是由一个idea 开始，这个idea往往是公司领导层发现市场的某个商机而产生。

这类人往往对市场商机具有敏锐的洞察力，但没有谁能够对商机有百分百的把握，这就需要产品经理在前期要做好充足的市场调研。

通过各种数据网站、亦或是企业内部调研数据，研究目标市场的发展空间和竞争力水平；还要了解目标用户的容量和消费水平，分析直接/间接/潜在竞品，以及该市场的现有商机模式。

在完成上述工作之后，生成《产品6要素》：产品定位、产品目标、需求背景、用户群体、产品形态、使用场景；综合分析产品的可靠性。

在撰写《产品6要素》时，结合真实数据进行汇报会更能打动领导层，产品的目标则最好分为用户侧、市场侧、公司侧（商业）。

第一阶段的汇报演讲将会决定产品是否投入研发，产品经理通过内部邮件的形式将第一阶段所形成的所有文件传达给开发团队和上层管理层，确定会议时间、地点以及汇报主题，在此之前需要根据市场实时情况及时更新调整文档内容。

产品经理在汇报时应该从多维度进行全面分析，包括产品的切入方向、发展空间、竞品情况、项目需求、风险、预算、整体规划等，积极引导团队成员进行讨论交流，整理问题，会后总结并调整。产品开发通过之后第一时间制定甘特图。

在确定产品需求时，因产品设计的核心逻辑就是以用户为中心，围绕用户进行产品设计，所以在汇报完成之后就需要开始手机用户的需求和问题了。

首先，用户的需求往往是隐性、模糊和多变的，因此在手机用户需求时，尽可能的保证用户反馈的主观性，不能通过问卷设计和主体设定来误导影响用户的回答。

其次，我们对于收集来的数据需要进行深度分析，数据分析的方法有：聚合分析、相关性分析，回归分析等…

需求的来源往往有以下几个方面：

• 内部团队的想法。
• 竞品的功能设计。
• 行业调研分析报告。
• 业内专家与资深专业人士。
• 定性研究：用户访谈，可以通过焦点访谈、电话访谈、一对一接头狙击访谈等方式。
• 定量研究：用户问卷，调研问卷数量不应过多，避免影响用户的主观性。

在做好初步分析后，就要及时和同事、领导进行汇报，产品经理的主要输出文档分为3种：

1. BRD（Business Requirement Document商业需求文档）。
2. MRD（Market Requirements Document市场需求文档）。
3. PRD（Product Requirement Document产品需求文档）。

在汇报的时候要注意，不同的文档的汇报对象侧重点也不同：

• BRD主要给产品、运营、研发、财务、老板等管理层人看的，主要是决定是否要开始某个产品。
• MRD主要是给产品、运营、研发等项目组人员看的，在大家一致认可需求成立的时候，来商量该怎么做，如何做，什么时间做。
• PRD主要是给项目经理、交互设计师、ui设计师、开发团队、测试工程师、运营等人员查看，是非常具体的产品设计方案。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档，PRD决定了产品做成什么样子。

BRD决定要不要做，MRD决定如何开始做，PRD是决定做成什么样。

（B、M、P具体内容以后再单独写一篇文章详述）

项目管理之前应该先判断该项目的类型，不同的项目推进和管理的方式区别很大，根据项目大小与任务并行程度，我分为以下三类：

对于单个部门内部开发周期较长的项目（超过2周），我总结有以下项目管理的关键点：

1）提前沟通开发方案

一般较大项目功能比较复杂。因此整体方案设计时需要预先跟开发人员沟通，明确一些关键限制因素和影响点；避免需求评审时方案不可行，或者调整太大，在评审会上难以达成一致。

2）关注功能先后顺序

提前关注项目中不同功能的相互依赖性以及对外部系统依赖性。根据功能依赖的先后顺序确定项目的排期节奏，提高排期衔接程度；避免一个功能开发完很久之后还不能与其他功能联调，浪费开发资源。

3）对项目的强推动力

每日跟进关键点的结果，尽早发现风险（日报、周报、晨会等形式）。

4）项目复盘总结

项目完成后回顾项目过程中哪些过程效率有待提高、哪些过程安排的不够合理，如何避免在下一个项目中继续出现。

跨部门和跨公司合作的项目，开发量不一定很大，但由于牵连方较多，比起团队内开发有了更多的不确定因素，项目容易延期。

因此在上述大项目的管理基础上需要额外关注这几点：

1）找到合作关键点

不管是跨部门还是跨公司合作，首先要明确对双方的关键利益点，并强调合作对对方的好处，才能获得对方的积极支持，否则很容易被踢皮球；

2）书面确认详细事项

跨部门和跨公司合作，一般都是远程电话沟通，因此对会议上达成一致的点需要书面记录邮件至对方，对达成一致的点也需要记录并积极跟进对方的最新答复。这一点主要是为了提高需求的确定性，明确双方职责，避免因为沟通没有记录影响项目开发进度。

对于互联网的敏捷开发模式，超过两三周的大项目少有，多个小项目并行才是更常见的状态，这里的小项目其实是单个很明确的需求，粒度比较小，这种状态下产品经理一周可能同时在跟进十多个需求在开发状态，这对多项目并行的考验很大。

我总结了以下几点：

1）更合理的排期节奏

由于项目太多，为了避免同一天过多需求同时在开发或者在测试，在排期的时候尽量均匀的分布。这样保证在一些需求已经进入测试或已发布，另外的项目刚进入开发，避免某一天的事情太多。

2）每日tips跟进每个项目的状态

首先需要实时记录这些并行的需求的开发状态、开发人员，然后每天早晚跟对应的开发人员跟进需求状态，及时解决相关问题。

3）小需求归档

小需求上线一时爽，后期维护痛苦不已。每个小需求在开发过程中是独立的，但对于整个产品来说它是一个个的迭代，只有及时将这些迭代归档到对应的功能模块，才能后续方便的了解查询当前线上的产品规则是怎样的。否则后期连自己都忘了到底最新的迭代是什么，这个坑谁踩过谁就知道有多苦。

与项目管理类似，沟通之前我们要对沟通的对象进行分类，不同沟通对象需要注意的事项是不一样的。

1）沟通方式的合理选择

一般与合作方很难面对面沟通，大多是电话和在线沟通，因此对于不同的事项要选择合适的沟通方式。比如首次确认合作内容，需要电话详细说明合作细节，然后书面记录达成共识的事项；确认完合作内容后，有小的疑问点可以在线沟通。

2）催进度也有技巧

有依赖合作方确认的事项或开发进度时，催进度是最频繁的事。但是催进度需要包含几个关键因素才能起到好的效果。

• 首先是良好的态度。对对方的尊称是必须的，就算对方态度比较冷淡也需要保持着热脸贴冷屁股的热情。因为在工作中，合作的顺利完成才是最重要的，这也是职场人的必备素质。
• 其次是明确具体内容和时间点。比如当希望对方对某个点反馈结果时，反面教材是这样的“请问你们这个功能可以快一点开发吗？”、“麻烦尽快确认下XXX这个点哦”，这样的询问都没有明确时间点，对方感受不到压力，催进度的效果不明显。正确的方式是“请问某某负责人，针对这个三点事项（一一列举），您可以在今天下午5点之前确认吗，麻烦您了”。
• 再次是要找对关键人确认。比如你一直跟对方的一个开发人员催进度没什么用，需要直接找到对方的产品或项目负责人，甚至是对方领导。

1）搞清需求方的本质诉求

需求方可能是运营、销售、客服，他们会根据自己当前遇到的问题直接跟产品经理提需求。

大家都知道快马和汽车的故事，需求方需要一匹快马，我们是直接按他说的给他快马，还是思考他提出这个需求的本质诉求是什么？能否转化成另一个需求？是否还有更合理的解决方案？

如果来一个需求就做一个，缺乏对需求背后的思考，这不叫产品经理，叫需求实现师。

2）明确产品和需求方的边界

当与需求方长期合作时，需要形成一个良好的沟通模式，明确各自的职责范围和边界。比如与运营合作上线一个项目，哪些内容是运营需要明确的，哪些内容是产品可以有施展空间的。

这个过程中，产品不能随意修改运营确认的规则，但也不能放任需求的不断变化，不能让运营直接干涉产品系统层面的影响。优雅的把握好边界，相互尊重彼此的工作内容，能够减少很多扯皮，让合作效率更高。

对于初级产品经理偏重于项目执行，日常沟通的对象最多的一定是开发人员，如果沟通太少，要么是你需求文档完美无缺（几乎不可能），要么是你不够主动。

1）跟开发大佬和开发小弟沟通的区别

开发大佬就是某条线的技术负责人，在有重大功能迭代的时候，可能会需要先跟他对方案。与开发大佬沟通时最好是提前想好靠谱的方案，而不是偏差太大的天马行空，这样避免浪费双方时间，也能提高大佬对你的信任。

开发小弟就是除了大佬之外的开发同学，与他们沟通的核心技巧是要建立利益共同体，因为他们是具体做需求的人，你需要把需求的背景、实现后的价值讲给他们，以及上线之后的效果也要多同步给他们，提高他们的自豪感。开发小弟也需要成功的项目来体现自己的价值，让他们感受到你们是一条线上，他们也会尽心尽力帮助把系统做的更好，开发过程中改点小需求也就不在话下了。当然，这些技巧是要建立在需求文档质量合格的前提下。

2）预期管理

产品立项时、项目开发过程中，对开发人员的预期管理是很有必要的，有的开发觉得这个项目不是很重要，重视程度不够，最后导致延期；有的开发对这个功能上线期待很高，最后上线后效果并不理想；有的开发在立项时认为这个项目开发这些功能需要2周，但中途你又加了几个小需求导致开发时间压缩，开发人员非常不满。这些都是实际的情况与开发人员预期情况产生较大不一致造成的。

因此一些关键的事项，需要跟开发人员预期保持一致，我主要总结以下几点：

1. 项目目标和价值。比如一个非常重要的项目，需要在2周内上线，预计可以获取新增用户10万个。这些明确的项目目标和价值需要在立项时及时同步给开发人员，有时候你的重视程度会影响开发的投入程度。
2. 关键时间节点。开发时间、转测时间、上线时间，几个关键的节点要时刻强调。建议直接写在项目群公告中，避免有的开发同学遗漏忽略。
3. 风险和备用方案。项目可能产生的风险和备用解决办法，在立项时也应该跟开发同学保持同步，一些外部的不可控因素可能会产生什么影响。比如一个项目可能临时更换合作方这种突发事项，提前同步可以让大家心里都有底，不至于发生时产生太多不利于合作的情绪。

3）跟开发的工作氛围建设

除了工作中，工作之余与开发同学经常一起玩，开开玩笑，建立良好的工作氛围和私人关系也很有必要，会让工作的合作效率更高。也许一个小需求对于关系一般太严肃的开发来说需要排期才能处理，但关系融洽的开发可能随手就帮你解决了。

产品经理从第一天开始工作起，基于自己的工作内容和所在领域，就可以开始规划自己的能力模型，并不断的完善。这样一个能力模型既与工作内容相关，又是独立于当前的工作内容，是抽象出来的通用的能力模型。这样才能保证自己在产品经理这个岗位中的竞争力。

根据我个人建立的产品能力模型，相比于各种经验技巧方法论，我认为最底层的是思维方式，优秀的思维方式可以让你在面对不同工作内容时举一反三。

而产品经理到底要具备哪些思维方式？

这个问题我建议你也不要看别人直接输出的结论文章，我给出两点建议：

1. 阅读经典的评分高的思维方式书籍，相比于产品同行写的产品思维的文章，优秀的思维方式书籍的含金量更高且内容更系统，更有利于对思维方式的学习。如《思考，快与慢》、《穷查理宝典》、《用理工科思维理解世界》。
2. 根据自己实际的工作经历，复盘做得不好的项目各个环节欠缺哪些思考，回头看如何思考可以做得更好。而对于做得好的项目又是怎么思考的。以此进行演绎，形成自己认为重要的思维方式。

参考原文：

BRD、MRD 和 PRD 之间的区别与联系

本文由@Eric Y 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。