Ford's service operations had a problem with how long vehicles sat off-road, and no central view of it. Repair orders sat across systems. Status was scattered, ownership was unclear, and the senior leadership running service operations across every market Ford sells in — North America, Europe, APAC — had no shared lens on how their portfolios were performing. The original brief was modest. A data-visualisation dashboard for business leaders and portfolio managers, summarising end-of-day status of the population they were responsible for.
The product needed clean data the team didn't own, with critical feeds across upstream and downstream systems, owned by other product teams whose roadmaps and priorities had to be negotiated into ours. The second constraint was the difficulty of letting go. Command Center was meant to replace a set of existing third-party workflow applications that had poor UX and structural backend limits, and leadership had set the direction to move off them on cost and value grounds. Even with that direction in place, individual teams found it hard to release the tools they had built their workflows around. Decisions agreed on one month would get re-litigated the next.
The obvious path after the POC was to keep it as a dashboard. Add a few more metrics, expand the user list, polish the UI, ship a v2. Instead, I argued for something different. The same product that gave leaders their bird's-eye view should also give the operators responsible for individual repair orders the ability to drill in, see ownership, leave comments, follow status, and act inline. A dashboard for leaders, a workflow tool for everyone else, but one product, one experience, one source of truth.
The second call was how to build it. The full vision was eight to twelve months of work. Most enterprise teams would have planned a single release at the end of that runway. I argued for splitting the requirements into modules that could each ship as releasable software, sprint by sprint. Core modules first, then enhancements and new modules quarter over quarter. The reasoning was that no one would wait twelve months without losing faith in the product, and the feedback we got from each shipped module made the next one better. It also meant the business saw ROI iteratively, not on a single distant date.
The third call followed from the first two. Once the platform existed and worked, the cost of running multiple separate third-party applications became harder to justify. We started absorbing those applications into Command Center as modules, lift-and-shift with workflows redesigned and the experience modernised. The platform was no longer just the product. It became the workspace.
The upstream data was the recurring risk. Critical feeds were owned by teams whose roadmaps didn't have our milestones on them, and slippage often surfaced late, sometimes not surfaced at all until I asked. I built a habit of proactive check-ins, and when something was off-track, the response was a layered one: negotiate reprioritisation, lend resources where it helped, or design the release with placeholders that absorbed the data cleanly when it landed. The risk was constant. The response was a system, not a save.
Repair cycle time dropped 12%. That translates into millions of dollars in saved cost and increased revenue when you account for fleet-customer economics, retention, brand trust, and downstream service costs. Monthly active users grew 18% quarter on quarter after the pilot, compounding across each new module released. CSAT lifted 16%, measured at roughly 40-50% feature completion. Users were rating the product highly before it was finished.
The outcome that wasn't in the pitch was the way adoption happened. Other teams started reaching out asking for access without being pitched to. The modular release strategy paid off in a way the original plan hadn't promised. Users felt the value, and the platform's adoption became something that happened to us rather than something we drove.