Supermetrics

Marketers think about their data in four stages: connect, manage, analyse, activate. Supermetrics owned the first three. Activation—turning data into actual targeting, messaging, and action—was missing.

The platform that filled that gap came with a problem baked in: it was built by developers for a handful of large enterprise clients, each one supported by a consultant who set the product up for them. It was never designed to be used unassisted.

Supermetrics’ actual customer base is SMB and mid-market: no consultant, no patience for a learning curve, and expecting to open the product and use it.

My job was to take a powerful but consultant-dependent tool and make it usable on its own.

The clearest signal came from the consultants: almost no one could use the product without them. The few customers who had figured it out were long-tenured—proof of a steep curve, not a working design.

I interviewed existing customers and talked to marketers who had never touched the product. The same pattern appeared everywhere: poor discoverability, unclear labelling, information buried in the wrong places, and no in-product guidance.

Users were expected to already know a system that had only ever been explained to them by a person.

This was not a polish job. It was a rebuild of how the product teaches itself.

The brief was to work with Engineering, ship small incremental fixes, and stay close to the roadmap. I built a significantly better version of the core experience and validated it, then extracted pieces back into the live product.

The concepts deliberately reached beyond the current roadmap so the step-change could be defined first and broken into practical releases.

I validated the direction with interactive prototypes and real-user testing sessions, then presented the findings directly with engineers throughout.

I sat with Product Management and Engineering to break the vision into shippable pieces and get real pushback.

Compromises were made before a visual review, while redundant steps were hidden rather than removed until the team understood why they existed.

The habit that mattered most was never taking a workaround at face value. Every pushback got a “why” until I could tell whether I was looking at a real technical constraint or a workaround that had always worked.

That distinction is what let me meet Engineering’s limits without quietly shipping the same confusing experience back to users.

I designed the full experience—the node and connection model, the rule builder, and everything around it.

The design system team was building a new system in parallel, so without clear constraints, node and rule-builder components stayed grounded in the research rather than a familiar UI pattern.

AI support was treated as part of the workflow rather than an isolated feature: useful where people needed explanation, validation, or a faster route through complex setup.

Mid-rollout, testing with existing customers, prospective customers, and former consultants showed real gains in satisfaction and task completion.

The new experience is being folded into the live product in phases rather than shipped as one release.

What is next: full rollout, with time-to-first-journey as the core metric—how fast a new customer gets from opening the product to a live activation with no consultant involved.

I would bring Engineering into the earliest concept formation next time, so feasibility constraints shape the direction from day one.