Product Requirements Document 101
Everyone has its own story and so does every company has its own way to tell their story. In the product development cycle, documentation is an essential precursor to the design and development process. But why is it so important?
Now imagine that company is expanding, has various divisions and every division has its own target, objective, constraints, and procedure to approach its goal. The company has multiple numbers of products, each has its own purpose and unique features — and it’s not easy to keep up on each product. Try to look at the picture below as an illustration.
We often assume that people sees our products/company the way we see it — when actually it doesn’t. In the company, we can all agree on one main goal, but the process of achieving it can include layers of tasks, procedures, and consisting of different team works. Hence, resulting different outcomes. That’s why we need documentation.
In HARA, we are using the Agile Methodology, which depends on a shared understanding of the customer that is shared between the customer and the teams in the company
When the team share the same mindset, you don’t need ultra-detailed requirements.
Here are some recommendation how to create a shared understanding among teams:
- Include a member of the design and development teams when conducting customer interviews.
- Make developing and using customer personas a team effort.
- Make issue triage and backlog grooming.
After we have a shared understanding among teams, it’s time to write documentation. There are a lot of ways to create documentation in the product development process, some of them are explained below:
- Process Documentation (Business Flow)
Process documentation is an internal, continuous method for capturing the necessary steps to complete a process or task. A business process comprises all the tasks that lead to the delivery of a specific product or service. Process documentation is critical for any business because it increases consistency and standardized. This usually written in the flowchart.
2. Product Requirements Documentation (PRD)
The PRD serves as a compass, providing clear direction toward a product’s purpose while creating a shared understanding among business and technical teams who will help build, launch or market your product. It outlines the product’s purpose, its features, functionalities. It’s written by the Product Manager.
3. Technical Documentation
Technical documentation refers to any document that explains the functionality, creation, or architecture of a product. Think of it as a nuts-and-bolts “how to” guide for your users, new hires, administrators, and anyone else who needs to know how your product works. Technical documentation is usually either written by a technical writer who’s been trained to translate complicated product knowledge into content that’s easier to understood by the end-users or written by our engineers as they are able to break it down into implementation.
4. Variable Mapping and Glossary
This documentation contains all variables used in the back end or front end side, every front end variable has its own description, type, mapped to the back end variable, measurement in the back end, also the validation if it’s input format. This usually includes technical documentation.
5. User Acceptance Testing Documentation
User acceptance testing (UAT) is the last phase of the feature/product testing process. During UAT, actual users test the product to make sure it can handle required tasks in real-world scenarios, according to specifications. UAT is one of the final and critical product documentation that must occur before the newly developed product is rolled out to the user.
6. Definition of Done (DoD)
Definition of Done (DoD) is the acceptance criteria that are common to every single user story. For scrum teams, it’s really important to have a solid definition of what “done” means. They work in sprints and need some way of deciding whether a user story is actually finished. DoD can be different, but what is important to note here, is that the initial Definition of Done must be agreed before the first Sprint.
7. User Documentation
It is often called a user manual or user guide, who usually provides to customers once they have bought a product/service. Still, the users frequently ask the same questions about the product again and again.
Remember the golden commandment of documentation writing is “thou shalt not assume”. You might think you’re being obvious, but you have to be aware of the knowledge level your audience is at.
As the first Indonesian startup focusing on financial inclusion in the food and agriculture sector, we support our products through the documentation for future development which are:
- Business flow, the standardized reference of all processes in our system, can also involve various products.
- PRD, the first document resulted from backlog grooming as the compass for all stakeholders involved.
- Variable Mapping and Glossary, as a document between product and engineer to have a shared understanding of one variable associate with the back-end.
- Technical Documentation, developed by the engineers
- User Acceptance, resulted from the demo of the product, contains all bug/success feature in the product
- User Guideline, resulted after the product has launched to help the end-users comprehend the product fully
Currently, in HARA, we create documentation using Google docs, Excel and Azure DevOps. From a lot of PRD templates, we prioritize the main factors in supporting our product, here are the example of our Product Requirements Document content:
- Product Specific contains the information on who is involved in delivering this product, documents status and the update time information.
2. Goals, Business Objectives, and Background: The specific purpose of product and how does it fit into overall company objectives.
3. User Stories and Test Case Scenario: a link to User Story in DevOps, User Story description, Priority and Notes
4. Design: contains of product flow and the mock-up of the product
With a lot of information to be written and updated, the product manager often spends much of their time revise and update the PRD just to conceiving the stakeholders in such a way that it hits perfection thus it accommodates all stakeholder's needs. That’s why I suggest an internal documentation platform to store all of the company documentation. It’s easier to manage, on every update there will be information, all of the stakeholders can be involved by a comment, ask questions, encourage others to contribute with thoughts and ideas.
Conclusion
You don’t have to follow the same format every time — do what you need, when you need it, and be agile about it. Chop and change as needed.
Every company has its own way to tell their own story, there is no such thing as perfect documentation, but of course, there is a perfect way to deliver your product documentation. The key to delivering a product in agile methodology is also being agile about the documentation. Create a document that eases the pain point of all stakeholders.
References
https://plan.io/blog/technical-documentation/
https://www.atlassian.com/agile/product-management/requirements
Learn more about HARA
- Visit the HARA website
- Read our White Paper
- Follow our Social Media
Facebook, Twitter, Instagram, Medium & LinkedIn
