PRD created by: Kingsley Makinde
Approved by: Tunde Akin-Moses
Feel free to adapt and modify to your use case.
For any questions, you can send me an email at Kingsley.Makinde@Sycamore.ng
P.S There are instances when you may need to add assumptions to your PRD as well.
What is a Product Requirement Document?
A Product Requirement Document is a living document that is written by a Product Manager to communicate the purpose of a product or an initiative in a product to any software developer, designer or stakeholder.
Product Requirement Document (PRD)
Revision History
Objective (Brief Description of the Changes Requested)
What is the problem statement?
The lend platform has over time been a source of constant hiccups. Hence, the purpose of this project is to regain ownership over our data and processes to help us scale fast and improve our speed-to-market without compromising on quality of service.
Sales and credit risk agents currently manage the loan process on whatsapp due to the lack of a platform to pass workflow from one unit to the next.
Investments are currently managed on a google sheet which has a lot of limitations with an ever demanding customer base.
A lot of our users typically take loans for basic needs we should be able to provide on our platform. Airtime, bills, transfers etc.
Requirement Definition
Process flow, specific items/forms that require a change
List the major goals of this change/product:
Sales agents should be able to receive and manage loan requests applied for on the mobile app/web dashboard. Investment agents should be able to receive and manage investment requests. Total ownership of the data/technologies supporting Sycamore’s loan/investments services. Sales/Investment agents should be able to view all the details and documents as provided by the customer during loan/investment applications as done on the mobile app. Sales agents should be able to send an offer letter to the customer via email. Sales agents should be able to activate a DDM(direct debit mandate) for the customer. Sales agents should be able to manage all repayment instruments provided by the user. Sales agents should be able to book a loan for a customer. Credit risk officers should be able to receive loans from sales agents and approve or decline accordingly Finance officers should be able to disburse approved loans to borrowers. Customer service agents should be able to manage basic customer info to treat complaints/issues accordingly. Collections agents should be able to set debit instructions on borrower’s accounts on the due date to collect money owed. Background Context
Provide context on this project and explain how it fits into the organization's strategic goals
This project will place us strategically in control of our data, delivery timelines and operational procedures. Consequently, it’ll serve as a launchpad for some of our more expansive goals such as exposing loan/investment APIs to 3rd parties, loans amongst friends, target savings(groups & individual).
This is in line with Sycamore’s strategy to make credit easily accessible to every African.
Success metrics
List project goals and the metrics you'll use to judge its success. Describe financial and non-financial benefit of change e.g., improved performance, Enhanced client satisfaction
Target Audience
Who are we building for and how will they interact with this new feature/ product?
Internal users at Sycamore which include: Customer experience, Marketing, sales, investments, Product, collections, credit risk This product will be used to manage the entire loan/investment lifecycle from application to operational management to closure.
Technologies
Add the dependencies or applications or platforms that this work is dependent on before the feature(s) can be completed
Databases: Postgress, Redis
Servers/Cloud Infastructure: Google Cloud Platform(GCP)
Direct Debit: Paystack(card)
Direct Debit: Remita(bank account)
Virtual Account: Providus
SMS : Termii
Email: Sendgrid
Airtime/Data/Bills Payment: VTPass
Identity Verification: Identity Pass
Payout: Paystack
1.1 Modules
Add the name of the feature or initiative e.g. Profile Edit
1.1. Permissions and Roles
The permissions can be as follows:
● Can Edit: Users can add/delete/edit items in the relevant module. The user will be notified by in-app alert and/or email whenever his/her action is approved or rejected by the user with publish rights.
● Can Publish(approve): Users can only publish added/edited/deleted items in the relevant module from the activity section in the console. The user will be notified by in-app alert and/or email whenever a request is waiting for his/her approval.
● Can View: User can only view the sections.
Note that a user with Edit and Publish rights has the right to make a request, and publish other customers’ requests except his/her own requests.
A User with Executor rights (* on all permissions) has the right to make a request without the need for it to be approved or rejected.
1.4 Risk Factors
What are the inherent risks/exposures that may occur if this change is implemented?
None at the moment
1.5 Technical Resources
1 Product Manager
3 Backend engineers
2 frontend engineers
1 Devops
2 Product designers
1 QA
1 Project manager
Out of Scope
List the features discussed which are out of scope or might be revisited in a later release.
LDAP Integration
Wema Bank Integration
Admin Guide
DTI Calculator
Group Loans
Level of Impact of Changes
Budget: ______High High, Medium or Low
Implementation: _____High High, Medium or Low
Project: ________High High, Medium or Low
Approvals