The edge case is where customers decide what your product is
A service can look healthy on every dashboard and still feel unreliable to the customer.
A current report about Odido verwacht belkwaliteit naar andere providers nog dit jaar te verbeteren is the context here. The news is not the point; it makes the operational decision pressure visible.
That is the uncomfortable part of quality: people do not experience your system in the clean, internal version you test most often. They experience the boundary conditions. The call that crosses a network. The login that depends on a third-party identity provider. The payment path that only breaks when the timing is slightly off.
Odido’s own example is telling. The company says call quality between Odido customers is fine, while calls between an Odido SIM and a SIM from another provider are not yet optimal. It expects to improve that before the end of this year.
That is not a telecom footnote. It is a product lesson. Quality is not a feeling, and it is not a slogan in the launch deck. It is a set of conditions, and some conditions are much harder than others.
Internal success can hide external weakness
Most teams optimize for the paths they can see most clearly.
That is rational. Internal traffic is easier to measure. Reproducing a problem between two customers on different networks is harder. The logs are messier, the ownership is shared, and the failure may only show up when your product meets someone else’s system.
But this is exactly why software leaders get surprised.
A platform can be genuinely solid inside its own walls and still disappoint users the moment it leaves them. The product works in the demo, in the staging environment, and in the happy-path test suite. Then the real world adds variance: another carrier, another region, another device class, another timing pattern.
The customer does not care that the problem is “outside your stack.” They only know that their call, checkout, or workflow broke at your edge.
That means the real question is not whether your core system works. It is whether your quality claims survive contact with adjacent systems you do not fully control.
ISO 25010 becomes useful when it stops being abstract
This is where ISO 25010 matters in a practical way.
Not as a compliance artifact. Not as a slide with eight quality characteristics and a nice diagram.
It matters because it forces a more precise conversation: what exactly is broken, under which conditions, and how would we know?
In Odido’s case, the distinction is narrow but important. Calls between Odido subscribers are not the issue. The problem appears when a call crosses provider boundaries. That is a specific failure mode, not a vague complaint about “bad quality.”
That specificity is what software leaders should want in their own systems.
If users say “the app feels slow,” that is not yet useful. If you can narrow it to “the first action after SSO into tenant X adds 4–6 seconds only when the upstream token exchange retries once,” then you have moved from perception to mechanism. You can work on that. You can test it. You can decide whether it is acceptable.
Quality gets real when it is attached to a condition.
Without that, teams end up defending a general feeling while customers are describing a very specific failure.
The hardest bugs live at the boundary you did not build
There is a familiar scene in software leadership.
A product manager walks into the room with a support thread. Engineering says the internal service is healthy. Infrastructure says the network is within normal limits. The vendor says their side looks fine. Everyone is technically correct, and the user still had a broken experience.
That is not a rare edge case. It is the normal shape of modern software.
The more your product depends on external systems, the more your quality becomes distributed. You own part of the experience, but not all of it. The boundary matters more than the core architecture presentation makes it seem.
This is why “works for our users” is too coarse. Which users? Under what conditions? Through which path?
If you only test the obvious path, you will always be late to the problem that customers actually feel. And by the time it becomes visible in support, the damage is already wider than the ticket count suggests.
The practical consequence is simple: you need to know which quality properties are internal, and which are only proven when the system meets the outside world.
Call quality across networks is one example. Authentication across tenants is another. Search relevance across languages. Media playback across devices. Payments across issuers.
These are not “special cases.” They are the real product.
Good enough quality is often conditional quality
The phrase “good enough” sounds pragmatic until you ask: good enough for whom, and where?
A product can be good enough inside its own ecosystem and still fail the moment the customer steps outside it. That is not a minor detail. That is the difference between a controlled experience and a conditional one.
Odido’s situation makes that visible because the difference is so concrete. Same operator, different outcome depending on whether the other end of the call is inside or outside the provider’s network. That kind of boundary-specific issue is exactly where users stop believing the service is simply “working.”
For software leaders, the consequence is uncomfortable but useful.
You cannot manage quality as a general sentiment. You have to manage it as a set of testable properties tied to real paths, real dependencies, and real failure modes.
If you don’t, your metrics will keep telling you the core is healthy while your customers quietly pay for the edges.
And the edges are where trust is won or lost.