这是在某社区的一位前辈作出的总结，结合自己的产品经历进行了一些补充和修改。
- 需求来源部分
不同方向的需求来源略有不同，总体来说，产品经理的需求来源有以下几个方面：
业务需求：由业务方，比如 BD、编审、运营等，直接提出的业务需求；
数据挖掘：通过数据挖掘和分析，发现的问题或需求；
竞对调研：通过分析竞对的产品，发现竞对比我们有优势或值得学习借鉴的地方；
实地观察：不论是 B 端产品还是 C 端产品，其实都有大量的机会实地观察用户行为。比如直接陪访城市运营等；
战略需要：俗话说「老大拍的」，这类是由公司 leader 直接安排的需求，通常表示公司未来发展方向或急需解决的关键问题；
其他还包括客服、商服反馈的问题，通过在线渠道或用户访谈获得的需求，还有微博、朋友圈吐槽等各种 SNS 途径。不论哪种途径获取的需求，产品经理都应该有一个自己的需求池，统一记录各种想法。
在不同需求来源中，最看重的产品经理自己发现/评估的需求，这是评价产品经理需求决策能力的重要指标。
- 收集和整理需求
收集和整理需求，就是将需求统一记录到需求池，方便团队内/间的传播。每个团队建议维护自己的需求池地址。
需求池只是一个备忘，记录下来的需求不一定都要做，也未必是值得做的需求才记录下来。
及时维护
- 立项审批
立项是产品流程中的第一个必要步骤，在这个阶段，核心的是要确定项目的价值和目标。
3.1 确定项目的价值
确定项目价值有三个核心要素：角色、场景和目标。也就是，谁在什么情况下要解决什么问题（满足什么需求）。三个要素必须齐备，才能做出基本的价值判断。
具备了三个要素，还需要从两个维度去定义项目的价值。
第一个维度，是当前业务/产品阶段。基于不同的业务阶段(一般都是萌芽期、成长期、发展期、稳定期、衰退期），产品在战术和战略的打法各有不同。比如某共享单车做Growth中的17年红包大战，虽纵向来看不利生态循环，但横向来看利于业务竞争。后面会另起一篇分享“业务型产品经理赋能业务的逻辑与思考”
第二个维度，是影响范围。抛开计量谈毒性，都是耍流氓。前面我们提到了用户第一个的标准，但是，如果一个需求仅对 1000 个用户有收益，但对 50000 个商家有收益，那么优先级的判断也是不同的。影响范围是大家日常工作中非常容易忽略的思考点，往往发现一个 badcase，就拼命想解决，说好听点叫偏执，说难听点就是本末倒置。
思考项目价值，推荐用5 Why 分析法，对事情不断追问，看看一个需求，是否还有成本更低的解决方案，本质收益到底是什么，到底会影响多少人。
3.2 确定项目目标
价值说的是对什么有好处，目标说的是有多少好处。
制定目标必须符合 SMART 原则 ，细节看链接，我这里举个例子。
我的目标是要变成瘦子；
我的目标是要减肥 6 斤；
我的目标是要一个月减肥 6 斤；
我当前体重是 75 公斤，以我的身高计算，合理体重是 72 公斤，我希望在下个月 1 号前减重 1 公斤，3个月内达到标准体重。
上述四种描述目标的方式：
第一种，典型的没有任何意义的目标，没有时间点、没有量化目标；
第二个，有了一个量化目标，但是什么时候到达，没有明说。还记得我说过的抛开计量谈毒性么？
第三个，有个一个时间点，但是几乎不可能完成，即便能完成，也是以牺牲健康为代价。这就是不具备可完成性和与总体目标的相关性；
第四个，相对比较合理。首先说明了当前的情况，以及合理的目标值。其次，有明确的时间点和量化指标，还有相对长期的规划。最后，相比之下，可行性也会更高一些。
3.3 如何进行立项审批？
建议组/团队有一个立项表，其实核心就是确定价值和目标。表格填写好以后，可以在每周一早上的例会上提出立项的要求，leader确认立项后会将立项标红。
任何口头承诺都是无效的，只有立项表中的项目被标红，才说明立项成功。
价值描述是否清楚，价值优先级是否足够高；
项目目标是否 SMART；
项目主 R 是否有足够的时间精力确保项目的质量；
项目投入有多大；
立项有三种结果：成功、待定和放弃。需要严格把控需求，以确保资源的最大利用化(切记不仅仅是研发资源)。
- 调研、写方案和组内评审
立项成功只是第一步，围绕立项时确定的项目价值和目标，需要进行深入的方案设计工作。
4.1 方案调研
所谓调研，就是收集我们设计方案所需的背景信息和数据。需要遵循以下原则：
有明确的调研范围，不能太窄，也不能无休止的调研；
一定要调研第一手资料，不能偏信二手信息。比如综运反馈运维师傅有需求或者有问题，我们就应该直接调研运维，了解商家的真实需求；
数据调研需要足够的样本量；
实地调研。如果是系统功能，就要自己测试；如果是需求，最好直接和需求方进行面谈；
要输出调研报告，尤其是调研结论；
4.2 方案编写
这里不多讲，需求文档最重要/首先是讲明白事、拉齐认知。后面会另起一篇分享“需求文档编写规范”
4.3 组内评审
评审注意事项：
各组 leader 必须参加组内评审；
所有需求必须经过组内评审；
评审需要输出评审结果报告，记录修改点、反馈和是否通过的结论；
根据不同需求类型，评审可以酌情邀请业务、RD、UI/UE 和 QA 参加；
建议方案出来以后，PM 先和需求方或自己的 leader 进行一对一沟通，对方案要点进行确认；
组内评审原则上不应该超过 2 次；
如果评审次数过多，需要评估对应 PM 是否具备完成该项目的能力，如不胜任，需要及时换人，确保项目进展和质量；
- 项目评审
也可以叫做大组评审或正式评审，评审要点如下：
大组评审必须邀请 RD、QA 、UI/UE、业务方和关联方，周知到业务 leader 和各产品 leader；
评审形式，以主 R PM 讲产品需求文档为主，讲解过程中，尽量不要打断陈述人，让陈述人有机会完整表达方案；
避免「钓鱼评审」，不能出现大家写需求，PM 记录的情况；
严格控制评审时间；
评审结果分为：重写、修改和通过；
评审至少提前一天发出会议邀请
- 技术评审
技术评审的重点是技术评估项目可行性，有以下要点：
技术评审也可以由 PM 发起，最好是 PM 发起；
技术评审后必须拿到估时；
按照功能列表，如果能给出每个具体功能的估时最好；
技术评审必须在排期会之前完成；
重点项目需要邀请 RD leader 参与；
多系统关联项目，需要邀请关联方 RD 参与；
需要 UI/UE 参加的项目，技术评审前需要完成相关交互设计；
原则上，进入技术评审后，需求关闭，不允许进行需求增改；
评审至少提前一天发出会议邀请，需带文档链接，方便相关团队提前熟悉；
之所以需要按照功能列表进行每个功能点的估时，同时也需要给每个功能点确定优先级，是因为在后续的排期中会用到。
- 排期会
所有开发资源都需要排期，一般来说，后端和 FE 因为不依赖版本，可以在一个排期会进行；客户端由于需要跟版，有自己独立的排期会。
这里不多阐述，每个团队有自己的节奏，关键在于“严格执行和优化迭代”
- Task 分解
项目排期成功后，建议 PM 给相关 RD 和 QA 创建 task。要求如下：
Task框架最好覆盖“需求开发流程的各节点”；
至少一个功能点要分拆一个 task，或一个页面也需要一个 task；
测试任务也需要开 task；
中大型项目，或 task 数量超过10个的项目，需要创建 dashboard；
一个功能点，如涉及多个 RD，每个都需要创建 task；
task 必须在开发之前创建；
没有开 task 的功能点或页面需求，RD 可以不做；
及时维护
- 项目进度跟踪
项目开始开发后，PM 不能做甩手掌柜，还需要对项目进度进行跟踪。一些项目进度管理方面的方法：
开发周期较短的项目，PM 需要每天 check task 的完成情况；
开发周期较长的项目，项目初期可以每两天 check 一次 task 完成进度，临近 deadline 需要每天 check；
根据项目要求，可以周期性与 RD 开项目沟通会，了解 RD 在项目进度中的问题和困难。比如相关方响应速度、需求理解、资源协调等；
重点项目或难度比较大的项目，PM 可以酌情开每日站会。站会可以在早上，5-10分钟，沟通前日进度或 todo；
项目跟进过程中，要非常关注外部依赖，需要明确依赖方和依赖顺序，尤其是对外部资源的依赖；
优先级比较高的要求，可以每天汇总项目进度，发送给相关方和需求方；
- 功能验收
功能验收指的是确保项目完成了最基本的功能实现，与 RD 一起确定项目是否达到提测需求。
需要在编写需求文档的时候，就确定功能的验收标准，所以验收环节就要严格按照验收标准进行验收。
验收完成后，可以发出一个正式的验收结果。但是，需要注意的是，验收不代表项目达到上线标准，仅表示项目可以提测。
为什么在提测前 PM 需要验收？主要还是因为我们的 QA 资源非常紧张，希望 QA 用在更有价值的地方，而不用去操心基本的功能完整性问题。
- 项目提测
项目开发并进行基本验收后，由 RD 发提测邮件。
测试之前，其实在项目开发过程中，PM 需要与 QA 一起编写测试用例。原则上来说，项目提测之后，PM 只需要与 QA 沟通测试进度，了解测试中出现的问题。测试中的 bug，需要 PM 和 QA 来判断是开发 bug 还是产品设计的缺陷。
如果提测过程中有产品设计缺陷，需要分情况讨论。
如果是客户端版本，而产品设计缺陷并没有很大的影响范围，不会导致用户体验层面的 block 和太大伤害，原则上不在提测后修复产品逻辑的问题。可以将这些问题作为高优先级的需求列入下次项目。这个判断需要产品线 leader 来判断。
如果是服务端需求，不存在严格的发版和上线时间，可以评估 bug 的影响范围和严重程度，酌情进行修复。
当然，项目中出现产品逻辑 bug 属于 PM 的严重失职，需要我们避免。
在项目开发过程中，如果有 delay 的风险，需要尽早发项目延期预警邮件，最好面对面周知到KP，如关联方 RD、PM 和需求方。
测试过程中，最终 PM 还要进行一次产品上线验收，在 QA 确保项目质量的情况下对功能完整性和可用性进行评估。并正式邮件发出。
- 预上线与上线
项目开发并测试完成后，PM 需要先发预上线邮件，并在相关渠道进行周知。之所以要发预上线邮件，是因为考虑到项目上线对各方可能带来的影响，需要各方提前有所准备。原则上，预上线邮件至少提前 1-2 天发出。
项目上线后也需要发正式邮件周知，注意事项如下：
原则上，周五和节假日前三天，不能上线。如有特殊需求要上线，需要产品线 leader 和 RD leader 确认；
预上线和上线邮件要发送全组，包括业务、运营、PM、RD、UI/UE、QA 等；
预上线邮件侧重说明项目上线的影响范围；
上线邮件侧重说明项目的价值、目标和方案，邮件中需要明确说明上述内容；
上线邮件中，不仅应该包含项目的方案说明，还需要酌情考虑增加使用说明、运营计划、FAQ 等内容；
上线邮件中，要说明项目上线后各方需要关注的数据和异常；
- 项目总结评估
项目总结评估是整个项目中最重要的环节之一，有 PM 主导，主要做以下几个事情。
第一个，写项目总结文档。从以下几个方面：
目标完成统计（数据）
目标完成情况的分析，为什么完成得好，为什么完成不好
方案设计问题复盘
项目执行问题复盘
开发测试问题复盘
产品运营问题复盘
后续运营推广方案
下一步产品计划
第二个，需要基于总结文档开项目复盘会。是否需要正式复盘会，视项目情况绝对。大中型项目一定需要复盘会，效果突出或不能达到预期目标的项目，也需要专题复盘。
第三个，将上述信息内容，简要填入项目总结表。
作者：喂喂喂喂卫
链接：https://www.jianshu.com/p/852b61abe89a
来源：简书