The devil is in the (requirement) details

In this post, Michael explains the various acronyms used for the artifacts necessary to develop tech products. It's a really helpful summary of the most common terms. Many of the terms refer to the same concepts but by different names. BRD, MRD, and PRD offer various details versions of requirements; FSD and PSD refer to levels of specifications. And as Michael points out, the implementation of these documents differs from organization to organization.

In my experience, companies with too many types of documents are attempting to correct the emptiness of one document type by expansion into another. "The MRDs we're getting are not detailed enough so let's introduce a PRD." Product managers who write poor market requirements are often supplemented with Requirements Analysts who write good requirements. So an MRD is actually a poorly written PRD. A poorly written FSD is supplemented with a well-written PSD.

Maybe we would have fewer roles and fewer artifacts if each were well defined and appropriate performed. You get overlap and redundancy if you have too many types of documents. Read On Reqs and Specs for more on this point.

Perhaps this expanded set of documents isn't that they're poorly written but that the writers have smashed together the artifacts from a dozen different methods. Meetings today often take on a tone of folklore as each person describes a process and set of documents from the old days, from an old company, from an old (or new) book. If you're writing SRS documents, someone has read Weigers; if you're writing stories, someone has read Beck.

A requirement is a statement of the problem to be addressed; a specification fully describes it solution. In the end, I fear that many companies are reacting to poor execution in one group by introducing rigor in a downstream document written by another group. Alas, no amount of documentation can overcome incompetence or malevolence.

Be clear on the objectives and content of each document in the process and then hold the writers to that standard.

Steve Johnson

Steve Johnson

Steve Johnson was a founding instructor at Pragmatic Institute, a role he held for more than 15 years before he left to start Under10 Playbook. In his return to Pragmatic Institute, Steve supports the complete learning path for product teams, ensuring they are fully armed for success. 

Over the course of his career, Steve has helped thousands of companies and tens of thousands of product professionals implement product management processes. He has worked in the high-tech arena since 1981, rising through the ranks from product manager to chief marketing officer. Steve has experience in technical, sales and marketing management positions at companies that specialize in both hardware and software. In addition, he is an author, speaker and advisor on product strategy and product management.


(0) Comments

Looking for the latest in product and data science? Get our articles, webinars and podcasts.