而产品的本质是是用户需求的集合，满足了用户价值和商业价值，是一个长期、含杠杆、复杂的重复工作。
- 长期是指在产品生命周期内，无论哪个阶段都需要产品经理去进行维系。
- 杠杆则意味着产品需要以小博大，优先满足大部分用户的高频次需求。
- 市场变幻莫测，在用户和场景变化的背景下，可能还需要针对一个产品进行反复而又复杂的迭代。
市场都是充满竞争和遍布友商的（不包括垄断），在这种背景下，如何更快速满足用户需求，成为决定了产品成败的关键点。项目是过程，产品是结果，对于产品经理这个角色而言，两者需紧密结合，借助强有力的项目管理能力来保证按时按质交付，是为产品赢得竞争优势的前提。
二、启动：师出有名，齐心协力正如前文所描述的，项目的特点之一是临时性，即每个项目都会有明确的开始时间和结束时间。因此，以终为始，在启动阶段时就需要对项目进行通过阶段化管控，从而清楚每个阶段的主要矛盾是什么。
对于项目而言，主要可以分为 4 个阶段：启动、规划、执行和收尾。
每个阶段最关键的就两个事情：需要完成哪些工作和如何量化可交付成果。
在启动阶段，最核心在于师出有名，齐心协力。
一般而言，产品经理会组建“虚拟团队”（产品经理如何抢人力资源这是另外的 topic），里面会包含各类角色，例如前端、后端、QA、设计等等。往往产品经理都是有责无权，即和其他成员角色属于平级，而角色之间的利益可能不同，举个例子，设计可能更多考虑好用，开发可能更多考虑能用。因此，产品经理需要在其中充当润滑剂，协调和沟通，促使团队成员齐心协力。
始于需求而终于需求，产品经理会在调研中确定评估需求的优先级和利弊，当确定好后，就有了目标。这个目标也许产品经理自身权衡决策，也许是从领导层自上而下的“命令”。无论如何，就像大海里的游轮，方向已经定好。
项目经理会有项目任务书，产品经理也有产品需求文档，尽管产品需求文档已经在尽可能的完善，但是不同的角色会基于自身角度出发给出自己关于“航线”的建议和看法。如何选择航线，这需要产品经理在自身想法的基础上，尝试找到能使各方达成一致且投入产出比最高的方案。有时候，这也被成为“需求初审”。
曾经我一直好奇，为什么会有七夕节需要送花，端午节需要吃粽子、中秋节需要吃月饼。仿佛不同节日总有一个约定俗成的一个象征物品。后来我发现了，时间没变，变的只是人们赋予节日的意义，人需要有仪式感，所以就有了一个象征物品。
《小王子》里说：仪式感就是使某一天与其他日子不同，使某一个时刻与其他时刻不同。
项目同样需要仪式感，每个阶段的开始或结尾都是一个里程碑，每个里程碑都需要不同仪式来让团队成员意识到已经进入下一个阶段，从而都意识自身责任和项目节奏。
项目启动的仪式感可以通过启动会的形式来完成，在项目启动中，产品经理需要力争达到以下三个目标：
- 传达业务目标、需求价值和产品方案；
- 同步项目各大关键里程碑，确认好可交付物和量化标准；
- 合力消灭产品方案的不足点并达成共识。
好的开始是成功的一半，项目启动会的作用，在于能够通过一个会议让每一个团队成员尽可能的明确业务目标和把握项目里程碑，同时合力让需求文档更加完善，进而达成初步共识，增强凝聚力。
三、规划：运筹帷幄，决胜千里启动会，也就是产品方案初审，在会议上我们已经同步了几个关键里程碑，但是还需要进一步细化每个里程碑的时间点，而产品经理则需负责整体规划和把控细节，运筹帷幄，方可决胜千里。
产品规划有两种做法，一种是固定发版周期，然后从版本发布时间倒推可完成功能时间节点，一种是由版本上的功能，由产品经理统合后确认最终版本发布时间。
对于产品经理而言，如果是负责的是整个版本，那么就要确认版本发布时间。如果负责的是版本上的某个功能，那么就需要保证这个功能能够赶上版本发布，俗称“上车”。
“凡事预则立，不预则废”。
毫无疑问，规划是整个项目管理中的灵魂，好的规划能够让项目事半功倍，为每个工作项设定Deadline，是规划的核心。
就我自己项目经验而言，实际不可能完全按照计划进行，但是计划可以量化工作，从而把控风险。根据布利斯定理： 用较多的时间为一次工作事前计划，做这项工作所用的总时间就会减少。 事前想得清，事中不折腾。
当然，这里规划的前提，是已经在和技术总监/架构师确认了技术可行性，评估大致工作量后，现在需要进一步精确工作量。
在项目启动时，会议其实还有另外一个隐含的目的：让每一个计划执行者参与规划，从而提高准确率。
那么如何做规划呢？
做规划，说来也简单，核心就是拆拆拆，拆分工作量也就是项目管理中的工作分解结构（WBS），工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、可度量的工作细节的过程。正所谓魔鬼藏在细节中，对细节的把握程度也反映了一个产品经理的项目管理水平。
在整个团队会有不同的角色，最简单的工作分解即按照角色来分，包含设计、前后端、客户端、测试等，然后再由每个角色根据产品需求文档细化功到工作细节，最后形成产品规划。
在拆分时，这里有几个需要注意的点：
- 首先，也是关键点，作为产品经理，不要越俎代庖，在尊重团队成员拆分和估算的基础上，如有必要，可继续请技术总监/架构师审核。
- 其次，工作细节需要遵循 MECE 法则：“相互独立，完全穷尽”，也就是既不重复，也无遗漏。
- 再次，对于一个工作细节需要从从两个维度考虑：空间和时间，即交付成果和时间成本。时间成本的度量单位可估算到人天，即 1 人全力投入所需要的天数。
- 最后，单个工作任务，应只分配给一个责任人，避免旁观者效应，即分配的人都觉的“与我无关”。
坦白来讲，在项目早期阶段的拆分，因为还没正式开始，所以无论是设计还是开发，基本都是使用类比估算，即根据以往经验来估算现有项目工作细节所需时间。因此，实际项目中，技术和经验的积累可以提高估算准确性，比如引入技术总监/架构师参与评审，其次开发还可以通过手工实验等方式来进一步精确时间。
