Too many startups build products based on assumptions, not evidence.
Founders brainstorm features, developers execute, and months later the product launches with low adoption. Not because it was poorly built, but because it was never needed.
In markets like Nigeria, where users are highly practical and cost-sensitive, this mistake is expensive.
01. Start with the problem, not the feature
Most founders skip straight to the solution. Before you define what you're building, obsess over the problem.
Ask yourself:
- Who exactly has this problem?
- How often do they face it?
- What are they doing right now to solve it, even if the workaround is clunky?
- What does it cost them in time, money, or frustration?
If you can't answer these questions with specifics, you don't understand the problem well enough to build the solution.
02. Talk to real people before you design anything
Not your co-founder. Not your developer. Not your cousin who said, "This is a great idea." Talk to the actual people who are supposed to have this problem.
The goal of these conversations is not to pitch your idea, but to understand their reality. Ask about their current workflow, their frustrations, and how much they've tried to fix it. Listen more than you talk.
Set a Goal:
Speak to at least 10–15 people in your target segment before treating any idea as validated.
If you finish 10 interviews and everyone "loves the idea" but nobody describes the pain unprompted, the idea may not be solving a real problem. Enthusiasm for ideas is cheap. Pain is real.
03. Define your riskiest assumption. Then test it first
Every product idea rests on assumptions. The mistake is treating all assumptions equally. One assumption, if wrong, kills the entire product. That's your riskiest assumption, and it should be the first thing you test.
Examples of riskiest assumptions:
- "Merchants in Lagos will pay a monthly subscription for inventory software."
- "Users will trust a digital wallet they've never heard of with their money."
- "Logistics agents will update job statuses on a mobile app in real time."
How to identify yours:
Ask "If this turns out to be false, does the whole business collapse?" If yes, test it first.
04. Build a landing page first, Not a Product
One of the fastest ways to validate demand is to describe the product as if it exists, put it in front of people, and see if they try to sign up, pay, or engage.
A landing page can be live in a day. It should explain what the product does, who it's for, what problem it solves, and include a call to action. Be it a waitlist signup, a pre-order, or a "request access" button.
What to measure:
- Click-through rate on your CTA
- Conversion rate from visitor to sign-up
- Time spent on the page
- Messages or questions from curious visitors
05. Use fake door tests to validate specific features
A fake door test shows users a button or option for a feature that doesn't exist yet, and measures how many people try to click it. When they do, they see a message like "Coming soon, Please join the waitlist."
This gives you real behavioural data, not just survey responses. People saying they want a feature and people actually clicking on it are two very different signals.
Where to run this:
- Inside an existing MVP or prototype
- On a landing page with multiple feature descriptions
- In a simple Notion page or interactive mockup shared in community groups
06. Validate willingness to pay, not just willingness to use
Usage and payment are two different things. African markets in particular have a pattern of high engagement with free products and sharp drop-off at the point of monetisation. Know this early.
Before you build a paid feature, test whether your target user will actually pay for it, even symbolically.
Ways to test payment willingness:
- Offer early access at a discounted price (pre-sell before building)
- Ask users to pay a small deposit to join a beta group
- Run a "Founder's Plan" with a limited number of slots and a one-time fee
If nobody is willing to pay anything before the product is fully built, that's a critical signal — not a reason to panic, but a reason to investigate.
07. Score your validation before you develop
Before moving to development, give your idea a validation score. This forces honest reflection and prevents founders from rushing into build mode on weak signals.
A simple validation scorecard:
- 10+ problem interviews completed ✅ / ❌
- Riskiest assumption identified and tested ✅ / ❌
- Landing page live with measurable CTA ✅ / ❌
- 50+ waitlist signups or early interest ✅ / ❌
- At least 1 person has paid or committed to pay ✅ / ❌
- Fake door test run on key feature ✅ / ❌
And if you have fewer than 4 checkmarks, you are not ready to build. Go back and gather more signal.
