During my time as lead Program Manager on Application Control tooling, I drove holistic product and process improvements such as building cross-team partnerships, leading a major documentation overhaul, and generating insights from co-design sessions with customers to inform feature work.


2 years


lead PM & researcher


3 primary engineers

Key Skills

strategy, service design, HCI research


What is application control?

Application control is a security strategy that restricts what applications are allowed to run on a device. 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.

Why is it important?

Application control is a crucial part of an enterprise’s holistic security suite, preventing file-based malware and spyware from taking over a system or stealing sensitive credentials. 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.”

Who uses it?

Microsoft Application Control is primarily used by security-conscious enterprise customers. 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.

What problems were users facing?

Application control is an inherently challenging space, since organizations must balance security and productivity: 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.
Even though Microsoft Application Control tooling existed, it came with inadequate support and an array of idiosyncrasies that prevented many customers from successfully deploying and maintaining it across their systems.

Our Goal

How might we lower the barrier for enterprises to proactively defend their systems against malware and spyware by using Microsoft Application Control?

Gaining Context

Understanding The Product

Upon beginning work on Application Control, I first tried learning to use the product myself in order to get a handle on its current state and figure out what to prioritize in the existing list of potential feature changes. I quickly experienced firsthand how challenging it was to implement, even in a test use case. During set up, I ran into incomplete, outdated, and incorrect documentation that frequently left me relying on the expertise of my teammates. When I was finally ready to deploy it to my test device, I discovered that I had to do so using outdated technologies which relied on text rather than visual UI. My teammates informed me that there was not yet any integration with Microsoft's newer and more popular management systems, like Microsoft Endpoint Manager.

Understanding user feedback systems

After gaining a handle on the basics of Application Control, I began sorting through our backlog of potential feature changes. When I asked my manager and teammates how we knew what was important to customers so we could determine prioritization, I found out that we had basically no feedback channel. While quantitative data around security features is a known issue (security-conscious enterprises are unlikely to allow Microsoft to collect telemetry data), I was surprised to learn that we had minimal ongoing relationships with customers to gain qualitative data.
To get a sense of what our users were saying online, I looked into a number of security IT blogs that covered Microsoft Application Control. I saw common complaints of usability and documentation issues, including one IT pro who in 2018 said “whenever a new Windows build is released, I diff the Windows Defender Application Control [...] code integrity policy schema [...] to see if there are any new, interesting features. I resort to doing this because new WDAC features are seldom documented.”

I realized that by focusing on feature work, we were trying to fix symptoms instead of causes.
To build a high-quality product, we first needed to address the deeper issues by redesigning our internal processes.

Process Improvements

I led a three-pronged approach to improvements on my team's processes surrounding Microsoft Application Control:

  • Co-created a cross-team partnership to support seamless integration of application control into other security offerings
  • Advocated for standardizing documentation best practices across my PM team
  • Supported the creation of a recurring participatory design series with a core set of enterprise users

Cross-Team Partnership

No matter how much our team perfected Microsoft's Application Control tooling, it wouldn't work in a silo.

This tooling is intended to allow enterprises to build lists of allowed and blocked applications, thereby creating strong security guarantees. However, it relies on management tooling to be deployed, and cloud-based intelligence to make sense of what is actually happening in the enterprise's device ecosystem.

Because these integration points were almost entirely nonexistent when I started, building a relationship with Microsoft's enterprise device management and cloud-based security teams was the first area that my team and I needed to target. No matter how good WDAC is, won’t work in a silo Joined mid-cycle for a product improvement (LOB sideloading), started asking why this got prioritized and why our integration with MEM wasn’t deeper Also found out that Defender ATP (cloud-based) was building their own version of app control Broken line of communication Luckily, both of the PMs on these teams had recently taken over this area and quickly understood how fragmented this story was

Documentation Best Practices


Recurring User Feedback Sessions


Product Improvements



unresolved challenges
  • inherent technical complexity
  • prioritization (ex. research plan)
  • quant measure of success (most security-conscious orgs turn off data reporting back to MSFT)