產品設計方式
第一，產品經理與設計師合作設計產品的高保真原型，這個原型只具備實現商業目標的最基本功能要求，以及良好的用戶體驗和吸引力。只設計基本功能的產品可以把複雜度降到最低，把開發時間減到最少，因此是非常重要的。
第二，邀請一位開發人員（比如架構師或主程序員）參與設計原型。請他檢查原型，幫助產品經理和設計師估算各種功能的直接成本和間接成本，指出設計上的誤區，並分析、評估尚不確定是否可行的功能。等產品原型確定時，開發人員詳細估算出所有產品功能的時間成本。如此一來，各項功能已經明瞭，而且對對方都是透明的，開發團隊心裏也就有底了。
第三，請真實用戶驗證（測試）產品原型，這一點至關重要。在產品團隊全力開發產品前，產品經理和設計師必須確信產品是用戶需要的，然而僅僅相信還不夠，必須通過用戶測試來驗證。這好比不能僅僅因爲開發人員相信代碼沒問題，就允許發佈代碼一樣，必須對代碼展開測試。
一旦基本產品確定，通過了目標用戶的測試，就不可能削減任何功能。如果還能削減，那說明我們定義的不是基本產品。
產品軟件開發
敏捷方法同樣適用於產品軟件的開發，但應用時應該做出相應的調整：即如何在開發過程加入用戶體驗設計，如何管理產品的發佈和部署等。敏捷方法唯一不適合產品軟件開發的地方是在架構設計方面。
敏捷方法鼓勵開發人員不要拘泥與傳統的開發流程，要相信簡單重構和快速設計架構的優勢。這對多數定製軟件來說是可行的。但產品團隊照搬定製軟件的敏捷模式，就會遇到問題。至今多數介紹敏捷方法的圖書、文章、培訓課程依然沒有深入理解產品經理和用戶體驗設計師的作用，因爲它們針對的讀者還是定製軟件團隊。
要想成功轉型成爲敏捷開發團隊，選一位合格的敏捷教練相當重要，他必須理解產品軟件與定製軟件的差別，瞭解產品軟件的特殊需求，而這正是多數人不明白的。
產品軟件開發合理運用敏捷方法的十大祕訣
1、產品經理即是產品負責人，他代表了客戶的需求。
2、使用敏捷方法絕不等於省略產品規劃。產品經理仍然要明白產品的方向和目標，設定衡量產品成功與否的標準。在敏捷環境裏，規劃週期應該適度縮短，反覆迭代，採用輕量級的機會評估方法代替冗長的市場需求文檔。
3、產品經理和設計師的工作進度應該比開發團隊領先一兩個迭代週期，確保團隊有時間攻克難題。
4、儘量把產品設計工作拆分成獨立的部分，分而治之，但也不能拆得太細——好比建築不能一次只設計一個房間。目標是設計出符合基本要求的產品。值得注意的是，在敏捷環境裏，設計師必須加快工作速度，採用迅速製作原型的方法更能適應敏捷環境。
5、產品經理的主要任務是定義有價值、可用的產品原型和用戶故事，作爲開發的基礎。請用戶測試原型，根據反饋意見反覆修改原型設計，確保交給開發團隊的是有價值的結果，避免任何浪費，哪怕只是一個迭代週期。
6、讓開發人員自主劃分迭代週期。有的產品功能可以在一個迭代週期完成，有的卻需要好幾次迭代才能完成。好的原型可以提高工作量和開發時間的精度。開發團隊必須考慮產品的質量、性能、擴展性，讓他們自行決定如何劃分迭代週期。
7、產品經理和交互設計師必須出席每天的晨會。晨會是一天溝通過程的開始，而不是結束。
8、除非達到了產品經理的要求，否則不要輕易發佈新版本。產品經理必須確保交給用戶的產品能正常運行，過度頻繁更新版本會讓用戶感到不安。
9、在每次迭代完成後，產品經理應該向團隊展示產品現狀，以及下次迭代的產品原型，讓大家看到工作成果，同時加深大家對產品的理解，增強團隊對這種開發方式的信心。
10、在團隊內展開敏捷培訓，聘請諮詢顧問協助你們完成向敏捷團隊轉型的目標。只有每位團隊成員都真正理解敏捷方法，大家才能把工作重心放在執行上，否則敏捷方法就只能停留在教條式的理論層面。
機會不斷
產品軟件開發的機會會越來越多。爲什麼如此堅定，有三點原因：
首先，只要市場上還有蹩腳的產品，就有機會。（憤怒的用戶決定着產品未來的發展方向——《跨越鴻溝》）
其次，技術不斷髮展。今天難以置信的創意，明天也許就能實現。
最後，現有的應用程序爲將來的發展打下了基礎，這是行業規律。比如最初，瀏覽器只是一個查看網頁的應用程序。我們看到，以因特網爲基礎，有了應用程序、電子商務的蓬勃發展，出現了許多新應用的平臺。