I led a 6-month overhaul of Lever’s Role-Based Access Control (RBAC) model, addressing a high-demand request from 32 customers representing over $2.4 million in Annual Contract Value (ACV). The project resulted in the creation of a custom roles feature, allowing customers to define and tailor roles to meet their specific needs. This initiative achieved a 57% customer retention rate and generated over $1.2 million in gross revenue within three quarters, with 75% of customers adopting the feature in the same period.
In Q3 2023, Lever’s executive leadership team polled its strategic customers, and 100% voted RBAC as the platform’s most valuable feature. This project not only resolved critical customer challenges but also drove substantial business growth and customer satisfaction.
I took over as the lead project owner after two previous PMs transitioned out of Lever. The initial problem centered on "access inflation," which suggested that, due to uncertainties and potential blockers, organizations often default to granting users the highest level of permissions. This poses a significant risk, as "super admins" (sadmins) have unrestricted access to all candidate and employee data, including sensitive or private information. Addressing this issue was critical to ensuring organizational data security and maintaining trust.
Another core issue was the lack of tools for managing and monitoring permissions and access roles across the organization. Employees had no clear visibility into their assigned permissions, leaving individual contributors unaware of the access they had, should have, or—worse—shouldn’t have. This gap created significant risks, including unauthorized access to sensitive information and confusion about role-based responsibilities.
Access roles define sets of permissions assigned to users within an organization, typically based on their job title, function, or persona. These roles range from limited access to fully unrestricted permissions, which include visibility into all employee and candidate information.
However, admins often faced confusion and uncertainty about which access role was the best fit for their employees. This lack of clarity led to concerns and distrust, particularly regarding sensitive data. For example, employees were sometimes granted unintended access to confidential information such as salary details, notes on their own interview performance, or private data about hired employees.
Lever’s access model includes five predefined roles: Super Admin (Sadmin), Admin, Team Member, Limited Team Member, and Interviewer. Each role carries varying levels of permissions, but the existing structure made it challenging for admins to confidently manage access without risking over-permissioning or exposing sensitive data.
Permissions define the specific features or functions that users can access within the product. Each access role comes with a default set of permissions, but additional permissions can be layered in for sensitive or private content as needed.
The lack of customization in Lever’s permissions model made it difficult for customers to find the right fit within the five pre-defined access roles. For example, if an employee needed a single additional permission to perform their job, the only option was to assign them a higher-tier access role. This often granted unnecessary permissions to confidential areas of the platform, such as sensitive data, compromising organizational security. The rigidity of this system created inefficiencies and security risks for customers.
A key challenge identified during research was the confusion between "personas" and "access roles." Lever employees often used these terms interchangeably, leading to misalignment in product understanding. Product owners assumed that personas—user archetypes tied to specific "jobs to be done"—were directly mapped to how access roles functioned within the platform.
However, this was not the case. Personas had not been developed or validated, leaving access roles as the closest approximation for understanding user needs. This gap created risks in feature planning, as roles had not been tested against real-world use cases, resulting in assumptions about how customers utilized the product. Establishing validated personas became critical for aligning product strategy with user behavior and needs.
Understanding Lever’s RBAC architecture and its access model was essential to success. I delved into the relationships between roles, permission sets, and private data, ensuring I fully grasped how each role and its associated permissions were defined and assigned to users. This foundational knowledge set the stage for informed design decisions and a cohesive solution.
Lever lacked defined company-wide personas, leaving product with a list of 22 job titles involved in the hiring process, but no clarity on their responsibilities. I worked to map these roles to permissions by exploring how user roles aligned with specific tasks, and how these roles shifted based on company size and team structure. This process was critical for creating a flexible and scalable permissions model.
To better inform our solution, I conducted an in-depth review of our top competitors' configuration documentation. I explored how their roles were defined, mapped to permissions, and tied back to user needs. This research surfaced key patterns, helping us avoid potential pitfalls and focus on areas of differentiation within our solution.
I collaborated with internal stakeholders—including recruiters, customer success managers, and implementation teams—to validate design directions and uncover insights. These conversations shed light on how customers approached roles, titles, and permissions, as well as their blockers and pain points, directly shaping our approach.
Armed with research, prototypes, and high-fidelity mockups, I turned to our customers to validate our direction. I conducted interviews with over 10 recruiting and talent operations teams across all market segments. These discussions confirmed our hypotheses, refined our designs, and ensured the solution met diverse customer needs.
Through internal and external customer interviews, I validated aspects of the default permission sets hypothesis: "Do user personas and their jobs to be done tie directly to product access?" This research delved into what users consider “safe” and essential within role titles and permissions, as well as what might be too risky to include by default without considering specific roles or titles.
A key finding was that users had varying perspectives on what permissions should be standard versus customizable, depending on their responsibilities and the sensitivity of the data involved. Additionally, competitors’ approaches to permissions revealed a major trend: they focused less on granular job titles and more on what users needed to do within the product or the data they needed to manage.
These insights informed the redesign for the "Add New User" step within the onboarding, introducing key flow improvements, such as role and permissions assignment. Custom controls allowed users to gain visibility into the individual permissions within each role, remove permissions as needed, group permissions by location, office, or department, and view private permissions with added clarity.
Managing the Product or Platform: The most elevated access role across competitors was often labeled "Org Admin." This role included responsibilities like managing user profiles, access, statistics, integrations, compliance, payments, and platform add-ons. Competitors tailored access based on whether the user was managing the entire ATS software or specific organizational functions.
Managing Talent and Hiring Processes: These roles, typically referred to as "Standard" or "Job Admin," varied in granularity. For instance, Greenhouse permissions were segmented by assigned job title once linked to a specific job, whereas ICIM grouped all hiring roles under a “Full Access User” category. Users often required additional permission layers when assigned to specific teams or job openings.
Interviewing and Reviewing Candidates: This role was often labeled as “Interviewer,” “Basic,” or “Limited.” It provided the most restricted access, suitable for users who did not manage the platform or hiring processes but were involved in interview panels, candidate feedback, and referral submissions.
One of the most critical insights came from observing trends within enterprise organizations. These customers frequently restricted "super admin" roles due to security and compliance requirements. However, this strict role segmentation led to unintended consequences.
Enterprise talent and recruiting teams often faced severe limitations in access, which disrupted workflows. For example, employees required manager approvals to view applications or job postings, creating hours of extra work and long delays. These bottlenecks slowed down hiring processes, causing talent pipeline issues, and in some cases, resulted in lost candidates due to delays in offer negotiations.
This insight highlighted the need for a solution that balanced enterprise security requirements with operational efficiency, ensuring that critical permissions could be managed flexibly without compromising compliance or speed.
In collaboration with stakeholders and my PM, I led a re-strategizing session to refine our MVP approach. Given our newly uncovered insights, we pivoted away from mapping personas to permissions 1:1, deciding instead to integrate with an HRIS tool in the future. This integration would automate user detail collection and enable precise permissions provisioning, streamlining operations while maintaining scalability. For our MVP, this shift allowed us to focus on immediate customer needs while laying the groundwork for more advanced features in later phases.
This approach ensured alignment with how customers define success in permissions management. By offering flexible, tailored access roles that mirrored how organizations approached talent operations and recruitment, we delivered a solution that resonated with both customers and business stakeholders. Excitement around custom permissions kept the project on track for its MVP release while opening the door for seamless scalability in future phases.
