You’ve all seen them, probably had to read them, and maybe you’ve even written them. Some of them are so bad, you have to wonder what was going through the author’s mind when they created them.
I’m talking about those long requirements documents that people used to write, but that get little if any respect anymore.
Don’t get me wrong. A lot of those documents are really, really bad, and the majority of the blame lies with the Product Managers who wrote them. Some reasons are below, and while self-criticism (and self-reflection) are healthy, if any of the following descriptions sound like you, seek expert advice.
The Problems
Some PMs simply don’t know how to write
Let’s admit it. It’s the first step towards addressing the problem. Not everyone can analyze and consolidate information and present it in a coherent manner. I’ve read my share of poorly written short documents, but for some people, as their documents get longer, the coherence level drops exponentially.
I once had to plow through a 67 page nightmare (written by my predecessor at that company) that had little structure, except for the 5 level deep numbering system — Section 5.2.12.7.9 anyone? — and had a seemingly endless set of requirements pages based on some generic template where about 80% of the subheads for each requirement were empty.
Who wants to read something like that? I don’t, and I’m a Product Manager. But it was foisted onto Engineering to decipher. No wonder that PM was still cursed by the developers a year after he left the company.
A long meaningless document can be better than a short meaningless document
What’s that line? If you can dazzle them with brilliance, baffle them with bullsh*t.
While some PMs don’t know how to write, there are other PMs who don’t know how to be a PM – yes there are PMs like that unfortunately. And if you don’t know what you’re doing and don’t have data to support your requirements, then what options are there?
It’s a matter of optics, albeit not a great one. Creating a long document can make it look like the PM is doing something, even if that something isn’t really what’s needed. Hey, at the very least, it might give the PM enough breathing room to get a successful job search going.
Some companies actually support this kind of behavior
It’s not always the PMs fault. In some cases, and I’ve seen one company like this, there is a culture that valued long, detailed documents. The fact that those documents were poorly written is a secondary issue.
In the one case I’ve personally seen — a startup — there was some level of dysfunction in the company — shocking for a startup, I know — and the requirements were a very loosely prioritized amalgamation of virtually every request from every customer/prospect encounter that had occurred. Did I say “dysfunctional”?
The Solutions
There are some solutions to this problem. Here are a few that I recommend.
A long document has a time and place
A big honking requirements document for a point release, is not only pointless, but brings a PM’s credibility into question. But, if your company is embarking on creating a significant new product, or is looking to make major investments in new product areas, then a detailed document that fully explains the research, rationale and requirements is totally justified.
That document is a repository of a lot of knowledge and insight that was likely gained through a lot of effort. It becomes a reference document for further definition, detail and discussion as time progresses.
Not everyone will read this document, but those who do read all (or even key parts) of it will gain that common knowledge and insight that you placed there.
Don’t accept poorly written documents (of any length)
Not everything has to be written in a large document, but a poorly written short document can be understood, and thus the poor quality ignored. But companies — and especially Product Management executives in those companies — need to be vigilant about ensuring that Product Managers have the necessary analysis and communication skills to do their jobs.
When interviewing PMs, test their writing (or rewriting) skills. If you’ve got existing staff that can’t write well, get them some training or other assistance. Have peer reviews of documents to help improve content, structure and meaning. All of these not only will improve the documents, but will also enhance the skills and credibility of the PM organization.
Provide alternative means for communicating complex information
Just as not everyone is a great writer, not everyone can absord a long document easily and understand all that it conveys. Provide your audience with other (parallel) paths to comprehension.
Yes, share the document with necessary stake holders, but also create presentations to support the content. Hold Q&A sessions to review the key points and answer questions people have. Hold one on one sessions with executives to discuss the information.
In short, help those who really need to understand the information you’ve collected in the document, without forcing them to read every page themselves.
In the end, the objective is clear communication and understanding. There are many ways to get it done, and some topics absolutely deserve the depth and detail that can only be captured in a longer document.
Saeed