One of the primary jobs of a Program Manager is to create functional specifications. A functional spec describes “What” a feature is going to do. A functional spec should not describe the “How”, which is described in a developer spec or and architectural spec. So at Microsoft the products are large and complex with many features. Product features are prioritized and divided up to feature teams. A feature team at a minimum consists of a Program Manager, a Developer, and a tester. The PM will write the functional spec. The Dev will write the build spec. The Tester will write the test spec. Functional spec’s purpose is to tell everyone what the feature will do. Early in a product’s design the only thing that exists to tell people about the features of a product are the functional spec. So it is important to completely tell the story about the feature. A good spec may save a feature from being cut at crunch time. So the specs contain many sections. I will point out a few of the important ones. The Summary is the first section and it is the paragraph that tells you what the feature is. This is the elevator section. Which is if you were on the elevator with the CEO this is what you would say to him to sell your feature before the elevator reaches his floor. The scenarios section tells the story of the user using the feature. This is where you describe how the user is going to use the feature. The Requirements section should enumerate the “Must Haves”, “Should Haves”, “Nice to Haves”. These Must Haves are things the feature can ship without. The Nice to Haves are features that are important to the success of the feature but are not critical to the functionality. The Nice to Haves are items that can be done if there is time. These are the first items to be cut when time is short. Functional spec writing is a import role at Microsoft and should be a important role in any project.