What telecom teaches product leaders about operational products
MVNO platforms are a hard school for product management: the operational floor never pauses, correctness is regulated, and every partner integration is a contract you cannot break quietly.
I have worked in telecommunications since 2024, as CTO of an MVNO platform where other companies build connectivity products. It is a domain of evidence in my work rather than a definition of it — I write about it because it taught me things that generalise, not because I intend to be read as a telecom specialist.
If you are looking for the transferable version of these lessons, the platform and operating model pieces are where they live in general form.
The vocabulary, briefly
Definition
MVNO (mobile virtual network operator) sells mobile service using another operator's radio network. MVNE (enabler) supplies the platform an MVNO runs on — provisioning, subscriber management, billing, integration with the host network. MVNA (aggregator) buys wholesale capacity in volume and resells it to smaller MVNOs.
The distinction matters commercially, not just technically: the interesting position is the enabler, because that is where the product is a platform and the customers are businesses rather than subscribers.
Why this domain is a hard school
The operational floor never pauses. A SIM activation either works or a customer has no service. Provisioning failures are not degraded experiences, they are total ones. This means there is always a body of work — edge cases, retries, reconciliation, partner drift — that competes with new product investment and will never announce itself as strategic. It is the clearest case I know for funding continuity as a standing allocation rather than arguing for it case by case.
Correctness is regulated, not negotiable. Billing accuracy, number portability, identity verification, data retention: these are obligations with legal weight. You cannot ship a fast approximation and iterate. That constraint is unusual in software product work, and it changes how you sequence: the compliant version is the minimum version.
Every partner integration is a contract. When an enterprise builds its connectivity offer on your provisioning API, a breaking change is not a migration inconvenience — it is their customers losing service. This is what makes the governance test in platform strategy unforgiving. Versioning policy, deprecation notice, and error semantics stop being engineering hygiene and become the commercial product.
Latency of feedback is long. Some failure modes only appear at the end of a billing cycle, or when a partner’s traffic pattern changes seasonally. You cannot learn everything in a two-week loop, which forces more upfront design than a purely digital product would justify.
What generalises to any operationally heavy product
The lessons are not about mobile networks. They apply to payments, logistics, invoicing, healthcare — anything where software commits an organization to doing something in the physical or regulated world.
- Operations belongs in discovery. The people handling activation failures know more about your product’s real problems than any backlog. In telecom this is unavoidable; in most companies it is merely true and ignored.
- A product decision and an operational obligation are often the same decision. Choosing to support a new plan type is also choosing to support its billing edge cases forever. Pricing this honestly at decision time is the single most valuable habit the domain teaches.
- Reliability is a feature with a price, and the price is roadmap. Making that trade explicit is better than letting it happen by neglect.
- Reversibility is worth paying for. In a regulated context, the cost of an irreversible mistake is high enough that optionality justifies real engineering effort. This shaped how I now think about data models and external contracts in general.
The same lesson at small scale
I hit a version of this before telecom, building POS and electronic invoicing for the Peruvian market at Syma between 2018 and 2023. Invoicing under SUNAT rules has the same shape: a regulated interface that must stay correct and stable while the product keeps moving, and where “mostly working” is indistinguishable from broken for the customer standing at the counter.
The scale was smaller and the lesson was identical, which is part of why I trust it.
What I do not claim
Observed MVNO platform work from 2024 onward, and POS/electronic invoicing under Peruvian tax regulation from 2018 to 2023.
Inferred That these lessons transfer to other operationally heavy domains. The reasoning is structural, but I have not run payments or logistics at scale.
Opinion That the enabler position is the more interesting product problem than the retail operator position.
I am not a radio network engineer, and I do not work on spectrum, RAN, or core network internals. My work sits at the platform and product layer above that: provisioning, subscriber and plan management, billing correctness, partner integration, and the organizational design required to keep all of it moving.