Leading Product Operations Across Two Connected School-Finance Products.
For a three-month contract, I led Schoolable's day-to-day product operations across engineering, product, QA, customer service and marketing — maintaining delivery continuity while the CEO focused on fundraising and company-level priorities.
Expanded mandate: I was also entrusted with a Project Manager assignment for a Café One merchant-payment solution.
A clear, three-month operating mandate.
Schoolable's CEO needed room to focus on fundraising and company-level priorities. My mandate was to absorb day-to-day product management — keeping engineering moving, prioritizing escalations and maintaining communication across functions.
Fundraising · Company strategy · Executive relationships
Product operations · Delivery coordination · School escalations · Cross-functional alignment · Weekly reporting
A Y Combinator-backed school-finance company in Lagos.
Schoolable was a Y Combinator (W19) company building financial and operational services for African private schools — tuition collection, fee payments, financial management, financing access and administrative operations. I joined to run product operations, not build the company or its funding story.
Public company context: Schoolable's Y Combinator profile describes its founding proposition. This case study covers only my operating engagement, not the company's history.
Two connected products, one operating system.
Schoolable and Dolittle shared schools, finances, and a delivery team. I oversaw the operating health of both during the contract.
Coordinating across nine connected groups.
This was a coordination role, not a chart of titles.
Received weekly product reporting; freed to focus on fundraising
Owned product domains; escalated and reviewed issues with me
Received clarified, prioritized tickets via Linear
Worked dependencies and data-layer tickets against shared priorities
Validated fixes before customer-facing confirmation
First to hear from schools; fed issues into the product team
Coordinated on roadmap context for school messaging
Engaged when a ticket required design input
Active customers depending on both products
Two functioning products schools depended on every day.
Schoolable and Dolittle were already live when I joined — not a rebuild, but keeping a system schools relied on daily running smoothly as issues surfaced.
Schools depended on the platform for daily operations
Feature-level issues still occurred via ticket assignments
Product owners understood their assigned domains
My role connected customer reports, product context and engineering
Speed mattered — a small feature failure could interrupt a school's day
From school report to confirmed resolution.
Product owners gathered and investigated escalations before bringing them to me. I reviewed impact, clarified workflows, and looped developers in when it mattered.
I frequently joined calls with product owners and developers to build shared understanding before work began. I operated and coordinated this flow — I didn't invent it.
Some urgent feature issues could be triaged and assigned within minutes because product owners, developers and customer-facing teams remained closely connected. Not every problem moved that fast.
How I decided what mattered first.
This is a reconstruction of the principles I used to prioritize, not a documented proprietary Schoolable formula.
A weekly rhythm across every function.
Communication ran through WhatsApp and video calls, with Google Docs for documentation — the cadence held the team together between touchpoints.
Working inside a ticket-driven engineering model.
Developers worked on a ticket-based compensation model, so clear tickets directly affected delivery. I stayed close to execution, connected developers with the right product owners, and balanced urgency against feasibility.
Working inside a ticket-driven engineering environment strengthened my understanding of APIs, dependencies, and the language developers use to explain technical constraints.
Schoolable: school management and financial operations.
I oversaw the operating health of the full Schoolable product. I didn't create the platform — my responsibility was keeping it reliable for schools running on it.
Dolittle: connected student payments and school access.
Dolittle was a connected student payment and school-access product within Schoolable's ecosystem. I did not invent or design it — I maintained its operating health alongside the core platform.
Dolittle was the product name used during my 2023 engagement.
What I owned, and what already existed.
Credibility here depends on this distinction. I ran the operation — I didn't originate the products or their architecture.
What I owned
Product priorities
Cross-functional coordination
Product-owner alignment
Engineering clarification
Weekly planning and reviews
Roadmap discussions
Executive reporting
Operational continuity across both products
What already existed
Schoolable's original product concept
Dolittle's original product concept
Core software architecture
Existing ticket and escalation processes
Existing school relationships
Existing product-owner structure
Trusted to lead delivery for a Café One merchant-payment project.
During my Schoolable engagement, I was entrusted with an additional Project Manager assignment for a merchant-payment solution connected to Café One, Sterling Bank's coworking and digital-experience environment.
I coordinated the designer, developers and internal QA contributors, aligned delivery reviews with Sterling Bank stakeholders, and kept requirements, implementation and testing preparation moving across both teams.
Development completed and handed over for client QA.
After development and internal delivery preparation, the project was handed over to Sterling Bank's QA team for independent review and testing. My documented responsibility ends at that handover stage; no public launch or post-QA outcome is claimed in this case study.
What I managed
The assignment expanded my responsibility beyond Schoolable's core products and demonstrated the organisation's trust in my ability to coordinate delivery involving an external enterprise stakeholder.
This was an additional Project Manager assignment during my three-month Schoolable contract. I coordinated delivery through development completion and handover to Sterling Bank QA; I did not own Café One's wider strategy, Sterling Bank's payment infrastructure or the bank's internal QA process.
What I maintained during the contract.
The result was continuity: schools retained a dependable escalation path, teams kept a shared rhythm, and the CEO maintained visibility without returning to daily product management. These are operational outcomes, not quantified metrics.
Coordination Continued
Day-to-day coordination continued through the CEO's reduced role.
Clear Issue Path
School issues had a clear path from support to product and engineering.
Product Owners Aligned
Four product owners remained aligned across their domains.
Engineering Coordinated
Engineering priorities were coordinated against school impact.
QA in the Loop
QA remained part of the delivery loop for assigned product work.
Executive Visibility
Weekly reporting maintained executive visibility.
A responsible handover at contract's end.
At the end of the planned three-month contract, I handed operational ownership back with established team rhythms intact, current documentation and weekly reporting records.
Operating Cadence
Weekly planning, reviews and retros running on schedule.
Product Documentation
Current documentation handed back in Google Docs.
Weekly Reports
A complete record of weekly reporting to the CEO.
Roadmap Context
Current roadmap context for continuity.
Known Issue Visibility
Open issues and status made visible, not hidden.
Team Coordination
Product owners, engineering and QA left aligned.
Stewardship, not reinvention.
This engagement wasn't about transforming Schoolable — it was about holding a multi-product operation steady so its CEO could focus elsewhere with confidence. Interim stewardship means knowing what to preserve, unblock, and when to step back.
Discuss a product leadership role?
Book a 20-min intro call, or send the role details by email.
