作为一个2年级产品经理，虽离毕业还早得很，也在这2年里经过摸爬滚打，堪堪入了个门。最近有很多小盆友在问我有关pm的那些事，就想写点东西当作回复，也趁机作为自己这2年的课堂笔记，尝试着总结些浅显的入门干货，希望能帮助（不误导）到想入门的盆友们。

除了基本介绍，后面都是纯干货，干透了，讲实际产品需求、项目里的几个小技巧。想要大纲似的入门手册，请出门右拐百度或者“人人都是产品经理”网站（不是广告！）。
（高能提示：篇幅较长，建议保存或改天有空再看。）

初心

写在最前面，建议在入门前写下自己为什么要当产品经理的理由，无论因为钱多，还是基于理想，这样做有助于当你在2、3年跨不过坎的时候，翻出来看看，重新激起斗志。

说句实话，产品经理也是吃的“青春饭”，常年加班、熬夜、累心，老的都比同龄人快几倍，通常做个3、4年就要考虑走向M岗，即管理层，等到30好几，还在跟95后00后一起做着细节的执行，才会真正感觉到中年危机。

无论出于什么目的，写下来，当自己面临重要抉择的时候，拿出来看看，再决定自己未来的方向。

产品经理=写PRD的+催人的+找人的+测试的+……

产品经理是团队的灵魂吗？

某种情况下，是的。

为什么说是在某种情况下呢？因为产品经理是否成为团队的灵魂，完全取决于他是否靠谱，取决于他的逻辑思维是否缜密，他的沟通协作是否通畅……

没有谁可以随随便便成为灵魂和核心的，项目组是一个小团队，公司是一个大团队，能成为灵魂和核心的寥寥无几，大多数的产品经理只是做一些沟通协作的工作，没有想象中的那样重要。

有段时间听人装X，说我（产品经理）啊，最近有点忙，这个项目我要去push啊，要知道这块是谁cover的，督促QA去diff下代码，最后还要自己去test。一连串夹杂着鸟语的普通话，以为很高大上？no，其实这些都只是产品经理的日常罢了。

作为一个万能的PM，你要厚脸皮，因为对于一个负责的pm来说，不是指挥别人做事，而是：

• 1、做事之前，考虑所有逻辑

• 2、讲需求，表达清楚，跟开发沟通要有逻辑，没有逻辑也得有煽动力

• 3、几乎没有什么头脑风暴，做好一个人冥思苦想、一个人弄原型、一个人写需求的心理准备

• 4、随时做好战斗的准备，资源不足、人手不够，冲吧，战斗的撕X小能手，学会跟别人争取资源；记住项目是你的，何时开始何时上线由你掌控，所以随时hold住全场，关注每一个节点。

（友情提示：以下一部分是有关PM基本技能说了2000字，如想看实操请略过，直接到后面“如何快速的进入项目”）

产品经理所需技能

明确了产品经理的工作是什么后，那么产品新人需要具备哪些工作技能呢？

工作技能可以分为软实力和硬技能两种。软实力是指基于自身素质的基本能力，比如乐观的心态，时间管理能力、知识管理能力等；硬技能狭义的说是为胜任工作需要具备的工具使用能力，广义来说，就是与实际工作相关的一切技能。

软实力

1、知识管理-管理你的idea

作为一个产品经理，不严格来说，就是一个杂家，你最好要融会贯通，收集知识、消化并创新，最终让知识为我所用，那么如何做？

• （1）建立固定的知识获取渠道，比如网络、书籍、人际交流、线上线下分享

• （2）保存并整理，进行资料分类，用各种、笔记，可参照我之前写过的《让你爱上生活的记事软件》

• （3）总结，记录每一次收集知识信息时的idea，梳理和建立自己的知识体系

• （4）分享，只有分享出去的东西，你才真正学会了，找机会分享出去。

2、善用你的生命

这个年代拖延症患者并不少，有人建议进行时间管理，但我并不赞同，首先我其实认为“时间”这个概念是我们的妄想，普遍上我们体会和感知到的时间跟人类定义的并不一致，其次它用不着“管理”。

真正要管理的，只是事项。所以，我用“善用你的生命”表示你完成生命中每一件事情的意思。

那么，如何管理我们工作或生活中的事情呢？

• （1）擅用清单。根据GTD简化出来的一个最好用的东西就是todo list，清单。把脑袋里所想到要做的事情先列出来，腾出头脑的空间去想重要的事情，不要让那些计划、想法、考虑把你脑袋塞满。

• （2）四象限法则，根据紧急性和重要性分为四个象限，来决定你清单里的事项属性，然后“重要不紧急”是你最需要关注的事情。

• （3）番茄工作法。其实我并不常用这个方法，列出来只是想表达一个想法：专注。番茄工作法的本质就是确保你集中精力做某事。无论你是用番茄工作法的30分钟一个工作单位，还是任意你想要的时间，只要你达到集中精力专注就行。

3、宝宝也有小情绪要管理

宝宝有小情绪了，宝宝心里苦，但宝宝不说。

产品经理心里的苦可比宝宝多太多了。需求被毙掉了，这周需求排不进开发队列了，开发资源不够了，项目delay了，效果不好了，哎呀，压力不能更大啊。

说实话，这块我也在精进，情绪管理这东西，说的都是皮面上的话，考的是长久功力，每个人都有针对自己不同的方法。这里只能作为建议：

• （1）自我催眠、心理暗示

• （2）冥想

• （3）回看初心

• （4）交流沟通

• （5）换位思考

硬技能

似乎每一个产品新人都认为刚开始做产品，就必须要熟练掌握Axure、思维导图、visio、ppt等各类工具。no！我只想说，工具只是“术”，我们要追求的是“道”，这类工具只要集中花一点时间，网上教程大批大批，不是手残的基本都能会用。当拥有“道”，我们可以做的是融会贯通、举一反三，切勿在工具使用上走火入魔。

那么硬技能里的“道”是什么？需求管理。

像之前说的，产品经理有大部分精力在管理需求的分析筛选和推动项目的开发及上线，遍历整个需求流程。每个PM都不会只进行一个需求，更多时候都是同时进行N个，面对资源不足的时候，还要根据需求的优先级来有所规划。

那么需求管理，就是包括需求条目化管理、需求跟踪以及需求过程管理。如何做呢？

1、工具类

• （1）Excel。
  通常用excel做需求归宗和进度记录，列出需求的管理维度，比如编号、背景、目标、优先级、干系人、有关进度控制、关键时间节点等。

• （2）脑图。
  也叫思维导图，一般用作需求功能点的合并整理，类似头脑风暴，发散列出所有的需求功能点，再整合。以图形化的形式从多个维度展现你要实现的想法。最原始的思维导图工具，应该是纸笔，也可以用各类电脑、收集软件。
  宗旨就是，穷尽所有想法，对想法进行分组合并，判断隶属和层级关系。

• （3）Visio。
  跟开发沟通的大杀器，完成一个需求的设计后，用Visio画出主流程及子流程，在这个过程中还能梳理自己的想法，在跟开发讲的时候，直观明了逻辑清晰，开发GG再也不会鄙视你讲不明白了。
  注意要根据你文字表达的逻辑走，初期新人可能会先写文字，后画流程图，到了后期就会发现，一般通过沟通、思考后，有关需求的逻辑很容易先有主流程，这时候根据主流程写文字简直太easy，通常情况就是思考+流程3小时，写文档10分钟。

• （4）Wiki或各类版本管理杀器。
  更新同步，共享给相关人员，可存档用。

• （5）原型。
  原型是在梳理清楚产品的主要功能和操作流程后，将功能和流程从想法阶段到输出阶段的过程，简单来说，就是把一个抽象的想法，变为具体形态。
  通用的软件比如Axure，类似的还有Mockplus、腾讯开发的UIDesigner等等。关于原型网上相关的介绍太多，这里就不多说。

• （6）文档。
  显而易见，PRD详细需求文档。
  一般包含：文档的版本管理，功能概述，流程图，核心功能模块，各功能模块的细化说明等，根据业务，还会有一些不同。
  文档的质量好坏直接影响到研发部门是否能狗明确产品功能跟和性能，这就像网上盛传的“姑姑理想图”。

2、需求分析

需求管理，除了利用工具，还会涉及到一些统计与分析，那我们通过以下几个维度：

• （1）来源。需求的来源基本是用户、市场、运营、开发、领导。明确需求来源，对于我们了解需求背景和目的是铺垫工作。

• （2）描述。对于需求的详细描述，包括遇到的问题，想要达到的效果、目标等。

• （3）产品方案。针对需求的处理方案。

• （4）优先级。对于需求的评估，是否紧急，代表何时去解决需求。一般情况先解决优先级高的。

• （5）需求进度。关注需求的处理进度，是方案中，还是开发中，还是已上线。都需要有进度跟踪，做整体管理。

• （6）其他。包括需求涉及的部门、干系人、时间等等。

高能警报：干货来了~

如何快速的进入项目

很多新人刚进公司，被扔进一个进行中的项目，然后就不知道怎么办。我见过同样是新人的2种情况，一种是一年多了，还跟刚来一样，另一种是进来不久就可以放心交给他任务。

前一种是闷头做事，还不见得真正懂这个任务的目的；后一种，做事，但会问。快速进入项目的秘诀就在于，主动出击。没有人有义务主动向你介绍项目的背景和逻辑，需要的是主动了解，但这里面很有讲究。

首先，主动找有关负责人或者自己座位旁熟悉的人要点项目资料、文档或者wiki，这些东西就是有空时随手一发，没人会真的拒绝你，然后快速花时间大致了解下大流程；

其次，认真做安排给你的任务，或者没有任务主动询问是否可以帮点什么，了解一个项目永远是做的过程中，结合你得到的所有资料，这个时候去做吧，就可以进行下一步；

第三，问，前提是你自己真的看不懂你得到的资料时，问项目里看上去比较懂且和蔼的同事，注意语气可以谦逊但不要太过小心翼翼，在得到反应的过程中给点自己的反馈，形成互动，让人觉得这是一场“交流”，而不是“教学”；或者问跟你合作的开发团队，一般来说开发menber都比较nice，抱着跟他们聊聊项目进程的幌子，在聊天的过程中，问些你不知道的逻辑，如果遇上热心的开发直接给你从头讲到尾，那恭喜你，以后一定要把这个沟通能力极强的开发当成宝。

第四，反省，在需求review的时候，从leader或开发那里得到反馈，记下每一个你缺失的细节，抓住机会求证你错误的逻辑真相。

这四个要点，只要开始了第一点，你就跨进了项目大门。其实说到底，重点就是要主动、要沟通，产品经理大多时候是个嘴皮子上的活儿，注意一些细节，为什么要让询问变成“交流”而不是“教学”？职场经告诉新人说，喜欢爱发问的员工，这句话是扯淡，没把下一句话说完：“除非问的很有水准”。都知道产品经理是条狗，忙的死去活来，最烦遇到凡是都问为什么、没有眼力劲时刻来求教的，说句腹黑的话，大家都是打工的，又不是你老师或老妈，有必要都跟你说？所以问这个东西，需要你问到点子上，经过自己脑子后，再去发问。分配给任务的时候工作安排没说清楚，必须问；项目细节不知道，委婉问；项目大逻辑、背景，聊天抽空问。

做需求需要注意的地方

作为产品经理，你要知道一个项目的流程是什么，简化流程基本是：沟通-写方案-沟通-改方案-沟通-循环以上-审核-进入开发-进入测试-达到发布状态-发布-发布后评估。

一般来说，新人开始做的都是leader、老大拍下来的活儿，这就是为什么让你在分配任务时一定要了解、问清楚需求到底要干嘛，它的目的是什么，前因后果、要达成的目的。有了需求背景，起码你就了解这个需求的50%，剩下的50%是细节。

剩下的50%里，30%是去了解原有的逻辑，现在是有什么问题；10%是找到相应的干系人，这里的干系人包括以前做过该项目的产品、开发，现在跟项目有关的产品、开发等，定位到对应的项目负责人，之后环节有用；5%通过前面的了解，进行调研工作，整理数据；5%留给自己思考。

所以终于要做一份需求了，不仅仅是写一份PRD这么简单，作为新人，需要注意些什么呢？

沟通。

看项目基本流程就应该知道，沟通在里面占据了你70%的精力，所以，在这个过程中会有以下几个节点：

1、跟老大沟通

接任务时，不要怕说出自己不清楚的地方，比如对目的、背景不了解，一定要趁老大把任务这只“猴子”扔给你之前，抓住他问清楚，当然，除此之外“怎么做”这种问题，你问了就是死。

2、跟干系人沟通

找到跟这个需求有关的干系人，换句话说，是去了解这个产品需求以前是什么样子的，它呈现在产品上是如何表现的，背后的逻辑大致如何，现在是有什么问题。这个可以通过刚才讲的“如何快速进入项目”方法，完成项目背景的了解。顺便可以做下数据收集。

3、跟你的开发沟通

有很多新pm会有个误区，以为在进入开发之前，需求跟开发一点关系都没有。

错！我想建议，在思考需求设计时，一定要跟开发多沟通！不论说需求review需要过开发那一关，就是在撰写需求之前，也少不了开发的角色。

开发GG或JJ绝对不高冷，产品特别是新产品写需求，都是一个人独自设计，就算再兼顾多少用户需求体验，也需要考虑开发系统实现的问题。这里就会有很多人说，开发是干嘛的？只要你产品提出来，开发就一定能帮你实现。对，我不否认万能的开发GG或JJ强大的技术能力，跟开发沟通，可以获得技术上更有可行性的建议和需求灵感。

在这里，也可以抽个空回应“产品是否要会技术”这个问题，我认为，会技术当然更好，不会技术也没有影响，究其本质，就是为了做产品设计时逻辑更加合理、跟开发沟通更流畅、push进度时不会被调皮开发忽悠，这些，通过每次做需求时跟开发来一次需求“前世今生”的交流，就能一箭三雕。
话说回来，你的需求在下笔设计之前，就已经把自己的想法结合所有更可行的技术方案，有了前期沟通，至少在开发面前有了“脸熟”，后续排期还有机会刷脸，在跟开发聊的时候基本能摸清他对这个方案时候的把控程度，来推断后期是否在忽悠你delay（延期）。

4、跟reviewer沟通

做完一版需求，就要跟你的leader过一次需求review，在这个过程中，讲清楚你设计的逻辑，保证逻辑清晰、观点分明，同时，记下对方的反馈，缺失的有误的地方，拿回去重新想一遍，再进行修改。

自我学习

产品经理的工作开始都是琐碎重复的，如果不带着知觉去工作，总有一天等反应过来，你已经成为“闪电”——任何事都比别人慢一拍。

所以为了避免自己的重复单调的工作中磨灭了性子，就要在工作里学习学习再学习。

如何学习？可以从人的五官角度来说。

1、看

• （1）看书

• （2）看行业动态

2、听

多跟领导、有经验的老司机，哦不，老同事聊天，这个不是巴结关系，而是通过跟他们聊天，听取各方面的意见，兼听则明，才能正确认识事物，了解行业是什么样，为什么要让你这么做，以及你可以怎么做。首先要找靠谱的领导和同事。

听用户和团队的意见，学会对听到的意见，进行分析评估，不是全盘接受。

3、动手

作为产品经理，要保持某种行业的敏感度，某公司上线新产品或者某产品有重大更新时，第一时间动手安装并使用，一方面是对产品功能的了解，另一方面也用于验证各种假设和预测之后的发展。

配合动脑，去了解产品的功能点，思考背后的逻辑流程，是否存在问题，针对每个功能点分析：哪些是核心功能，哪些是辅助功能，为什么，等等。

4、说

我觉得刚才以上已经说的够多了。

5、想

• （1）独立思考，已经被圈内说烂的词，可以延展成另一篇文章，这里不细谈。总的来说，遇到问题，先自己想，不盲从，多方面听取再佐证。

• （2）换位思考

• （3）发散思维

以上，闲来时的总结，说的不好请见谅~

感谢你将无聊的白天与黑夜给我