Responsibilities
- Build product knowledge. Continually research and learn the current and future best practices of using MUI.
- Resolve users’ issues. You will solve these issues at two levels.
- on the surface. It's achieved by answering them on GitHub, email, Slack, Twitter, Zendesk, etc.
- at the root. It's achieved by creating and updating documentation and fixing bugs in collaboration with the relevant developer.
- Provide feedback. Work alongside product managers to define and shape the product goals, roadmap, priorities, and strategy based on your frontline knowledge of customer needs.
- Operations.
- You will establish key support metrics and identify how best to measure them.
- You will establish a workflow to reduce 'time to response' and 'time to fix' that can scale to multiple team members.
- You will identify where internal tooling might be developed or obtained to improve support efficiency.
Performance indicators
Cultural fit of the role within the organization
This role silos the pain product knowledge of the engineers working on the product. This is far from ideal. We should not hire for the role until we feel the pain is harmful. For example:
- Examples of good reasons ✅:
- we want to sell SLAs, we have tried the above but none of the solutions are working, they prevent us to move the product roadmap forward.
- engineers spend time answering over and over the same questions, they have done all they can to fix the root causes, but it's not enough. It's distracting them, they don’t learn anything new.
- Example of wrong reasons ❌:
- we have 1k issues opened on GitHub, we can't keep up with it. Here I would advocate that the solution is either:
- to break down the product ownership, to become more efficient, and compete with both MIT libraries that have a single focus.
- to deprioritize new features if the issues raised are more important.
- to foster a culture of community contributions by ignoring issues and focusing on community PRs first.
- recognizing a hiring cultural misfit, we take the most pride in delivering a great product, delivering a specific outcome, issue signals that this outcome isn't reached, and challenge us in finding a good enough solution that yields better outcomes.
- to recognize that having this many open issues is OK.
- we want to improve our community contribution stats but the engineering team doesn’t find it rewarding.
Benchmarks