A tool for better visibility of cloud software usage in Enterprises

Reframing a shadow IT "kill switch" as visibility and human-to-human coordination.

Reframing a shadow IT "kill switch" as visibility and human-to-human coordination.
Don't have the password? Get in touch
Lead designer on a cross-functional team. I joined the project at inception and fundamentally reshaped its direction, phasing, and go-to-market framing.
With the increased adoption of cloud tooling and low barriers to product expansion, products being created and managed by users outside of the IT department becomes a serious and costly management problem. Studies showed that 79% of IT admins believe the security of company data is at risk due to Shadow IT.
Admins are responsible for how their company utilises cloud software — they therefore need visibility into how their company utilises cloud software.
The product manager had mapped out a phased roadmap leading with a "kill switch" that would let centralised IT block specific email addresses from signing up. I saw several risks with this approach.
First, it only governed the Atlassian ecosystem. If a nimble team hit a block, they'd sign up with a competitor. The governance didn't solve shadow IT — it just pushed it elsewhere. Second, there were legitimate cases of satellite IT: departments that managed their own licenses and budgets. A blanket block would flatten that nuance. Third, new Atlassian products trying to gain traction would be trivially easy to block wholesale, cutting off bottoms-up growth — the engine that powered Atlassian's go-to-market model.
There was also a practical inevitability I kept raising: even if we shipped the kill switch, it would only apply to net new resources. What about the existing resources that were already in breach? There would still need to be human-to-human coordination — we couldn't just shut them down. User experience principles aside, legally we couldn't. So the coordination capability was needed regardless.
And then there was the customer maturity spectrum. Through our research, we found the range was enormous: people who didn't know what shadow IT was, people who knew and didn't care, people who'd care once they learned, and people who already cared deeply. That spectrum meant we had to tread carefully with outreach — we couldn't assume a uniform level of concern.
I argued for visibility and human-to-human coordination first. Instead of a kill switch, give administrators line of sight into what resources their managed accounts had created or joined across the Atlassian cloud. Show them what exists. Provide communication pathways so they can reach out and have a conversation — sanction it, migrate it, or shut it down, on a case-by-case basis.
This was bundled into the existing Access management subscription as an extension of account management capabilities. It kept users within the Atlassian ecosystem. It was a conversation, not a wall.
The kill switch phases still existed in the roadmap — they were reordered, not removed. But leading with visibility meant we could ship something that was immediately useful, lower risk, and strategically aligned with Atlassian's bottoms-up growth model.
I advocated for a usefulness signal built directly into the feature. We sent email notifications to organisation admins whenever new products were discovered within their managed accounts — batched, not real-time, with the ability to opt out.
The initial email served as a triage: given the customer maturity spectrum, we needed to first understand whether this admin even cared about this information. Those who opted in received ongoing monitoring. Within the feature itself, we placed a usefulness survey and a qualitative feedback collector, alongside utilisation tracking — did they export the list, did they directly contact someone.
The experience drove a 3x higher evaluation rate, with 57% purchasing.
88% of admin respondents said they found this feature useful.
56% of all unique admin visitors contacted discovered accounts or exported this data, and less than 1% opted out of notifications.
Subsequent efforts approached the problem space with richer domain understanding due to the feedback collector we built into the first release.
There was also friction. Some admins were frustrated that the information was gated behind a paid subscription. My view was that this was conceptually consistent — SSO, security policies, and access management were already behind that subscription. If you're operating at the scale where shadow IT matters, you're operating at the scale where that subscription makes sense. But it was real feedback.
Just want to say how cool the Discover Products feature is — I got the email today and found out about two other Jira instances we had no visibility of previously! So a huge thank you for that one.
— Atlassian Customer
After I offboarded from the project, I passed along thinking on how the feature could evolve toward a request-based system — where administrators could set preferences for how users request new resources, rather than blocking or just monitoring. Others carried that forward, and the feature eventually incorporated application request and user request workflows closer to that original philosophy.