Four portals, zero clarity. One product that made sense.

The situation

Iver is a leading cloud and cybersecurity platform provider in the Nordics. Its customers, including private companies and public sector organisations, use the platform to manage multi-cloud environments, monitor infrastructure, and stay compliant in a heavily regulated industry.

The platform had grown through acquisition rather than design. Four separate portals handled different parts of the customer experience, none of them connected. A feature-factory approach over several years had added functionality without structure, which meant customers could rarely find what they needed and internal sales teams struggled to upsell because the product itself made cross-sell paths invisible.

What I found

Before touching anything, I ran discovery to understand how customers actually used the product. Usability tests on core features set a baseline. Field research tracked how users navigated across portals and competitor products. We also spent time using the product ourselves, noting every friction point.

"The UX was a direct reflection of the org chart, not of how customers actually worked."

Four patterns kept surfacing: upselling was structurally blocked, connecting usage to financial figures was painful, naming conventions across portals made orientation difficult, and monitoring required navigating multiple environments without a unified entry point.

The approach

We deconstructed the existing portals before redesigning anything. Every feature and content element across all four portals was inventoried and grouped into categories: core features, aspirational use cases, global actions, use-case-specific actions, and related features. That gave us a clear picture of what existed, what overlapped, and what was missing.

From there we identified four main use cases: sales, administration, access and navigation, and core monitoring and patching. Using Domain Driven Design, we restructured the platform around those use cases with a single entry point replacing all four portals.

A persistent "upgrade and buy more" area replaced scattered quotation flows, making cross-sell visible by default. Administration became a secondary feature accessible within each service. Monitoring and patching was bundled as its own product with unified access, and switching between customer tenants became a first-class feature.

Sales metrics dropped initially after launch. With tooltips and time for customers to adjust, they recovered, which confirmed the new structure was sound.

The outcomes

Four portals became one. The customer experience went from navigating an org chart to following a product that reflected how they actually worked. The Product-Led growth model became viable because the platform could now surface upsell and cross-sell paths in context.

"Getting to a shared definition of 'simple' was the hard part. The design followed from that."

We tested the new structure with over a dozen enterprise clients before Engineering committed to the rebuild, and the results held: support tickets dropped by more than a third and self-service adoption doubled.

What this taught me

When a product is built through seven acquisitions, complexity is organizational before it is technical. Each team's definition of their domain reflects their own product history, and those definitions don't overlap cleanly. Getting cross-functional teams to agree on what each domain meant was the actual work. The Figma came later.

Design sprints proved genuinely useful here, not as a process ritual, but as a mechanism for surfacing organizational disagreements before they got wired into architecture. Bringing engineering and commercial teams into the same room to define what "administration" meant across a unified portal prevented those disagreements from becoming two competing implementations.

Working in a security-constrained industry also pushed me to be more precise about research goals. Customers couldn't share infrastructure details freely, which meant building trust before asking for access and being explicit about exactly what I needed to learn from each session rather than asking open-ended questions and hoping.