不管是传统的瀑布模式开发，还是时下比较火的敏捷开发，调研需求，分析需求，这些最基本的工作都是离不开的。
在敏捷开发里面，先不谈敏捷开发的思想，单说产品经理要做的事：
第一：用户故事，这个是肯定要写的，但是写的依据是什么呢，那就是调研需求和分析需求，只有先了解需求，知道用户想要什么，才能把这个用户故事写出来。
第二：原型和先关辅助文档、流程，（到底是先写用户故事还是先画原型，这个问题，在实际工作中还存在一点争议，有的产品经理比较倾向先出原型，他们认为原型是所见即所得，原型出来了，用户故事也就是出来了，有的产品经理则倾向先写用户故事，他们则认为，用户故事出来之后，原型这个东西其实就无所谓了。）
不管是谁先出，谁后出，反正这两件事，咱们产品经理都得做。 备注：一般情况下，敏捷开发，都会使用jira这个系统。
第三：用户故事、原型、先关辅助文档、流程都出来之后，剩下的就是团队开会过方案了，（讨论一下你的原型或者用户故事，大家集思广益。）方案没问题的话，剩下的就是举牌，评估故事点了。
第四：产品经理的方案通过，故事点也确定之后，剩下的就是由项目经理或者技术经理，根据产品经理撰写的用户故事，拆分成，技术上的任务，然后分派给下面的研发工程师进行开发。
传统的软件开发，就是很早以前，在没有原型以及用户故事这个概念之前，研发工程师，都是以需求规格说明书即PRD为准。那个时候，调研需求，分析需求的人，不能叫产品经理，应该叫需求工程师，或者需求分析师。需求工程师调研完需求之后，可能先会出一个需求调研的报告，1是用做工作的汇报，2是记录第一手需求调查的资料，做存档备份。（在这其中也会伴随着大量的文档，不同的项目，根据项目的量级，文档的数量以及种类，会有所区别。这个咱们也不需要特别费心去搜集需求分析师到底要写多少种文档，甲方作为需求方，要求什么文档，作为最后的验收材料，甲方会提的，需求分析师，根据甲方的标注写就行）
抛去其他的辅助文档，作为乙方的需求分析师，最为重要的，也就是一个需求规格说明书了，这个文档将是最为开发的指导性文档，研发人员将按照这个文档里面呈现的业务流程和功能细节，进行开发。当研发人员，对你这个文档不明白，有意义的时候，最为需求分析师（或者也可以理解为现在的产品经理）要及时的给予研发以支持，以保证开发能够顺利进行。所以，即便是需求分析师的文档（PRD）写完了，也仍旧需要跟进研发，跟进测试，等等
如果将需求分析师的工作内容映射到产品经理上，那么自然也需要跟进UI、跟进运营，等等。
以上内容，节选自大饼老师与学员的沟通答疑（仅供参考学习）