Roles and access discovery research

Problem and context:

The roles available for Mux users have traditionally been binary: Administrator or non-administrator. Multiple product requests had been made around the ability to provide more granular roles, control who sees what content, limit some users to certain features, or provide read-only access. Additionally, Mux’s account structure does not meet the needs of some customers with more complex use cases. While that was not the initial focus of the research effort, we planned to learn as much as possible in that area as it’s closely related to access.

Key challenges:

Managing the scope of the research. Internal interviews revealed multiple use cases that I wanted to go deep into, but the scope had to be managed tightly due to timing.
Framing the research appropriately with stakeholders. Due to the limited number of users I would be speaking with, I needed to carefully set expectations with stakeholders. The approach I planned to take would be to go deep into some specific use cases, as opposed to a more broad generative research study.

Research plan and structure:

After conducting internal interviews with 12 Mux colleagues across different teams, most of whom worked directly with customers, we were able to identify 5 key areas where we wanted to learn:

How well are Mux’s current roles working for customers? Do they need more or different roles?
Are there features where our customers want to restrict or control access?
Are there content or assets in Mux that customers want to have control over who can access it?
What are some of the unique needs of customers who use Mux with their own customers?
What other access-related concerns are important, such as auditing and provisioning?

These areas of focus helped me identify which external customers to talk to around each specific use case. Working closely with our sales and customer success teams, I reached out to customers who had made specific feature requests or provided feedback in the area of RBAC. Thankfully, most of these customers were more than willing to have a dedicated session to go into their use case in detail. I kept interviews short and focused at 30 minutes, which really helped in recruiting.

I structured the discussion guide to align to the 5 key areas above so it would be easy to both go very deep into their use case, but also gather general information.

Synthesis and findings:

I tagged all interviews in Dovetail, and synthesized the output of each conversation around the 5 key areas above. Dovetail also offers other ways to slice the data, so I also looked at each area in terms of customer size (enterprise, mid-market, or startup) and customer archetype. This identified a few trends, and helped later on with prioritization of the opportunities we uncovered.

Synthesis revealed the following findings:

Mux customers want to protect their video content and metrics by controlling who can access it, for a variety of reasons. Fear of accidental deletion, the security principle of least privilege, and proprietary data were the reasons most commonly cited.
Mux customers struggle to scale the product with their business. They are unable to structure their content and data in a way that aligns with their business, which has prevented them from adding additional users.
Those problems get worse for customers with their own customers, and they often resort to unideal workarounds. These types of customers wanted to keep their client’s assets and data completely separate, and also view their customer’s billing and usage data separately. This problem has led some of them to create multiple separate accounts with Mux to protect their assets.
Roles needed to evolve, but need to remain simple to provision. Some new persona-based roles were suggested (e.g. a developer role, billing admin, etc.), but these were generally considered nice to haves, and most wanted to keep things simple. Many used the example of how complex a product like AWS was to provision and maintain.
Immediate improvements could be made by improving documentation on roles and access. This was the most notable finding at all to me – customers didn’t understand how our current system worked, and had many misconceptions.

*Findings slides from stakeholder presentation*

Value delivered by this work:

Provided much-needed color to key use cases around RBAC that helped define a multi-year roadmap
Helped identify and prioritize an MVP solution that would allow customers to manage access to specific sets of assets by development environment or by digital property
Strengthened relationships with customers (who I plan to reach out to for design feedback in subsequent RBAC projects)

My contributions:

Solo execution of full discovery project
Developed research plan and discussion guide
Conducted internal and customer interviews
Synthesis of findings and recommendations
Stakeholder presentation