Designing for Enterprise Scale
Helping an enterprise cybersecurity platform evolve from isolated customer experiences towards a scalable multi-tenant platform.
The Challenge
Enterprise customers rarely operate within a single account. They may manage multiple business units, regions or customer environments, each with its own data, users and operational needs.
For these customers, simply being able to access multiple accounts wasn't enough. They needed to understand, manage and take action across their entire estate without repeatedly moving between individual environments.
Instead, everyday tasks often had to be completed account by account. Checking security posture across twenty accounts could mean visiting twenty separate views. Making a change across an estate could mean repeating the same action twenty times.
The customer needed to operate at enterprise scale, but the experience still assumed they were working with one account at a time.
One piece of customer feedback captured the gap perfectly:
"You don't really sell a platform. You sell a single login."
That quote completely reframed the problem. The challenge wasn't adding more enterprise features. It was designing workflows that allowed enterprise customers to operate at enterprise scale.
Understanding Enterprise Customers
Enterprise customers weren't simply larger versions of existing customers. They operated in fundamentally different ways, with different relationships between accounts, users and data.
Understanding those differences was important. Two customers might both appear to be managing multiple environments, but what they needed to do across those environments could be completely different.
Accounts had three distinct models:
Standard account
The simplest model. A customer operates within a single account, with users accessing and managing one set of data.
Multi-org
One customer has multiple separate organisations, often representing different business units, regions or environments. Users may have access to several of them, but the data and experiences remain separate. The primary need is separation.
Multi-tenant
A primary customer manages multiple customer accounts. This is common for managed service providers, where teams need to work across many independent customer environments. The primary need isn't simply access to each account, but the ability to operate across them.
Multi-org was designed to separate data. Multi-tenancy needed to enable work across separate data.
Managed service providers made this complexity particularly visible. A single provider could be responsible for dozens or hundreds of independent customers, each with their own users, products, permissions and security data.
Their teams weren't simply switching between accounts. They were operating a service across an entire customer estate. They needed to manage access, configuration, security posture and investigations across those customers while still preserving the boundaries between each environment.
This changed the design problem.
Experiences originally designed around one user working within one account now needed to support people working across many accounts, without losing context, control or trust.
My Role
My role was to help define a shared vision for what an enterprise platform experience should become.
Rather than owning a single feature, I partnered with Product, Engineering and leadership across multiple initiatives to build a common understanding of enterprise customer needs and establish principles that could guide decisions across navigation, permissions, configuration and reporting.
A significant part of the work involved creating alignment beyond the design team. By translating complex enterprise concepts into a shared language, I helped secure executive buy-in for long-term platform investments and created a foundation that individual teams could build upon with confidence.
The service map became a shared artefact used to align Product, Engineering and Design around a common understanding of enterprise customer needs. Rather than solving isolated feature requests, we could identify recurring patterns, establish shared principles and build a long-term platform strategy that individual teams could contribute towards.
Representative Initiatives
This wasn't one large feature. It was a series of connected initiatives that each solved a different enterprise challenge. Together they helped shift the platform from supporting access across multiple organisations to enabling customers to genuinely work at enterprise scale.
Feature Spotlight: Rethinking the Enterprise Dashboard
One of the most challenging enterprise experiences I worked on was the multi-tenant dashboard. Unlike many of the foundational capabilities, this wasn't a problem that could be solved by extending an existing experience. Bringing together data from multiple organisations is technically complex, so the natural instinct was to minimise change and build on the dashboard that already existed.
The challenge was that this assumed the purpose of the dashboard hadn't changed.
For a single organisation, the dashboard helped users understand the health of their own environment. Enterprise administrators, however, weren't responsible for one environment. They were responsible for many. Simply displaying more data, adding additional columns or repeating the same visualisations across multiple organisations didn't help them decide where to focus their attention.
Rather than starting with the existing interface, I stepped back to understand the value the dashboard was providing to customers and asked how that same value could be delivered when someone was working across an entire customer estate. The question wasn't how to scale the dashboard. It was how to help enterprise customers identify what mattered most across multiple organisations before allowing them to drill into individual environments.
The technical challenge was merging data from many organisations. The design challenge was deciding what information became meaningful once that data had been brought together. Solving both problems was essential to creating an experience that genuinely supported enterprise customers working at scale.
Managing Enterprise Access
Designed enterprise administration experiences that enabled organisations to manage users at scale. By introducing Customer Groups, customer-level SSO and cross-tenant administration, enterprise customers could define access once and apply it consistently across multiple customer environments instead of configuring every organisation individually.
Accelerating Customer Onboarding
Designed self-service onboarding that enabled managed service providers to provision new customer environments independently. By removing the need for vendor-led provisioning, customers could immediately begin onboarding their own teams, configuring new environments and delivering services to new customers on their own schedule.
Managing Configuration at Scale
Designed the experience for Detection as Code and multi-tenant APIs, enabling enterprise customers to define security configuration once and apply it consistently across multiple customer environments. Rather than repeating the same changes organisation by organisation, customers could manage configuration programmatically while trusting that updates were applied consistently across their entire customer estate.
Working closely with engineering, I translated complex programmatic workflows into experiences that helped customers understand, validate and manage automated configuration with confidence.
Enabling Co-Managed Security
Designed experiences that enabled managed service providers to work seamlessly alongside an external managed security team. The platform supported investigation handovers, shared operational context and flexible ownership models, allowing multiple organisations to collaborate while ensuring the managed service provider remained the primary relationship for the end customer.
Partnering closely with a strategic customer throughout the pilot programme, I iterated on the experience through regular feedback, helping shape a collaboration model that could scale across different operational approaches.
Outcomes
Customers could operate across their estate
Enterprise users could move beyond simply accessing multiple accounts towards managing them as a connected environment, with cross-account access, navigation, permissions and experiences designed around working at scale.
MSSPs could grow without waiting for us
Partners could create and begin configuring new customer environments themselves, immediately give their teams access and start delivering value without waiting weeks for internal teams to complete the setup.
Repeated work became scalable
Capabilities such as customer groups, APIs and configuration-as-code allowed teams to manage people and configuration across many accounts rather than repeating the same task customer by customer.
Enterprise became a platform concern
The work helped shift multi-tenancy from something addressed within individual features to a broader platform consideration. Shared customer models, research and strategy gave teams a clearer foundation for considering enterprise requirements earlier in product development.
Reflection
One thing I'd definitely do differently is invest in building a shared understanding much earlier.
For a long time I found myself having the same conversations with different people. Everyone understood one piece of the problem, but very few people understood the whole picture. Multi-org and multi-tenancy were often used interchangeably, even though they solved fundamentally different customer problems. Multi-org was designed to give a user access to multiple independent datasets. Multi-tenancy was about enabling someone to actively manage multiple customer environments. The underlying technology was similar, but the customer experience needed to be completely different.
Eventually I brought Product leadership together for a dedicated workshop to explain the different customer models, where our existing platform assumptions no longer held true and why enterprise customers were struggling. It changed the conversation almost immediately. Rather than discussing individual features, people started asking better questions about the underlying customer model and what we needed to build first. Looking back, I wish I'd run that session much sooner.
One thing that genuinely surprised me throughout this work was how much vocabulary mattered.
I have a running joke with our content designers that words are hard, but this project reinforced just how true that is. When people use the same term to describe different concepts, they naturally arrive at different solutions. Once we started being much more deliberate about our language, conversations became clearer, decisions became easier and it was much easier to recognise when people were talking about different customer problems rather than disagreeing about the same one.
Looking back, I think one of the most valuable outcomes of this work wasn't a specific feature. It was helping the organisation develop a shared understanding of what enterprise customers actually needed, creating a stronger foundation for future platform decisions.