Product Managers are all familiar with writing MRDs (Market Requirements documents) and PRDs (Product requirements documents). Are these enough to communicate to engineering all the customer requirements that would result in engineering building a product that is usable by customers to solve their problems? Unfortunately in my experience, a PRD is not enough.
PRDs are very good high level documents that communicates to all stakeholders what one needs to build – new products, key elements of a new product release etc. But when it comes down to detailed customer expectations of the individual features called out in the PRD, there is nothing in the PRD that helps out the engineering teams understand the customer requirements and expectations. This is not a fault of the PRD but calls out for the existence of a supporting document that builds upon what is stated in the PRD. Such a document is well known as the functional spec.
But after talking to my friends and acquaintances from different companies, I am surprised to find that many companies do not invest the time and energy in creating the functional specs upfront. The net result many times, is a product that does not meet the customer needs/expectations/requirements and one that sometimes is unusable and hence not sellable. Lack of a functional spec essentially makes a product manager hope and pray that engineering has exactly understood what needs to be build from one sentence/one paragraph describing the feature in the PRD. To have this happen, you either need very smart developers who can put themselves in the user’s shoes (and there are very few of these) or you have to get outright lucky (I think winning a lottery has better odds). This becomes even more important if you have globally distributed development teams who may not have the luxury to talk to your customers.
So what exactly is a functional spec and what does it need to contain. I was asked this the other day and I put the following FAQ together.
1) What is a functional spec?
Functional specification is a document that lists the requirements for a single item (project) listed in the PRD. It lists all the minimum requirements and the interaction requirements for any new feature including all graphical user interface elements being introduced by the new feature.
The functional spec is typically written by someone who intimately knows the user needs and user expectations. In many cases, this happens to be the Product Manager since he is expected to best know the user’s needs.
2) Why do need a functional spec when we already have a PRD and engineering design documents?
Functional spec is more detailed than a PRD. For example, a PRD may call out for a search utility or for a migration tool. There are multiple ways to solve this problem. A functional spec on the other hand would detail out all the solution requirements and also how the user interface should be presented to the user and how the user would interact with the UI.
Engineering design documents are documents written to design the internal architecture of the system such that the minimum requirements and the user interface called out in the functional spec can be implemented.
3) When is a functional spec written?
Functional spec is written before engineering embarks on the implementation of a new feature. The functional spec is reviewed, iterated and agreed upon before the start of implementation of the new feature.
4) Do all items in a PRD need a functional spec?
Not necessarily. This is something that has to be decided by the Product Manager and Engineering. For example, a project titled “Ensure that the new release supports backward compatibility – new client works with a old server” does not require a functional spec since this is a system requirement that does not have any new user functionality. But all projects that introduce new User Interface elements should have a functional spec.
It is also possible that in some cases, one item listed in a PRD may get broken into multiple projects by engineering. In these cases, one item in a PRD may end up having multiple functional specs associated with it. This is something that needs to be worked out between the engineering and the person writing the functional spec.
5) Who needs to review a functional spec?
The functional spec needs to be reviewed by the Product Manager, Engineering Managers, developer who will code the new feature and the QA engineer who will test the project.
6) What can a functional spec be used for?
Once agreed upon, the functional spec becomes the driving document for all downstream tasks including:
· Generation of any internal design documents
· Creation of test plans by QA
· Reference document for Tech Pubs to create product documentation
· Reference document for the field (system engineers, support staff, professional services) to get more details on any new feature
Having been a product manager for the last 12 years and having written functional specifications for products used by hundreds of thousands of users, a functional spec is one that I think is an absolute must. Just like how a business plan would have detailed financial projections and assumptions, items in a PRD should be supported by a functional spec. It is the document that explains to engineering the “devil in the details”. It is one thing I cannot comprehend product managers not writing early in the development cycle. Not writing it is leaving too much to chance !!
Software Product Manager by Gopal Shenoy 
Well said Gopal. Crafting each and every detail for the particular requirement on paper surely helps reducing the risks of misinterpretation of the requirements.
This is much essential because each member of the team who is developing your product have their own perception and they see the picture standing inside the frame so missing even a single detail can lead to something very different from the expected. Functional Specifications Surely helps here.
Hi Jeff,
I agree with you. The storyboards that you describe is another form of a functional spec. Whether the functional spec takes the form of a word document, a storyboard, a powerpoint presentation, does not matter – my point is that such a document with details on the features called out in the PRD is absolutely needed – just a PRD will not do.
I agree with you that the information you describe is needed, but I would disagree that a “functional spec” is the only vehicle that can deliver this information. Product managers in Agile environments know that there are other effective ways of conveying the detail that you mention.
I see the goal overall is to communicate a certain level of information to developers, testers, and others to ensure everyone is on the same page as far as what you’re developing. A functional spec is one way to do that, detailed stories with appropriate acceptance criteria (Agile PMs know what this means, others might not) is another, and a high fidelity prototype is yet another.
Personally, I’ve seen the combination of a prototype and stories be the best way to achieve the above goal, but other methods might work better for other teams, organizations, and types of products. Product managers ultimately are responsible for delivering the product, not the documentation — the documentation is just a means to an end, so PMs should use whatever means can best achieve that end.
Jeff
My blog: How To Be a Good Product Manager