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.
Buyer personas are the people who serve as the main buyer in an organization or a champion within an enterprise that drives the buying conversation and coordinates various teams to make a purchase. We are iterating on updates to buyer personas on this Buyer Persona page.
Also see the four tiers on our pricing page.
While personas describe ideal targets, roles are the real people in job titles you will encounter while selling. 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. It will help you know: a) if they are even someone who may have an interest in GitLab (don't waste time), b) what questions to ask to learn more and qualify the lead, c) what value prop they'll want to hear that could get them to a demo, discussion, or POC.
See the Enterprise IT Roles page for more details about who we sell to and how to approach them.
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.
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 models 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 models as our research continues and introduce new personas that fit into these new organization models.
It can happen that a persona from one organizational model will have similar jobs-to-be-done, or other characteristics, as one or even multiple personas from another organizational model. Describing all of them will help us understand the differences that could otherwise go unnoticed and make better-focused decisions during product development.
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.
I provide support for our infrastructure, environments, and integrations. I split my time between coding to implement features and bug fixes, and helping developers deploy, build, and release as efficiently as possible.
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’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.
I have responsibility for ensuring the application I create is accessible and performant for its users. I wear an Application Ops hat, but I also wear a Software Developer t-shirt.
Use powerful and extensible operational tools consistenly across platforms and environments to ensure their application is performant and available in production.
This persona is part of an ongoing UX Research project.
I have responsibility for providing, maintaining and operating a shared modern cloud platform which my application development teams utilize to develop, test, ship and operate software more quickly. My team is increasingly being asked to manage our cloud platform like a product - internal.
Configure environments and managed services to satisfy the operating requirements and increase velocity of my application development teams.
Empower developers with self-service capabilities/tools so they can easily provision, configure, monitor, and decommission tiered environments as needed without requiring a third party to get involved.
Migrate the existing infrastructure to align with company partnerships and account selection.
Architect the best infrastructure solution for cost optimisation, availability and the needs of the organisation.
Architect and/or migrate the existing infrastructure in order to modernise and optimise the infrastructure.
This persona is part of an ongoing UX Research project.
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.
Note: for continuity we've historically used these buyer persona descriptions. Consider them deprecated, as the above Buyer Personas are more complete.
