This article is written by our community member Shivam Sethi who is an expert tech developer having a diverse experience in multiple tech-stacks both in Frontend and Backend. Currently he is working for a product based organisation in a major OTT platform provider site.
For any organisation be it big or small that intends to create a tech product for its platform / service range, it is important that they have a clarity on all the cases of human interactions of functionalities associated with it. There needs to be a total clarity on the types of features, specs , built functionalities required for the product. Usually one could just pen down all these requirements in a piece of paper, draft an email and be done with it.
However, based on his personal experience, Shivam strongly feels that there needs to be a mechanism / structured process to capture all the essential elements of project in a well planned document as without the same , the delivery is totally reliant on what he calls as Monkey Coding. As the project goes bigger, complexities are magnified and the need for such a structured document becomes more essential. And in absence of the same, the code gets more polluted accounting multiple feedbacks due to uncertainty of the plan during the start of the project.
He adds, “Half a baked product is much better than a half baked product” By this , he means that any product with such a documentation is much better even if it is incomplete / unsuccessful than a successful launched product w/o clarity as latter is not a sustainable approach towards Product Delivery.
This document is called a PRD or a Product Requirement Document which is required during the start of technical delivery process. Engineering team relies a lot on PRD be it Frontend / Backend or even QA professionals. QA teams need to ensure that all bug / issue reporting has to be done vis-a-vis matching with expectations of the project or whatever is listed in a PRD.
He adds on saying that he has personally seen projects/ modules that would otherwise take 3 to 4 days but stretch out to even 2-3 weeks in absence of a PRD. He agrees that engineers / developers are not much motivated writing a PRD, however that effort pays off well in long term. There are cases when developers just start coding w/o any PRD and enter into a process of Monkey coding soon enough to find out delays / errors emerging out in the delivery process.
Now, if we talk about essentials of a PRD, it would depend a lot on the type of project you are working on. In the end, it should answer all the questions of an engineer. Generally a PRD of a project should be divided across different modules. e.g. for an OTT module, one should list down all the modules in a PRD starting from a user-auth module, onboarding state of a user, content discovery module, configuration cases and content personalisation cases. One more level of clarity within the same would be to define all the screens a product would contain . There also needs to be another level where each screen should define all the components inside the same , interaction between the same and purpose of each component.
One of the biggest advantage of a good PRD is traceability of project status. If there is a PRD, one would always know what is the exact status of development, what is done and what is left and helps in defining the project delivery timelines and tracking very well.
In conclusion, presence of a good PRD is directly correlated to how a code structure would look like. With a PRD, you could have a failed or successful product but without it, there is a higher certainty, you would be entering in an unsuccessful execution. But why talk about latter when we are already convinced that you are going to make one !