1
需求
产品以解决用户核心问题为目的。这里的一个关键词，用户核心问题。可以理解为需求，虽然两者有区别，但是这样画上一个≈号，没什么不妥。
获取需求的方式，也就是需求的来源：
商业需求-来自于商业化团队，或者老板、合作商，外包团队多见于甲方；
用户反馈-来自于各大应用商店的用户评论或应用自带的用户反馈，也可以是客服团队的用户反馈，问卷调查等；
团队其他部门-来自包括但不限于测试、运营、开发、产品等团队；
自身挖掘-产品线负责人体验自身产品、对比竞品、数据分析来得出的需求点。
身为产品经理在这个阶段要做什么？简单的收集和整理，就足够了。
随后是产品迭代第一步需求的第二个阶段：需求分析
顾名思义，不是所有的需求都是真正的需求，这就需要产品经理掌握需求分析的技能。首先是筛选，讲一些明显与产品定位背离的需求过滤。还有一部分需要过滤的需求，即不合理的需求或小众化场景的需求。综上可以统称为伪需求，如何辨别真伪需求是一个永恒的话题，作为一个初出茅庐的产品经理，以理解自己的产品为基础，若不能很好的判断。个人建议请教前辈，或了解这个产品的人，领导、同事，都是你可以咨询请教的对象，但是也要注意方式，不是拿着一堆需求，听他讲，哪些哪些是伪需求。一定是你先进行尝试，然后再拿有疑问的去请教。不耻下问，才能进步，这也是一种学习的方式，而且是很好的学习方式。第一步筛选过后，剩下的基本就是真需求了，我们已经完成了“做还是不做”这个问题，这时候又会面临一个问题“什么时候做”，网上有许多具体的方法，比如四象限分析法，kano原型等等，这里就不一一赘述了，还是那句话，作为一个初入产品的年轻人，要学会不耻下问，不要指望一下子就会把一件事做的很好。
最后是产品迭代第一步get需求的第三个阶段：需求管理
学会如何管理好需求，对产品经理接下去的产品迭代有很大的帮助。创建一个自己的需求池，并保持不断更新，从中发现产品迭代的方向。这里贴一个自己的产品需求池，放不了太多，大家谅解一下。表内包括了需求的收集和整理，也包括了需求的分析，还有需求的状态和时间等记录。
2
竞品分析
当你从得到下个版本的需求以后，身为产品经理的你需要做什么。当然是对需要的功能进行设计规划啦，这时就少不了做竞品分析。注意，初入门的产品经理，一般都会被分配到一个小功能的优化和迭代，所以像产品培训班的对整个产品做所谓的深入分析，一般没什么X用，很少见有应届生或刚转行的产品能负责从0-1的，况且从0-1，也不需要如此大费周折的长篇大论。
那么在真实工作中，我们需要的一份正确做法的竞品分析，应该是什么样的呢？
明确竞品分析的目的；解决一个实际的问题，比如要做购物车的商品分享功能，想看看同行都怎么做？
选择好竞品分析的对象选择细分行业的前二/三即可；比如对于淘宝公司来说：天猫，京东，就是不错的选择；
对比目标状态的截屏，放到一起；横向放置不同产品同一功能的截屏，纵向放置当前功能页面的不同状态；
在页面合适的位置可以使截屏右侧叙述优缺点，和自己的思考与总结；
通过对比分析，得出自己的观点，我们应该怎么搞？
3
原型
原型是产品经理很关键的一个输出物，个人不推荐用墨刀或者mockplus等原型工具，还是喜欢用axure，当然更推荐有条件的同学使用sketch。我想讲述的并不是如何使用这些工具，我想讲述的，是一个产品新人，如何去产出原型。流程来到这里，你已经做足了功课，完成了竞品分析，now，就是把需求落地的第一步，产出一个demo，也就是原型设计稿。这里引申出两个问题：
你是否已经完美的完成了竞品分析，明确需求的规划和设计？
是否已经决定参照哪一款竞品或者已经有了自己的规划和设计？
有自信鉴定的回答是好事，但是往往事与愿违。因为，经历不足导致你还摸不透领导的想法，你还不知道需求到底想达到一个什么样子的效果。怎么办？如果在做竞品分析的时候没有和领导讨论过。那我想最好的方法，就是参照竞品，结合自己的产品，设计出多套原型稿，根据自己的思考和分析，推荐一套，并跟领导进行讨论，在过程中讲明各方案的优劣。如果在竞品分析时已经完成了和领导的沟通，也不要局限，至少产出两套原型方案，再和领导沟通。如图（比较粗糙。。突然找不到好点的了，将就下吧）：
再补充一点，许多产品经理在纠结做高保真还是低保真的问题上分歧很大，我对这个问题的看法是这样的，在所限时间内，根据任务轻重缓急，能画的高保真一点就高保真。我的许许多多迭代需求原型都是直接在原图上进行修改的，效果看上去会很直接。高保真原型也有利于UI进行视觉优化，可能有人要反驳我了，但站在UI的视角上，你给我一个很丑的原型，我连看都不想多看两眼。能画高保真，为什么不呢？对自己也是一种技能的提升，何乐不为。下图贴自己的低保真，0-1的项目，任务重的情况下我也会画低保真，但是效果上绝对不会做的很差劲。
4
PRD文档
prd文档无疑是产品经理输出内容的重中之重了，上下游交付，全靠这份文档。这里小小diss一下pmcaff的高赞文，题目叫上下游都喜欢的XXX文档。大概是这个名字，我看了以后很不是滋味，因为这样的文章，包含的内容太多，任凭UI还是开发，不会有那么多时间，来看这种文档。
这里贴一下前项目组小伙伴的一些文档，各有各的特色，但是无一例外，都是不错的文档（开发挺喜欢看着，然后拿着文档骂需求啥时候改了这种）。
上图展示的仅仅是某个功能的prd文档单页，prd远远不止这些内容，下面贴一个一般prd需要的目录，详细的在上面lisanke老师的链接里也有，看官们选择性阅读。图如下：
最后，prd文档不是写完上交，就可以了。要保持实时更新，特别是版本的需求变更等情况，要及时的记录并更新，一是为了不背锅；二是为了等待下一位有缘人接盘的时候，需求出现偏差不知所措。
5
需求评审
在完成了原型和PRD文档以后，需求评审就到了终于要交付的时候了。你要做到的就是告诉上下游，项目组的所有人，这个版本我们要做什么，为什么要做这个，设计是怎么样的，预计上线时间等等。当然，这样直接讲，压力难免有些大，而且，你怎么保证你写的文档没有问题呢？so，我们来讲一讲需求评审的流程。
在确定方案并完成了初版的prd文档v1.0之后，与产品线领导1对1，或产品组内部，进行需求评审。指出不足和有问题需要修改的点。大概流程就是你先讲一遍，然后大家讨论，自己做记录，然后结束后抓紧时间讲prd文档进行完善。
然后的然后，在prd文档v1.1会有专家组（boss们）对prd文档进行专家评审，有问题则指出并修改，循环。没问题则选良辰吉日，交付项目组其他成员（一般为设计团队和开发团队）。
第三轮，prd文档v1.2，可以交付设计团队和开发团队了。无可避免的，会上大家会各自发表意见，会发生诸如，需求变更，需求延期等常见问题，身为产品经理的你，要记录并整理，参与讨论甚至主导讨论，多站在对方的立场看待问题，并试图说服别人或者被别人说服。同样，需要快速产出prd文档v1.3，确认无误后，交付设计和开发团队，进行下一阶段。这里顺带提一句，如果是Axure完成文档的小伙伴，建议在设计产出作品后，将prd文档中的图片进行替换，可能有人会说多此一举或者麻烦，但是好处是显而易见的，开发可以看得更明白更直接，问题会少很多。
至此，需求评审结束，prd文档经过一系列的修改，完成归档。
6
对接UI&开发
这个话题也是产品届经久不衰的话题了，不多做赘述，没有什么意义。个人的意见是，在设计团队，开发团队，测试团队，运营团队，任何人在这个版本，或者你负责的某个功能上有疑问的时候，你都要及时出现，说明并解决问题。保证进度正常。其实话语之间，都凝结为一句话，别人在加班，你也就老老实实待着吧，乖。
至于如何和大家沟通，这个全凭自己，谁都教不了你，一句话：不会沟通，难以胜任产品经理。
补充一点：进入开发以后，产品经理可以就下一轮的版本迭代计划进行筹备了，即开始接需求，然后就是循环往复了。
7
需求验收
需求验收不等同于测试，测试有专门的测试方法论和测试工具。产品的需求验收，指的是对自己负责的功能点进行验收，确认与设计稿是否一致，确认是否存在问题。这个流程非常重要，直接关系到了预想和实际的差距。这个阶段多发的状况，是在原先的基础上进行优化，这是很正常的，在不改变需求的情况下，更好的将需求落地。
同样，期间可以安排设计团队走查，保证UI稿的正确性。
同时，更新项目进度表，记录并整理开发时间，进入测试流程。下图贴一个自己的项目进度表吧，看起来更加直接一点。
8
上线跟踪数据
一般APP上线流
在线咨询
0519-85268026