Product managers are always asked to write everything down. Some documents are read (e.g., requirements, specifications, whitepapers, etc.), most are not (e.g., demo scripts, strategy documents, processes). Certain large organizations seem to thrive on documentation. One’s productivity equates to the number of documents created. The more you create, the more productive you appear and the happier your boss is. And, consequently, the less is ultimately read.
As a result, it’s fairly difficult to discern what should be read, skimmed or ignored. Granted, people learn through different mediums. So, a combination of communication techniques is always required. But, often writing and official document is the most laborious. Even when you know a sales person will only listen to you, often you’re asked to still write it down for them to ignore at some later date. And, only after the urging of their management, you write it down.
I personally have no problem with writing it down. I like to write. I just hate to write when my audience won’t read it. So, when writing an internal document or draft, I will often add reader tests throughout. These are often incoherent statements (e.g., ever seen a blue duck?) or calls to action (e.g., email me if you actually want me to publish this document). These act as triggers to see if people have actually read the document. Typically, my inclination is correct and people haven’t and won’t read the document. So, if you ever say you’ve read something I wrote, make sure you have and have some feedback (if I’m asking for it).
And, likely, I’ll be able to tell if you haven’t – you’ll have no clue about blue ducks or orange kangroos!