Every product framework I learned was designed for a specific context: reliable infrastructure, high smartphone penetration, credit card-holding users, and stable connectivity. Silicon Valley.

Building products in Nigeria โ€” and more broadly in Africa โ€” means rethinking almost every assumption in that model. Some things work brilliantly. Some fail spectacularly. And a few surprises reveal something important about what users actually need, everywhere.

Connectivity is a feature, not a given

In Nigeria, network conditions vary wildly โ€” not just by geography, but by time of day, proximity to a cell tower, and whether NEPA (the electricity company) has been cooperative recently.

What this means in product terms:

  • Offline-first isn't a nice-to-have. It's the baseline. If your product fails on a 2G connection, a significant portion of your users are locked out.
  • Page load time is a trust signal. Users on slow connections have been burned by products that start loading and never finish. They'll back out before you've even said hello.
  • Data cost is real. Some of your users are paying per megabyte. A photo-heavy landing page isn't just slow โ€” it's expensive for them.

The products I've worked on that performed best in low-connectivity conditions had one thing in common: they were designed for constraint first, and then enhanced for speed when bandwidth allowed. Progressive enhancement, not graceful degradation.

Formal vs. informal user journeys

Western product models tend to assume that users interact with products in a linear, formal way: they download an app, create an account, complete an onboarding flow, and use the product as designed.

The reality I've observed is messier and more interesting. Users often:

  • Share accounts between family members or colleagues
  • Complete tasks across multiple devices with no session continuity
  • Work through intermediaries (an agent, a relative with better data access) rather than interacting directly

Designing for this means building in flexibility. Shared accounts need privacy controls. Multi-device journeys need state that persists properly. Intermediary use cases need permission structures that weren't in the original spec.

None of this is exotic. It's just designing for actual behaviour rather than assumed behaviour.

Trust is earned differently

In many Western markets, a polished UI and a recognisable brand are sufficient to earn initial trust. Not here.

In markets where scams are common and institutions have historically let people down, trust is earned through:

  • Human touchpoints: A phone number that someone actually answers. A WhatsApp message that gets a response. The ability to talk to a person before committing.
  • Social proof with specificity: Not "Join 10,000 users!" but "Moses in Kano used this to complete his tax registration in 20 minutes." Real names. Real outcomes.
  • Low-stakes entry points: Give users something valuable before asking for anything. Registration friction at the front of the funnel kills acquisition in low-trust markets.

The highest-performing acquisition we ran for one of our products wasn't a paid ad. It was a referral from a local association, delivered via WhatsApp. Context is everything.

What this means if you're building here

Stop adapting. Start designing.

Adapting means taking a product built for another context and tweaking it. Designing means starting from the actual user โ€” their environment, their constraints, their mental models โ€” and building outward from there.

The frameworks still apply. Discovery, validation, iteration. But the inputs to those frameworks are different, and if you don't know them, you'll keep solving the wrong problems with the wrong solutions.

The market is large, the problems are real, and the users are not waiting for someone to figure this out. They're already building their own workarounds.

Your job is to make something better than the workaround.