IE產業組分為十個項目組，每個組大概有十到五十個人，基本上負責一個產品模塊，像瀏覽，或者HTML的編輯、打印。但是有一些時間一個項目經理會負責不止一個特性，甚至有一些開發人員可能他在某些方面有專長，他也需要在不同組織之間流動，所以這種組織實際上是一個動態的。
下面我們談一下微軟產品開發過程。開發過程劃分的基本原則是，希望把大的項目分為若干個里程碑式的開發周期，并在各個周期都要考慮一些冗余，使你的開發周期變得更實際一些。通過目標描述來保證所有的人是沿著同一個方向發展。利用產品特性描述來指導開發過程。同時利用用戶的數據來決定一些特性的取舍，或者優先級的排定。加不加這個特性，不是開發人員覺得好，我就做這個東西，往往還是從用戶角度來考慮，用戶從中間有多大收益來決定。
還有更重要一點就是統一的術語。在微軟內部剛進去時也會做類似這樣的培訓，會請的各種角色做一個講座，大概需要六七個小時。其中有對很多術語、縮寫，還有對這套開發模式的介紹。從而保證所有人理解的都是統一的。這樣你才能保證無論在做事或者討論的時候，大家的理解是一樣的。
還有一點是在開發產品過程中不間斷地測試，而不是做完了到某一個階段才開始測試，因為往往那個那時候往往已經太晚了。
微軟產品開發過程分為四個階段，第一個階段是規劃階段，這個階段基本上是由產品規劃人員以及項目經理來驅動的，這個階段主要是要完成這樣一些事情：一個是目標描述�；谶@個產品目標，我們已經知道了，我們需要做哪些事，做哪些特性來達到這個目標，這樣就決定了產品提供哪些的功能。然后PM就要根據這個功能來寫出相應的規范說明。一般產品規格說明，就是傳統上說得技術文檔，基本會寫兩次，第一次寫一個簡單的，里面列出了你這個功能或者你的特性希望達到什么要求，跟我們整個產品的目標有哪些相關的，產品之間依從性，為什么要做這個特性。寫完這一頁的特性描述之后，大家會坐在一起看一看，排定一個優先級別，哪些事我們先做，哪些有可能做，或者哪些是下一版本在做。把這個事情做完了，程序經理會寫一個更詳盡的特性說明，這是指導開發、測試整個過程的技術文檔�；旧弦话愣加幸恍┠０�。
在規劃階段，當所有的特性規格說明完了以后，還要制定日程進度表。這個日程進度表往往需要由開發人員的參與�？吹搅诉@些產品規范，根據你的經驗估計做這個需要多長時間，還需要打入一些冗余，把這個做完之后，產品規劃階段就已經完成了。
產品階段完成的標志，就是目標描述，所有特性規格說明，以及日程進度表的完成。這樣就進入第二個階段，即開發階段。因為我們自己有特性描述，已經知道做什么。所以根據這些特性，會把這一階段，分為三到四個小的階段�；镜膭澐衷瓌t是重要的或者相互依從的特性開始做，剩下的一些次重要的。會在第二或三間段做。這一間段是由開發人員去推動。所有的開發人員開始寫代碼，對于每一個開發人員都有相應的測試人員，會把開發人員寫的代碼拿去測試。這個階段完成的標志是所謂的特性完成，或者叫代碼完成，也就是所有的這種特性都已經開發完畢。這時就進入了下一個階段，測試階段。測試階段主要由測試人員推動。在開發階段也有測試在進行，但在測試階段進行的主要是集成的測試，象安裝，兼容性測試，性能，或者其他方面的測試。此外通常還要發放一些“beta”版本，讓用戶去實際使用并發回反饋。這一階段會有更多的“bug”進來，但是這一階段基本上不會增加一些新的特性。這一階段結束的標志是所謂的“零缺陷”。微軟有一些來跟蹤缺陷或者叫“bug”的工具，如果從這些工具看到針對這個發布周期已經沒有任何活動的bug，這就標志著穩定化階段已經結束�，F在有一個趨勢，就是穩定化階段做得越來越長，從而更好的保證產品的質量。