Day 28 - Writing a PRD
What it takes to write a good PRD...
Hello learners!
Welcome to the 28th lesson of the series 30 Days of PM by Crework! Today, we will talk about one of the most important things that you need to know if you are a PM, or at least when you are an AMP. How to write a PRD.
But before we start, make sure you are subscribed to us. In case you are not, subscribe to us right now and complete the challenge.
What is a PRD?
PRD means “Product Requirements Document”. It is a high-level document that outlines the features and attributes of the product you’re working on.
But that is a very lame definition I guess. So, let’s break it down further.
So, when you work on a product, there are a lot of people involved with it and a lot of teams that needs to work on it. The business part, the management comes up with the requirements, the product manager figures out what needs to be built and why. But, how is it communicated to the other teams? How does the design team know what they are supposed to design and how it’s supposed to work? Same with developers right?
The answer is - PRD.
A Product Manager writes and maintains a PRD where everything related to the product - from the problem statement to the “why” of the solution is documented along with the way the solution will be implemented.
The design team uses the PRD to understand what’s required and come up with designs. The tech team uses the PRD and designs to understand what needs to be built. The marketing team looks at the PRD to understand the product and come up with the campaigns.
When do we write a PRD?
PRD is generally written once the problem has been identified and a solution has been thought of, so whenever the PM knows what they will be building, a PRD is written.
Then, this PRD evolves as other teams interact with it and come up with their inputs.
How to write a product requirements document?
Here’s how to write a PRD that leaves no stone unturned:
1. Define the product
In your opening, summarize your plan. State the product you’ll create, the project team and stakeholders, and a tentative release date. You should also include a description of the product’s purpose, identifying what pain points it alleviates for the target audience and who that buyer persona is. Provide any other high-level information on how the product creates value for the end user.
2. Determine goals
Write the team’s objectives for the product development process. This section lets you delve deeper into why this product benefits both the end user and the company that’s creating it. Generate SMART goals — specific, measurable, achievable, relevant, and time-bound — that can later serve as goalposts.
3. Identify assumptions and constraints
Assumptions are the points or roadblocks you know you’ll meet during the product development process, usually involving end-user needs. Constraints refer to unknown external pressures or limitations that have the potential negatively impact workflow, like working with a new supplier. Defining them from the start lets you more accurately determine final expectations for the product.
4. Limit the scope of work
Define what is and isn’t within the project scope. No matter the type of project, setting boundaries will help prevent scope creep — work that’s outside of the project’s reach — and keep the team on track.
5. List features
Identify the product's primary features, describing how end users will use the item, service, or software. Describe each requirement in as much detail as possible so any teammate or stakeholder who’s reviewing the document will understand what’s within scope. The PRD is all about requirements, so this section should be robust.
6. Define release criteria
In this step, identify the criteria that will determine whether your product is customer-ready. This might include notes on functionality, usability, and reliability. Once you check off these release criteria boxes, you can feel confident that you’re launching a quality product to a target audience that will be eager to use it.
7. Set metrics for success
Decide on a methodology for approving work and ensuring the customer readiness that you described in the steps above. When you begin the product development project, you can track these metrics and make sure you aren’t missing anything.
Day 28 - Completed ✅
Congratulations on completing the 28th lesson of the series. 🥳
Now, you know what to do. Share your learnings with the world and be accountable.
If you have any feedback, please share it with us. We would love to have your suggestions and improve our future content for your better learning.
If you want to join a community of product aspirants where we discuss product management topics and case studies, you can join it here: Join Community!
References: