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.