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.
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.
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.
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 wear lots of hats, but the majority of my time is spent monitoring and flagging events, running down high priority tasks and working with other teams to implement new systems.
I want a smooth deployment
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 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.
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.
