A generic admin/member split did not match how enterprise teams work, so sharing and onboarding needed hand-holding.
Rebuild permissions as role-based access control mapped to the 5 personas who actually use the platform.
Enterprise accounts could finally share work and onboard on their own. Security complaints went down.
- Generic roles → persona roles
- 2 → 5
- Workspace, project, user features
- 3 levels
- Security complaints
- Fewer
Context
- Company
- VectorShift (YC S23), multi-tenant enterprise platform
- My role
- Redesigned the permission system
- Users
- The 5 personas who use the platform, and the admins who manage them
- Trade-off
- Chosen over flashier feature work
The problem
Permissions had two roles: admin and member.
An enterprise account is not two kinds of people. A fund has partners who need to see everything, analysts who build, outside advisers who should see one project, and IT staff who manage access but should not read deal data.
With only two roles, sharing work and onboarding a team needed hand-holding from us. I picked this over more visible feature work, because it was blocking adoption of those features.
- Enterprise onboarding needed hands-on help.
- Security complaints were coming in.
- The complaints came from accounts whose structure the two-role model could not express.
Constraints & non-goals
Constraints
- Multi-tenant. Permissions have to work across workspaces, projects and user-level features.
- Roles map to the 5 real personas, not an abstract list of permissions.
- Existing accounts move over without anyone losing access they depend on.
Out of scope
- A fully custom permission builder for every user.
- Field-level permissions on individual data points.
- Changes to single sign-on or identity providers.
Options I weighed
- NOT CHOSEN
Add a few more fixed roles to admin/member
Each new role would patch one account’s problem and confuse everyone else.
- NOT CHOSEN
A fully custom permission builder
Maximum flexibility, but it hands the hard design work to the customer’s admin.
- CHOSEN
Role-based access mapped to the 5 platform personas, across a multi-tenant hierarchy
Roles people recognise make the default right for most accounts, without configuration.
The spec
Users
- The 5 personas who use the platform.
- Account admins who manage access.
Requirements
- Roles map to the 5 platform personas.
- Permissions apply across workspace, project and user-level features.
- Admins can see who has access to what, and why.
Acceptance criteria
- A new team member gets the right access from their role alone.
- Sharing a project with someone grants exactly what their persona allows.
- Migrated accounts keep the access they already had.
Guardrails
- No permission change can widen access silently.
- Access-related support tickets are tracked before and after launch.
What shipped
Map personas
Start from the 5 personas who actually use the platform.
Structure
Build a hierarchy across workspace, projects and user-level features.
Assign
Each person gets a persona role, which sets their access at every level.
Share
Teams share work across the account without asking for help.
What changed
Enterprise accounts could share work and onboard without hand-holding.
- Security complaints went down.
- Larger teams could start adopting the more visible AI products.
HONEST CAVEATThese are qualitative outcomes. I don’t have a measured reduction in onboarding time to report.
Reflection
AI products still depend on ordinary foundations. Permission design decides whether an enterprise can adopt the visible features at all.
If I did it again, I would publish the persona-to-role mapping as customer documentation at launch. Admins trust a permission model faster when they can read the reasoning behind it.
Last updated · Company tenure is VectorShift · Jul 2025–present, not a claim about individual project dates.