03010 Pitfalls of the Paper Document Culture

We’re all familiar with the problems that come from not documenting requirements, designs, plans, and expectations. You wind up with slipped deadlines and disappointment. Most of us have learned the hard way that we’re better off writing down important agreements and plans.

In fact, so much of product management depends upon written documents to spell out needs and plans. Documents are critical to product management.

But I also see a problem with relying too much on documents such as requirements, development plans, test plans, analysis and reports to carry most or all of the burden of communicating important demands, agreements, and results across the organization. I call this the Paper Document Culture.


Software companies, because of their technical workforce, are prone to falling into the trap of the Paper Document Culture.

Having a Paper Document Culture is already a nice step up from not documenting everything. But it is far from the solution.

The problem with the Paper Document Culture comes when individuals rely on the documents they circulate to do all the necessary communicating between and across departments. And that’s a problem because written information is rarely sufficient to communicate fully and achieve consensus.

Effective communication requires lots of talking, lots of discussion, lots of back and forth, as well as written documents to confirm or summarize the discussion. For some of your teammates, you may only reach a level of clear communication once you start actually doing a task, answering questions as they come up.

These various communication methods correspond with the three ways people absorb and understand information:, namely visually (documents are good for this), verbally (speaking and hearing), and kinetically (doing).

The problem with relying on paper documents is that they don’t effect change in and of themselves. They don’t require action, and don’t lead to action in most cases. Nothing actually happens as a result of merely sending out a document to the appropriate recipients.

Take a look as the tips below to get beyond the Paper Document Culture to one where written communication is used effectively to make things happen.

Get Everyone’s Opinion

It’s really easy for one person to write a plan or report and complete it quickly with just their own input. But communication requires that everyone review, understand, and agree upon the content. To make sure that a document becomes an effective vehicle for communication, circulate it among all the people who are involved in the decision, and ask for their input.

Also, don’t expect the input to happen in writing. You will either need to hold a meeting where people contribute and discuss their input, or you’ll need to go around to each individual and talk to them while you write down what they say.

“It’s Only a Draft”

People treat the written word as an authority that they do not necessary feel free to contradict. You may wind up with a lot of passive resistance to ideas that were quickly thrown together in a development plan to get the discussion going but were treated instead as final decisions. Consequently, creating a document may actually squelch input and communication.

Make sure, when you send requirements and plans to people whose input you need, that you clearly explain that “It’s only a draft. I need your input.” This puts your teammates in the position of expert reviewers who are contributing and shaping the outcome, and communicating with you in the process.

Get Input Before Writing

Because the written word has the power to stifle communication when it’s viewed as final, avoid writing up a quick document to get a conversation going. It’s better to start the communication with discussions, only after which you can begin to write.

Use Writing to Generate Discussions

Use the process of writing to generate the necessary discussion. Reading a document will constitute only a small part of the necessary communication. Most of the communication will happen by discussions around the topics the document covers.

Discussions do not have to be formal meetings. Writing the document provides an opportunity to send out emails to different individuals for different points covered. Just expect that much of the effort to write a document will be conversation, rather than mere time spent sitting alone and writing.

Collect Signatures

Don’t just send out a plan for people to read. Have a place for approval signatures of all the required functional leaders or managers.

Suddenly the head of Engineering or Sales will pay closer attention, making corrections and raising objections, if they see they have to sign something.

That’s even more true if someone’s boss also signs the document. Major documents such as requirements, development plans, and business plans should have the President’s or CEO’s signature.

The Document is The Recap

Think of the document in this way: communication occurs during the writing, and the finished document is only the recap. Make sure that you reach agreement before or while writing, before the final version. Don’t rely on the mere circulation of a document to sell an opinion, idea or decision.

Use Final Documents For Reference

Since you want your requirements, plans, and analysis to be taken seriously, whenever there is a question that has been covered in a document, consult the document. Make people adhere to the discipline of referring to and reading the document before asking questions.

This makes it clear that the document wasn’t written and then put on a shelf to be ignored. When people realize that a document will later be used to guide their work, they will give it the attention it deserves.

Do Something

Don’t let written requirements and plans just stand there. Make sure that everyone follows the steps and carries out the tasks that are written there. If documents are circulated half-heartedly but never followed up on, nobody sees them as legitimate, or meriting their attention.

Conversely, if nobody ever follows through on certain documents, you can drop the pretense involved in creating them in the first place until you have buy-in from the people involved that they will do what’s written, and let you know – in writing – if there’s a significant change in plans.

— Jacques Murphy, Product Management Challenges


Comments are closed.