本文是敏捷開發產品管理系列的第一篇。（序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理）
這裡所指的新產品研發，不是指自己企業的新產品，而是特指那種在行業中初創，前途不明，尚需市場檢驗的新產品。敏捷開發可以在很大程度上幫助這種產品的開發過程。
策劃新產品的第一要務是：誰會買這種產品？為什麼？
開發新產品的第一要務則是：它與以往產品的核心差異是什麼？
這個聽起來不難理解，但是做起來有困難。因為一般產品開發往往是先做「最重要的功能，最基礎的功能，最影響架構的功能」，這很容易在很久以後，才能看到產品的核心差異。
因此，雖然不可能完全脫離重要性、基礎性、架構性的制約，但仍然應該常記：驗證與市場上以往產品的核心差異是第一要務。
如何快速體現核心差異（一般是創新性的價值觀），是新產品研發的中心。
具體做法很多，下面舉乙個例子。
曾經有一家遊戲企業，希望能用「廣種薄收」的方法來做新遊戲。但是發現每個遊戲上來都要做視覺化、使用者登入、商店、npc、場景、幫派……這些基本功能，所以經常遊戲開發開始很久了，還看不出遊戲「好不好玩」這個最重要的核心。這就極大地制約了人才、資金的流動性。
後來他們決定：開發乙個基本平台完成上述基本功能，任何團隊拿到這個平台，直接在其上開發「核心玩法」，在規定時間點上公司領導會評審遊戲的可玩性，來決定其去留。這就是乙個讓團隊將開發重點從基礎功能轉移到核心玩法。
再舉乙個我自己的例子。
我們正在開發的產品在市面上已經有很多了，因此儘管從敏捷開發的角度看應該盡快做乙個「可工作」的產品出來，但我們實際過程卻相反。
我們的確有「可工作」的產品，但只限於部分體現核心價值的功能點上。單單靠這些功能點，整個產品其實跑不起來；但整個產品跑得起來不，並非我們評價產品成功的要素；反而是少數不連貫的功能，體現了我們產品的價值。因此在早期的開發工作中，整個產品其實不能完整地「工作起來」，但是那幾個能體現核心差異的功能，卻能幫我們驗證是否值得完成整個產品。
敏捷開發正好可以利用優先順序排序、評審會、迭代交付等實踐，幫助完成上述步驟。
尤其是迭代交付。即使只有3個月的初創期，也不要認為時間比較短可以在前期作出完整的功能或設計。迭代開發能夠保證在第3個月的判斷點來臨之前，自己與仲裁者能有多次溝通的機會，仍能改進產品的方向；而且在真正的時間點上，一定有可交付的功能，而不是一堆做了一半的文件。
「只有一堆文件」雖然未必導致老闆直接把專案砍掉，但至少會讓他很為難。不如用迭代給他一些「看上去可以，但仍有待判斷」的功能，以便獲取更多機會。
敏捷開發產品管理系列之五 預估會議
本文是敏捷開發產品管理系列的第五篇。序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理 粗估會議是乙個較少使用的敏捷實踐，但其作用還是很明顯的。scrum裡邊，有兩個關於需求的比較頭疼的問題。乙個是po...
敏捷開發產品管理系列之二 產品版本規劃
本文是敏捷開發產品管理系列的第二篇。序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理 本文是一篇舊文，原名為 迭代期內無變更 與敏捷開發產品版本規劃 因符合本系列內容，做相應修改後重新編排發出。支援派...
敏捷開發產品管理系列之二 產品版本規劃
本文是敏捷開發產品管理系列的第二篇。序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理 本文是一篇舊文，原名為 迭代期內無變更 與敏捷開發產品版本規劃 因符合本系列內容，做相應修改後重新編排發出。支援派...