Asher's Blog

Customers usually describe a problem through the moment at which it became visible to them. They say a report is difficult to download, a payment is late, onboarding takes too long, the price is too high or the product needs another feature. These complaints are useful because they tell us where the customer is experiencing friction, but they do not always tell us what the company should fix.

The complaint is often a symptom. The real problem may sit several layers beneath it, and a company that responds only to the words used by the customer can spend months improving the wrong thing.

When a customer says, “Your report is difficult to download,” the obvious response is to make the download button more visible. That may be helpful, but the deeper question is why the customer needs the report in the first place. Perhaps the customer is downloading it because the information inside the product cannot be shared with management, because the dashboard does not answer an important question or because the data must be manually reconciled with another system. Improving the button solves the complaint while leaving the job unchanged.

The discipline of product building is therefore not merely listening to customers. It is learning how to interpret what they say.

Customers speak from experience, not from diagnosis

Customers are experts in their own frustration, but they are not always experts in the system producing it. This is not a criticism. A patient can accurately describe pain without knowing its medical cause, and a driver can describe a troubling sound without knowing which part of the engine has failed. In the same way, a customer can tell you exactly where work became difficult without being able to identify the design, process or policy that created the difficulty.

Founders sometimes ask customers what feature they want and then treat the answer as a product specification. This feels customer-centred, but it can become a way of transferring product judgment to the person who has the least visibility into the whole system. Different customers will propose different solutions to the same underlying problem, and implementing every request can produce a complicated product that still does not resolve the original need.

The better approach is to listen carefully, then investigate the circumstances surrounding the complaint. What was the customer trying to accomplish? What happened immediately before the problem? What did they do next? How often does this occur? What does the failure cost them? What workaround have they created, and why does that workaround feel safer or faster than using the product as intended?

These questions move the conversation from a requested feature towards the outcome the customer is pursuing.

Follow the workaround

One of the clearest clues to the problem behind the problem is the customer’s workaround. When people repeatedly export data into Excel, send screenshots over WhatsApp, maintain a parallel notebook or ask one employee to check every transaction manually, they are showing you where the product has failed to earn their confidence.

The workaround may initially appear inefficient, but it often contains important information. A customer may prefer a spreadsheet because it provides flexibility, visibility and a sense of control that the software has removed. If the company responds by merely telling the customer to stop using spreadsheets, it misses the point. The real task is to understand which qualities of the spreadsheet the customer is unwilling to lose, then reproduce those benefits inside a safer and more structured system.

This is particularly important in African business markets where formal software frequently meets long-established manual processes. A founder may assume that customers resist technology because they are unsophisticated, when the actual problem is that the new product asks them to surrender a method they understand without giving them equivalent confidence. Adoption will not improve through education alone if the product does not address that loss of control.

Observe what customers do after your product disappoints them. The improvised process they create may contain the specification for what you should build next.

Ask what the complaint threatens

A useful way to find the deeper problem is to ask what the customer believes is at risk. The practical issue may be small, while the perceived consequence is enormous.

An employer complaining about a delayed payroll report may actually be worried about paying employees incorrectly and losing their trust. A finance manager asking for another approval layer may not want more bureaucracy; they may fear being held responsible for an unauthorised transaction. A customer who repeatedly asks whether funds are safe is not requesting another status message. They are asking whether your company is worthy of carrying an important responsibility.

Once the threatened outcome is understood, the product team can consider a wider range of solutions. The answer may involve product design, communication, operational controls, service guarantees or training rather than the feature initially requested.

This is also why emotional language should not be dismissed as irrational. When a customer says a process is stressful, the stress itself is information. It may reveal uncertainty, lack of visibility, fear of consequences or a previous experience of being disappointed. A company that solves the functional task while ignoring that emotional burden may still fail to create a product the customer trusts.

The first “why” is rarely enough

Teams often say they are performing root-cause analysis when they have only renamed the symptom. A payment failed because a provider returned an error. Why did that error stop the transaction? Why was there no alternative route? Why was the company unaware until the customer complained? Why could the support team not explain what happened? Why had the same failure appeared before without producing a permanent fix?

Each question moves the organisation away from the immediate incident and towards the design of the system. The payment provider’s error may be outside the company’s control, but the decision to depend on one route, the absence of monitoring and the weakness of the escalation process belong to the company.

The purpose of repeatedly asking why is not to create an endless philosophical discussion. It is to reach the level at which the organisation can make a change that reduces the probability or effect of recurrence. If the proposed fix addresses only the final visible event, the team should ask whether the same underlying weakness could create a different failure tomorrow.

Separate the person from the system

When a problem becomes visible through an employee, leaders may conclude that the employee is the problem. Sometimes an individual has genuinely performed poorly, but replacing the person without examining the system can conceal the deeper issue.

If several competent employees make the same mistake, the process may be confusing. If one department regularly delays another, the incentives or dependencies may be poorly designed. If customer complaints disappear inside support tickets, the problem may be that nobody owns the outcome from beginning to end. A system that depends on exceptional memory and constant heroics will eventually disappoint customers, regardless of how talented its people are.

Good diagnosis asks what conditions made the mistake likely. Were responsibilities clear? Did the employee have the necessary information and authority? Was the expected standard measurable? Did the system warn anyone before the problem became serious? Would another reasonable person in the same situation have produced a similar result?

The objective is not to remove accountability. It is to ensure that accountability produces improvement rather than a convenient person to blame.

Do not let the loudest customer define the whole product

Not every complaint represents a widespread or important problem. Some requests reflect one customer’s peculiar workflow, and implementing them may make the product worse for everyone else. The company therefore needs to combine depth with pattern recognition.

After understanding the problem behind one complaint, ask how many other customers experience the same underlying difficulty. The words may differ while the need is identical. One customer asks for a downloadable report, another asks for an executive dashboard, and a third asks for weekly emails. Beneath all three requests may be the same problem: decision-makers cannot see the information they need at the right time.

This is why support conversations should feed into product thinking. Complaints should be categorised by underlying job, consequence and frequency rather than stored only as isolated tickets. Over time, patterns become visible, and the company can distinguish an edge case from a structural weakness.

Urgency also matters. A problem affecting a small number of customers may deserve immediate attention if it threatens money, security, compliance or trust. A highly requested cosmetic improvement may remain less important. Product judgment requires evaluating frequency, severity and strategic relevance together.

Define what solved means

Teams sometimes declare a problem solved when code has been deployed or a support ticket has been closed. Those are activities, not proof that the customer’s problem has disappeared.

If customers complained that onboarding was too slow, success is not the release of a redesigned form. Success is a measurable reduction in the time required to become operational, with fewer customers abandoning the process or asking for help. If customers said payroll was stressful, success is not merely another automation feature. It is greater accuracy, fewer last-minute escalations and stronger confidence that employees will be paid as expected.

The definition of solved should therefore be written before the team chooses a solution. It should describe the change in customer behaviour or outcome that will demonstrate improvement. Without that definition, teams can complete substantial work and still disagree about whether anything became better.

After releasing the fix, return to the customer. Observe the process again and check whether the workaround has disappeared. Sometimes the original complaint stops while the customer develops a new workaround around the new design. That is evidence that the deeper need remains unresolved.

Solve the need, not merely the sentence

Listening to customers is essential, but listening is not passive obedience. It requires curiosity, interpretation and the humility to test whether your first understanding is correct. The customer gives you the evidence of pain; the company must perform the work of diagnosis.

The complaint is where the investigation begins. Follow the customer’s behaviour, identify what is threatened, examine the workaround, ask why the system produced the outcome and define what will be observably different when the problem is solved.

When companies skip that work, they accumulate features around unresolved needs. The product becomes larger without becoming more useful, and customers keep discovering new ways to express the same frustration.

The most valuable builders learn to hear more than the sentence being spoken. They recognise that behind “I need another report” may be “I do not have enough visibility to make a safe decision,” and behind “your product is too expensive” may be “I cannot yet see enough value to justify changing my behaviour.”

The customer’s complaint matters. It is simply not always the thing to fix. The real opportunity lies one layer deeper, in the problem that caused the complaint to exist.