这里所指的新产品研发，不是指本人企业的新产品，而是特指那种外行业中初创，前途不明，尚需市场检验的新产品。敏捷开发可以在很大程度上协助这种产品的开发过程。

新产品的第一要务

策划新产品的第一要务是：谁会买这种产品？为什么？

开发新产品的第一要务则是：它与以往产品的核心差异是什么？

这个听起来不难理解，但是做起来有困难。由于普通产品开发往往是先做“最重要的功用，最基础的功用，最影响架构的功用”，这很容易在很久当前，才能看到产品的核心差异。

因此，虽然不可能完全脱离重要性、基础性、架构性的制约，但仍然应该常记：验证与市场上以往产品的核心差异是第一要务。

新产品研发

如何快速体现核心差异（普通是创新性的价值观），是新产品研发的中心。

具体做法很多，下面举一个例子。

曾经有一家游戏企业，希望能用“广种薄收”的方法来做新游戏。但是发现每个游戏上来都要做可视化、用户登录、商店、NPC、场景、帮派……这些基本功用，所以经常游戏开发开始很久了，还看不出游戏“好不好玩”这个最重要的核心。这就极大地制约了人才、资金的流动性。

后来他们决定：开发一个基本平台完成上述基本功用，任何团队拿到这个平台，直接在其上开发“核心玩法”，在规定时间点上公司领导会评审游戏的可玩性，来决定其去留。这就是一个让团队将开发重点从基础功用转移到核心玩法。

再举一个我本人的例子。

我们正在开发的产品在市面上曾经有很多了，因此虽然从敏捷开发的角度看应该尽快做一个“可任务”的产品出来，但我们实际过程却相反。

我们的确有“可任务”的产品，但只限于部分体现核心价值的功用点上。单单靠这些功用点，整个产品其实跑不起来；但整个产品跑得起来不，并非我们评价产品成功的要素；反而是少数不连贯的功用，体现了我们产品的价值。因此在晚期的开发任务中，整个产品其实不能完整地“任务起来”，但是那几个能体现核心差异的功用，却能帮我们验证能否值得完成整个产品。

敏捷开发的协助

敏捷开发正好可以利用优先级排序、评审会、迭代交付等实践，协助完成上述步骤。

尤其是迭代交付。即便只要3个月的初创期，也不要认为时间比较短可以在前期作出完整的功用或设计。迭代开发能够保证在第3个月的判断点来临之前，本人与仲裁者能有多次沟通的机会，仍能改进产品的方向；而且在真正的时间点上，一定有可交付的功用，而不是一堆做了一半的文档。

“只要一堆文档”虽然未必导致老板直接把项目砍掉，但至少会让他很为难。不如用迭代给他一些“看上去可以，但仍有待判断”的功用，以便获取更多机会。