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 !!