本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）
这里所指的新产品研发，不是指本身企业的新产品，而是特指那种在行业中初创，前途不明，尚需市场检验的新产品。敏捷开发能够在很大程度上帮助这种产品的开发过程。
新产品的第一要务
策划新产品的第一要务是：谁会买这种产品？为何？
开发新产品的第一要务则是：它与以往产品的核心差别是什么？
这个听起来不难理解，可是作起来有困难。由于通常产品开发每每是先作“最重要的功能，最基础的功能，最影响架构的功能”，这很容易在好久之后，才能看到产品的核心差别。
所以，虽然不可能彻底脱离重要性、基础性、架构性的制约，但仍然应该常记：验证与市场上以往产品的核心差别是第一要务。
新产品研发
如何快速体现核心差别（通常是创新性的价值观），是新产品研发的中心。
具体作法不少，下面举一个例子。
曾经有一家游戏企业，但愿能用“广种薄收”的方法来作新游戏。可是发现每一个游戏上来都要作可视化、用户登陆、商店、NPC、场景、帮派……这些基本功能，因此常常游戏开发开始好久了，还看不出游戏“好很差玩”这个最重要的核心。这就极大地制约了人才、资金的流动性。
后来他们决定：开发一个基本平台完成上述基本功能，任何团队拿到这个平台，直接在其上开发“核心玩法”，在规定时间点上公司领导会评审游戏的可玩性，来决定其去留。这就是一个让团队将开发重点从基础功能转移到核心玩法。
再举一个我本身的例子。
咱们正在开发的产品在市面上已经有不少了，所以尽管从敏捷开发的角度看应该尽快作一个“可工做”的产品出来，但咱们实际过程却相反。
咱们的确有“可工做”的产品，但只限于部分体现核心价值的功能点上。单单靠这些功能点，整个产品其实跑不起来；但整个产品跑得起来不，并不是咱们评价产品成功的要素；反而是少数不连贯的功能，体现了咱们产品的价值。所以在早期的开发工做中，整个产品其实不能完整地“工做起来”，可是那几个能体现核心差别的功能，却能帮咱们验证是否值得完成整个产品。
敏捷开发的帮助
敏捷开发正好能够利用优先级排序、评审会、迭代交付等实践，帮助完成上述步骤。
尤为是迭代交付。即便只有3个月的初创期，也不要认为时间比较短能够在前期做出完整的功能或设计。迭×××发可以保证在第3个月的判断点来临以前，本身与仲裁者能有屡次沟通的机会，仍能改进产品的方向；并且在真正的时间点上，必定有可交付的功能，而不是一堆作了一半的文档。
“只有一堆文档”虽然未必致使老板直接把项目砍掉，但至少会让他很为难。不如用迭代给他一些“看上去能够，但仍有待判断”的功能，以便获取更多机会。