當一個產品決定通過驗證要正式投入開發時，就應該要先進行一個長期的規劃。講到這裡，或許就會有人提出質疑，這不就和瀑布流的起手式一樣了嗎？似是而非，與瀑布流不同的，這邊的長期規劃不是一個嚴謹、難以容錯、一鏡到底的規劃方式，而是透過排序、只固定某些變數、指引方向卻不指點執行細節的一種長期規劃。

根據回饋的結果，產品負責人要將想開發的功能建立一個粗略的待辦清單，每一個項目只提出是為了什麼樣的需求而去制定想要這個功能的原因，卻不交代應該要怎麼做。然後將這些項目進行想要開發的優先順序去排序。

接著團隊就可以開始討論版本規劃，也就是第一個版本的產品要包含哪些功能。沒錯，我們不是要進行一個要求全部做完才釋出的產品規劃，而是根據排序以及認為什麼樣的功能先投入市場有辦法搶佔商機以及暸解市場的回饋，將待辦清單分成好幾個階段釋出的切割，每一個階段就是一個產品主要版本。每個版本包含的功能只是一個未來規劃的方向，不是一個定律，這些版本規劃會隨著每個版本的釋出所得到的回饋去修正。每個版本的清單都可以劃分出兩個部分，一個是該版本釋出至少必須要有的功能清單，以及若有會更好，但是若是時程趕不及可以犧牲的功能清單。

再來團隊就是要來決定在開發流程上，應該要固定哪些要素。是固定時間，定期釋出一個潛在可交付的成果，交由產品負責人決策是否對外發布？還是固定功能清單，透過持續的開發，逐漸將這些清單上的必要項目完成？不管要固定什麼要素，都會有預算壓力去限制我們長期可用的時間，這時候要怎麼做取捨也是個重要議題。最忌諱的是將所有變數都固定，要求團隊在固定預算且固定的時程釋出固定範疇的功能清單，這時候開發出來的產品通常會是災難。

在這些規劃都塵埃落定時，團隊就可以開始討論開發的流程，以及過程中需要什麼活動去協助溝通、團隊是否還缺少怎樣的專業人員等等。比如說團隊決定每兩週交付一個可以動的產品，或許就可以考慮採用 Scrum、或是團隊若想要透過簡單流程，去持續穩定的開發，可以單純採用看板。也可以考慮是否在開發過程中是否要每天舉行簡短的日會、有沒有想要在固定週期舉辦一個回顧活動讓團隊得以自省等等。若是團隊在敏捷相關的領域還不甚熟悉，也可以盡量一切從簡，並且透過這個產品的開發過程中，逐漸導入敏捷相關文化，去建立對應的政策。

而等規劃、團隊都準備完成後，產品就可以開始開發了。