Assignment maps
A revolutionary new way to scope configurations to managed devices.
Role: Product Designer (solo)
Team: Product Manager, 4-6 engineers
TLDR;
The method of scoping configurations to devices in the MDM space has always been complex. When the Kandji product was first built it took a uniquely simple approach to this problem, but as users needs grew and more functionality was required, the approach was not scaling.
I identified this problem and led an initiative to pause upcoming feature work which would build on the unscalable solution, and pivoted the team's focus to discovery research to revaluate user needs. I proposed a radically different solution based on customer research, and was the primary definer of it's features and functionality. I worked with PM and engineering to gain approval for, define, build, test, and market this solution.
The feature, Assignment Maps, has resulted in 2 patents pending for it's innovative approach to scoping management.
It unblocked $8,161,254 of ARR, reducing redundant scoping configurations by 13.6%, and meaningfully differentiating Kandji from competitors.
163,718 devices are currently managed using this feature which currently has an adoption rate of 48.52% across the platform (aprx 1 year post-release, legacy solution not yet deprecated).
The Mobile Device Management space
Kandji is a Mobile Device Management (MDM) software. MDM providers are used by IT Admins to configure and manage the company's devices. If you've ever been forced to reset your password or update your OS on your company computer, this is likely a setting that you employer's IT Admin has set up for your device. We refer to these as configurations.
Configurations can also be scoped, similar to how a marketing campaign may want to scope certain ads to certain target audiences. For example, your computer may need different password reset settings than the CEO's.
Most competitor solutions allow scoping directly to user groups, eg "ELT gets X configurations", "R&D org gets Y configurations".
However, as complexity increases, it can become difficult to see what all configurations a device should receive and why. Also, some configurations may conflict. For example, one configuration may tell your device to run Sonoma operating system and one may tell it to run Ventura, but a device can only run one operating system at a time. In these cases, competitors do not have any way to resolve this kind of conflict and it results in an error on the device.
Kandji's approach
In Kandji, rather than scoping configurations directly to groups, admins
- 1. Create a Blueprint
- 2. Put the desired configurations in the Blueprint
- 3. Assign the device to the Blueprint
This creates a clean source of truth for all the configurations on a device, rather than looking through all the associated user groups to determine why the device received certain configurations.
If there any any conflicting configurations, Kandji simply does not allow these configurations in the same Blueprint.
However, there were some problems with this model
1. Whenever different configurations were needed for different devices, a new Blueprint was made, leading to a proliferation of Blueprints. This led to more manual work when configurations needed updated across Blueprints.
2. When onboarding new devices, it was difficult to identify the right Blueprint to enroll them in.
3. When devices changed attributes (such as when users changed departments), they would need to be manually moved to a new Blueprint.
Later, "Assignment rules", scoping logic tied to the configuration itself, were introduced to allow for more scoping granularity in Blueprints. However, this meant the Blueprint was no longer a source of truth for all the configurations a device would get, and made it difficult to troubleshoot configuration assignment.
and more complexity was coming...
When I joined, several features were already slated to build on this model which was not scalable. The planned features were attempting to address three major points:
- 1. Conflict resolution
The current model simply did not allow conflicting configurations in the same Blueprint. This led to more Blueprint proliferation. How might we allow >1 of these conflicting configurations and, when present, resolve the conflict without the user having to do anything?
- 2. Reusable groups of configurations
Making changes to a group of configurations was time-consuming as it needed to be repeated across all Blueprints. How might we make it easier to manage and update configurations as a group?
- 3. Moving upmarket
- The company wanted to move upmarket. With the current solutions, enterprise users would need to manage many Blueprints to achieve their more complex scoping needs. How might we create a more scalable solution that allows for complexity without becoming complicated?
Permission to take a step back
By proving out some of the planned solutions, I was able to illustrate how they would not scale for our future needs. I successfully made the case to pause on the current trajectory and conduct foundational discovery research on scoping configurations.
I worked with User Research to conduct interviews with 5 enterprise customers. I had them walk us through their current scoping setup and describe how, ideally, they would be able to manage their scoping. Our 5 main findings were:
- 1. Ideally, almost all their devices could be managed in one Blueprint
- 2. Ideally, they can reuse all their scoping from their identity provider
- 3. Groups of configurations would be useful for certain cohorts (eg Design)
- 4. Global groups of configurations would be useful for global/cascading updates
- 5. Groups of configurations must allow nesting of more groups/rules
-
"If I'm installing a Avid Media Composer, I also need to have Adobe Premier and Adobe Media Encoder. Like those three things would always go together. But here's a splinter thing- If I've got Avid Media Composer, well, if the device is in-house, I need the Avid Nexis, if it's out of house, I don't want the Avid Nexis on it. There's some things like that that kinda branch out." - IT Admin at Whitehouse post
Based on these findings, I had one major takeaway:
We need a layered approach to scoping:
After presenting this proposal, leadership was interested in the concept but still apprehensive about reimagining the core product. My PM and I embarked on a campaign to get buy in at multiple levels of the company. This involved leveling up in some fidelity while moving quickly.
Green light on the project, onto user testing
After many conversations, we got the go ahead on to continue pursuing this project!
Next we needed to validate that this concept solved our user's problems, and ensure that the design was usable. At the same time, our engineering team started investigating feasibility and frameworks. I put together some mid-fidelity prototypes so we could quickly test the concept as well as four main user actions.
- 1. Creating a map
- 2. Adding scoping logic and configurations
- 3. Nesting configurations
- 4. Looking up a device's logic
-
Overall, the concept was a success! There were several learnings to improve the design and interactions.
- 1. Confusion over a time-based vs logic flow
Some participants interpreted the flow as more of an automation triggering sequential actions in time, rather than a visualization of logic with one action (assigning the configurations) at the end. Indicators were added at the beginning and end of the flow to define the actions that would happen.
- 2. Confusion over similar looking buttons with different actions
In the tested designs, adding an "if else" statement and adding a nested conditional block were both done through a "+" button. This was resolved by differentiating the buttons through style and text.
- 3. Search facets unclear, unqualified items in results not visible for inspection
A simple search bar allowed users to search by multiple device facets to target a device in device lookup, however it was unclear what they were searching on. In the results of the search, items were greyed out if a device did not qualify for them, but users wanted to see these unqualified items in order to troubleshoot why a device did not receive them. The search was redesigned as a filter to show more complex information about the device, and an interaction was added to unqualified items to reveal them on hover so users could inspect them.
- 4. Users were not aware when conflicting configurations were added
- An important aspect of this feature is that it allows conflicting configurations in the same Blueprint. Most users did not notice this feature, which could lead to unexpected things happening on their devices if they did not understand how we resolve priorities. We added an alert when conflicting configurations are added to let them know how we handle this resolution and allow them to cancel.
Final design and demo
Key features
Reusable groups of configurations
Admins can create groups based on facets of the device or user, and configurations can be added or removed from these groups as needed. These configurations go to any device in the Blueprint that meet that groups' logic.
Device lookup
A device can be looked up on the map, and once selected the map will highlight the path the device takes through the map's logic to receive it's assignments.
Conflict resolution
Whichever of two conflicting configurations appears last, or furthest right, in the map is given priority in resolving the conflict, allowing admins to easily make overrides without affecting anything upstream.
With all these features combined, we were able to solve multiple user problems including
- 1. Reducing manual work to update devices with different configurations
- 2. Making it easy to troubleshoot and understand why a device received certain configurations
- 3. Allowing for nesting of configurations, eliminating the need to make a new Blueprint for offshoot assignments
- 4. Eliminating the need to manually find the correct Blueprint for a device on onboarding, or manually move a device when its attributes change
-
- 5. Allowing for conflicting configurations to be managed on the same Blueprint, without ever creating a conflict error on a device
Going to market and initial reactions
My PM & I demo-d the product in our June 5 youtube launch event. I also worked behind the scenes to advise on the script, example scenarios, and create assets. As customers began to use the feature, the initial feedback was overwhelmingly positive. Customers were impressed with our ability to differentiate and out-innovate our competitors.
Continued success
This feature resolved multiple revenue blockers valued at a total ARR of $8,161,254 and resulted in two patents pending for it's innovative approach to scoping configurations.
As of March 5, 2025 (9 months post-launch):
There are 5,400 Assignment Maps in Kandji
48.52% customer adoption
Our top customers are managing 28k devices on maps
Across Kandji, there are 163,718 devices on maps
There is a 13.6% reduction in # of Blueprints for tenants using Assignment Maps
Ongoing enhancements
Our team continues to enhance this feature, with the goal of fully deprecating the legacy solution by the end of 2025. To that end we have several features recently implemented and on the roadmap to continue optimizing this solution. A few examples:
More resources
