My Team Had 5 Weeks to Build a Real Product for Africa. This Is What Happened.
Loladeogundijo7 min read·1 hour ago--
By Ololade Ogundijo
There is a specific moment in every product journey where the energy shifts.
Where the conversations about what you could build become conversations about what you are building. Where the frameworks in your notebook become features in a codebase. Where the personas you wrote stop being fictional characters and start being real people whose lives your product is supposed to change.
I hit that moment in Stage 4.
And nothing — not the research, not the documents, not the presentations — fully prepared me for what it actually felt like.
Let Me Catch You Up
If you have been following this series, you know the story so far.
Stage 1 — I built a full product from scratch as an individual. A collaborative knowledge board for remote teams. I made the top 4. I wrote about it here.
Stage 2 — I went deeper. Post-launch data. Root cause analysis. RICE scoring. Feature proposals. A/B experiment design. I came first. I wrote about that too.
Stage 3 was different from both of them.
Stage 3 gave me a team.
A real cross-functional team, a frontend engineer, a backend engineer, a designer, a growth marketer, and an HR specialist. Six people with six different skills, six different working styles, and six different ideas about what we should build.
My job was to be the PM. To align all of that into one coherent product direction. And then to stand in front of evaluators twice and defend it.
The Product We Decided to Build
After a lot of conversation and some very honest disagreement we landed on GrantBridge.
A direct micro-grant platform connecting small African entrepreneurs with funders who believe in them.
The problem it solves is real and it is massive. There is a $331 billion annual financing gap in African SMEs. Forty million micro and small businesses in Nigeria alone that cannot access formal capital. Entrepreneurs with real skills, real ideas, and real customers waiting, who cannot start because no bank will look at them and no grant portal was built for people like them.
On the other side, there are diaspora professionals, NGOs, and individuals who want to fund grassroots entrepreneurs but have no trusted, transparent, direct platform to do it. The money exists. The talent exists. The infrastructure to connect them does not.
GrantBridge is that infrastructure.
And the more we talked about it, the more we believed in it. Not because it was a nice idea. Because it was a necessary one.
Two Presentations. Two Rounds of Feedback. One Lesson.
We presented twice — a first pitch and a final pitch.
The first presentation taught me something important — there is a big difference between a product that sounds impactful and a product that sounds like a business.
Our first pitch leaned too far into the social good story. The evaluators pushed back immediately. They wanted to understand the commercial opportunity. They wanted to know how large the market really was. They wanted to know why a funder would choose GrantBridge over everything else that already existed.
Fair questions. Hard questions. The kind of questions you cannot answer well unless you have actually done the work.
So we went back and did the work.
We rebuilt the market sizing — TAM, SAM, SOM. We reframed the problem around the commercial opportunity, not just the human story. We sharpened every answer until it was crisp. We added a competitive analysis that showed exactly why no existing platform does what GrantBridge does. We deepened the revenue model from one income stream to six.
The second presentation felt different the moment we started speaking.
The evaluators were engaged differently. The questions shifted from “convince me this is a real problem” to “how do you plan to scale this.” That shift from scepticism to curiosity, is one of the best feelings I have experienced in this programme.
We made it to Stage 4.
Then the Real Work Began
Here is what they do not tell you about product management.
The planning phase feels like the hard part. The research, the frameworks, the documents, the presentations, all of it feels challenging and important and like genuine work.
And it is.
But the moment you move into a build phase with a real team, you realise that the planning phase was actually the easy part.
Because in planning, you control everything. You write the words. You frame the narrative. You decide what goes in and what stays out. Everything is theoretical and therefore everything is perfect.
In building, reality pushes back.
Screens that looked clean in Figma take twice as long to build as expected. APIs that seemed straightforward turn out to have edge cases nobody anticipated. The team’s energy fluctuates — some days everyone is locked in and moving fast, other days the channel goes quiet and you find yourself wondering what is happening and how to change it.
And in the middle of all of this, the PM’s job is to hold everything together. To know the status of every feature. To answer every product question the engineers have. To protect the scope when someone suggests adding something new. To communicate clearly enough that no one is ever confused about what they should be working on.
I am doing all of that right now. In real time. While also helping prepare for our upcoming demo.
It is the most demanding thing I have done in this programme. And honestly — it is also the most exciting.
What GrantBridge Actually Looks Like
Let me tell you what we are building because I think it deserves to be described properly.
An entrepreneur — let us call her Chioma — opens GrantBridge on her phone. She fills in a simple form. Her project name, what her business does, how much she needs, and exactly how she will spend the money. She uploads a photo. It takes her less than five minutes. She hits submit and her project goes into our admin review queue.
Within 48 hours, our admin reviews her submission. If it passes, it goes live. If it does not, she gets feedback and can resubmit.
On the other side, a funder — let us call him Tunde — opens GrantBridge in London. He browses a feed of verified, approved projects. He can filter by category, location, and funding amount. He reads Chioma’s story. He sees exactly how she plans to spend the money — ₦35,000 for a sewing machine, ₦15,000 for starter materials. He funds her project through Flutterwave.
The money moves. Chioma receives it in her bank account within 24 hours.
She posts an update. Tunde gets a notification. He sees a photo of the sewing machine arriving. He sees the first piece she made. He feels the impact of what he did.
And he comes back to fund another project.
That loop — submit, verify, discover, fund, disburse, track, update — is what we are building. Six features. One complete flow. Designed to work end to end before anything else gets added.
The tech stack is React and Next.js on the frontend. Python and Django on the backend. PostgreSQL for the database. Flutterwave for payments. BVN verification to prevent fraud. Railway and Vercel for hosting.
It is a real product. Built with real technology. For real people.
What Leading a Team Has Taught Me
I want to be honest about this part because I think it is the part most PM articles skip.
Leading a cross-functional team is not the same as working hard as an individual contributor. The skills are different. The challenges are different. The moments of satisfaction are different.
As an individual, your output is directly tied to your effort. Work harder, produce more.
As a PM leading a team, your output is tied to other people’s clarity, motivation, and momentum. Your job is not to build — it is to create the conditions in which other people can build well.
That means communicating clearly enough that no one is ever confused. It means protecting people from scope creep so they can focus. It means noticing when the team’s energy is dropping and finding a way to reconnect everyone to the reason the work matters.
It also means trusting people who are better than you at things you do not understand. I cannot write Django APIs. I cannot build React components. I cannot design in Figma. But I can write a product brief that makes all three of those things possible. I can set a scope that makes the build achievable. I can ask the right questions to unblock the people doing the work.
That is the job. And it is a completely different job from what I expected when I started this programme.
The Thing About Building in Africa
GrantBridge is not just a product I am building for a programme. It is a product I genuinely believe should exist.
The financing gap we are addressing is not an abstract statistic. It is the reality for millions of people across Nigeria and across Africa who have everything it takes to build a business except the capital to start. And on the other side, there are millions of diaspora professionals and community members who want to invest in those people but have no trusted way to do it.
That gap between people who want to give and people who deserve to receive is not inevitable. It exists because no one has built the infrastructure to close it in a way that works for this market specifically.
We are building that infrastructure. With a five-person team. In five weeks. On a platform that handles naira, verifies identities through BVN, and disburses funds through Flutterwave.
Is it going to change everything immediately? No.
But every product that eventually changes something started with a team that believed it could. And we believe it.
Where We Are Now
We have a demo coming up.
There are still screens being built and APIs being connected. There are things that are not perfect yet. There are things that will probably never be perfect.
But the product is real. The team is building. And for the first time in this entire programme I am not presenting a plan for something, I am showing something that exists.
That difference between presenting a plan and showing a product is everything.
Stage 4 is not done yet. When it is, I will write about how it ends.
Until then — we build.
