A Product Requirements Document defines more than just your product. Leave no room for assumptions!
If you are having trouble at ideation or perhaps are an “idea machine” but can’t get it across the board, read my article on “How to make your next idea at work a reality”.
Writing a Product Requirements Document (PRD) is a monumental task. At very minimum, it requires you to address aspects, such as features that you would not ship without, features that customers might expect but are not necessary for a product launch, nice-to-have-features, and more. How do you make sure your PRD reflects the Minimum Lovable Product you imagined? How do you ensure engineers are not assuming requirements as they code because of lack of clarity? (Yes, that happens)
The key is to keep your PRD explanatory enough to avoid room for confusion or assumptions. Have a template and be specific. The template may differ depending on the type of product but it should cover details as discussed below.
Define your customer’s expectations of the product
This is where you define the features of the product your customers view or interact with and the experience they get out of it. Moreover, you want to order them on priority (P0, P1…) of the customer’s expectations. Priority helps understand the features you would not ship without, thus making it clear that these should be implemented early on. When engineers assess the complexity of the requirements in terms of implementation, priority helps them tackle complex P0s or P1s first.
For example, consider the requirement — “As a customer, I want to see a button to clear my browser history”. This is a requirement, but what’s unclear is the title and position of the button, what happens when you click it, what the impact to other items is on the page, etc. You want to think through all scenarios and leave no room for assumption.
Define your expectations as a Product Manager
The next step is to define expectations as a Product Manager. As a PM, it’s your responsibility to gather customer usage data that helps evaluate the success of the feature or product as a whole. The usage data should be defined as technical metrics in the PRD, again prioritizing them as required.
Consider the requirement — “As a PM, I want to capture clicks on the ‘Clear History’ button”. Apart from defining the metric for click, define what’s the maximum latency customers may observe before the history is cleared.
Define the expectations for all stakeholders such as a Marketing Manager
Remember, there are external stakeholders who interact with your product apart from your customers. Their requirements and interactions with the product should also be well defined in the PRD. Consider all stakeholders in your requirements such as legal, marketing, etc.
For example, here’s a requirement — “As a Marketing Manager, I want to program sign-up campaigns on the home page.” This requirement will allow the marketing team to have the flexibility to program unique content for different customer markets. You want to define exactly what they will be able to program, whether it’s the content or hyperlinks to content or both.
Once you have an exhaustive coverage of product requirements, review it time and again with the involved stakeholders. This will ensure a smoother product development cycle and fewer surprises to handle towards the end.
