PRD - Long or Short!! Which one is better?
Malthi SS (Product Coach)
CEO & Founder @SparkProd |Product Advisor | Product Leadership Coach | Founder @ Podcast: Product Talk with Malthi | Professor@ IIM-U & Masters Union | Product Management Trainer | Speaker | Ex-PayPal, Intuit, SAP}
Recently I read a post which said that Large PRDs are big RED flag.
And I sighed and thought, it depends……
My first ever PRD as a Product Manager was about 50+ pages that I wrote over a period of 2-3 months and yes this was the “waterfall” era!! My engineering team got a “draft” glimpse of it only after 3 months??
I have worked on a lot of Tech Refresh projects where we forklift the legacy product to a new tech stack. These kind of projects are “realities” in all LE organizations. One of the biggest glitches in such projects we would have is lack of tribal knowledge as people would have left and missing/incomplete documentation will just makes matter worst – Why do we need this feature, what are the business logics, does it have dependencies etc. In the “absence” of a detailed document, developers would scan through the code to understand the functionality. In these times we utterly missed a well documented PRDs(the Whys, What and How).
In my opinion, product documentation is one of the primary responsibilities of a PM and writing is one of the skills they should ace. Writing always gives clarity to the thoughts and helps in better articulation. Writing a PRD is a deep-thinking process which helps a PM to navigate and explore possible scenarios and complex use cases.
More than focusing on the length of the PRD, I like to emphasize:
-??on quality and completeness of the content
-??transmit on the need with clarity. This is very important to bring everyone to same level of customer empathy
领英推荐
-??bringing the alignment to achieve the objective of the initiative/feature
-??provide enough details to avoid churn for development/QA team
- connect the purpose to measurement
- capture the "domain specific nuances" if applicable
-??leverage the tools to organize in the most readable way(I have used confluence with JIRA links for user stories, links to tech architecture and flow charts, links to Adobe XD links, links to research ppt and customer tickets)
-?Tag the teams/people in sections so that they focus on specific areas they should look at. Make it as collaborative and bring in stakeholders to contribute/as questions as soon as possible
-??Reviewing the PRD with a cross-functional team
?The purpose is to effectively communicate and translate the needs and solution directionally irrespective of the format. But the format may vary based on maturity of the product team/organization, lifecycle stage of the product, industry, nature of the product(problem that it is solving for) etc.