Personas describe the ideal target for GitLab. They help us define our messaging and marketing delivery. They are theoretical people to target. By defining their concerns and where they go for information, we can best spend our marketing dollars and sales efforts by focusing on this ideal target.
Roles are distinct job titles. These are the real people you will encounter while selling. You will find a contact at an account with a specific role. Understanding the challenges faced by each role in IT, along with what they care most about, is helpful to deliver the right value proposition to the right person.
Personas are a generalized way of talking about the ideal target we are aiming to communicate with and design for. They help us not only define our messaging and marketing delivery, but also our product. Keeping personas in mind allows us to use the correct language and make the best decisions to address their specific problems and pain points. GitLab has both buyer and user persona types.
We are iterating on updates to buyer personas on this Buyer Persona page.
User personas are people who actually use GitLab. They may or may not be the person in the organization who has the authority and budget to purchase GitLab, but they are heavy influencers in the buying process. Users personas are created from data gathered from UX research studies. If a new user persona is needed, or an existing persona has to be updated, see our handbook guide on How to Create a User Persona.
While user personas are often distinct individuals it is equally important to understand how multiple personas interact as to understand the workflows and motivations of individual personas. As a result we will also consider:
Organizational archetype describe how organizations have structured their software development process and teams. They help us understand common structures and the resulting types of interactions that the personas in those structures experience.
We'll build out descriptions of common organizational archetype as our research continues and introduce new personas that fit into these new organization archetypes.
It can happen that a persona from one organizational archetype will have similar jobs-to-be-done, or other characteristics, as one or even multiple personas from another organizational archetype. Describing all of them will help us understand the differences that could otherwise go unnoticed and make better-focused decisions during product development. Learn more about the organizational archetypes GitLab is addressing.
We describe the following personas in terms of the jobs they do, their motivations and frustrations. Understanding our users through this lens helps us contribute to a product that supports their workflow.
Our personas span across stages (see table below for a depiction of how our user personas map across stages). Understanding how our personas map across stages helps us understand how to collaborate cross-functionally to support their needs.
Note: To change the table above, team members can edit the Google Slide deck.
I am responsible for defining and scoping features, incorporating company objectives into the product roadmap, and giving developers and designers the requirements they need to deliver strong features. Whether I’m making sure I have the right skill-sets on the team, prioritizing feature requests, or ensuring that we deliver on time, my job is to set my team up for success.
I am responsible for meeting with the product management team to discuss and schedule features, so we can convert concepts into practical solutions. I ensure that capacity is properly estimated, create program specifications, and often mentor junior developers.
My goal is to translate the product’s mission into an effective, empathetic, and efficient user experience. I am responsible for understanding user needs and product requirements, in order to conceptualize and design the graphic elements and components needed to shape the user interface. I collaborate primarily with product managers and developers, in addition to working with other stakeholders such as UX research and marketing.
I spend the majority of my time focused on completing planned development tasks, with roughly 30-40% of time taken by meetings, planning for the next sprint, and fixing bugs or customer requests as they arise. I work off of JIRA tickets and have a regular stand-up with my team.
My job is to enable the developers to focus on the business code only. To achieve my goal, I write pipeline definitions, deployment templates, CLI tooling to be used by development teams, so the software delivery process is streamlined across organization. Beside building out these features and fixing potential bugs, I educate and support the development teams around topics related to our pipelines or target infrastructures, so they can build, deploy, and release as efficiently as possible.
Depending on the organization and/or need of the development teams, I am part of a central platform team or a member of an application development team.
My job is to enable developers to ramp up the learning curve of modern DevOps practices - including when that adoption is not compulsory. This can include new work management, new tooling and navigating the modernization of their applications into the cloud. To achieve my goal, I write and maintain automation code that can be directly consumed by developers as dependencies as well as scaffolding templates to be sure new projects are off to a good start. In addition to CI/CD automation, this frequently this involves support for cloud deployment, kubernetes manifests and any other associated parts for a wholistic approach to moving teams onto modern application practices. This technical work frequently involves exposing company specific things to developers as an easy to use 'service' - for instance, registering their application with our company-wide Configuration Management Database (CMDB).
My job also includes being an active champion and evangelizng development teams to leverage the new assets and ways of working - this involves treating my work as though it were a product or service - managing it to be stable, fixing bugs, taking feature requests and creating and promoting release information. This also includes workshops, managing communities of practice and creating peer Q&A platforms.
My manager has developer productivity and enablement as a strong focus and is very interested in how our efforts accelerate onboarding to our next generation application frameworks and also how we contribute to the long term productivity gains and business value generation of the teams that adopt our enablement.
My job also includes influencing not just technology, but also processes and culture when they might inhibit adoption of modern application and devops practices and technology.
Developer enablement plays such a critical role in the efficient onboarding of developers that I generally have strong input on tooling selection as I screen it for the ability to allow us to extend it.
Depending on the organization and/or need of the development teams, I am part of a central enablement team or a member of an application development team if the team's work has a large enough scope.
I maintain and scale our infrastructure and configurations, and my priority is to automate as much as possible. When needed, I also build servers and help developers deploy to them.
I’m a software engineer in my organization with a keen interest in quality and the skills necessary to promote it. My objective is to help build quality into the development process and promote ownership of quality across every team. To accomplish this, I develop tooling to support test processes and quality reporting. I also write tests at every level in the test pyramid. I groom my organization's tests to make them both efficient and effective as well as help grow a quality mindset across departments.
Alternative Job Titles: DevOps engineer, Lead developer, Site Reliability Engineer
I have responsibility for ensuring the application I own is accessible and performant for its users. I wear an Application Ops hat, but I also wear a Software Developer t-shirt.
I have responsibility for providing, maintaining and operating the shared infrastructure which my application development teams utilize to develop, test, ship and operate software more quickly.
Dakota is a key IT leader who manages and leads several teams of developers supporting a specific set of business applications. See the buyer persona and Engineering Director Persona research for more details.
I am responsibility for assessing potential business-critical vulnerabilities, performing code reviews to focus on security best practices, and verifying security fixes in the environment.
I am responsibility for creating and maintaining security tools, monitoring production environments, and assessing security tools to ensure my organization's assets are compliant with the security requirements.
I’m the firefighter of the Security team. My objective is to prevent malicious attacks and mitigate active risks to my organization as they pop up, as quickly as possible. In order to do that, I develop detection tooling that generates trustworthy alerts, and take part in an on-call rotation where I serve as an Incident Responder.
“I need to be jack of all trades: When SecOps get paged, it could be about anything, and there’s a high probability that the incident concerns something you’ve never dealt with before. The sky could be falling and there’s a lot at stake and so the role of a security operations person can be pretty stressful.”
I’m in charge of ensuring that our organization’s use of third-party software adheres to internal company policy. This can consist of the SDLC, access management, change management, and a multitude of other policies. I interface regularly with our internal compliance, audit, and/or security teams to deliver the information they need for our organization’s compliance program.
Internal personas reflect the workflow, needs, and challenges faced by GitLab team members. These personas support and influence the work of GitLab groups that serve internal use cases.
I am responsible for creating, updating, and curating content for my company’s site. I review and submit changes to existing pages and create pages to add new content as needed.
My goal is to deeply understand the lifecycle of data from various sources and model it in a way that fosters cohesive, accurate analysis. I am responsible for maintaining high quality data, building reports and dashboards, and explaining trends across data sources. I collaborate with stakeholders across the company, providing useful analyses and insights that empower them to build a stronger product and organization.
