Creating a Product Requirement Document; The Easy Step by Step Guide

In this article, we describe how to create a PRD (product requirement document) which shows the basics and technical need-to-know features of the product Esify. This document was created by the product management team on its first week of sidehustle Bootcamp.

The concept of A PRD as it is commonly called, can be a hard nut job depending on the approach you render. In essence , a PRD is whatever you want it to be.

In our case, we embraced the PRD as a common document equipped with details of features, user experience, design and business analytics of our new product in preproduction. Just as you have deduced, a product requirement document (PRD) is an internal document that explains what your product is all about. i.e. what your product does, who it does it for, why it does what it does, and why anybody should take you seriously as you plan to develop this product.

Meaning, it’s financial feasibility. Because, even as much as we want to solve problems, in the long run. Every solution will require finance to maintain its efficiency. Hence, the need to put in details of achieveable tasks. Some of them will be discarded eventually because a PRD has to be approved by the dev team, market, digital and design team. Because as product managers, we conceive ideas, collect ideas, and compile to make tangible sense. As we do this, a lot won’t be perfect. Don’t fret. No one is an island. It takes more than one person to be a team. You are part of one and everyone’s opinion counts. It may be sad to see something you worked super hard on being discarded. I feel you, but we say in the streets. “We gather dey, nothing do you”

However, in any PRD you update. Always add the old version at the bottom. It helps for reference and eases progress.

In creating a PRD for the product Esify. Firstly, we conceived the idea of a platform where people could go to question the society standards and have a say in institutional decisions that directly or indirectly affects them.

The idea was the easy part, selecting a suiting name for our idea was far from it. As it was almost a daunting task. Literally, every name selected had been taken by another product. In the hot tussle back and forth of name selection, we settled unanimously for the name ESIFY. However, DENOTE was a runner up in name candidacy. Yes, your guess is as good as correct; DENOTE was off the market. Too!

Upon name selection, the basic tasks of a product manager was activated and each member in the product management team. Had their work respectively.

From user persona to user flow, wireframe, business analysis, design, and user research. Applying lessons learnt from the sidehustle internship. Each member completed their write ups and mock ups.

All of these were respectively delivered to the product soft lead, and with his own additions and scrutinizing. The respective documents were compiled into a draft of about 8 tabs. And duly filled in, into the PRD as it has a template which can be whatever you make of it. But in our case, we choose to make it simple and direct.

Therefore, the first section to be filled was the Section One: Introduction and Goals. This section describes the basics of the product, what and why. This section included user persona, user flow, epics, user stories, use scenarios, market analysis, assumptions, scopes and target audience. These details made up the bulky section one.

Section two: Features and Funtionality. This section covered the user experience. Ranging from features to appearance. Giving off subtle details and in-depth details of user experience at every necessary level.

Section three: Release Criteria. A product is not completely developed if there aren’t any scope to it’s use by prospective users or customers. This sections defined the levels of technicality that must be met before release of ESIFY 1.0. Which by default included functionality and environment.

Section four: Timeline and Constraint. Perfection is a state of mind, it can be met and achieved. Or it can be visualized. With limited time, we did not aim for perfection. Because adding unrealistic tasks to a 7 day work time frame. Will only make the product design and dev team build an imperfect product, fail to deliver or be complacent. Hence, there was need to clearly define the timeline of the project, and the perceived shortcomings.

Remember, a PRD is whatever you make it to be. If you choose to wear your shoes and walk this path we have chosen. We guarantee you an easy understanding in making your very first PRD. Even when you feel lost, always have this in your mind; it’s just a document made in msWord that contains details of my product and it is not a business plan.