In the Beginning — PRD
For a long time, founders and business owners in Africa built businesses the best way they saw fit. As long the business case made sense to the entrepreneur, and probably validated the business idea with family and friends, the next thing was to either assemble/recruit staff in key positions, or outsource the development of the software to software engineers, after communicating the idea to them.
We all know family members or friends who have gone through this process at one time or the other, especially for their failed businesses; but the bitter part? More founders in Africa still start businesses without understanding the need to build from the customer perspective, and so, products get designed and developed with many features and functional requirements that the user doesn’t need, nor will ever need. And since many small business owners have opined that recruiting a Product Manager increases their wage band, it’s necessary that these founders begin to learn to walk in the shoes of Product Managers. To do this, there’s a need to start with one of the most important documents a Product Manager prepares while building a product — a Product Requirement Document.
A Product Requirement Document, PRD popularly called, defines the requirements of a particular product, including the product’s purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch or market the product. This simple document, which has been deemed a “living document” (because it gets regularly updated with requirements and updates, should cover the following:
- Goals
- Business Objectives
- Scope
- User Stories
- User Interview/Analysis
- MVP Success Metrics
- Prototype Strategy & Finding Users
- Product Messaging
- User Persona
- User Scenario
- Features
- Product Strategy
- Other Considerations
- Roadmap
These basic fields should be covered in a simple PRD, even before meeting other stakeholders like the development team (engineers and designers). Further meetings with them, should avail you enough information to include the following:
- Software Architecture: Selected Language, Sequence Diagram, System Diagram, Database Schema, API Document, and User Flow.
- Use Case Diagrams for MVP
- Wireframes
Now, it’s important to know that the above mention fields are not the Product Manager’s to solve. Their job is to get these details from the devs and designers he’s working with. And so, armed with these fields, you’re ready to begin your journey as a Product Manager.
PS: Your PRD must not follow the above-stated format, but it’s necessary that it contains most of the above information, so as to help you build a better product.
