Episode 4: Why 40% of Your 'Product Problems' Are Really Communication Gaps

A low NPS score feels like a verdict. The number drops, customers sound angry, and the obvious conclusion is that something in the product is broken. So the team opens a ticket, schedules a fix, and moves on.

Edward Olayemi thinks that reflex gets research wrong more often than people realize. He heads customer excellence and user research at FairMoney, the Nigerian fintech, where he runs NPS and in-app surveys for an app with around 30 million downloads. On the fourth episode of Research Secrets, he put a number on how often the "product problem" isn't a product problem at all: in his experience, about 40% of the time.

The score tells you something's wrong, not what

A metric is good at flagging that something is wrong, but it won't tell you what. An NPS score can show that a group of customers is unhappy, and the number alone won't explain why. The why is where the actual decision lives.

Edward's warning is that teams stop too early. They collect the quantitative signal, see the dip, and treat the dip as the finding. But the dip is where the investigation starts. Without the qualitative deep dive underneath, you're acting on a symptom and guessing at the cause.

The 40% that aren't product problems

When Edward does dig underneath, he keeps finding the same thing. A large share of complaints aren't about a feature that fails. They're about a customer who didn't understand how the feature works, or didn't know it existed, or expected it to do something it was never built to do.

"40% of the time, it's just a communication gap with customers, not that the product is not working."

Hear Edward explain this in the episode → watch the full conversation.

That reframes the fix entirely. If the product works and the customer is confused, rebuilding it solves nothing. What needs to change is the explanation: the onboarding, the in-app copy, the help article, the message that sets the right expectation. Edward's point is that a lot of research ends with a recommendation to change the product when it should have ended with a recommendation to change the communication.

Make the call before you file the bug

How does he tell the difference? He calls the customer.

When someone leaves a low score and a one-line reason on a survey, Edward doesn't accept the line at face value. He follows up directly to find out what they actually meant, because a short survey answer leaves too much room for assumption. Often the call shows that the product was fine and the customer simply didn't know something. That distinction only comes out in conversation.

This is the step teams skip under time pressure. The survey hands you a tidy reason, the reason sounds plausible, and it's tempting to run with it. But the tidy reason is exactly what Edward distrusts. The follow-up call is what separates a real insight from a confident mistake.

Don't take the answer at face value either

There's a second trap, and it runs the other way. Sometimes the customer's explanation isn't accurate, even when they believe it. Edward describes checking a reported experience against the customer's actual transaction history and finding that the two didn't match. What someone remembers happening and what the logs show aren't always the same story.

So he validates before concluding. On his team, a tricky case doesn't rest on one person's read. He hands it to a second group to investigate independently and confirm whether the assumption holds, and only then does the team advise the product or business unit on what to do. Two levels of checking sounds slow, but it's far cheaper than shipping a fix for a problem that was never real.

The cheapest fix is usually a message

Put these habits together and Edward's argument becomes plain. The team that stops at the score ships product changes to solve communication problems, and sometimes solves problems that don't exist. The team that goes deeper often finds the fix was a sentence all along.

That's the payoff of pairing quantitative with qualitative. The number finds the unhappy customers fast. The conversation tells you whether they need a better product or just a clearer explanation. For a lot of what looks like a roadmap item, the answer is the second one, and the fastest, cheapest thing you can do is say the right thing at the right moment.

Before the next low score turns into an engineering sprint, ask Edward's question first: is this product actually broken, or does the customer just not know how it works?

Edward goes deeper on this, plus autonomous research and the Nigerian market, in the full conversation. Watch the full episode on Research Secrets.

About the guest

Edward Olayemi heads customer excellence and user research at FairMoney. He was the fourth guest on Research Secrets, BlockSurvey's podcast about uncovering real user insights to build better products.