In Defence of the Big Freaking Requirements Document
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
Related posts:
- Tom Grant Kicks Some SaaS
- What Origami can teach us about Product Requirements
- Your CV is a sales document, not a feature sheet
- Open Question: How and When do you define usability requirements?
- Questions for Product Managers
In defence of the big freaking requirements document – http://wp.me/pXBON-1LV #prodmgmt #prodmktg #requirements
#Requirements #Documentation http://tinyurl.com/36n4l9f #businessanalysis #specification #baot
RT @saeedwkhan: In defence of the big freaking requirements document – http://wp.me/pXBON-1LV #prodmgmt #prodmktg #requirements
If they are really bad as some of the ones that I inherited at my last company, then they can be used to level out uneven desks.
Good post. I once worked with a Product Manager that routinely wrote PRD’s that were well over 100 pages – and just for point releases.
There were pages and pages of “cut and paste” charts and graphs from Industry Analysts, that added little to the value of the PRD. A simple footnote and reference to the external doc would have accomplished the same point and made the document a lot easier to digest for everyone.
I think he did it to show how Product Management uses market data to validate the requirements. But all it did was make everyone think he was a pompass windbag and confused the heck out of the Development teams.
Thanks for the comment. I’ve seen this as well. Did Product Management have a credibility issue at your company that caused him to do this?
No credibility issue that I was aware of. I think he just wanted everyone to think he was much smarter than everyone else at the company and backed it up with useless facts, charts and other figures.
An additional problem/solution for your list:
CYA
How many times have PMs been thwacked with the “It wasn’t in your requirements document” as an excuse for Engineering to deliver a completely inane implementation of the requirement? Thus causing the PM to get more and more specific in the amount of documented detail.
Solution:
Collaboration (dare I say it: Agile!).
-Linda
Linda
Yes, this is another reason and I’ve seen this one as well. The problem is that the Engineering teams that use this as an excuse don’t typically care about the requirements as much as they want the freedom to build what they want or how they want.
But if the PM just throws the requirements over the wall and never talks to the engineers that’s a big problem as well.
Agile *may^ help, but my experience has been that dysfunctional teams remain dysfunctional after going agile because the issue is not process, it’s culture.
Agile may help expose the dysfunction to Sr. Management more clearly, though to be honest, if everyone knows about the dysfunction except for Sr. Mgmt, then the company has a much bigger problem to address.
RT @saeedwkhan In defence of the big freaking #requirements document – http://wp.me/pXBON-1LV #prodmgmt #prodmktg
RT @saeedwkhan: In defence of the big freaking requirements document – http://wp.me/pXBON-1LV #prodmgmt #prodmktg #requirements
Well written. According to my experience is One reason that the PM is either not trained about the purpose of this document (and does not focus). Or, the developers have wrong expectations (require a spec but not requirements). Solution:define the scope of these documents for your company
Andreas
Good point. Whether it is lack of training or lack of definition, the result is not good. Someone needs to take charge and change the situation to bring some order back into the process.
RT @sjohnson717: RT @saeedwkhan: In defence of the big freaking requirements document – http://wp.me/pXBON-1LV #prodmgmt #prodmktg #requ …
In Defence of the Big Freaking Requirements Document http://t.co/TcqsZTh via @onpm
Added comment RT @saeedwkhan: In defence of the big freaking requirements document http://wp.me/pXBON-1LV #prodmgmt #prodmktg #requirements
Thanks for sharing this interesting post,
I’m not a fan of documents being long for length’s sake. It’s like attitudes that people should be at the office for a fixed number of hours per day.
Both of these metrics have no correlation whatsoever with success. There’s plenty of long documents that are nothing more than waffle and rubbish, just as there are plenty of people that come in early, stay late… and do nothing all day.
What’s important is that the quality is good. You could have a really well written short document, a good presentation and a nice ‘elevator pitch’ do a much better job than a big detailed requirement. I think it’s critical to make sure whatever content you’re writing is written with the audience in mind.
Paul
Paul,
Thanks for the comment. I totally agree — creating long documents without a valid reason is pointless and that quality is what is very important. As I said in the post:
“A long document has a time and a place, companies should not accept poorly written documents of any length and for longer complex documents, provide alternatives to help communicate the information.”
There seems to be a general trend to making things shorter, for shortness’ sake.
e.g. Twitter. But more in context, WRT requirements, people try turning EVERYTHING into User Stories and PPT documents.
Those too have a time and place, but it’s very difficult to convey more complex ideas and functional inter-relationships when everything is broken into small separate chunks. It’s like looking at a picture, but with only a small chunk visible at a time. The observer has to do a lot of work to put all the pieces together, and there is a lot of room for misinterpretation.
Add all that onto poor writing and/or poor product management skills and a much bigger problem arises.
A Good Read – In Defence of the Big Freaking Requirements Document – http://t.co/lWLRcQe #pmot
In Defence of the Big Freaking Requirements Document http://t.co/iVNqS9O via @onpm
Even if there r badly written PRDs, doesn't mean PRDs r bad – In Defence of Big Freaking Requirements Document http://t.co/LJvloDE via @onpm
RT @samx18: A Good Read – In Defence of the Big Freaking Requirements Document – http://t.co/lWLRcQe #pmot
RT @pmDetroit: RT @samx18: A Good Read – In Defence of the Big Freaking Requirements Doc – http://t.co/lWLRcQe <- love it!! Resonates 2day
The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @theprodmgr: RT @saeedwkhan: In defence of the big freaking requirements document http://wp.me/pXBON-1LV #prodmgmt
RT @afox98: RT @theprodmgr: RT @saeedwkhan: In defence of the big freaking requirements document http://wp.me/pXBON-1LV #prodmgmt
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @kfriedson The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @deniseching: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
In defence of the Big Freaking Requirements Document http://bit.ly/bGvn4t via @bskelton – for greenfield projects, a BFRD may be justified.
I have been involved with some pretty complex products… I think the last PRD I wrote was pretty concise, each requirement was called out, with a requirement number, and a quick rationalization. It totalled up to 150 pages. But that document once done, formed a baseline of so many other engineering-originated documents like functional specs, which strangely enough created better test plans, which strangely enough created better Q/A use cases, which strangely enough created better product documentation, which strangely enough created fewer support problems and happier customers.
I agree with the observation nobody probably read all 150 pages of it. However, that has more to do with the nature of the work than the value of the document. *Somebody* derived value from all 150 pages of it, it’s just that it happened to be 30-40 engineers who had responsibility for separate parts. Even the architects didn’t read the whole thing, but *somebody* in aggregate did read the entire thing, I can assure you.
Having done the start-up thing without the luxury of resources to do the big greenfield document, I can tell you, the value chain worked in the opposite direction. Quality and customer satisfaction suffered demonstrably.
However, if the nature of your product allows agile (which technically means you don’t have all the requirements by definition anyways until you are well along) then the big document is a foolish waste of time.
Generalities don’t work in this subject….
Amen to that!!! It's about the quality and clarity of the content not the length in your PRDs. http://bit.ly/bdKv7F
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t
RT @kfriedson: The Big Freaking Requirements Document: Why it should die http://bit.ly/cz5Yru and why it shouldnt http://bit.ly/bGvn4t