Unblocking four years of inertia on in-app troubleshooting
Launched a device and network troubleshooting MVP in T-Life that had failed to ship in any prior T-Mobile app for four years — $4.5M in realized annual savings.
$4.5M
RealizedMVP
After 4 yrs stalledHigher
Care contacts ↓Problem
T-Mobile postpaid customers hitting device or network trouble routinely ended up calling Care or visiting a store. The troubleshooting experience had been attempted — and stalled — in every previous T-Mobile app for four years; the surface area touched device settings, network state, and account services, and no single team owned the seam. T-Life was still relatively new, and this was the first app where the experience actually launched.
Context
- T-Life was the primary digital touchpoint for postpaid customers with ~28M MAUs, making it the most critical funnel for care deflection.
- Leveraged this massive scale to design a unified troubleshooting approach for postpaid subscribers.
- Stakeholders spanned device engineering, network operations, account services, Care, and design — each with their own roadmap and risk tolerance.
- Care cost per contact made even modest deflection a material P&L line.
Team & scope
- Reported to
- Senior Manager, Services — T-Life
- Team
- Led 2 product teams in parallel. Shared resources: 2 designers, 2 QAs. Per team: 8 engineers (2 onshore leads + 6 offshore).
- Directly owned
- UX of the new troubleshooting experiences inside T-Life.
- Influenced
- Outcomes and goals across cybersecurity, fraud, and multiple domain teams that supplied the underlying capabilities.
Approach
Reframed the problem as a seam, not a feature
Mapped the top contact drivers in Care data against the surfaces T-Life already owned. The pattern was clear: the value wasn't a 'troubleshooting page' — it was three small wedges that crossed org boundaries. I framed the MVP as device, network, and account services in parallel, so no single owning team had to ship the entire experience.
Built the cross-functional coalition first
Ran working sessions with device, network, and account leads to align on what 'good' looked like for each wedge, what data they could expose, and what risks they wouldn't accept. Got verbal commitments before writing any spec, then locked them in writing.
Sized the prize with Care data, not opinions
Worked with finance and Care analytics to model deflection per contact type and surface the $4.5M figure with explicit assumptions. That number unblocked exec sponsorship and prioritization conversations that had been circular for years.
Shipped the thinnest slice that proved each wedge
Each wedge launched as a minimal, instrumented surface — enough to validate containment lift and rule out regressions in Care contact rate, without trying to solve every troubleshooting flow on day one.
Research insight
Care contact data showed the top drivers crossed three org boundaries — device, network, and account. The reason this had stalled for four years wasn't technical complexity; it was that no single team could own the seam. The MVP had to be designed as a coalition, not a feature.
Decisions & tradeoffs
- Chose containment lift as the north-star metric over engagement — engagement could be vanity if it didn't reduce Care contacts.
- Deliberately scoped out the long tail of edge-case device issues to ship the 80% in months instead of years.
- Kept the surfaces in-app rather than rebuilding a web parity flow, accepting some segment coverage tradeoffs to move faster.
The tradeoff I defended
What I'd do differently
Executed on the MVP vision earlier instead of chasing every last stakeholder approval. I had the critical sign-offs; the rest would have aligned once the build was visibly moving — and launch would have come materially sooner.
Tools & methods
- User testing
- Competitive analysis
- Power BI
- Internal analytics platform