Assistant
Ask Favour's Assistant
👋 Hi there, I'm Favour's AI assistant.

Ask me anything about Favour, her experience, services, projects, or capabilities.
Case STUDY

Sepow Employee Assessment Platform — Delivering a Complex B2B MVP in 6 Months Without Losing Scope

sprint planning
QA oversight
MVP scope definition
launch preparation
Requirements gathering
stakeholder communication
cross-functional coordination

My Role

Project Manager

Duration

6 Months

Tools

MS Project, Jira, Figma, Stripe API, Agile PM Framework

Industry

B2B SaaS

The problem

Overview

Six months from idea to live product is not a comfortable timeline for a B2B platform. It is the kind of timeline where one misaligned sprint, one unresolved dependency, or one scope conversation that never happened can push a launch by weeks. Sepow had all the ingredients for that outcome: payment integration, automated scoring logic, an admin dashboard, and a QA requirement rigorous enough to meet enterprise client standards, all running in parallel across a team that had never worked together before.

 

The hardest constraint was not the deadline. It was that the deadline was non-negotiable. First-mover advantage in Sepow’s market segment was the entire strategic rationale for building fast. Slipping the launch date was not a project management failure. It was a business failure. Every decision I made from week one was made with that in mind.

The solution

My Approach

Foundation and Planning

Before a single design frame was opened, I ran requirements gathering with the founder and mapped every feature against the MVP boundary. The question I kept asking was: does this need to ship in August, or does it need to exist eventually? Anything in the second category came out of scope. I documented every decision in a project charter and built a risk register before the first sprint started.

Design and Architecture

I coordinated UI/UX design in parallel with technical architecture review so neither was waiting on the other. My role here was dependency management: making sure design output was actionable before architecture was finalised, and flagging any direction that would create technical debt we could not afford on this timeline.

Development and Integration

Sprint planning ran on a two-week cadence with daily standups. I tracked velocity weekly against the Gantt baseline and flagged slipping sprints before they actually slipped. Payment gateway integration and scoring logic were the two highest-risk items. I sequenced them early, built in buffer, and gave QA visibility into both before formal testing began.

Launch Preparation

From Month 5, the team shifted into full QA mode: 200+ test cases, UAT with the founder, admin dashboard sign-off. I ran launch preparation as a separate mini-project with its own checklist and daily check-in, because a severity-1 bug at launch was not just a technical problem. It was a trust problem with the enterprise clients Sepow was already pitching.

Key Design Decisions

Working demo at Month 2 instead of waiting for feature completion

The default approach would have been to keep the product internal until feature-complete. I pushed back. By Month 2, we had enough of the core assessment flow working to prepare a demo for the founder’s investor conversations, even though payment and scoring were still in development. Waiting until Month 5 would have meant missing three months of business development conversations. The demo also created team accountability and surfaced UX issues early, when fixing them was still cheap.

Scope creep on a 6-month build does not arrive as one large request. It arrives as twelve small ones, each sounding reasonable on its own. I introduced a formal change request process after Phase 1: any feature not in the original charter required a written request, a timeline impact assessment, and founder sign-off before it touched the sprint board. Two requests came in during development. Both were deferred to post-launch, protecting roughly three weeks of developer time.

With a cross-functional team across disciplines and time zones, the default would have been weekly full-team review meetings. I replaced them with structured async updates: written summaries, milestone check-ins in the project channel, and Loom walkthroughs for anything needing visual context. Synchronous time was reserved for decisions that genuinely required it. The team spent more time building and the founder had a documented record of every decision made throughout the project.

The Outcome

Sepow launched in August 2025, exactly six months from kickoff. Payment integration live, automated scoring operational, admin dashboard complete, 200+ QA test cases passed with zero severity-1 defects. Enterprise security requirements were met from day one, meaning the product was ready to pitch to corporate clients immediately after launch.

 

The Month 2 demo directly supported investor conversations and early client wins before the product went public. The architecture was built from the start to onboard multiple enterprise clients without re-platforming. Sepow entered its market as the first mover with a product that was ready to sell, not just ready to show.

6 Mos

Speed to Market

0

Severity-1 Defects

100%

Enterprise Compliant

Month 2

Live Investor Demo

Reflection

The change request process worked, but I would introduce it earlier. Two requests still reached informal discussion before the formal process caught them, and managing those conversations cost time I could have protected with clearer governance from day one. What this project sharpened in me is simple: make the rules of engagement explicit before momentum builds, because changing them mid-sprint always costs more than setting them right at the start.

If I returned to this project, I would push for usability testing specifically on the two-sided onboarding flows: the moment where a new user self-selects as a job seeker or recruiter and enters their respective experience for the first time. Over 16 weeks I designed extensively for what happens after that decision, but I validated the onboarding sequence primarily through stakeholder review rather than with real users. The stakes at onboarding are high: a job seeker who misunderstands the CV builder in the first two minutes will not complete it, and a recruiter who can’t find their pipeline on day one will not return. Testing that critical first five minutes with both user types would have either confirmed the current approach or surfaced drop-off points I couldn’t have anticipated from the inside.

What this project built in me was a sharper instinct for two-sided product design: the discipline of asking, for every single screen, which user is looking at this and what do they need to be able to do next.

Have a project that needs owning?

Whether it is a product build, an internal initiative, or a project that has already started and needs rescuing, tell me what is happening. I will tell you honestly how I would approach it.

Favour Ukpabi © 2026 | All rights reserved