Repositioning asset discovery as a core product experience
Only 40% of Intruder's AWS customers were using the cloud integration that most predicted whether they'd stay. The feature was critical to activation and retention, but the experience around it was actively discouraging adoption. This is how I redesigned Asset Discovery from a peripheral feature into the platform's main target ingestion funnel.
Context
Intruder is a vulnerability management SaaS platform serving 3,000+ companies, with a core customer base of mid-market and enterprise security teams. Asset Discovery - the feature that connects customers' cloud infrastructure to the platform for vulnerability scanning - was critical to both customer activation and long-term retention.
Despite its importance, only 40% of AWS users were using the available cloud integration. The team was operating without a dedicated Product Manager, which meant myself and the lead engineer jointly owned scope, implementation, and release. Every design decision had to earn its complexity.
The problem
To connect a cloud estate, a user navigated to the Targets page, opened the Discovery tab, and added a single subscription at a time - re-entering credentials for each one. For a company with tens of AWS subscriptions, each containing hundreds of assets, this meant repeating the same manual process until task fatigue set in.
Automation options existed, but came with a significant catch: if the wrong licence was applied, it would tie up that licence for a full billing month with no recourse. That risk was enough to make most users avoid automation entirely. 60% of AWS customers were manually adding individual targets, not because they didn't care about their exposure, but because the alternative felt financially unpredictable. For a security product, that's not just a UX failure. It's a product failure.
Four interconnected issues held Asset Discovery back:
- One-by-one connection - customers could only add a single cloud subscription at a time, unusable at directory scale
- Hidden feature - the toolset was buried within the portal, invisible without explicit direction
- Licence anxiety - automated licensing could trigger unexpected charges, creating genuine hesitation
- Outdated UI patterns - a shift in ICP meant asset volumes had grown exponentially beyond what the existing interface could handle
Research and insight
Analytics gave us the shape: where users dropped off, how estate size varied across our base, and - crucially - that users who adopted cloud integrations had measurably higher retention and NPS than those who didn't. Integration adoption during trials was a leading indicator of activation.
We interviewed customers who used the feature regularly, and those who had consistently avoided it. A conversation with Kevin Hand, CISO of River Island, reframed the problem entirely. We'd assumed the biggest source of friction was the interface.
Kevin's team had resisted integration not because it was hard to find or configure, but because they didn't trust what would happen to their licence when they did. The automated billing model felt like a trap. Until we addressed that anxiety, no amount of UI improvement would move the needle.
The core challenge that emerged: customers needed bulk import capabilities supported by granular, transparent control over what got licensed and when - and the ability to explore the integration without making any financial commitment upfront.
Strategic reframe
Before committing to a direction we considered alternatives. Changing the licensing model directly would have addressed the root cause most cleanly - but Intruder's scanning infrastructure depended on Tenable, which constrained what was commercially feasible. Optimising the existing subscription-level flow would address task fatigue without touching the confidence problem. We also briefly considered a guided wizard, but that would have added ceremony without solving the underlying data model limitations.
The structural decision we landed on: move to directory-level imports. One set of credentials at directory level to import all subscriptions and assets in a single operation. Three things had to be true before we touched individual interaction patterns: prominent placement, a design built for directories not just subscriptions, and an experience that felt like the default entry point - not a layer bolted on. Optimising the existing flow would have addressed task fatigue without touching the confidence problem. The directory model addressed both.
Solution
The Discovery hub became the first page customers saw - aggregating all discovery methods with a clear path to add new ones. Cloud integrations surfaced detected accounts, removing a key activation barrier for customers already using cloud platforms without having connected them.
Four interaction principles shaped the experience beneath it:
Progressive disclosure
Assets segmented by status - Unresolved, Targets, Excluded - letting users navigate by task without cognitive overload. The status bar gave an at-a-glance read of triage progress across every subscription.
Granular sync controls
Customisable sync rules let users control precisely which assets got ingested - user sync, sync all, or selective sync with tag-based rules. Critically, this separated the act of exploring an integration from making any financial commitment, directly addressing the trust issue surfaced in research.
Directory-level view
Directories became first-class entities - identifiable, automatable, and prioritisable. A single credential set at directory level was all a user needed to import every subscription and asset beneath it, with per-subscription sync settings manageable in bulk.
Bulk triage (inbox-zero metaphor)
Progress through triage was visualised as a status bar showing the proportion of Unresolved, Targets, and Excluded assets - giving the experience momentum and a clear sense of completion. At subscription level, users could triage individual assets with contextual recommendations.
Embedded expansion flow
Intruder's first in-product upsell mechanic - designed to let users licence exactly the targets they wanted, working around the automatic allocation model that had been causing anxiety. The upsell was deferred to a follow-up release to ensure users trusted the experience before being asked to spend more.
Constraints and trade-offs
Licensing was the single biggest pain point, but restructuring it entirely was beyond what was commercially viable at the time. We made a deliberate decision to design around it - containing the problem rather than solving it - so we could move forward with confidence. The sync rules and pre-commit visibility were the design answer to a problem we couldn't fix at its root.
The upsell workflow was deferred to a follow-up release: fix the top of the funnel before optimising the bottom. Engineering was small and shipping across multiple cloud platforms quickly, so the key tension was between depth of sync rules and comprehensiveness of recommendations - we delivered on the former and deferred the latter.
Outcomes
Revenue growth came primarily through customer expansion - existing customers growing their usage once the experience gave them confidence to do so. Trust first, then growth.
Reflections
Carrying both design and product ownership front-loaded a lot of coordination work. More time than I'd have liked went on stakeholder alignment rather than exploring the full solution space. In hindsight I'd have pushed earlier to get even lightweight PM support in place, or been more ruthless about protecting design time during discovery.
The investment in the first integration compounded quickly. By the time we moved to Azure and GCP, the design system and structural decisions made for AWS meant those integrations were largely repurposing existing work. The modular approach paid off precisely because we'd taken the time to get the underlying model right.
The Tenable dependency was the constraint sitting underneath everything - it shaped the licensing model, which shaped the trust problem, which shaped most of the design decisions. Long term, diversifying away from that dependency would have unlocked a more fundamental fix. Working around a constraint isn't the same as resolving it.
Three things I'd return to given more time: richer visualisations and granularity in the asset sync controls, replacing siloed discovery methods with unified views, and better use of asset type and behavioural baselines to inform automation defaults.