always bear in mind：
开发人员的工作从来不是单纯地画页面、写工程文件。
实际上，参与项目的每一个人都应当了解和理解业务，这是所有参与人的责任。产品经理有义务确保这一点的落地。
共同概念构建
正式开工前，就应在项目组内构建共同的概念和目标。
开发人员同其他职能的项目同事一样，需要对项目的需求背景、业务范畴、产品目标有清晰的认知：知道开发的产品是给谁用、何时何地用、用来做什么。产品价值的实现，依赖于共识。
共同概念构建的时机未必发生在进入开发阶段时。实际上，一旦决定开发新的产品，进入产品探索和产品定义阶段，共同概念就会因为需求和技术研究的深入而形成。进入开发阶段后，团队纳入新成员时，都应当被及时同步，力求所有参与人都on the same page。
规则构建
确定开发模式、成员及分工、协作及进度管理工具
一般来说有瀑布式和敏捷式两种产品开发模式，两者各有优点。而所在行业不同、企业内协同习惯不同、业务不同，产品类型（自主创新产品、定制产品）不同，项目节奏不同，这就导致没有绝对可以拿来就用的开发模式，产品经理应当在了解项目属性、干系人诉求之后，选择或者构建合适的开发模式（或者说项目节奏）
明确目标之后，需要及时就工作中关键的部分建立规则：
- 交付节奏：应拿出规划（路线图）
- 成员及分工：明确团队的构成及每个人的分工
- 写作及进度管理工具：需求和bug都应当被归集整理起来，有详细的描述（描述内容可以在具体的文档里）并标记责任人、deadline、所属迭代。应当从初期就有管理平台，如果没有平台软件条件，也至少应当持续维护在线表格，使得任务、职责、时间都是清晰的。
需求评审
需求评审不是整个开发阶段的前期事项，而是产品整个生命周期里会不断进行的工作，每一个需求，都需要经过需求评审，在团队内充分讨论后，再进入开发。
需求评审的需要明确3块内容：做什么需求，做成什么样，怎么做。
- 做什么需求：每次会前需要完成待评需求的梳理（原型和文档），列出清单，简要介绍业务场景和解决方案逻辑，附上文档链接，标注重要性或优先级，有特殊的要求也可以一起标注上。将清单提前发给参会人员。复杂的需求可以在会前先和技术leader进行讨论。
- 做成什么样：给定场景，应当有很多种解决方案，评审时应当拿出最有价值、最可行、最可用的方案，有必要的话，可以说明为什么在众多选项中，选择了当前这种，并且强调哪些地方是需要注意的。
- 怎么做：确定产品方案有价值、可用、可行后，需要确定技术方案，包括表结构怎么设计、接口怎么设计、ETL怎么设计等等。这个环节可能会涉及页面的微调，产品需要快速评估是否可以进行调整。
需求评审，评审的是需求的价值和解决方案，而不是做需求的人。每个人在这个过程里都应当竭力保持客观，围绕产品目标，进行设计、讨论和执行。
进度把控
产品开发的进度受到多种因素影响：需求梳理是否到位、评审时是否完整充分讨论问题、开发资源是否充足，开发的流程会存在先后和并发两种，因此前序任务是否及时完成，开发人员能力是否足够等等，都会影响进度。
产品应当在梳理、评审、开发、测试、上线的每个阶段都做到细致、及时：
- 梳理：做需求时，应力求逻辑严密、原型完整、表述明确，避免后续的需求变更、修正。需求一旦进入开发阶段，就尽可能地不去做大的更改。
- 评审：评审时，明确关键点，将关键问题讨论清楚，并在团队内拉齐
- 开发：需求进入开发阶段，并不意味着可以撒手不管了，除非是思维及其严密、文档写得滴水不漏的产品，开发才有可能可以直接执行，多数时候，进入开发阶段，开发还会有各种细节需要和产品确认打磨（当然，前期工作如果够细，这些都会相应减少），因此在这个阶段需要做到及时响应和及时调整
- 测试：不需要等到功能全部做完了，再做测试，页面画完了、接口逐渐接入了、部分功能上线了，测试工作就可以开始了，这样测出来了问题，开发通常可以很快地修正，等到全部功能做完之后，再进行一两轮的全盘测试，这样基本能够保证在功能开发完成的两天内完成所有测试和bug修复工作（两天的估计是基于这9个月的开发期的经验）
- 项目侧演示：项目侧演示这一环节不在产品开发的一般阶段里，但是对于定制项目而言，这是一个十分有必要的环节。当功能达到产品验收要求后，需要邀请项目侧的同事开会，同步进度（包括需求的实现逻辑、特殊处理的地方、需要和客户解释的点、后期运营的注意点）并进行功能演示。这是功能正式上线前，项目侧唯一的修正机会，而这个机会对产品和对项目都很重要。
- 发布上线：功能上线前，需要对照checklist（实体or非实体均可，但产品本人要十分清楚），保证功能及其依赖项没有问题。功能上线后，及时到线上环境进行测试，有问题的当天提交bug。
以上是在每个节点，产品把产品工作从50分做到80分甚至90分的要点。
除了产品自己的行为之外，还有一些团队管理手段帮助推进进度：
- 每日短会：开发期的每天早上，需要通过15分钟以内的短会进行组内信息交流。会议的目的是同步进度，提出当前的卡点和问题，是否需要其他人的协助等。15mins是上限。站会是一种控制会议时长的手段。
- 每周例会：每周需要进行例会，例会的目的是及时总结、重置。例会内容包括当周开发内容、存在的问题、进度是否符合计划、下周计划等。
开发进度是团队协作的结果（不考虑资源变动和外界依赖），整个过程里，会有各种可能发生的事，产品的任务是尽力让团队的每个人专注、高效。