Asher's Blog

Most companies build for the customer they hope to acquire, but some of the most valuable product improvements come from building for the customer they have already disappointed.

That customer has experienced something your product demonstrations, internal tests and normal operating reports may never have revealed. Perhaps a payment failed at an unusual time, a report contained an error that affected only one type of account, or a support process that normally works became confusing when two exceptional conditions occurred together. The incident may affect less than one per cent of customers, but it has exposed a weakness that could eventually affect many more.

It is natural for a company to describe such an incident as an edge case and move on. From the company’s perspective, the system may still have a success rate above 99 per cent. From the affected customer’s perspective, however, the failure rate was 100 per cent at the moment they needed the product. Both statements may be mathematically compatible, but only one reflects the customer’s experience.

This is why a disappointed customer should not be treated merely as a complaint to be closed. The customer has shown the company something it did not know about itself.

The complaint is part of the product research

When a customer reports a serious failure, the first responsibility is to solve the immediate problem. The next responsibility is to understand why the product, process or support system allowed it to happen. A response that ends with an apology may calm the conversation without improving the company.

The team should ask what conditions produced the failure, why the system did not detect it earlier and whether another customer could encounter the same problem. It should also examine the entire experience surrounding the incident. Sometimes the original technical failure is small, but delayed communication, repeated explanations and unclear ownership turn it into a much larger disappointment.

This is one reason founders and product leaders should remain close to customer-service teams. Dashboards are useful, but they organise experience into categories and averages. Customer-service conversations reveal the language people use when the product has disrupted something important in their lives or businesses. The emotional intensity of a complaint can show you which parts of your product carry more consequence than your internal prioritisation reflects.

A complaint from an important customer deserves particular attention, not because smaller customers are unimportant, but because your most committed users often understand the product deeply enough to reveal where its promise and its performance have separated. If the people who rely on the product most are becoming disappointed, the company may be damaging the very relationship that proves it has created lasting value.

Thank the customer for revealing the weakness

A customer who reports an edge case has contributed to the improvement of the product, even when the conversation is uncomfortable. The company should acknowledge that contribution honestly.

This does not mean sending a generic message that says, “Thank you for your feedback,” while nothing changes. It means explaining that the incident revealed a weakness, accepting responsibility for the part the company played and telling the customer what will happen next. Where the failure has caused meaningful inconvenience or cost, the company should consider an appropriate remedy, which may include a refund, service credit, free period or another form of compensation.

The purpose of a remedy is not to purchase the customer’s silence. It is to recognise that the company failed to deliver what the customer reasonably expected and that the customer spent time and energy helping the company diagnose the problem. The response should be proportionate to the harm rather than designed merely to protect a retention metric.

After the correction has been implemented, the company should return to the customer and explain what changed. That final step is often missing. Teams fix a problem internally but never tell the person whose experience caused the work to begin. Closing the loop allows the customer to see that speaking up produced an outcome, and it gives the company an opportunity to test whether the solution addresses the real issue.

Winning the customer back is not guaranteed

Even an excellent recovery does not entitle a company to the customer’s return. Some disappointments occur at moments that are too consequential, and some customers will decide that they no longer want to take the risk. The company should still repair the problem because the purpose of learning is larger than saving one account.

There are also customers whose confidence can be restored, but not through persuasion alone. If the product failed during payroll, for example, another presentation about its reliability will not be as convincing as several months of demonstrably reliable performance. The company may need to offer additional monitoring, clearer escalation contacts or a controlled way for the customer to begin using the service again.

Trust cannot be argued back into existence. The customer must experience enough evidence to decide that the company has changed.

This makes the disappointed customer one of the most demanding people to build for, but also one of the most useful. A new customer evaluates the promise. A disappointed customer evaluates the difference between the promise and reality. If the company can close that difference without creating unnecessary complexity for everyone else, the entire product becomes stronger.

Edge cases become important as the company grows

At a small scale, a one-per-cent failure may affect only a few people. At a much larger scale, the same percentage can represent thousands of disrupted transactions, delayed payments or damaged relationships. Growth does not make edge cases disappear; it turns rare conditions into recurring events.

The right response is not to build an elaborate feature for every unusual request. Some complaints reflect individual preferences rather than weaknesses in the core product. The company still needs judgement. It should ask whether the incident threatens money, data, compliance, safety, business continuity or an essential customer promise. Problems in those categories deserve attention even when the number of affected customers is small, because the severity of the failure matters alongside its frequency.

This is how customer service becomes part of product strategy. The support team identifies recurring frustration, product and engineering investigate the system, operations examine the process, and leadership decides which risks cannot be allowed to remain. The customer’s disappointment travels through the company until it becomes a better feature, control or standard.

Build the product that would have prevented the disappointment

Every company will disappoint a customer eventually. The real test is whether the disappointment becomes an isolated apology or the beginning of a better product.

Go close to the people handling complaints. Ask which customers had to contact the company repeatedly, which problems created the greatest anxiety and which failures the team solved manually without addressing at the source. Look beyond the number of complaints and examine their consequences.

Then build for the customer whose experience revealed the truth. Fix the immediate issue, compensate fairly where appropriate, improve the underlying system and return to explain what changed. The customer may come back or may still decide to leave, but the company should not waste the lesson.

The customer you disappointed may be the person who shows you what your product needs to become before everyone else discovers the same weakness.