Pivotinga30-year-oldCompany

The brief was 'modernize the system': a direction, not a problem. Rather than designing against assumptions, I led all user research personally across more than two years in the field, shadowing hundreds of people in the customer base. One stretch ran two consecutive weeks on-site at our largest customer, mapping every role, process, and responsibility across their infrastructure teams. I hired a junior UX researcher to support execution and synthesis, coaching them throughout.

Two distinct failures emerged. Cities were paying for fragmented departmental software and private data centers: expensive, siloed, and impossible to maintain at scale. Field workers were drowning in paper: print-outs for every job, handwritten documentation, disconnected processes between crews and control rooms. These were not the same problem. Solving one without the other would have produced a cheaper version of the same failure.

The risk of pivoting a 30-year company is committing to a new direction before the product exists. Rather than asking customers to trust a vision on paper, I built high-fidelity prototypes of the new platform: interactive enough to demo, specific enough to generate real reactions from city decision-makers who had never seen anything like it.

Early adopters committed to the new platform based on those prototypes. Their contracts gave the startup the runway to build what we had shown them. Design wasn't just a product function — it was the mechanism that made the pivot financially viable. The trade-off: we had promised a platform that didn't exist yet and now had to deliver it.

The temptation with a new platform is to chase net-new customers first: clean contracts, no legacy baggage. But legacy customers had existing trust, deep institutional knowledge of the problem space, and a high cost of re-acquisition if lost. Building on an unproven foundation while abandoning proven revenue was the wrong sequence.

As CXO, I defined a three-phase strategy: pilot with five selected customers to test product-market fit, migrate the existing base before any acquisition push, then scale. This forced us to learn from users who knew every edge case in the old system, and use their adoption as proof of concept for the wider market.

Before I joined, 7 frontend engineers were building the platform feature by feature with no shared component library. Every button, form, and interaction pattern was recreated from scratch per module. Inconsistencies accumulated: different hover states, mismatched animations, spacing that drifted between screens. Users felt it as a platform that didn't quite hold together.

I introduced a component library built on Material Design. The cost was 3 sprints, about 6 weeks, to integrate the library and migrate the existing codebase before any return. After that, every new module drew from the same foundation, with animations, transitions, and interaction behaviour pre-baked rather than hand-coded per feature. As the platform grew, I extended the library with purpose-built components Material Design didn't cover: interactive maps, collaborative dataset views, guided field workflows. Development compounded instead of duplicating.

The legacy system centralized control in administrators. Field workers couldn't do anything without waiting for an admin to update a config file, regenerate a map, or modify a workflow. In public sector organizations where extra headcount never comes, this wasn't just inefficiency: it was a structural failure with no staffing solution.

I redesigned the platform so field workers and managers could configure their own dashboards, add assets directly from a catalog, and modify workflows without admin intervention. Admins weren't displaced — they were relieved. They had been the bottleneck everyone depended on for basic operations. Freeing them gave them capacity for work that actually required their expertise. The trade-off was trusting users with more configurability, accepting that some would misconfigure things. In a sector where autonomy was the only path forward, it was the right call.

The legacy platform was bolted onto AutoCAD. That kept it locked to a small group of technically proficient users. Everyone else either struggled or depended on those experts as a second bottleneck. Moving to web-based maps using Google Maps APIs didn't just modernize the interface: it fundamentally lowered the barrier to entry for the vast majority of field workers, managers, and administrators who had never been able to use the old system independently.

But 1% of use cases genuinely required millimeter precision: hydraulic pressure modelling in sewer systems, infrastructure design at centimeter-level altitude differences. For those, a web UI would never meet the bar. Rather than compromise the platform for the majority, I preserved the AutoCAD integration for that 1%. Maintaining two interfaces added complexity. But forcing precision users into an inadequate tool would have killed adoption among the most demanding part of the customer base.