Send to HN
  1. You are here:
  2. Handbook
  3. Product Handbook
  4. Personas

On this page

Roles vs personas

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

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

We are iterating on updates to buyer personas on this Buyer Persona page.

User personas

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.

How do user personas interact?

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:

  • Organization Archetype
  • Persona Composition
Organizational Archetype

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.

List of User Personas

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.

  1. Cameron, Compliance Manager
  2. Parker, Product Manager
  3. Delaney, Development Team Lead
  4. Presley, Product Designer
  5. Sasha, Software Developer
  6. Priyanka, Platform Engineer
  7. Sidney, Systems Administrator
  8. Sam, Security Analyst
  9. Rachel, Release Manager
  10. Alex, Security Operations Engineer
  11. Simone, Software Engineer in Test
  12. Allison, Application Ops
  13. Ingrid, Infrastructure Operator
  14. Dakota, Application Development Director

Cameron (Compliance Manager)

  • Alternative Job Titles: Compliance Program Manager, Audit Report Analyst, Audit Events Analyst
Job Summary

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.

Jobs to be done
  • I need to be able to provide our internal compliance teams with evidence artifacts that help my company maintain a positive compliance posture.
  • I need to find tools that enable my organization to manage our compliance program and mitigate risk within the application and its use.
  • I need to create effortless processes for compliance so that my team will remain productive and efficient while meeting obligations for our primary job responsibilities.
Motivations
  • When I’m supporting an audit, I need the information to be available quickly and easily so I can reduce the time and disruption involved in the evidence collection process.
  • When I’m managing my teams and projects, I need to know I’m not introducing unnecessary risks so I can protect the company from liability.
Frustrations
  • I’m frustrated because it’s difficult to find, aggregate, and report on all of the necessary data for audit purposes.
  • I’m frustrated when tools do not have features that give me peace of mind about our organization’s compliance posture.
  • It’s challenging to compile data in a format that’s efficient and valuable to my internal audit or compliance team.
  • It’s challenging to build custom tooling and services every time we identify a gap in the compliance posture of our tools.

Parker (Product Manager)

  • Alternative Job Titles: Program Manager, Project Manager, Technical Product Manager, Head of Product
Job Summary

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.

Motivations
  • When company objectives shift, I want to have a standard process for communication in place, so that I can be in sync with all team members.
  • When development begins, I want to see an overview of all the relevant information related to a feature or project, so that I can monitor progress throughout a cycle.
  • When I’m planning for the next cycle, I want to see a history of how accurately the developers on my team estimated their capacity, so that I can be sure that key features will be delivered on time.
Frustrations
  • It can be difficult to know the status of certain requirements, when my team members do not take the time to update the various tools we use.
  • I often have trouble balancing feature requests with capacity.
  • It can be difficult to give clients a reasonable timeframe that is not off-base, since a cycle is often unpredictable.
  • It’s challenging to explain why certain features have been delayed or deprioritized, when customers and upper-level management are not working closely with the team.

Delaney (Development Team Lead)

  • Alternative Job Titles: Technical Manager, Software Engineering Team Lead, Technical Team Lead, Software Development Director, Development Lead
Job Summary

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.

Motivations
  • When discussing feature requests, I want to receive clear requirements from the product and design teams, so my team can deliver on time and reduce back-and-forth communication.
  • When assessing team resources, I want to see a history of how accurately developers on my team have estimated their capacity, so that I can assign them to the right tasks.
  • When important deadlines are approaching, I want all team members to reliably update our tools, so that I can track progress without having to search for relevant information in other communication channels.
Frustrations
  • It can be difficult for my team to do thorough code reviews in a reasonable timeframe, while still making progress on their own assignments.
  • When demand surpasses our current capacity, it can be stressful to resolve issues while not creating new ones that result from hasty work.
  • I am not always aware of the best way to explain technical limitations to stakeholders who are not involved in the development process.

Presley (Product Designer)

  • Alternative Job Titles: UX Designer, Interaction Designer, UI/UX Designer, UI Designer, Experience Designer
Job Summary

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.

Motivations
  • When a deliverable is requested, I want to have clear, up-to-date requirements that I can reliably refer back to throughout the design process.
  • When collaborating with other designers, I want to be able to see who has edited a file so that I can confirm whether changes were made intentionally.
  • When presenting deliverables to stakeholders, I want to be able to make updates to a design without having to edit a series of files in various tools.
  • When developers are implementing my designs, I want to easily keep track of changes that go live in production, so that I can alert them of any needed fixes.
Frustrations
  • It’s frustrating to have to create a file in one tool, export the file, create a prototype in another tool, and use a separate tool to handoff the design to developers.
  • It can be difficult to ensure that stakeholders are looking at up-to-date designs, when carrying out an iterative feedback process.
  • It can be challenging to get access to more resources, when my company does not have a defined way to prove design value to stakeholders.

Sasha (Software Developer)

  • Alternative Job Titles: Software Engineer, Application Developer, Digital Solutions Developer, Consultant, Database Developer, Mobile Developer
Job Summary

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.

Motivations
  • When I’m planning work, I want to have better communication between stakeholders, so I can deliver something they really need and use.
  • When I’m on-call, I want to be the expert on some part of the system, so I know that I’m a valuable part of the team.
  • When collaborating with a large number of developers, I want to see a record of everyone’s changes, so we can pinpoint and unwind mistakes.
  • When I’m pairing with my teammates, I want to learn new tools and skills, so I can keep growing in my career.
  • When I’m making changes, I want to deliver secure and performant code, so I can ensure the integrity of my organization’s software is not compromised.
Frustrations
  • I’m frustrated when requirements change after work has already begun on a project.
  • I’m frustrated when work is inaccurately scoped, because it causes stress and eats into time planned for other work.
  • I’m frustrated when I come across brittle code and something that should be an easy fix requires a lot of rework.
  • I’m concerned that by taking longer than expected on a task I may be judged or seen as blocking others’ work.

Priyanka (Platform Engineer)

  • Alternative Job Titles: DevOps Engineer, Operations Engineer, Systems Engineer, IT Consultant
Job Summary

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.

Motivations
  • When developers plan a project that requires my support, I want to be notified, so I can avoid unnecessary reactive work.
  • When I resolve problems, I want to be able to track impact and other important success metrics, so I can raise my profile in the organization.
  • When I create a solution for developers, I want to see it being used, so I know that my contributions are reliable and valued.
  • When I’m facing a new or novel challenge, I want to whiteboard it with a teammate, so I have the satisfaction of helping solve a problem that has no manual.
  • When I’m advocating for a new process or tool, I want to point to a metric or test, so I can support my case with something objective.
Frustrations
  • It is hard for me to quantify my efforts and convince others of time that will be saved in the future by investing time in proactive tasks in the present.
  • I’m frustrated by the avoidable crises, caused by a lack of communication, that derail my work and burn up my resources.
  • I dislike frequent context-switching and being responsible for some tasks that I feel I am not good at, because of the many hats my job requires me to wear.
  • I’m frustrated by the politics of convincing people to adopt my recommendations.

Sidney (Systems Administrator)

  • Alternative Job Titles: Systems Engineer, Database Administrator, Infrastructure Engineer, Site Availability Engineer, Site Reliability Engineer
Job Summary

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.

Motivations
  • When I get asked for help multiple times on the same task, I want to automate that task, to save time and avoid mistakes in the future.
  • When I’m on-call, I want to receive tiered notifications, so that the true emergencies don’t get lost in the noise.
  • When I’m releasing an improvement, I want no one to notice, so I know that it has gone smoothly.
Frustrations
  • I’m frustrated by the large volume of reactive work that I face.
  • I’m frustrated by the number of channels (email, Skype, SMS, Slack, pager) on which I receive on-call notifications.
  • I’m frustrated when I get inundated by requests from people who have not followed the correct process.
  • I’m frustrated when developers do not implement my recommendations, and I’m responsible for fixing their preventable problems anyway.

Sam (Security Analyst)

  • Alternative Job Titles: Security Consultant, or an Application Security Specialist
Job Summary

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.

Motivations
  • When I’m monitoring my dashboards, I want to see everything I am monitoring in one tool, so I can do my job easier and more efficiently.
  • When security testing, I want to be more proactive than reactive, so I can anticipate potential threats or vulnerabilities before the bad guys do.
  • When I’ve done all I can do proactively, I also want to be able to enable reactive tools and investigate the data from them as a final layer of defense.
  • When on the job, I want to stay up to date on the latest information and education in information security, so I can grow in my career.
Frustrations
  • I’m frustrated I don’t have the resources to complete this project to its specifications.
  • I’m frustrated when I know how to fix a security issue but the red tape at my company doesn’t allow me to in a timely manner.
  • I’m concerned that what I don’t know, I don’t know and my company can be attacked in any manner of ways at any time.
  • I’m concerned that I might miss something and my company may become compromised because of it.

Rachel (Release Manager)

Jobs to be done
  • I am responsible for coordinating a deployment to production. I push the last button in our pipeline; i.e. changing the load balancers to point to the latest deployment.
  • I coordinate the release by defining the scope and tasks for delivery.
  • I am in charge of external communications around a release, especially assembling changelogs or release notes.
  • I organize a response room if necessary to bring in everyone that may need to support a release
Motivations

I want a smooth deployment

  • I want to make sure everything in the pipeline will work, because it’s the last thing that happens before it’s moved to production. If you ship something into production that shouldn’t be there, that can be catastrophic.
  • Every time the CI/CD pipelines run to green or catch issues when needed, I can sleep calmly.
Challenges
  • Dealing with archaic infrastructure, such as slow connections and outdated equipment, can make it difficult to ensure everyone has the files they need to contribute and manage the pipeline.
  • Ensuring enough developers, Product Managers, etc. are available to support projects.
  • UI testing isn’t automated so that takes time out of the testing process.
  • Coordinating all the different teams across a release can be challenging and requires a lot of follow up to ensure they play their part when they should.
Tools
  • GitLab
  • JIRA (for tickets from non-technical users)
  • Trello (for planning issues and communication)
  • Slack (for communication)

Alex (Security Operations Engineer)

My role

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.”

Jobs to be done
  • Manage incident response: When I am on-call, I need to respond to and manage incidents as they pop up, so as to mitigate the risk to my organization as quickly as possible.
  • Real-time documentation: As an incident unfolds, I want to document as much of what is happening as possible, so that later on I could use that information as part of updating or creating a runbook, and possibly creating an RCA (Root Cause Analysis).
  • Building detection tools: When I’m not on-call, I want to build tools that enhance our detection and alerting capabilities, so as to improve my organization’s security stance.
  • Short-term project management: As an incident unfolds, I want to assign tasks and coordinate the work of multiple individuals across my organization, so I can move as quickly as possible to remediate the risk.
Skills & Personal Traits
  • Great ability to divide my focus effectively and deal with interruptions, such as new alerts, new data, and urgent requests from colleagues
  • Good at thinking quickly on my feet and maintaining my composure in stressful situations
  • Can think like an attacker as well as a defender
  • Enjoy building tools (has coding skills)
  • Passionate about improving processes
  • Effective communicator: articulate both verbally and in writing
  • Enjoys the variance of SecOps work
  • Feels relatively comfortable with handling unknown unknowns
Frustrations
  • It is cumbersome to edit description of timeline in real-time, and it’s especially difficult to do in hindsight. Often the timeline documentation isn’t completed.
  • Often important parts of the info I need in order to handle the incident are either not communicated fully, or are being communicated in an unstructured manner which makes aggregation and searching difficult.
Key Tools
  • GitLab Issues: Tracking, documentation
  • PagerDuty: Initiation standpoint, where pages are sent through
  • Slack, Zoom, GitLab Issues: Communication
  • Google Docs: Real-time documentation
  • Terminal, coding environment: Mostly Python, some Go – for building and/or running tools
  • The Hive: A security incident management tracking tool
    • Cortex – part of The Hive, allows for easy automation
  • A cloud management console: To access the infrastructure
  • Various tools for triage and mitigation:
    • Docker – to reproduce security issues and test approaches
    • Accounts for different environments – to test against
    • ELK stack – to go over logs
    • Stackdriver or BigQuery – long-term storage, used for incidents that are open for a long period of time
Collaboration with other teams
  • Infrastructure
  • Legal
  • Compliance, AppSec
  • Support
  • Development teams
  • Various SMEs

Simone (Software Engineer in Test)

  • Alternative Job Titles: Software Development Engineer in Test
My role

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.

Jobs to be done
  • Develop and maintain test frameworks: I need to provide the engineers in my organization with one or more well-maintained test frameworks that facilitate writing tests at the appropriate level.
  • Provide tooling and reporting to facilitate quality: I need to create and maintain both tooling and reporting that allows developers to more easily accomplish quality-related tasks and provide feedback to engineering and management.
  • Perform quality planning with counterparts: I want to interact with my engineering counterparts on a regular basis, tracking what is coming up for development as well as what is happening now and what is being delivered. Knowing this, I need to be able to identify both the riskiest and most important work being done so I can provide quality feedback at the appropriate time through performing code reviews and having discussions about both the design and implementation of the features.
  • Manage Test Environments I also provision and maintain test environments that are representative of the software being used in production. Through these environments testing can then occur that is as realistic as possible and catch issues earlier.
Skills & Personal Traits
  • Focused: Has a great focus on quality and what it means in an engineering role
  • Adaptable: Can think like a developer and an architect
  • Curious: Enjoys learning how things work or taking things apart
  • Technical: Enjoy building tools (has coding skills)
  • Passionate: Loves improving tools and processes and advocating for quality
  • Effective communicator: articulate both verbally and in writing
Frustrations
  • Flaky tests
  • Long running test suites
  • Not being able to reproduce issues due to lack of representative test data
  • Unstable infrastructure
  • Not being able to give earlier feedback on development work
Key Tools
  • Tracking, documentation: GitLab Issues
  • Communication: Slack, Zoom, GitLab Issues
  • Real-time documentation: Google Docs
  • Terminal, coding environment: VIM, VS Code, or RubyMine with Ruby, JavaScript, Terraform, and other supporting languages
  • Test automation frameworks: Implementations of testing tools suited for my products
  • A cloud management console: To access the infrastructure (Google Cloud Platform, Amazon Web Services, Azure)
  • Environment Provisioning: Terraform and Ansible
  • Triage and mitigation:
    • Docker – to reproduce issues and emulate environments
    • Accounts for different environments – for testing and infrastructure
    • Data repositories and generators
    • Logging tools
      • Elastic Stack (Elasticsearch, Kibana, Beats, Logstash)
      • Sentry
      • Prometheus
Collaboration with other teams
  • Development teams
  • Product teams
  • Infrastructure
  • UX teams
  • Support

Allison (Application Ops)

Alternative Job Titles: DevOps engineer, Lead developer, Site Reliability Engineer

My role

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.

Jobs to be done
  • I want to be able to deploy to production and non-production environments automatically without requiring action from other teams.
  • I want to use my selected deployment tools so I can predictably understand what “deploy” means.
  • I want to deploy following the company best practices set out by Priyanka, the platform engineer so that we minimize the risk of a new deployment.
  • I want to get up-to-date, real-time information about the system components I own so that I can be assured about the performance and health of the applications I own.
  • I want to be notified about potential problems with the applications I own, so that I can act avoid downtime and degradations before they happen.
  • I want to roll back or roll forward from erroneous deployments so that I can keep my systems functional.
Frustrations
  • As a consumer of a monitoring platform, I’m frustrated when my apps instrumentation doesn’t report in the monitoring systems
  • I’m frustrated when I can’t determine the root cause of the monitoring system’s errors.
  • I’m frustrated when I need to use multiple tools to identify that there is an issue.
  • I’m frustrated about processes that slow down deployments.
  • I am frustrated when I can’t trust the data coming from monitoring systems (false negatives or false positives)

Ingrid (Infrastructure Operator)

  • Alternative Job Titles: Systems Engineer, Database Administrator, Infrastructure Engineer, Site Availability Engineer, Site Reliability Engineer, System Administrator
My Role

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.

Jobs to be done
  • When I set up new infrastructure, I want to do it in a programmable way, so others can review my changes and we can repeat the steps if needed.
  • When I own an infrastructure resource, I want to keep it up to date with security patches, so I can sleep well at night.
  • When I own an infrastructure resource, I want to assure that it serves its purpose well, so I fulfill my SLAs.
  • When I own an infrastructure resource, I want to be mindful about its costs, so that I can run it within budget.
  • When I support developers, I want to automate the integration points, so I will not become a bottleneck in their processes.
  • When I’m on-call, I want to receive tiered notifications, so that the true emergencies don’t get lost in the noise.
  • When I’m releasing an improvement, I want no one to notice, so I know that it has gone smoothly.
Frustrations
  • I’m frustrated by the large volume of reactive work that I face.
  • I’m frustrated by the number of channels (email, Skype, SMS, Slack, pager) on which I receive on-call notifications.
  • I’m frustrated when I get inundated by requests from people who have not followed the correct process.
  • I’m frustrated when developers do not implement my recommendations, and I’m responsible for fixing their preventable problems anyway.

Dakota (Application Development Director)

Job Summary

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.

Motivations
  • Business Satisfaction: Delivering consistent and predictable business results.
  • DevOps transformation: Transforming my organization to create new value with DevOps processes and tools.
  • Team building: Growing and improving the team through my managers.
  • Process excellence: Ensuring that my team have the tools, training, and resources to successfully deliver the business value.
Frustrations
  • Reactive versus proactive: Urgent roadblocks, organizational issues and emergencies make it difficult to manage time and workload.
  • Context switching: There is a large amount of content to cover across all of my projects and teams.
  • Creating business cases: Securing budget for new strategic initiatives and resources for her team is labor-intensive and time-consuming.

Internal personas

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.

Eddie (Content Editor)

  • Alternative job titles: Content Marketer, Technical Writer
Job Summary

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.

Motivations
  • When I need to improve existing page content, I want to quickly find the areas that need to be updated, so I can ensure that the content is consistent and up-to-date.
  • When I need to create a new page, I want to easily find the correct directory, so I can submit my changes to the appropriate location.
Frustrations
  • It’s challenging to know which pages need to be updated, when I am responsible for managing a site with a lot of content.
  • It can be intimidating to make content changes, if I am not used to working with technical editing tools in my workflow.
  • It’s frustrating to have to spend time figuring out where content lives in the directory structure, especially when making small changes.
  • It’s difficult to make bulk updates to a page without tools that allow me to find-and-replace content.

Dana (Data Analyst)

  • Alternative Job Titles: Data Analytics Consultant, Business Data Analyst
Job Summary

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.

Motivations
  • When directors are assessing key performance indicators, I want to build dashboards with reliable data, so that they can have confidence in the conclusions drawn from the data.
  • When our product team needs to measure the value of our features, I want to see more granularity and context for patterns in usage data, so that we can develop a better understanding of how people are interacting with the product.
  • When important company initiatives are being discussed, I want to deliver queryable data and empower my colleagues to run their own analyses, so that they can use data-driven insights to inform critical decisions.
  • When my colleagues are working on projects requiring data analysis, I want to find ways to optimize queries, so that they can spend more time actioning insights.
Frustrations
  • It can be frustrating to work with data that is not properly structured and low in quality and confidence as a result.
  • It can be difficult to know exactly how to approach analysis, when my colleagues are not clear about the questions they have and why they want to explore certain aspects of the data.
  • It’s hard to trust the integrity of data, when inconsistent tracking results in missing context for key events.
  • It’s difficult to answer big picture questions about feature usage and user retention, when feature parameters and usage criteria aren’t completely defined.

Read More