iVoluntia

iVoluntia is a multi-tenant volunteering and charitable donation platform that connects volunteers, foundations and platform administrators.

It was built to support the full volunteer and donation journey — discovering opportunities, managing programs, processing donations, tracking engagement and giving each user type the analytics they need.

The product had three core experiences: a Volunteer mobile app, a Foundation web portal and a Super Admin web portal. The build ran for 6 months in 4-week sprint cycles. I worked on it as part of a cross-functional team of about 38 people — 7 developers, 8 designers, 4 marketers and 8 other product managers — and my product work covered the UI and requirements for roughly 19 screens.

The PRD named a fragmented volunteer ecosystem as the core problem.

Organisations struggled to reach relevant volunteers, manage sign-ups and participation, track program impact and manage donations.

Volunteers struggled to discover relevant opportunities, find causes that matched their interests and skills, track their volunteer history, stay connected to the causes they support and find programs to donate to.

So the product had to give each user type the right information and tools while keeping visibility across the wider platform.

The PRD set five goals: streamline volunteer and foundation onboarding, enable creation and management of impactful programs, provide secure and trackable donation processing, encourage engagement through feeds, badges, ratings and notifications, and provide analytics, auditing and user management.

My work focused on turning those requirements into structured, actionable work for the cross-functional team.

Worked within a cross-functional team of about 38 people, collaborating closely with developers, designers, marketers and other Product Managers to deliver product features.

Managed product work for the Payment Gateway Integration and Foundation Admin Dashboard, translating product requirements into clear execution plans.

Planned sprint work and broke requirements into user stories, acceptance criteria and actionable tasks.

Used ClickUp to manage priorities, deadlines, dependencies and overall product progress.

Worked closely with designers and developers to clarify requirements, resolve blockers and keep delivery moving.

Managed UI and product requirements across approximately 19 screens for assigned features.

Tracked blockers, dependencies, outstanding work and risks that could affect delivery.

Coordinated with testers during QA and UAT, followed up on issues and supported feedback through resolution.

Supported sprint reviews and release planning, helping ensure features were aligned with the intended product requirements.

Worked across product, design and engineering to move features from requirements to design, development, testing and release.

The PRD held high-level user stories like: “As a Foundation Admin, I want to see donation insights, program stats, active volunteers and goal progress so I can monitor performance at a glance.”

My job was to turn that into something the team could execute. The Foundation Admin Dashboard requirement broke down into donation summary, donor insights (donors, amounts, comments, highest donor), program activity, volunteer activity, goal tracking per program, and data behaviour — regular updates with expandable and exportable widgets.

Each piece then moved through design, development, QA and PM acceptance. That turned product requirements into clear workstreams that could be assigned, tracked and tested.

Foundation administrators needed to monitor donations, programs and volunteer activity at a glance.

Requirements: total donations received, donor list, donation amounts, highest donor crown, donor comments, active and ongoing programs, active volunteer count, goal progress per program, data updates, and expandable or exportable widgets.

I translated these into actionable work and coordinated the dependencies between design, frontend, backend and QA. Acceptance criteria set what had to work before the dashboard could be called complete.

Volunteers needed one place to see their current participation, achievements and history.

Requirements: current ongoing program, program status, earned certificates, downloadable certificates, unlocked badges, badge descriptions, past programs with status and dates, and editable profile information.

I broke these into clear product and implementation requirements — including the expected behaviour for certificates, badges, programs and profile data — and coordinated dependencies between mobile, backend and QA.

Super Admins needed platform-wide visibility to monitor performance and spot trends.

Requirements: total platform donations, donor list, donation amounts, highest donor ranking, donor comments, active foundations, top-performing foundations, donation trends, time-range filters, foundation filters, category filters and exportable insights.

I translated the platform analytics requirements into development-ready work and coordinated the design, frontend, backend and QA dependencies needed to deliver it.

Audit Log — built for transparency and accountability for Super Admins: user ID, role, action, timestamp, sign-ins, donations, content changes, data exports, user-linked records, CSV and PDF exports, and filtering.

Profile Management — for volunteers, foundation admins and super admins: name, email, phone, role-specific information, editable fields, earned badges and secure update processes. Sensitive fields like role and email needed extra restrictions or verification.

Badge System — badges as engagement and recognition. Volunteers earn them for hours contributed, program completions and certificate count. Donors earn them on cumulative donation amounts. Foundations earn them for program success, goal completion and volunteer retention. Each badge carries a title, icon, description and date earned, appears in the dashboard and profile, and is awarded through scheduled checks.

Managing this module meant keeping several teams aligned around the same requirements. I used ClickUp to turn the PRD into actionable work and to make ownership, timelines, dependencies and blockers visible.

Sprint planning: work ran in 4-week sprint cycles, where requirements became tasks, subtasks and acceptance criteria, with a clear owner and known dependencies for each.

Work tracking: a structured flow — design complete, ready for dev, development, ready for QA, QA, PM review, done — so the whole team shared one view of progress.

Coordination: I worked across product, UI/UX, frontend, mobile, backend and QA, making sure requirements moved between functions with enough clarity for the next team to execute.

Standups: daily check-ins surfaced completed work, current priorities, blockers, dependencies, requirement questions and delivery risks. When a blocker showed up, I followed up with the right person to move it.

Clear handoffs were a big part of how I ran delivery.

Design to development: Figma, components, interactions, assets, copy, acceptance criteria and data or API requirements.

Development to QA: implementation, PR, staging or emulator build, API information and test data.

QA to product: test results, bugs, severity, reproduction steps, expected versus actual behaviour, and screenshots or video.

That created a clear chain of responsibility from one stage to the next.

The module had several connected workstreams. The dashboard UI alone needed design, backend data, frontend implementation and QA.

I tracked those relationships so dependencies stayed visible and teams could work in parallel where possible.

Where a blocker could affect delivery, I followed up with the team involved instead of letting it sit hidden in the sprint.

PRD requirements and acceptance criteria were the reference point for whether work could move forward: build, test, validate, PM review, accept.

Development being finished did not mean the requirement was complete. The implementation had to match the expected behaviour and pass QA before I accepted it.

This project showed me how closely product management and project management work together during execution.

I was not the person designing every screen, writing the APIs or testing every feature. My job was to make sure the people responsible for those areas had clear requirements, clear ownership, clear priorities, clear deadlines, clear handoffs and clear acceptance criteria.

And when something got blocked, it was visible and followed up.

The product moved from a detailed PRD into coordinated work across product, design, engineering and QA.

The Dashboard, Profile, Badge System and Audit Log requirements were broken down into deliverable work for the relevant teams.

Across 10 months I gained practical experience in product planning, sprint execution, cross-functional coordination, Agile delivery, dependency management and product acceptance inside a real product team.

The biggest lesson was that product management is not about doing everything yourself. It is about creating the clarity that lets everyone else do their part well.

I learned to see delivery as a connected system: understand the problem, define the requirements, break down the work, align the teams, track execution, remove blockers, validate the outcome, deliver.

That shaped how I work today — product thinking joined to structured execution, with the user need at the centre of delivery.