6 Proven Practices to write & manage PRDs like a Pro — (2)
Hi reader, this is the second blog in the PRD series, where we will discuss the second proven practice to write and manage PRDs better & efficiently, and make PRDs even more effective for the entire team
In this blog, we will talk about how to write PRDs faster and efficiently, where you do not have to wait for the PRD to be completed to start your product development process. You can get done more than 60% of the development work before even the PRD is finished, and that too in a foolproof and effective manner
Proven Practice №2 — Start Early, Test, Review, and Iterate
Most startups and new-age companies work in an Agile environment, but many of these companies haven’t invested in good task management software yet, due to which writing detailed PRDs is a must for Product Managers
If your company follows Agile methodology, then you cannot wait for your PRD to be completed and then hand it over to the teams, because you will have to keep making changes and additions to the PRD as you keep progressing in the task
Here are some guidelines on how you can keep writing, testing, reviewing, and iterating the PRDs all the way from start to finish:
1 — Once you have finalized the requirements and expected timeline, scope it out with your team (tech, design, UX, data) to understand what is achievable in the timeline
2 — Start writing your PRD, fill out the details that you already have by now and keep it a WIP (work in progress)
3 — Gather the inputs from your team, and start working on the initial solution. Start with understanding the goals you are trying to achieve by solving this problem (given requirements) and how you will measure if you have solved the problem successfully or not
4 — Chalk out the metrics for this and see if you have a baseline number to start with, on top of which you can measure how much improvement your solutions have provided. If you don’t have the data for your baseline, find out ways in which you can collect the data for calculating the baseline
Until you are able to measure the impact of your solutions, you cannot really tell yourself and your team/stakeholders that your solutions have improved something
5 — When you think of solutions for the problems, don’t just think from a software/digital perspective, think holistically. This is a great trait of an experienced product manager
Think of the best ways possible to solve the given problems which will help to achieve the goals, the solutions can be digital, process recommendations, or anything that is feasible to implement
6 — Phase out the solutions. In the first phase, implement solutions that will immediately solve the core pain points of the users and they should be able to use your solutions without facing additional pains
7 — Visualize these solutions with hand-drawn sketches/wireframes, flow diagrams
8 — Discuss these solutions with your team (tech, design, UX, data) to give them a heads-up on the direction you are thinking about the solutions, and also get any feedback from them
9 — Do a quick usability testing with the paper prototypes/LoFi wireframes you have created. Just 3 users are enough to get you good feedback, which will help you to understand if you are thinking in the right direction. This will also provide you data to back up your user flow, wireframes when you present them to your company stakeholders. Gather the user feedback from the usability testing and apply them to your initial wireframes
10 — Do a PRD review with your product team folks
Read why and how to get your PRDs reviewed here — https://productpeas.medium.com/write-product-requirement-documents-like-a-pro-part-2-135496355ded
11 — Present the solutions to your stakeholders to keep them aligned, and get approvals that might be required for implementing the solutions
12 — Keep adding more details to your PRD — like the solutions, initial set of prototypes/wireframes, and keep fine-tuning it
13 — Share the PRD with your team and stakeholders, and get required approvals on the document, since now you have already added the solutions in the PRD. Mention that it is WIP and the process will be iterative, where you will tweak the wireframes/designs based on user research data
14 — Your backend tech team can start working on the backend codebase set up by now. Discuss with your tech team to understand the details of how the system design is going to be and why they are planning it that way
Look for scalability here, since you will be knowing what the future of your product might look like. Ensure that with the system design planned by your tech lead, implementing features, handling users as you see in the near future will be smooth
15 — Keep doing the usability testings with the solutions. Include your UX, Design team here. You have already started with testing the paper prototypes, now continue to implement the feedback you get in these testing sessions, and then again test out the prototype. You can keep on fine-tuning the prototypes and move from paper prototypes to grayscale wireframes to HiFi wireframes, as you get and implement the user feedback from these usability testing sessions. You can test out with just 3 users every time you test your solutions
You can have a mix of previous and new test candidates, to check if your the UX solutions have good memorability. Iterate and test out the designs all the way through LoFi and HiFi wireframes, upto the final designs
16 — Start including all your user flows, paper prototypes/wireframes/prototypes in your PRD. Do not wait for the final design to get completed for you to add them to the PRD. Keep adding all the wireframes, prototypes, designs to your PRD as you keep creating them in a sequential manner along with the user feedbacks, test observations, and notes about why each iteration/change was done to the prototype
This will provide an intense visualization of the entire process of building the solutions, iterations involved, and why they were done. This creates a history of sorts for the product/features that you are building, where you or anyone in the team would know why a particular feature or flow was designed that way, and what things should be avoided in future since they were already tested out before
17 — The backend tech work will keep on progressing as you keep confirming & sharing details about the product/features you are building
18 — Once the wireframes are finalized after the usability testings are done you can do a second PRD review with your product team folks to get any feedback or answer any queries about the upcoming product/feature you are building
Read more about Peer-to-Peer PRD reviews here — https://productpeas.medium.com/write-product-requirement-documents-like-a-pro-part-2-135496355ded
19 — Once you are done with the PRD review, and have implemented any feedback into the product you are building, you can share the final set of wireframes with your tech and design team. With the finalized user flow and elements in each screen of your product/feature, your backend tech team can get started with writing the APIs
20 — Once the designs have been completed and confirmed with user data, the front-end development work can get started
21 — Adding the final designs to your PRD will be the last step of completing the PRD. By now you would have completed filling up all the sections in the PRD and your product development process would be more than 60% completed
Follow this continuous, iterative process to write and share collaborative PRDs with your team ensuring faster development cycles while working in an Agile environment
