As the lead PM on Application Control, I advocated for a user-centered mindset, nurtured cross-team partnerships, and worked with them to facilitate recurring feedback sessions with a key group of IT Professionals representing security-conscious enterprises and government organizations.
|2 years||lead PM & researcher||3 primary engineers||systems thinking, relationship building, focus groups|
Although Application Control tooling was available for free to Enterprise customers, it faced limited adoption in large part because its lack of integration with Microsoft's management platforms made configuration, deployment, and maintenance enormously difficult. Behind the scenes, our team had no design or research involvement, and no direct line of communication with users.
Instead of taking a reactive approach in which a device assumes that all files are trustworthy and then tries to block known malicious files with an antivirus solution, application control can be used as a proactive approach in which applications must be designated as trusted in order to run.
The Australian government’s Cyber Security Center lists application control as one of their “Essential Eight” strategies to mitigate cyber security incidents, calling it “one of the most effective mitigation strategies in ensuring the security of systems.”
Our users were primarily IT Pros responsible for implementing and managing their organization’s application control systems. In turn, end-users are the employees who actually use company devices which are locked down via application control.
Application control is inherently difficult to get right: overly lax systems may still allow malicious applications to run, while overly restrictive systems may prevent end-users from running applications they need for their work.
For my first project after being promoted to take over application control, I was tasked with shipping a feature improvement that my predecessor had designed, intending to make 'S mode' more appealing by giving enterprises the option to loosen the policy restrictions to allow their custom applications. The plan was to add a point of integration with Microsoft Endpoint Manager, a management solution that enterprises could use for security as well as general fleet management.
I managed a tricky partner-team relationship, worked with our engineers to stay on schedule, wrote public-facing documentation and release articles. And the project succeeded! I was thrilled to have put my first feature improvement out into the world.
After shipping, I finally had the time and confidence to start questioning the work. My sense of excitement quickly crumbled as I started asking questions and testing out our tooling in more depth. I ran into issue after issue while trying to follow our public documentation to get a test case set up. I learned that the feature we just released only worked for a specific mode of Windows, despite the underlying technology being consistent on standard Windows as well. And I came to understand that although we had built out a single point of integration with Endpoint Manager, our product was otherwise still operating in a silo.
I began questioning the norms under which my team operated. How had we gotten to this point? What were we prioritizing, intentionally or not?
Before we began talking to users, I wanted to ensure that we had a consistent internal story across Microsoft's app control offerings. To do this, I first had to prioritize building up cross-team partnerships.
The timing was fortuitous, as two crucial and related teams (Endpoint Manager and Advanced Threat Protection) had also recently promoted new employees to take over application control. Both of these people were asking similar questions: what had caused the fragmentation and duplicated work between our teams? How could we fix it
Thanks for stopping by!
If you're interested in chatting about my work, feel free to email me at firstname.lastname@example.org or reach out on LinkedIn.