Building an analytics platform that closed enterprise deals before engineering started

Opensignal collects billions of mobile network measurements weekly from consumer apps like Meteor. The B2B business monetised this data by selling analytics to telecom operators, Vodafone, AT&T, Free, EE and others. But the company's ambition was bigger: shift from being a data vendor to being a competitive intelligence partner.

In 2017–2018, the strategy moved from public reports to a SaaS platform model. I led product discovery and drove the platform build during hypergrowth, from 20 to 300 employees, through to acquisition, with no established product process and direct accountability to the SVP of Products.

The challenge: each audience within a telecom operator had fundamentally different questions, technical literacy, and decision-making contexts, but they all needed to trust the same underlying data.

We settled early on two products rather than one dashboard with permission levels. The C-suite and the engineering team don't only have different access needs, they have entirely different relationships with the data, and one product built for both would have served neither.

Telecom analytics tools at the time were either internal engineering platforms, technically powerful but inaccessible to non-technical stakeholders, or lightweight competitive reports with no analytical depth. Nothing bridged executive decision-making and engineering diagnostics in one coherent platform.

That was the strategic opening. Moving from data delivery to competitive intelligence meant the product had to do something none of the competition had attempted: make complex network data genuinely useful to business leaders as well as engineers.

With four products serving distinct audiences, prioritisation was the hardest ongoing challenge. I used a two-axis framework: client value (how much business impact for telecom operators, and how directly it served the intelligence-vs-data positioning) against engineering effort. The goal was to find the decisions that moved the strategic pivot forward fastest.

Research first. I ran user research directly with telecom operators, learned the analytical models from our data scientists, and used RICE to turn what we found into roadmap decisions. Industry standards and the data science team set what the metrics had to show. My call was how the platform presented them, and which problems we solved first.

Architecture before screens. The hardest problem here was information architecture. Opensignal's metrics are deeply complex: speed decomposes into sub-metrics, each available at national/regional/city level, across 2G/3G/4G/5G, with confidence intervals. I worked with data science teams to map every metric relationship before a single screen was designed.

One design system, two density levels. CI needed white space and large trend indicators. PI needed data-dense views with multiple chart types per screen. I owned a shared component library (charts, filters, navigation, operator colour coding) while maintaining different layout grids per product. Both feel like siblings; each respects its audience's workflow.

The core question I scoped this product around: "Where do I stand, and what's changing?" I defined an architecture that surfaced ranking positions across all key metrics with trend indicators on load, then allowed progressive disclosure into any metric. Every number included confidence intervals and methodology transparency, because C-suite users have high skepticism about data sources and low tolerance for anything that feels like a black box.

The critical business constraint: these are the buyers. They need to feel confident in the data before their CTO will sign a contract, so trust had to come before usage.

"It's very rare to see telecom operators lean forward and be actively excited by a demo, however, this is the effect Malgo's design has on customers. It's certainly a level above what they're used to."

– Iain Masden, SVP Products and Solutions, Opensignal

Performance Intelligence serves a fundamentally different workflow: CTOs and network engineers decomposing metrics to find root causes. The question I scoped this product around: "Our video experience dropped in Region X, is it a capacity issue, a throttling policy, or a specific CDN?"

I defined a product that supported analytical storytelling, users build a narrative by drilling into data across dimensions. Linked charts that update in context, time-of-day patterns, distribution views, geographic breakdowns. The principle we worked to was density without confusion. Every screen is data-rich, but the hierarchy is clear.

Prototype-as-sales-tool: The Competitive Intelligence prototype validated the product internally and then became a revenue-generating asset. Sales used it to close enterprise deals before engineering had built the platform. That was deliberate: we invested in prototype fidelity early to compress the sales cycle.

Cross-product coherence: With four products serving distinct audiences, I owned the design system that held them together, shared components, consistent interaction patterns, unified operator colour coding. This mattered commercially: operators expected a cohesive intelligence suite rather than a collection of separate tools.

Scaling through hypergrowth: As the company grew from 20 to 300 employees and through acquisition, we kept product quality and the research-led culture intact. My part was setting the standards, building the shared systems, and making deliberate calls about what not to build.

I'd push for direct user research access earlier. Due to the seniority and scarcity of our target users (C-level telecom executives), we relied heavily on internal consultants as proxies for much of the discovery work. That created gaps we only discovered later.

I'd also advocate for a unified analytics layer across all four products from the start. Each evolved somewhat independently, and building cross-product consistency retrospectively was harder and slower than designing for it from day one.