I revamped Lever’s access and permissions model (RBAC), which was a high-demand, high impact request from 32 customers, totaling over $2.4MM in annual contract value. The project took 6 months start to finish, resulting in a custom roles feature that allowed customers to define and create roles tailored to their needs, achieving a 57% customer retention rate, generating over $1.2MM in gross revenue, and attaining a 75% adoption rate within 3 quarters.
In Q3 of 2023, the executive leadership team conducted a poll amongst Lever’s strategic customers, showing that 100% voted RBAC as the most valuable feature.
I inherited this project after the original product manager left Lever, where it was then passed to a different PM, who also left Lever. Their initial hypothesized problem was around the idea of "access inflation", which hypothesized that due to too many unknowns and risks of blockers, users get the highest level of permissions by default from their orgs. This could be a potential risk for companies, since the highest level of permissions known as "super admins" or "sadmins", have access to all information on hired and non-hired candidates, including private or sensitive candidate and employee data.
In addition to the above, a known core issue was the lack of available management and visibility into existing permissions and access roles assigned to employees org wide, or individual views into permissions, meaning ICs never knew the level of permissions they had, were supposed to have, or in a worst case scenario, not supposed to have.
Access roles identify groups of permissions that apply to a user within an org. This is usually based on their title and job function (or persona). Access Roles go from limited capabilities to 100% unrestricted access, including all employee and candidate details.
It was unclear to admins which access groups were the best match for their employees which resulted in concern and distrust in what they were providing. Some concerns included employees having access to hired employees information, salary details, confidential information, access to their own candidate profiles pre-hire, including notes written about their interview performance, and more.
Lever has 5 access roles: Sadmin (super admin), Admin, Team member, Limited team member, and interviewer.
Permissions are the individual features or functions users can or cannot access within the product. Access roles come with their own set of permissions by default, but users can layer in additional permissions for sensitive or private content on an as-needed basis. Permissions were too rigid due to the inability to customize, making it difficult for customers to find the right fit amongst Lever's 5 pre-defined role buckets.
For example: if one employee met the criteria for an access role, but one permission was missing required for them to get their job done, the only way to grant that permission is to assign the access role one tier higher. This would provide that employee access to additional areas of the tool that might be confidential, thus compromising security.
One of the challenges during research was how Lever employees used “personas” and “access roles” interchangeably. This caused confusion with product owners as they thought personas were individual, company defined entities around our users "jobs to be done" directly mapped to how our product defined access roles within the product.
However this was not the case as personas didn't exist yet! Roles were the closest thing product had to understanding how customers might be using the product, but created risk in feature planning since neither personas nor role use cases had been tested or validated.
Researching Lever's RBAC architecture for the access model, mapped permissions sets, and private data. Being fully informed of the relationships between roles and existing permission sets as well as how we defined and mapped those to each user was crucial to success.
Lever did not have known or defined company level personas. Product had a list of 22 different job titles involved in the hiring process without any defining factors to them. I needed to understand how users role tied to a set of permissions, and how those roles/titles changed based on company size and team structure.
I spent time reading through our top competitors configuration documentation to understand what type of roles they offered and how that mapped into their system, back to their users. Being able to pull themes from this research enabled us to rule out potential paths and focus in on the key areas of our solution.
I interviewed an internal team of recruiters, customer success managers, and implementations teams to validate design direction, hypotheses, and discuss how customers approach roles, titles, and permissions, as well as their blockers and biggest pain points today.
After combining all of the above into potential path forwards and high fidelity mockups, I needed to validate the direction we were headed and test solutions with our customers. I spoke to 10+ CSM, recruiters, and talent operations teams across all market segments to validate our original hypothesis.
With internal and external customers I validated more within the default permission sets hypothesis: "Do user personas and their jobs to be done tie directly to product access?" I inquired more on what users considered “safe” and necessary in a listed group of role titles and associated job functions as well as private permissions, or the things users may feel are necessary to get their job done, but risky to include as a "default" without level or title considerations.
I synthesized competitor permission models and found that the common theme amongst all competitors was the way they structured their permissions. It was less focused on granular job titles and more focused on what users are doing in the product or what users need to see and manage.
A trend amongst enterprise orgs was the limited amount of "super admin" roles allotted within the platform. Due to enterprise security and compliance concerns regarding employees access with each tier Lever offered, they decided to restrict all access available to talent and recruiting teams, creating entirely new workflows that required manager approvals for users to view or access application details and job postings. This created hours of extra work and long delays for employees that need to manage the candidate pipeline, slowing down their hiring process and unfortunately in some cases, losing talent due to long waits and the inability to negotiate compensation.
The "add new user" screen in the onboarding flow containing role and permissions assignment.
Custom levers added for users to gain visibility into each individual permission included within a role, the ability to remove as needed, ability to group permissions by location, office, or department, and added visibility into private permissions.
I led a session between myself, stakeholders, and my PM to re-strategize our MVP approach. We used this session to discuss tradeoffs and ideal solution from a business and customer needs perspective given our newly uncovered insight. We felt it was crucial to pivot away from mapping persona to permissions 1:1 until we could integrate with an HRIS tool and automate the collection and mapping of user details to each role. This would provide a more targeted and precise approach when enabling automated permissions provisioning, rather than needing to build the backend model from scratch during our MVP.
Knowing what customers defined as "success" for our permissions model, it was crucial to offer access roles that matched how their org approached talent operations and recruitment. We wanted to enable our customers as quickly as possible while staying on track for our MVP release date.
Custom permissions was a beneficial move that had business stakeholders excited, customers excited, and kept our release on track and aligned with business outcomes. Our solution would additionally allow us to scale easily as we move into phase 2 and beyond.
