This is my chance to help the engineers appreciate the impact of what we’re building. Even if the math behind the number is not a 100% (and includes assumptions), I still include it. I ensure that the impact is always quantifiable and measurable. But, it focuses more on the impact of solving the problem. Impact - this section is an extension of the above.The goal is to help everyone understand that the problem I’m trying to solve is worth the investment. Problem and its size - I include quantitative and/or qualititative data that I used to size the problem.The most important reason to include this section is to help the readers understand (and hopefully agree with) the rationale for the feature. The Purpose or Business Context or Problem StatementĪs important as it is, most PMs ignore and omit this section. I feel this structure is comprehensive and easy to consume. I like to include the following sections in a Product Requirement Document (PRD). In creating a source of truth, which acts as an agreement between the PM and engineers.In ensuring that I do not miss any details.
I find myself writing PRDs even today, as it helps: But I know for a fact that they are still commonly used in some form or the other. If you’re still thinking PRDs are not the as popular as they used to be, you maybe right. Now, let’s switch gears a little bit and talk about what an actual PRD should contain. Well-written PRDs act as sources of knowledge for anyone interested, even if they are not part of the specific team. Agree on acceptance and launch criteriaĪ good PM will always include clear acceptance criteria in the PRD.Īcceptance criteria helps the PM align with the engineers on the minimum requirements that the feature needs to meet before the team releases it to the world. A well written PRD leaves no room for interpretation. The PRD acts as a single source of truth for all stakeholders.Ī well written PRD ensures that every stakeholder understands the product scope in the same way. PRD is an effective to get everyone on the same page Creating the PRD pushes the PM to structure her thoughts, close open questions, remove ambiguity, and think of use cases that she might have not thought of so far. Until the PM creates the PRD, the product scope is high level and, sometimes, ambiguous. PRD provides a very deep level of clarity and remove ambiguity The job here is - to communicate to the engineers what they need to build and why. It is a contract between the engineers and the PM that defines what the engineers build.Ī precise definition is critical for the PRD to do its job well. Why is a PRD important? PRD helps in defining clear scopeĪccording to Wikipedia, “ a product requirements document (PRD) is a document containing all the requirements for a certain product.”įor me, PRD is a document that precisely defines what is and what isn’t in scope. Include the purpose or the business context for building a specific product or feature.
0 kommentar(er)
