Building what matters: Why founders should validate problems before building solutions

By Omoruyi “Uyilaw” Edoigiawerie, Esq
A sizeable chunk of startups in Nigeria are dying, not because the founders lacked talent, funding, or grit, but because they built something no one truly needed.
It begins innocently: a spark of brilliance during a late-night conversation, a catchy app name, a “disruptive” solution to an assumed but not confirmed problem. Within weeks, domains are bought, designs are commissioned, and developers are hired.
The MVP is launched. But then, silence. Users don’t come. The metrics flatline. The idea, once full of promise, sinks into irrelevance. This is not rare. It is the dominant story in Nigeria’s startup ecosystem. And at the heart of it is a single fatal mistake: skipping the hard work of validating the problem.
In Nigeria, where infrastructure is inconsistent, regulation is unpredictable, and user behaviour is complex, leaping from idea to MVP without evidence is not bold; it’s reckless. Too many founders are solving imagined problems. And too few are willing to let go of ideas they love, even when reality shows no one else does.
We need to stop falling in love with our solutions and start falling in love with the problems. Because until Nigerian founders master the art of rigorous problem validation, we will keep building beautiful products… that no one needs.
*The Nigerian problem validation problem
In developed markets, founders can sometimes avoid rigorous problem validation. A mature infrastructure and homogeneous user behaviour make some assumptions more likely to hold. Not so in Nigeria.
Here, users do not behave uniformly. What works in Lagos might flop in Kano. What feels “urgent” in Lekki is completely irrelevant in Aba. Payment APIs break mid-transaction. Delivery timelines are suggestions. Electricity is often a privilege. Trust in digital platforms is hard-earned. All of this should make the average founder more cautious and insistent on understanding the actual, lived problem before even sketching a product. But too often, we see the reverse.
Instead of validating the problem, many founders validate the solution they already love. They launch MVPs with hope, not data. They gather feedback not to learn but to confirm. They invest months of design and development into products that answer questions no one is asking. We are building solutions in search of problems, and it’s bleeding us dry.
*Why we fall in love with the wrong ideas
There is a psychological trap here. Founders are typically smart, driven, and imaginative. They believe they can build their way through anything. But imagination can deceive. A slick idea is emotionally intoxicating. It feels revolutionary. You can see the interface, the logo, and the media headline. But that imagined success is rarely grounded in a clear, specific, validated pain point.
In Nigeria, this problem is made worse by our hustle culture. Everyone wants to be seen building. Sitting with uncertainty, “Is this really a problem?” feels like delay, and no founder wants to seem idle. So, we build, we ship, we launch. But what we launch often misses the mark because we never took the time to understand our users’ actual problems.
*MVPS are not cheap in Nigeria
Let’s bust a myth: MVPs are not “cheap” in Nigeria. Every MVP in our context is a high-cost experiment. Data is expensive. Users are sceptical. Dev talent is scarce. Infrastructure is unreliable. Payments are fragile. Marketing budgets stretch thin. Building and launching even the simplest product version takes months of sweat, favours, and borrowed money.
So, when we say, “Just ship and iterate,” we ignore the Nigerian reality. In many cases, founders are burning their only shot. They don’t have the luxury of failing fast. That MVP needs to land, and the only way to make sure it lands is to start from a problem that has been deeply validated.
*What does problem validation mean?
Let’s be clear: Validation is not a survey. It’s not a Google Form filled by friends. It’s not X followers saying, “We would use this.” Real problem validation means:
• Talking to real users in the real context where the problem occurs.
• Observing behaviours, not just listening to opinions.
• Understanding how users currently solve the problem (even with pen and paper).
• Identifying whether they are actively looking for better solutions.
• Understanding whether and how much they will pay to solve it.
If you cannot point to actual users who feel real pain, are willing to spend effort or money to fix it, and are currently hacking together solutions in their own way, you may not have a real problem yet. Without a real problem, your MVP is just a passion project.
*Killing your idea: A founder’s superpower
The hardest thing a founder must learn is to kill their ideas. Not every idea is worth building, not every passion is a business, and not every cool concept deserves a prototype.
But most Nigerian founders cling to their first idea like a first love. They invest months in building, branding, and marketing, even when all the signs say, “Nobody wants this.” By the time reality hits, they have spent their savings, and team morale is gone.
Great founders know how to walk away from an idea they love. They are ruthlessly committed to solving a problem, not pushing a solution. They would rather spend 3 months validating than six months building the wrong thing.
*How to validate before you build
Let’s talk practically. How can founders validate effectively before writing a single line of code?
1. Map the problem landscape.
Start with a broad space, for example. logistics, education, and finance. Then narrow down to specific pain points you have observed or experienced.
2. Interview real users offline.
Talk to the actual people experiencing the problem. Don’t bias them by talking about your idea. Just ask: What’s hard about X? How do you solve it? What frustrates you about it?
3. Find people hacking the problem.
If people create spreadsheets, WhatsApp groups, or manual workarounds to manage a process, that’s a strong signal. It means the problem is real and urgent.
4. Understand willingness to pay.
Ask users what they currently spend or would spend to solve this problem. This will tell you if there’s a business here, not just interest.
5. Build only after problem clarity.
Don’t build because you “feel ready.” Build only after you can write a one-sentence problem statement that your target users agree with, without prompting.
*Funders and incubators must also raise the bar
It’s not just founders. Accelerators, VCs, and startup mentors in Nigeria must also stop enabling poor validation. Too many pitch days reward flashy decks and cool tech over a gritty understanding of user problems. Too many incubators accept startups without traction because they were built before talking to users.
We must raise the bar. Ask: Who did you speak to? What do they do now? What would they pay? Why now? These are the questions that uncover real businesses.
*Conclusion: Build what matters
The Nigerian startup ecosystem stands at a defining crossroads. Capital is harder to access, users are less forgiving, and teams can no longer afford to build on instinct alone. In this new reality, only one kind of idea survives: the kind rooted in real, painful, validated problems.
To every founder: You may need to kill the idea that excites you, in service of the one that serves people. You may need to listen longer, observe deeper, and resist the urge to build until you understand what truly needs fixing. That’s not hesitation, it is wisdom. That’s not a delay, it is a strategy. Because in this new era, the goal is no longer just building. The goal is to build what matters and leave everything else behind.
*Omoruyi Uyilaw Edoigiawerie is a leading startup lawyer and policy advisor at the intersection of law, technology, and equity in emerging markets. He is the Founder and Chief Servant at EandC Legal, a full-service law firm offering bespoke legal services focusing on startups, established businesses, and upscale private clients in Nigeria. The content of this article provides a general guide to the subject matter. Specialist advice should be sought about your specific circumstances. To get in touch, please email



