第六十篇：有了最小可行性產品之後的產品開發週期
原文連結：Product Development Cycle Fundamentals
作者在執行產品開發時遇到許多困難，包含開發週期太長，導致最後大家熱情被消耗，或是產品規格未被清楚定義、太希望建造完整的產品而非最小可行性產品！
作者分享他克服產品開發困難的心得，下面要點助於你快速迭代，測量，測試和改進你的產品。
這跟開發最小可行性產品的過程不完全相同，作者假設閱讀者已經開發了最小可行性產品，並正在嘗試下一步該怎麼繼續，正是這個階段讓新創團隊花費許多時間。
1.定義開發週期長度
關鍵是要規劃週期，讓團隊保持興奮，並仍覺得他們可以集思廣益。
2. 確定你的目標並確定產品負責人
我們只進行一次產品會議，在開發週期的第一天，有時這會議將持續五個小時。每次產品會議都圍繞著三個目標中的一個：
(1)增加內容架構
(2)增加新用戶
(3)增加保留率
無論我們選擇哪個目標，都將成為會議的討論重點。
3. 組織有廣泛包容力的腦力激盪
當我們進行腦力激盪時，將想法寫在白板上並分類成：新功能/功能迭代、維護和A / B測試。每個人都應該做出貢獻。每個腦力激盪的想法將由工程師在會議中評級為輕鬆（可以在一天完成），中等（一個人半天）和難（較長的開發週期）。通常，這種評分將由具有該特定領域最豐富經驗的工程師逐項完成。
4. 建立共識
我們將從艱難的想法開始，比較容易形成共識，因為我們一次只能做一個，然後中等難度的想法，最後是容易的想法。
5. 清晰的規範和明確的成功衡量標準
我們將詳細列出列表中的每個項目，並將每個項目分配給團隊成員（或多個團隊成員）。我們還會指定我們需要跟踪的統計數據，以衡量該功能的效果。
6. 開中週期中的工作方式
我的任務就是要把關於商業和營運的事情完成，然後我就可以去尋找有趣的產品洞見或是潛在的軟體缺失，最後，我還執行了一個月的使用者測試。我的團隊，包含工程師和設計師，工作都非常沉著和快速，知道專案的規格和其規模。在開發週期的最後三天，我們會停止建造和執行測試，我們有一個測試表，包含所有基本功能的測試，每一輪我們增加新功能的測試，並測試所有項目兩次，每個團隊的成員都執行測試，並且我們也會比較誰測試的比較快比較多。能讓煩人的測試被大家所分擔是重要的。
這是一個很清楚明瞭的產品優化的進程，這個進程如果不只是PM理解而是整個開發團隊都理解的話才能事半功倍喔。
