Product Manager · Lagos, Nigeria
Onyekachi
Agu
I'm a PM with a background in frontend engineering. I got into product because I kept noticing the gap between what engineers build and what users actually need — and I wanted to be the person who bridges that.
I've shipped products across fintech and health tech, mostly in early-stage and growing companies where there's no playbook. I write clear specs, stay close to users, and I'm comfortable in a room with engineers because I've been one.
Skills & Tools
Strategy
- Product Strategy
- Roadmapping
- MVP Definition
- Product Discovery
- Go-To-Market
Delivery
- Agile / Scrum
- PRDs & User Stories
- UAT
- Release Management
- Continuous Delivery
Research & Design
- User Research
- Journey Mapping
- Usability Testing
- A/B Testing
- Prototyping
Technical
- API Testing (Postman)
- Technical Writing
- Stakeholder Management
- Cross-functional Teams
Tools I use
Work
MSME Operations Platform
Orchestra builds software for enterprise clients managing MSME operations — think wallets, KYC, invoicing, inventory, and payment provider connections all in one place. I own the product roadmap and work closely with engineering to keep things moving.
The situation
When I joined, requirements were coming from stakeholders in every direction with no clear structure. Engineering was building things, then rebuilding them because the brief kept shifting. Compliance had different expectations from product. Nobody was aligned.
What I did
I got in front of stakeholders, documented requirements properly, and turned them into PRDs and user stories the team could actually act on. I also started running cleaner sprint planning and sat in on engineering sessions for payment integrations to make sure nothing was lost in translation.
DARA Recovery — Zero to Beta in Six Months
DARA connects people in addiction recovery with certified coaches — no waiting lists, no barriers. You sign up, answer a few questions, and you're matched with a coach in minutes. I was the sole PM from day one to beta launch.
The challenge
Recovery is a sensitive space. Every flow — intake, matching, messaging, session booking — had to feel safe and low-friction, because the person on the other side is often in a hard place. There was no room for clunky UX or edge cases that slip through.
My role
I wrote every PRD and user story, ran design reviews, coordinated engineering and QA, and drove UAT across both the coach and user sides of the platform. Six months from kickoff to a stable beta with real users on it.
Context
Recovery support in the US is broken — long waitlists, rigid programs, stigma at every step. DARA was built to cut through all of that. The product had to serve two very different users: people in recovery who need to feel safe, and certified coaches who need a clean workspace to manage their clients.
What we built
Quality & process
I used behavioral analytics to identify where users were dropping off during internal testing and redesigned those flows before we touched UAT. For UAT itself, I triaged every defect by business impact — not just severity — so we went into beta with the things that mattered most resolved. Post-beta we had 30% fewer production defects than projected.
Onboarding Pipeline — No Users Left Behind
Onvie is a US-based health startup. I came in on a contract to help them get their first users from sign-up to actually using the product. There was no onboarding system at all — just a gap where users were falling through.
The problem
Early adopters were signing up and going quiet. There was no structured flow taking them from initial engagement to active usage. No follow-ups, no fail-safes, nothing. The team was acquiring users and losing them at the worst possible moment.
What I built
I mapped the full journey from first touchpoint to active user and designed the operational flows to support it. Built in automated fail-safes at every drop-off risk point. Then worked with the team to put together a GTM strategy — pre and post-launch playbooks, messaging, success metrics.
PartyWithMe — Social Event Discovery Platform
PartyWithMe lets you find, create, and join events — and actually connect with people before and after. Think Eventbrite but with the social layer built in. I was PM from early product stage through MVP launch.
The gap
Event discovery was fragmented across too many platforms, and none of them let you actually connect with people going to the same event. 68% of users in our research said they struggled to find events that matched their interests. The social layer was missing everywhere.
My role
End-to-end PM. I ran the research (surveys, interviews, competitor analysis against Meetup, Partiful, Eventbrite), built the roadmap, wrote specs in JIRA, managed 2-week sprints, and owned QA through to launch. Post-launch I used analytics to iterate on the product.
What we built
Process
Research first — I ran surveys and focus groups before we wrote a line of spec. We built in stages: discovery engine and RSVP in the MVP, social features next. Three-tier QA workflow (pre-release, regression, UAT) before anything shipped. After launch I pulled analytics regularly to prioritise what to fix and what to push forward.
Atlas — Building a Fintech Banking Website
Atlas is a CBN-licensed online banking app built for Nigerians — personal accounts, business accounts, side hustle accounts, savings, bill payments, rewards. I was a frontend engineer on the team that built the website from scratch.
What I built
Co-led the frontend build and launch. I handled SEO implementation, responsive layouts across all product pages, KYC onboarding flows, and integrating RESTful API endpoints with backend services using Angular.
Cross-team work
I set up a cleaner alignment process between design, backend, and QA — mainly because we kept shipping things that didn't match the API contracts. Fixing that process cut rework significantly and sped up delivery.
Technical work
Why this matters for PM
Working as an engineer taught me how specs actually get interpreted by a dev team — and how much gets lost when requirements aren't clear. I know how to write for engineers, when to push back on technical decisions, and how to catch risks early. It's the most useful thing I bring to a product role.