HOW I DEVELOPED MY FIRST PRD (PRODUCT REQUIREMENT DOCUMENT)

Being a fellow at the Ingenii fellowship made me get my hands on a project and also gain real-life experiences. My team worked on building a to-do list web app and as the product manager, I was able to develop a PRD. This was the most exciting deliverable I had during the project because it had me research and read more. Although I was a little bit confused at the start but with the help of my mentor, I was able to do a lot this is why you will need a mentor guiding you if you’re just starting your career as a PM.

The PRD is a very important document in product development because it contains enough details that will make the team understand what the product is all about and the deliverables needed. The PRD is written to allow Designers, Engineers, and everyone involved in the development of the product to understand what the product should do and how it works. It also guides the engineers on the features to develop and at every point of the project, it’s always visited to review if everyone is on the right track.

Firstly, I searched for a PRD template to see what a standard one should look like because I am not the first to do it, I was able to come across some templates and I had to compare to see which was more relatable because I was a starter and I need to do something meaningful first. I got a template I would be using and viola I started.

Thereafter, I curated the content of my PRD accordingly so I won’t be missing out on any important items, let’s see the list :

Asides from creating a table that outlines the target release date, product managers, engineering team, designers, and document status.

I had the:

Objectives, User persona, User stories, acceptance criteria, features, competition analysis, market analysis, revenue model, metric definition, product vision, strategic targets, release phases, use cases, designs/flows.

I proceeded to create a google document that would contain all of these contents so I can start putting them in.

• The objective is the goal you will achieve with the product being built.

• The user persona(set of character(s) representing your users), user stories( explaining what the user wants from the user’s point of view and also come with acceptance criteria that are a set of requirements to be met for a user story to be complete ), and features are derived from the results of your user research and I have had them in the business case already, I just had to import them into the PRD document.

• Features are represented as tasks users can carry out on the product.

• The competition and market analysis took a while as it required that you investigate other products that are solving the same problems as you and look into how they operate to be able to state what you will do differently (competition analysis ) and the structure of the market ( market analysis).

• The revenue model is basically how the team will generate money to run the product.

• Metric definitions are how the team will measure the success of the product.

• Product vision is a long-term goal of the product.

• Strategic targets are you defining who and where the product is for.

• Releases phases allow you to state when different versions of the product will be released bearing in mind that the minimum viable product (MVP) will be the first version of the product

• The use cases state scenarios in which users get to use your product

• Designs/flows contain links to various designs made for the product and other relevant documents.

Asides from everything listed above, you can add or remove when creating your PRD as we have different goals. You can also read more as each piece of content listed above is a topic on its own. In addition, you should have great Microsoft skills.

Check out what the PRD I created looks like.

Now, you have all it takes to curate a product requirement document.

Let’s connect on LinkedIn