If you have ever pitched a business idea to a Nigerian uncle at a family function, you know the drill. Before you finish explaining, he has already asked "but who go pay for am?" That question, asked half jokingly over jollof rice and small chops, is the same question that sits at the centre of every product decision I make at Abango. Not "is this a good idea." Plenty ideas are good on paper. The real question is whether this is the idea worth building right now, with the time and money we actually have.
Everybody has a request. Not every request is a roadmap.
When we start working with a client, the list of "must haves" usually reads like an owambe menu, a bit of everything, because why not. Dashboard here, chatbot there, loyalty points, referral system, dark mode, five different payment options, all wanted for the first release. It is understandable. Founders are excited, and everybody is scared of leaving something out. But you cannot cook rice, swallow, small chops, and a whole cow for one small pot. Something will burn, and usually it is the thing that mattered most.
My job as a product manager is to sit with that long list and ask the unglamorous questions. Which of these features actually moves the business forward in the next three months? Which ones are we adding because a competitor has them, not because our users are asking? Which one, if we cut it today, nobody will even notice for six months? That sorting exercise is not fun, and it is rarely popular in the first meeting. But it is the difference between a product that launches on time and one that is still "almost ready" a year later.
We build the '001' version first, not the final masterpiece
In Nigerian street fashion, before the designer makes the full custom outfit, they cut a sample cloth first, the '001', to check the fit before committing the good fabric. That is exactly how we approach product development. We do not try to build the fully loaded, everything and the kitchen sink version on day one. We identify the smallest version of the product that still solves the core problem, ship it, and watch what real users actually do with it.
This matters more than people think, especially for Nigerian and African products. Our users are not shy about telling you the truth. Drop a half baked app on the Play Store and the reviews will read you your rights within 48 hours, in language your pastor would not approve of. That brutal honesty is actually a gift. It tells us quickly whether we built the right thing, long before we have spent months polishing a feature nobody wanted.
"Better a small correct thing that works than a big grand thing that is still 'coming soon' after a year."
Prioritisation is not favouritism, it is arithmetic
One thing I have learned working with founders across fintech, logistics, and consumer apps: prioritisation feels personal, but it should never be. We score every proposed feature against three simple things: how many users does this actually affect, how much value does it unlock for the business, and how much engineering effort will it cost us. A feature that excites the founder but touches five users and takes six weeks to build almost always loses to a boring feature that touches every single user and takes three days.
It is a bit like planning transport in Lagos. You do not send one danfo bus down a road with two passengers when the main route has a hundred people waiting. You put your resources where the traffic actually is. That is not favouritism to the popular route, it is just respecting where the demand lives.
Talking to users like they are people, not data points
The best product research I have ever done did not come from a survey tool. It came from sitting beside a market woman in Alaba as she tried to top up her data bundle on a client's app, watching her thumb hesitate over a confusing button, watching her mutter under her breath and almost give up. No analytics dashboard tells you that story as clearly as watching it happen in real time. So we make time for it: user interviews, screen recordings, WhatsApp voice notes from beta testers, even just reading through app store reviews line by line, because our people will tell you exactly what is wrong, and usually with better comic timing than any focus group.
Saying 'not yet' without saying 'never'
The hardest part of this job is telling a client, kindly but firmly, that a feature they love is not going in the first release. Nobody wants to hear no. So we never really say no, we say "not yet, and here is why, and here is when." We show the roadmap, we show the reasoning, and more often than not, once a client sees the plan laid out honestly, they relax. They realise we are not cutting corners. We are building the house on a foundation first, before we start arguing about the colour of the gate.
At the end of the day, good product management in this market is not about having the fanciest framework or the longest roadmap document. It is about respecting people's time and money enough to build the right thing, in the right order, and being honest when the plan needs to change. That, more than any template, is what keeps a product, and the team behind it, standing after the excitement of launch day has settled down.