Understanding Your Users

Why Bother With Research?

It is tempting to build whatever the loudest customer, the CEO, or your own gut tells you to build. Some of those ideas will work. Many will not, and you will not find out until months of engineering time have been spent. User research is how a PM replaces guessing with evidence before committing a team's time.

Research does not mean endless studying before anything ships. It means asking: do we actually understand the problem, for real people, before we solve it? A PM at Paystack investigating why merchants abandon signup, or a PM at Spotify investigating why free users never convert, is doing the same job: finding out what is true, not what is assumed.

---

What Good Research Buys You

• Fewer wasted builds. It is far cheaper to discover a flawed idea in a conversation than after three months of engineering.
• Sharper prioritisation. When you know which problems hurt the most users, the backlog argument mostly settles itself.
• Trust with your team. "Twelve of fifteen merchants we interviewed said the same thing" is far more convincing than "I think users want this."
• Better solutions. Research often reveals the real problem is different from the one you assumed. Airbnb's early growth did not come from a better booking form — it came from realising that bad listing photos were killing trust.

---

Qualitative vs Quantitative Research

PMs use two broad types of research, and the best PMs use both together.

Neither replaces the other. Quantitative data from Flutterwave's dashboard might show that checkout conversion drops sharply on step 3. That tells you where the problem is. Qualitative interviews with five merchants would tell you why: perhaps the OTP field is confusing, or the page times out on slow networks common outside major cities.

---

The Trap of Research Bias

Research is only useful if it reflects reality, not what you hoped to hear. Watch for these common biases:

• Confirmation bias. Only noticing feedback that supports the feature you already wanted to build.
• Leading questions. Asking "Don't you think a dark mode would be great?" instead of "How do you feel about the current appearance of the app?" The first plants the answer.
• Sampling bias. Only talking to your most engaged power users (or, conversely, only to people who complained loudly on Twitter/X) rather than a representative mix.
• Recency bias. Overweighting the last conversation you had, especially if it was memorable, rather than the pattern across many conversations.
• The "vocal minority" trap. A handful of angry App Store reviews can feel like a crisis, but may represent a tiny fraction of your user base compared to millions of silent, satisfied users.

A useful discipline: before you interview anyone, write down what you expect to hear. Then compare it honestly to what you actually heard.

---

A Nigerian Example

Consider a team at a Nigerian challenger bank (similar to Access Bank's digital arm) noticing that many customers stop halfway through opening a savings account. The quantitative data (analytics) shows the drop-off happens at the BVN verification step. Qualitative interviews reveal why: several customers are on 3G networks and the verification step times out silently, with no error message telling them what went wrong. Without both types of research, the team might have wrongly assumed customers were simply not interested in savings products, when the real problem was a confusing, network-dependent error state.

---

Building the Habit

Great PMs treat research as a continuous habit, not a one-off project before a big launch. A few interviews a month, a recurring look at support tickets, and a standing dashboard of key metrics keep a PM close to reality. The goal is never to prove yourself right — it is to find out what is actually true, even when that is uncomfortable.