许多产品经理可能会经常面临这样的问题：公司现有技术资源不足以支持自己的产品设计和迭代周期，导致不得不妥协。而Boss或客户还不断要求采用『小步快跑，快速迭代』的方式看到产品成果，这时作为产品负责人的你该怎么办呢?抱怨解决不了问题，以项目周期为时间段，在项目执行前、执行中从容应对，通过合理的控制和管理尽可能的达到目的。
在项目生命周期运行过程中的不同阶段里，由不同的组织、个人和资源扮演着主要角色。项目的生命周期是描述项目从开始到结束所经历的各个阶段，最一般的划分是将项目分为 "识别需求、提出解决方案、执行项目、结束项目"四个阶段。实际工作中根据不同领域或不同方法再进行具体的划分。
1、明确状态，获取理解和支持
在评估完时间，资源和可行性后，PM需要做好充足的心里准备，分别列出最坏，适中和最好三个结果。这其中又以『最坏』为重中之重，因为这很可能就是真实的结果。PM应当明确告知领导可能出现的后果，打好预防针。如涉及到对外合作项目，还要在内部达成一致如何对客户进行告知。不要隐瞒后果期待奇迹发生，更不要企图自己承担后果。P.S.有职责较为明确的公司，该工作会由项目经理承担。
2、做最后努力，争取(额外)资源
有给力的研发负责人带队，一方面可以对团队把控，也可以让年轻人发挥主观能动性快速成长，也许他们未来都是公司的财富。如果团队中不具备这样的人，发挥人脉关系哪怕借一个来，都是非常有必要的。还是不行?不如放弃敏捷开发模式或重新衡量项目可行性，以免拖垮团队毁掉声誉。
3、制定可行的迭代周期
迭代周期不要过短(团队HOLD不住，时间都会浪费在代码分支合并，冲突检测，发版上)，也不要太长(否则失去了敏捷开发的意义)，每次发版时间在可以在标准值基础上+30~50%时间，给不成熟的团队留出充分的容错时间，所以需要具体情况具体分析。这时作为产品经理的你，需要和研发负责人探讨每个里程碑实现程度。请考虑以下两方面：1.是否会影响你的产品设计节奏;2.在每次交付时能否满足领导或客户的预期。
4、部门间彼此配合，适当的对结果打『折扣』
举个极端的例子，注册验证码都搞不定的的人，就干脆去掉验证这步吧。由于资源局限性，部门间更需要彼此理解和对目标认可。根据现实情况，在产品设计上做一些妥协，给功能列表减负，优先级低或者『令人尖叫』的功能先砍掉。如果是对已有产品进行大的版本更新，就要考虑更多的兄弟部门和联动意义，比如去掉某功能是否会影响该部门开展业务活动，作为PM不可能令谁都满意，只能考验自己的平衡和交流能力了。
5、明确开发背景，不走回头路
在此环节，产品经理的参与主要体现在明确表述在与需求方的接触过程中，对方有何『硬性』要求都要提出，以供整个团队做设计背景。不要进行到一半发现完全跑偏，团队接收不了这样的惊喜。包括开发框架，网站架构，语言数据库服务器部署要求等等(尤其设计到客户，一定要确定清楚，必要时有合同，邮件为证)。