The Challenge
Four months into the subservicer's AI Innovation Lab, the engagement had already done what many enterprise AI initiatives never manage: a working operating framework, live experiments running across five use cases, and early wins that built real confidence in AI's applicability to mortgage servicing.
Then came the feedback that determines whether an AI lab matures or stalls. The subservicer's leadership was direct: they wanted production impact, not just impressive demos. Sharper prioritization, less use-case sprawl, and a lab more deeply connected to the people who run the business. Underneath the feedback sat a structural pattern: experimentation was outpacing production delivery, subject-matter experts were engaged mostly at discovery and then handed off, and the lab's value wasn't consistently visible across the organization. There was a deeper ambition, too: building internal AI capability had been a founding goal of the lab. The subservicer didn't want to rent innovation capacity indefinitely; it wanted its own people able to do this work.
This is the moment most AI labs quietly die. The subservicer and PhoenixTeam treated it as a design problem instead.
The Approach
Rather than defend the original model, the team ran an honest retrospective, treating the friction as learning signals, not failures, and rebuilt the lab's engine around a cross-functional MVP pod model.
Each pod is a small, temporary, outcome-driven team assigned to a single production-bound use case, staffed across five roles: a subservicer business SME who guides and validates results, a subservicer GenAI engineer who designs and executes experiments, a subservicer AI value engineer who owns success criteria and compliance rules, and PhoenixTeam's AI value engineer and AI software architect guiding execution and technical approach. Pods connect at the start and end of each day and work from a shared set of artifacts: use-case definition and success criteria, experiment plans, data validation notes, results, and a clear MVP-readiness or production recommendation, all documented centrally so the work is transparent to the wider organization.
The model's quiet superpower is that enablement happens through execution. The subservicer's team members build capability by working real use cases end to end, with knowledge transfer embedded in daily problem-solving rather than delivered as a separate training course. SMEs learn to guide, validate, and trust AI outputs; engineers absorb GenAI implementation patterns; value engineers sharpen how outcomes get defined and measured; executives gain visibility and confidence. PhoenixTeam's education practice supported the shift with role-based enablement, while delivery narrowed to production-bound priorities, a contract overlay intelligence solution and complaints trend analysis, each headed toward a formal Technical Readiness Package.
The whole redesign was de-risked the same way the lab treats every idea: with a time-boxed test. A two-week pilot ran a single pod through one production-bound use case, end to end, before scaling the model.
The Outcome
The pilot did its job: it validated the pod-based execution model, confirmed the collaboration cadence was sustainable for business teams, and produced a refined playbook ready to roll out more broadly, along with something more valuable, subservicer resources capable of running their own experiments inside the lab.
The refocus paid off where leadership asked for it. Within months, the lab had three production-ready solutions moving into the subservicer's environment, each carried to the IT organization with production-grade packaging, exactly the shift from lab activity to delivery that executives had called for.
The durable outcome, though, is the operating model itself. The subservicer now has a lab that runs on its own people as much as on consultants: faster idea-to-production delivery, stronger cross-functional ownership, and a repeatable rhythm the organization can sustain. And the engagement proved something worth more than any single solution: that the willingness to hear hard feedback and re-architect mid-flight is what separates AI programs that ship from AI programs that stall.
