Product Owner case studies: problems I've worked on
Unifying a Regulated Fintech Platform
Bringing 2 legal and financial investment systems onto one enterprise SaaS platform, across 6 delivery squads. This is the core of my current product work.
Result
30% less reworkPredictable delivery across 6 squads, with compliance-ready features carried all the way through UAT and rollout.
Context
2 investment and approval systems ran as separate workflows for one enterprise client base, with no single source of truth.
Problem
Fragmented approval chains and transaction flows slowed delivery and made every release harder to audit.
What I did
Authored the BRDs and PRDs for approval chains, transaction flows, and dashboards, and ran Scrum / Nexus ceremonies to align legal, compliance, delivery, and operations.
Documenting Core Fintech Features
Authoring BRDs and PRDs covering approval chains, transaction flows, and pricing & operational dashboards for engineering to build against.
Structuring Requirements for CRM & ERP
Running discovery sessions, mapping workflows, and turning complex client needs into prioritized specs technical teams could build against.
Designing for Multi-Tenancy
Shaping tenant isolation, access control, and modular pricing so one platform can serve multiple corporate clients across distinct business lines.
Making Multi-Squad Delivery Legible
Turning six squads' sprint data into one operational picture leadership could act on, so scope trade-offs got made on evidence instead of on whoever spoke loudest.
Freelance & consulting
The Zero-Friction Amazon Listing Wizard
A 26-page PRD taking a first-time seller from "I have a product" to a live Amazon listing, specified against the Selling Partner API and written to be built without a meeting attached.
Delivered
≤ 25 keystrokesA measured typing ceiling, 11 steps, 23 specified edge cases, and a Definition of Done written as conditions you can check rather than adjectives.
Context
Listing on Amazon means understanding product-type taxonomies, per-category attribute schemas that differ by marketplace, image specs, and Seller Central itself. First-time sellers have none of that.
Problem
Amazon's requirements change per category, per marketplace, and over time. Any spec that hardcodes them is correct the day it ships and wrong from then on.
What I did
Opened with Rule Zero: eight system rules that outrank the rest of the document, and a stated tiebreaker. Made validation schema-driven at runtime, used Amazon's own dry-run mode as the source of truth, and listed the out-of-code prerequisites with a named owner each.
Client PRD: Meta Business Profile Wizard
A production-ready PRD delivered to a client, that also opened the door to a larger engagement. The excerpt is published, matrix and acceptance criteria included.
Delivered
6-wizard roadmapDelivered on spec, then pitched the client an architecture-aligned roadmap of six further onboarding wizards.
Context
A client needed founders to self-serve their Meta Business Profile setup instead of relying on manual, error-prone onboarding.
Problem
Meta's setup spans several capabilities and prerequisites. Hard to turn into a clean, foolproof flow engineers could build without guesswork.
What I did
Applied the Decision-Point Rule, which says a wizard has as many steps as there are decisions only the user can make, and wrote it up against Graph API v25.0: capability matrix, phased UX, acceptance criteria.
Why Users Stop Coming Back
Daleel Store's brief called it a retention problem. The first thing I did was argue with the brief.
Delivered
2 user types, not 1Splitting "churn" into users who were failed and users who simply finished changed the metrics, the initiatives, and what got deferred.
Context
Signups growing, retention collapsing after the first purchase. No access to internal data, so every claim had to be written as a testable hypothesis.
Problem
A churned user and a finished user look identical on a retention chart. Optimising them the same way builds re-engagement machinery for people who were never coming back.
What I did
Named the Finished/Churned Split, separated three diagnoses that all look like falling retention, then built three initiatives and a 90-day plan on top of the distinction, plus an explicit list of what I deferred.
Shipping a Live Classroom in 10 Weeks
An interactive live-classroom product for MENA EdTech platforms. Five engineers, remote, two-week sprints.
Delivered
5 sprints to MVPFour scoped stories with acceptance criteria and edge cases, a teacher flow with its failure branch drawn, and a named owner for every kind of decision.
Context
Zon Net Digital Solutions. Mid-to-large platforms with an existing LMS, wanting a live-classroom layer they could integrate over API. Mixed devices, mixed bandwidth.
Problem
Five developers and a short window. Everything hinges on cutting an MVP that is small, and on knowing who decides what before the team disagrees.
What I did
Wrote the assumptions down first, built two personas, listed the questions worth asking each stakeholder, scoped four stories, and set the Decision Owner Rule: value decisions to the PO, execution to the Tech Lead.
Things I've built myself
Productology: An AI-Native Workspace for PMs
Prototyping the tool I wish existed, while writing specs for it the same way I write them for work.
Result
4 systems speccedPrompt libraries, file management, caching, and rate limiting, each its own release spec instead of one big-bang launch.
Context
PM tooling is still spreadsheets, docs, and switching between chat windows for every spec. Nothing treats prompt libraries or file context as first-class.
Problem
Every AI-native workflow I wanted for my own product work meant re-inventing structure that should already live in the tool, not the process.
What I did
Wrote the full technical blueprint end to end, then broke it into incremental release specs the same way I'd hand off to engineering at work: BRD discipline, applied to my own product.
Specs Engineering Can Build Without a Meeting
The through-line across every PRD here: name the tiebreaker rule, pin the API version, and give the failure paths more pages than the happy path.
Executive Sprint Reporting
Turned raw sprint data into executive-ready reports covering cost, efficiency, and commit metrics, then rebuilt the workflow as a repeatable script instead of a manual ritual.
SheGlow: E-commerce Storefront
A women's accessories storefront for the Egyptian market, taken from spec to working Django site. Product thinking and implementation, done by the same pair of hands.
FleetX: Smart Fleet Management System
Graduation project supported by ITIDA and ASRT. Led a team of four from concept to working system, my first step from engineering into building products people actually operate.