Those of us lucky enough to have a program manager know that while PMs are a big help they certainly aren't a magic bullet. Some PMs, in fact, are more hindrance than help. When a spec never gets past draft status (or, even worse, is in a perpetual state of One Page-ness), the spec is nothing more than a vague thought that's only useful for... well, nothing, really.
If you're one of the unlucky pm-less masses, take heart: you can still get all the advantages of a spec. You just have to write it yourself.
Specifications are a must when you're coordinating work between a largish product team or with external teams, but they're useful for smaller teams as well -- even one-person shops. I write games and utilities (mostly for my own amusement, but a few are posted at http://www.humbugreality.com) in the spare time I don't have. I've found that writing a spec before I start designing and coding helps me crystallize exactly what it is I'm trying to do.
I don't think a "typical" Microsoft spec exists, but most specs contain most of the following sections in some form. If a particular section does not apply it is not deleted; instead, text is added explaining why it is not relevant.
[The following is culled from multiple specs from multiple teams across Microsoft. Parts are verbatim from various spec templates; other parts are paraphrased or summarized. I likely missed at least one section that is vitally important to someone. Caveat emptor, caveat spector, yadda yadda yadda.]
First is the Page One section, which describes why the feature is being built. This is the first part of the spec to be filled out. The first round of cuts is often done based on Page One specs. This includes:
Next is the Detailed Design section, which goes into great detail about every last corner of the feature.
Overwhelmed? This is a lot of text to write, but taking the time to do so -- and review it, and revise it, and review the revisions, and... -- makes an incredible difference in the quality of a feature. Some teams organize the specification exactly like this, with full details for the feature in each section. Other teams organize the spec around the areas and subareas of the feature, detailing each of these items just for that area or subarea. Experiment to determine which works best for you.
*** Comments, questions, feedback? Or just want a job on a team that mostly does it right? Contact me at michhu at microsoft dot com. I need a tester, and my team needs developers, program managers, and a product manager. Great coding skills required for all positions.