许多产品经理可能会经常面临这样的问题：公司现有技术资源不足以支持自己的产品设计和迭代周期，导致不得不妥协。而Boss或客户还不断要求采用『小步快跑，快速迭代』的方式看到产品成果，这时作为产品负责人的你该怎么办呢？
让我们设想这样一个背景，并以此展开讨论：
某个产品的研发团队是由1位3年经验的研发Leader带队，加上3位0.5~1年经验的新人组成。要求：敏捷开发模式，并以此制定每个版本的里程碑和发版计划，通过以往的经验你明白该团队远低于正常配置，但时间紧任务急资源少，你只有上路。
抱怨解决不了问题，以项目周期为时间段，在项目执行前、执行中从容应对，通过合理的控制和管理尽可能的达到目的。
项目前期
明确状态，获取理解和支持
在评估完时间，资源和可行性后，PM需要做好充足的心里准备，分别列出最坏，适中和最好三个结果。这其中又以『最坏』为重中之重，因为这很可能就是真实的结果。PM应当明确告知领导可能出现的后果，打好预防针。如涉及到对外合作项目，还要在内部达成一致如何对客户进行告知。不要隐瞒后果期待奇迹发生，更不要企图自己承担后果。P.S.有职责较为明确的公司，该工作会由项目经理承担。
做最后努力，争取（额外）资源
有给力的研发负责人带队，一方面可以对团队把控，也可以让年轻人发挥主观能动性快速成长，也许他们未来都是公司的财富。如果团队中不具备这样的人，发挥人脉关系哪怕借一个来，都是非常有必要的。还是不行？不如放弃敏捷开发模式或重新衡量项目可行性，以免拖垮团队毁掉声誉。
制定可行的迭代周期
迭代周期不要过短（团队HOLD不住，时间都会浪费在代码分支合并，冲突检测，发版上），也不要太长（否则失去了敏捷开发的意义），每次发版时间在可以在标准值基础上+30~50%时间，给不成熟的团队留出充分的容错时间，所以需要具体情况具体分析。这时作为产品经理的你，需要和研发负责人探讨每个里程碑实现程度。请考虑以下两方面：1.是否会影响你的产品设计节奏；2.在每次交付时能否满足领导或客户的预期。
明确开发背景，不走回头路
包括开发框架，网站架构，语言数据库服务器部署要求等等（尤其设计到客户，一定要确定清楚，必要时有合同，邮件为证）。不要进行到一半发现完全跑偏，团队接收不了这样的惊喜。在此环节，产品经理的参与主要体现在明确表述在与需求方的接触过程中，对方有何『硬性』要求都要提出，以供整个团队做设计背景。
项目执行阶段
部门间彼此配合，适当的对结果打『折扣』
由于资源局限性，部门间更需要彼此理解和对目标认可。根据现实情况，在产品设计上做一些妥协，给功能列表减负，优先级低或者『令人尖叫』的功能先砍掉。举个极端的例子，注册验证码都搞不定的的人，就干脆去掉验证这步吧。如果是对已有产品进行大的版本更新，就要考虑更多的兄弟部门和联动意义，比如去掉某功能是否会影响该部门开展业务活动，作为PM不可能令谁都满意，只能考验自己的平衡和交流能力了。
会议的重要性
这点所有敏捷开发都会强调，包括通过站会汇报各自进度情况。能力不足更要保持信息畅通，不要让成员自钻牛角尖再给项目雪上加霜。产品经理在项目执行过程中，始终会保持与需求方的沟通。如果出现产品变更或需求变化，也要在会议上及时提出，如此反复修正复合当前情况的开发计划，并保证可行性。
适当的说不
在项目执行过程中，团队难免会受到各种各样的干扰和额外的工作要求，比如客户会要求你帮助部署服务器，测试线路等等。如果合同中有对应要求，可以协调兄弟部门作支持。但原本就超负荷的研发团队，最好合理的拒绝，避免再牵扯更多精力。
巧妙的进行汇报
虽然定期汇报项目情况是项目经理的工作，但产品经理需要通过在方案中植入相对感性化的描述，来弥补项目不足和客户的体验。举例来说，在重要又枯燥的数字（完成度，开发率等）之后，适当的可视化工作状态，比如放一些成员加班的照片，攻克问题的数字及内容和对下阶段的产品设想。核心思路是体现项目进度虽有一些延后和不尽如人意，但整体仍未失控。
额外：感情安抚
能力不足往往是团队年轻，但年轻人充满活力，加班到凌晨不眨眼，虽然解决的问题看似都『不值一提』。但长期如此消耗势必对团队成员的心里产生巨大的折磨和影响。端茶倒水零食饮料不能少，如果有『程序员安抚师』……想多了，有这预算不如在招个经验丰富的人。这期间大部分人的能力都在突飞猛进，没准也可以显露大牛天赋。
总结
