越短越好，盡量說明"產品不做什么"(而不是"產品要做什么"！)。
運用想象性描述，程序經理開始編寫功能說明文件，該文件解釋產品的特性是什么以及這些特性如何與其他特性及產品發生關系。初它只是一個概要性的說明文件，隨著項目的進展，程序經理會隨時向其中添加更多的細節，終的說明文件將變得象用戶手冊一樣。完整的說明不只起著對產品新功能的描述作用，而且它還是在產品投產與發貨之前進行測試與評估的主要依據。
想象性描述有助于決定刪除哪些特性。
微軟內的各個開發組采用想象性描述幫助細化產品版本的規定主題，然后以此主題來決定是否需要增加產品各個可能的特性。通常不要輕易改變所確定的主題，否則可能造成產品開發上的混亂。
編寫說明文件
說明文件在產品小組的所有成員之間，產品小組之間以及產品小組與管理部門之間起著傳遞產品的設想與要求的作用。在說明文件中必須清楚地描述產品特性（描述每個特性如何工作，外觀如何以及從用戶的角度出發如何與用戶交互。如果特性有一個界面，還應包括一張示意圖，以顯示出界面的效果），并賦于其相應的優先級。程序經理據此建立起項目的開發進度表。此外在其中還應包括以下各項內容：用一句話表示的項目開發目的，關于產品是什么與不是什么的清單，對顧客的定義，對競爭產品的定義，產品對系統的要求（包括操作系統版本、小內存要求、硬盤空間、處理器速度以及顯示器分辯率），對第三方（如打印機驅動程序、組件）的任何依賴性。程序經理負責協調并"寫下"說明
程序經理（Program Manager）應考慮以下問題：
這項特性的要點是什么？
用戶如何使用該特性？
這項特性有意義嗎？
該產品中或微軟的其他產品中有類似的特性嗎？
有哪些問題被遺漏了？
組內的交流令人滿意嗎？
終程序經理通過與組內開發人員的共同討論決定有關特性的內容，并將其寫下來。
構造原型
構造原型是程序經理具體說明一件新產品或一個新版本的好方法，這從許多方面來說都使開發前測試成為可能，尤其在可用性方面，并且有助于對與用戶交互情況作出好的理解，它也能使產品說明更緊湊。
微軟的開發人員通常采用VB構造用戶界面原型，但是對于構造計算機屏幕模型之類的工作，畫筆（Paint brush）也是一個很好用的工具。死板的說明變成有生命的文件，說明不應過于詳細以至限制了發明創造。在項目開發過程中，說明文件的早期版本會有相當大的增加與改變。由于說明的變動可能會導致相應開發工作的極大變動，所以微軟通常是將精力首先集中于那些沒有什么用戶界面的特性上，因為在完成開發前不必去了解用戶對它們有何反應，也是說這些特性不大可能改變。然后再面對其它特性。但是當產品開發到一定程序后，例如40%之后，程序經理必須嚴格控制對特性的修改（主要是指增加新的特性），否則不光會造成開發延遲，而且會壓縮可用的測試時間。
原則三：根據用戶行為和有關用戶的資料確定產品特牲及其優先順序
對于一個開發項目而言，如何確定終產品中應包含什么特性通常是比較困難的一件事。為此微軟采用了一個稱之為“基于行為制定計劃”的方式來進行特性選擇與優先級安排。
基于行為制定計劃法從對用戶行為，諸如寫信或做預算，做系統研究開始。然后，根據某一特性在支持重要的或者是經常的用戶行為上的程序對其進行評價。這樣做的優點是對特性取舍更具理性：討論對顧客想要做什么加以更好的安排，對某個給定特性是否方便了特定任務的更集中的辯論，可讀性更強的說明，以及在市場營銷、用戶教育和產品開發中更好地同步。
特性選擇和優先級安排中的基于行為制定計劃
基于行為制定計劃法中的關鍵點在于按用戶行為、產品特性以及行為和特性之間的內部聯系來分析產品。程序經理和產品計劃者把產品試圖支持的用戶任務或方案分成大約20個“行為”，然后他們努力把行為（以及任何子行為）映射入微軟的現行特性和競爭對手產品的特性中去。他們也把行為映射到不同的顧客形象或不同的市場部分中去。
當說明產品的新版本時，基于行為制定計劃法幫助程序經理和開發員集中他們的精力與創造力。象Excel之類的項目，爭取在每個新版本中加入的主要行為不超過四個。絕大多數特性直接映射入這些行為之中。該做法使項目可以按特性對用戶的價值來進行分級。通過分級，促使程序經理和開發人員都行動起來，使他們的特性支持盡可能多的行為。這種良性競爭對于用戶有益，同時也利于提高生產率。
為顧客行為而非產品特性準備資料
基于行為制定計劃進度，項目在計劃階段首先集中于行為，其次才是特性。程序經理和市場營銷人員并不去思考和排除他們喜愛的特性，再圍繞它們搞出想象性描述的草案。他們真正做的是列出一份顧客都做些什么的清單，然后把想象性描述集中于支持那些行為的特性上。
以行為為中心對產品進行全面考慮
由于基于行為制定計劃法是從整個產品的觀點著眼，因此有助于在不同職能上工作的項目成員理解產品做什么，以及其他產品的相應特性如何可能支持那些需要或不需要其他應用軟件產品的行為。
做市場營銷研究以支持基于行為制定計劃法
為支持基于行為制定計劃法，從市場營銷組來的產品經理與程序經理、開發人員一起開展一些聯合的研究，如指導對用戶的研究工作。然而，一般來說是產品經理做大多數的研究，并可使其更明確地影響微軟產品的演進。
原則四：建立模塊化的和水平式的設計結構，并使項目結構反映產品結構的特點
微軟產品設計中的一個關鍵概念是產品的基礎結構（Infrastructure），尤其是生命周期短的應用軟件，應隨項目的進展變得更加單一（而不是錯綜復雜）。當開發組構造產品的第一版時，他們更多地使用分級式結構，好為產品設計規定出一個初的架構。隨著時間推移，他們向單一的結構邁進，以使項目能集中于特性開發。微軟越來越強調不同產品間的特性共享。共享有助于使不同產品的“性能與感覺”（Look and Feel）都統一協調起來；它也方便了需要不只一個應用軟件的用戶，減少了代碼的重復書寫，縮小了單獨一個應用軟件的規模。
微軟用特性小組組織產品開發，這種方法使得每個人都容易明白小組是如何與整個產品相關聯的。項目從規定概要說明開始。概要說明的形式是一份已確定了優先級安排的內容清單，涉及產品下一版本將要開發的相對獨立的特性，以便由分開的特性小組加以開發。
程序經理和開發員把項目分成特性子集，再將之分配給每個特性小組，讓他們在3到4個主要的內部項目里程碑中進行生產。這種產品組織與開發方法使微軟能靠簡單地增加開發員和創建一個大的小組來漸進地增加產品的功能。
把特性(與函數)作為開發單位
微軟軟件產品的特性是用戶終可見的相對獨立的功能單位，如建筑材料一般，對應用軟件產品更是如此。系統軟件產品，如NT或者95的特性，對終用戶通常不直接可見。微軟和其他公司有時簡單地稱這些不直接可見的特性為“函數”。
程序經理承擔開發一組特性或函數，實現從說明經測試、文檔化直到后完成的過程。他們必須與開發員合作，后者負責估計進度表與完善每個特性。開發員還要在一臺聯網開發計算機上存儲一到幾個文件，用以保存特性的程序源代碼。大多數特性的開發與改進只要一名開發員，而有的大型特性則要一個小的小組。
產品結構是決定其長期結構完整性的基石
產品結構是產品內部的基干，它規定了重要的結構構件以及這些構件如何組裝到一起。產品結構及用于組裝結構的構件，提供了實現產品特性（即做詳細設計與編碼）的支柱。產品的結構對終用戶而言，通常并非直接可見。只有結構要實現的特性是可見的。產品結構也是決定產品長期結構完整性的基石。產品功能的任何改變都不應造成潛在的產品結構散架。
產品的層次結構
對于產品，也可以采用層次結構的方法加以分析。通常定義良好的層次結構有助于對產品特性進行靈活的增加、刪除與改進。此外良好的層次結構有助于產品在不同平臺上的移植。（例如Excel總共定義了五層，其中只有底層的操作系統層是與平臺相關的，其它各層均是通過調用其下層所提供的API接口加以實現的，所以其移植極其方便。而在Windows 95中通過“虛擬機”的概念實現了對16位、32位以及DOS程序的支持。）
