Writing Better Specs as a PM

Principle 1: More is not better

Start with the minimal, most important information: user story, success criteria, & design/ mock. Then, add in additional layers. Fewer people will read long specs. And even fewer will walk away with the right takeaways.

Principle 2: Quality matters

A bad user story is worse than none. Same for every other sentence: scrutinize each one. The broader team - design, eng, product leaders - lose faith in specs that have low-quality sentences in them.

Principle 3: Collaboration canvas

Release the spec early as draft to the broader XFN product team: design, analytics, legal, marketing. Get their input early and often. The spec isn't "PM hands over Requirements." It's a tool for collaboration and joint decision-making.

Principle 4: GIFs say more than words

A thousand words will not say as much as a simple mock wireframe. A spec without a mock, prototype or visual is incomplete. Even backend features should include the final use cases in code, or something similar.

Principle 5: Out of scope is as important as in scope

Great specs answer the corner questions for engineers so that they can build, marketers so they can market, and legal so they can assess the feature. The best specs help everyone identify what is out of scope, too.

Recap - Principles for great specs:

1. More ≠ better
2. Quality matters
3. Collaboration canvas
4. GIFs say more than words
5. Out of scope is as important as in scope