Sprint — Single-SKU Program

Context & problem

After acquiring Virgin Mobile, Sprint ran a multi-brand prepaid strategy: Virgin Mobile, Boost Mobile and Assurance Wireless, each with its own branding, carrier settings, preloads and feature policies. Prepaid was the fastest-growing segment inside a $35B operating-revenue business, and every brand wanted the same hot Android device.

The way the industry handled that in 2010 was a separate build per brand. Each one was a distinct OEM deliverable with its own certification pass — Sprint lab, Google compatibility, carrier acceptance. Three brands meant three builds, three certifications, three inventory SKUs. The marginal cost of a brand was weeks of schedule and a measurable chunk of device cost.

I was running a 10+ person cross-functional product and test-engineering team supporting this strategy, and had just integrated Virgin Mobile’s product and UX org into Sprint. The problem was ours to fix.

Insight

The part of the device that varies by brand is small, declarative, and doesn’t need to be in firmware. Carrier configuration, APN settings, branding assets, preload manifests, feature toggles — these are data, not code. If they could be delivered as a management payload after the device was built, the build itself could be brand-neutral.

OMA Device Management already existed for provisioning and diagnostics. The insight was to treat it not as a support tool but as the delivery mechanism for the brand: architect the brand-variable components of the Android device as nodes in the OMA-DM management tree, make them OTA-updatable, and push the brand at activation.

Mini PRD

Strategy & bets

• Decouple the variable from the fixed. Everything brand-specific moves into the payload; everything else stays in a single, brand-neutral build.
• Certify once. The single build is the thing that gets Sprint, Google and carrier certification. The payload is provisioned post-certification.
• Do it with Google, not around them. A Sprint-only fork would have broken on every platform update. Working with Google kept the approach aligned with the platform’s own direction — the same idea later became standard as carrier configuration.
• Design for failure at activation. A device that can’t fetch its payload still has to be a working phone, so the build carries safe defaults and the DM flow is retryable.

System design

What moved into the payload. The brand-variable components of the device — carrier and APN configuration, branding assets, the preload manifest, feature toggles — were re-architected as OMA-DM-manageable objects so they could be set and updated over the air. What stayed in firmware. Everything the device needs to boot, attach to the network and reach the DM server, plus safe defaults so an un-provisioned device is still a usable phone.

Delivery. At activation the device opens a DM session; the server resolves the subscriber’s brand and pushes the matching payload; the device applies it OTA. Payloads are signed and the flow is retryable, so an interrupted activation re-provisions rather than bricking.

The Google partnership made the approach durable: aligning the single-SKU model with the platform’s own compatibility and certification path meant it survived Android version updates instead of forking from them.

Engineering management

The single-SKU program was as much a people and delivery problem as an architecture one. I ran it as the manager of a 10-plus person cross-functional product and test-engineering team, inside a business that had just acquired the brand whose org I was absorbing.

Integrating an acquired organisation. Virgin Mobile’s product and UX team came into Sprint with its own device roadmap, its own test practices and its own relationships with OEMs. The integration decision was to keep what made Virgin’s brand distinct (its UX and its customer voice) and unify what didn’t need to be distinct (device engineering, certification, test). The single-SKU architecture was the technical expression of that organisational decision: one engineering team, one build, several brand voices.

Structuring the team. Product owners per brand, a shared device-engineering core, and a test-engineering group that owned certification for every brand on the single build. Brand teams specified the payload; the core owned the platform; test certified once. Clear ownership of the three layers is what kept three brands from re-creating three teams.

Running OEMs and partners. The program only worked if OEMs delivered a brand-neutral build on time and Google accepted the provisioning approach as compatible. That meant one technical spec for the single SKU across every OEM, a joint certification path with Google rather than a Sprint-only one, and weekly delivery tracking with each OEM on build, test and certification milestones. Escalations went to me first; the brand teams never had to negotiate with an OEM about a build.

Test engineering as the gate. Test owned the definition of “certified once”: the single-build test plan, the payload test matrix per brand, and the provisioning-failure cases (interrupted activation, re-provisioning, mid-life brand change). Shipping on the new model was gated on that matrix, not on a brand team’s launch date.

What I learned about managing engineers. Give the team the architecture problem, not the schedule problem. The single-SKU idea came from the engineers once the constraint — three brands, one roadmap, no more headcount — was made explicit and the cost of the status quo (three certifications per device) was put in front of them. My job was to protect that idea through the brand teams, the OEMs and Google, and to make the test gate non-negotiable.

Device security

Moving the brand out of firmware and into an over-the-air payload creates an attack surface that a per-brand build never had: if a payload can reconfigure a phone, a forged payload can too. Security was therefore a design requirement of the single-SKU architecture, not a review at the end — and it had a business driver as sharp as the technical one.

Transshipment. Prepaid devices are sold below cost, with the subsidy recovered through service. That makes them a grey-market target: buy a subsidised phone meant for one brand or market, divert it in bulk, and activate or resell it somewhere the subsidy was never meant to go. A brand-neutral build makes this easier unless the provisioning model closes it, because the device no longer carries its brand in firmware. So the single-SKU design had to make the device useless until it was provisioned by Sprint, for the subscriber it was sold to, on the brand it was sold under — which is exactly what authenticated, server-resolved provisioning does. The security controls below protect the device; the transshipment control protects the subsidy economics the whole prepaid business runs on.

• Signed payloads, verified on device. Every brand payload is signed; the device verifies the signature before applying anything, and an unsigned or tampered payload is rejected and logged. Provisioning without verification would have been a remote reconfiguration hole on every device Sprint shipped.
• Least privilege in the management tree. Only the brand-variable nodes are OTA-writable. Anything that touches the radio, the bootloader or the security configuration stays read-only to the DM channel, so a compromised payload can change the logo, not the phone.
• Authenticated DM sessions, brand resolved server-side. The device talks only to Sprint’s DM server over an authenticated session; the server resolves the brand from the subscriber record, not from anything the device claims about itself. A diverted device can’t ask to be a different brand, and an un-provisioned one is a brick with a boot screen.
• Safe defaults and rollback. An un-provisioned or failed-provision device boots into a safe, working configuration; a bad payload can be rolled back to the last good one rather than leaving the device in a half-branded state.
• Mid-life rebranding as a security case. A device moving from one brand to another on resale has to be wiped of the previous brand’s configuration and re-provisioned cleanly — treated as a security event, not a settings change.

The test-engineering gate owned the security matrix alongside the functional one: forged payload, replayed payload, interrupted session, downgrade attempt. The program didn’t ship on the new model until those cases passed on every OEM build.

Metrics & experimentation

This was a program, not a growth product, so the metrics were operational: builds per device model, certification cycle time, device cost, and provisioning success rate at activation. The before/after comparison was the experiment.

What it unlocked: wholesale

The single SKU was built for three Sprint brands. Its real leverage showed up when a fourth, fifth and sixth brand turned out to be other companies’ brands. Once the brand is a payload, an MVNO or wholesale partner is just another payload on the same certified device — no new build, no new certification, no OEM negotiation. That turned device provisioning from a cost of each wholesale deal into an asset Sprint could bring to the table, and it put me in the room on wholesale and MVNO arrangements with cable operators such as Cablevision and Comcast: the technical answer to “how fast can you get our brand on a device” was already built.

Beyond phones: data devices and IoT

The same team also carried Sprint’s prepaid data-device line — mobile hotspots, USB modems, connected tablets — and the early IoT / machine-to-machine devices that ran on the network without a person behind them. Those products stressed the provisioning model harder than phones did: a hotspot has no screen for a user to fix a failed activation, and an M2M module in a vending machine or a vehicle may never be touched again after it ships. Provisioning had to be fully remote, verifiable and recoverable from day one, which made the signed-payload, safe-default, server-resolved design a requirement rather than a nicety. The device and IoT work is also where the data-plan, certification and partner patterns from the single-SKU program were reused across a product line that didn’t look like a phone at all.

A good part of that work was below the application layer. On a CDMA network the data session itself is authenticated — 3GPP2 Mobile IP, with the device proving itself to the home agent before it gets an address — and a device that can’t complete that handshake has no data at all, however well it’s provisioned above it. I spent real time on the Mobile IP authentication path and with Qualcomm’s data team on the modem-side behaviour behind it: how credentials were provisioned and protected on the device, how failures surfaced, and what OEMs had to implement identically for the single-SKU model to hold across chipsets. It’s the layer where the brand-neutral build had to be most exactly the same on every device, because nothing above it works if it isn’t.

The other half of provisioning lives nowhere near the device. A subscriber exists first in internal IT and billing — the account, the plan, the brand, the credentials that the network will accept — and the device only becomes usable once those systems have provisioned the user and the network authenticates them against that record. The single-SKU program therefore ran across three organisations that don’t normally share a roadmap: device engineering, network authentication, and IT/billing. The server-resolved brand decision that makes the payload model secure is, mechanically, a billing-system lookup; a failed activation is as likely to be a billing record as a modem. Getting those teams to one activation flow, with one definition of “provisioned,” was as much of the program as the architecture. In practice that meant working directly with Sprint’s enterprise IT architects on the carrier-grade systems of record for prepaid — billing and customer management on Amdocs, number and service provisioning on Telcordia; postpaid ran on a separate platform with its own integration path. Prepaid is also where real-time metering lives. A prepaid customer buys a predefined bucket — a dollar amount, or an allowance of minutes and megabytes — and the system has to meter exactly how much voice and data each user consumes against it as it happens, so a call can be ended or a data session throttled or cut the moment the bucket is spent. Postpaid can reconcile at month end; prepaid can’t give away a byte it hasn’t been paid for. So provisioning and authentication were designed against a system that decides entitlement per event, not per month, and the accuracy of the voice and data meter is a revenue control, not a reporting feature. Unlimited plans are the norm now and have made most of that machinery invisible to the customer — but it didn’t go away; it became the deprioritisation thresholds and fair-use rules behind “unlimited,” and the same per-event metering logic is what every usage-based SaaS product meters tokens, seats and API calls with today. That shaped the data-device and IoT work in particular — a hotspot or an M2M module meters continuously, with no user to top up. Underneath all of it is a large body of business logic that had to be designed with IT, not handed to them: which brand a subscriber maps to and what that entitles them to; what happens at zero balance for voice versus data; how a top-up re-enables a cut session; grace periods, expiries and reactivation; what a device is allowed to do between sale and first activation; how a mid-life brand change settles balances and plans; which failures retry automatically and which go to care. Each of those is a product decision with a revenue consequence and a system home, and the work was writing them down precisely enough that billing, provisioning and the device all enforced the same rule. The integration work then meant mapping where the brand and subscriber records lived across those systems and the network, agreeing the integration points the DM server would call, and making sure a change on the device side didn’t require a change in a system with a two-year release cycle. The enterprise-integration design is what let the single SKU go live without re-architecting billing — and it’s the part that wholesale partners later plugged into.

Outcomes

• One Android SKU certified once and provisioned per brand over the air, replacing per-brand builds — and extensible to wholesale and MVNO partners as additional payloads.
• 10 %+ reduction in device cost and 2–4 weeks cut from certification time for OEMs and partners.
• Supported Sprint’s multi-brand prepaid growth strategy inside a $35B revenue business growing 5 % year over year, with prepaid the fastest-growing segment.
• Virgin Mobile’s product and UX organisation integrated into Sprint post-acquisition with the single-SKU model as the shared platform.

Retro — what I’d do differently

• Push more into the payload. We were conservative about what left firmware; in hindsight the brand surface could have been larger and the firmware even more neutral.
• Design mid-life brand migration from the start. The architecture supported it in principle; productising it (a Boost device becoming a Virgin device on resale) came later and would have been cheap to include.
• Name the pattern. This was config-as-payload before the platform had a word for it. Fifteen years later I’m applying the same instinct to AI video — the template is the build, the listing is the payload.
• Recognise what it really was. Strip away the modem and this is user provisioning: an identity created in a system of record, entitlements attached, credentials issued, the client configured for that user at first use, and a mid-life change handled as a controlled event. That is the same foundation every SaaS product stands on — account, plan, auth, tenant config, offboarding — specialised for a mobile subscriber whose “client” is a phone. It’s why the provisioning and account work in IQnition and Studio 3Sixty5 felt familiar: the system of record moved from a billing mainframe to a database, but the shape of the problem didn’t.