Frictionless Runners Problem Validation
What’s this issue all about?
Some prospective and current customers have reported that GitLab Runners are too difficult to use and in at least case created too much friction in their infrastructure, so much so that they chose not to use GitLab for CI/CD.
Customer quote: “Runners are currently our biggest problem with GitLab and almost certainly the one thing that will drive us to a different CI/CD platform within the next 12 months. The shared runners are not suitable for the requirements of a medium-large business and setting up private runners is a huge ball ache that we didn't expect and simply don't need.”
Opportunity Canvas: https://docs.google.com/document/d/1QBwpjE5iBYCBaEXwDYJGHhybGcMAD6vh7q9ceSfsmi4/edit
Who is the target user of the feature?
What questions are you trying to answer?
- What exactly do customers experience when setting up specific/private runners and why it's painful?
- What features are required to make their experience with private runners better?
- What type of issues do they have when managing their runners?
- What type of issues do they have when configuring their runners?
- How much time do they spend setting up/managing runners?
- Why shared runners don't suffice their medium/small business needs requirements? What should they do to be sufficient?
Core questions
What is the #1 (closed) problem when setting up specific/private runners? What is missing in the shared runner experience that would help/improve their current workflow?
Additional questions
Investigate their experience and needs on caching. This has been another topic that comes up as in different conversations and threads as a pain point area. Customers express that the lack of proper caching makes their experience with runners feel too slow.
What hypotheses and/or assumptions do you have?
TBD
What decisions will you make based on the research findings?
Roadmap decisions / New areas of work.