The Product Analysis group consists of a team of product analysts. This group reports to the Director of Product, Growth and serves as a specialized analytics team to support product data analysis requests. The primary customer this group serves is Product Managers from various sections/groups.
Read more about what we do at GitLab on our Direction page.
As part of the Research & Development (R&D) Data Fusion Team, the product analysts also work closely with members from the central Data team, including:
The Product Analysis group hopes to partner more closely with data engineers on the Data team, as well.
The Product Analysis group works in two-week iterations, which dictate how and when we plan and prioritize work. Iterations start on Mondays and end on Sundays (Fridays are the final working day).
You can see our current iteration here.
For all product analysis requests, please create an issue in the GitLab Data Product Analytics project,
product analysis label, and follow the guidelines below.
All data issues with the
product analysis label will appear on the Product Analysis board.
Please select the appropriate template based on your type of request and answer as many of the questions as you can. The more information and context we have up front, the faster we are able to triage and begin work on the issue.
|Ad hoc / Default request||Ad Hoc Request|
|Experimentation analysis||Experiment Analysis Request|
In order to be considered for the upcoming iteration, please open all issues by EOD Wednesday before the next iteration begins. We understand that urgent matters come up, but please try to adhere to the submission deadline for any planned work.
Please indicate the relative priority of the new issue compared to any other issues you have open in the backlog (if applicable). In general, the issues that are more immediately actionable and impactful to the company KPIs should be higher in priority.
Final commitment and prioritization will occur during the iteration planning meeting, which takes places the Thursday before an iteration begins. The team will consider new and existing issues, along with issues in progress. When selecting issues for the next iteration, the team considers the following:
The Manager, Product Data Analysis will help prioritize work based on importance and capacity, and will work closely with the Director of Product Growth, Chief Product Officer, and VP, Product Management on trade-offs (if needed).
Prioritization labels will be added by the Product Analysis team as a part of triage and planning.
||High and/or urgent|
Most issues will fall under
Each issue is assigned a weight based on estimated time commitment. If a partially-completed issue rolls over from one iteration to another, the weight will be adjusted to reflect the time commitment of the outstanding work.
If a single issue has a weight greater than the length of the iteration (2 weeks), it should be broken into smaller units of work. (This could also be an indicator that the issue should be converted to an epic).
|Weight Value||Estimated time to complete|
|1||< 1 hour|
Product Analysis defines velocity as the amount of work (measured in issue weight) completed by the team within a given iteration. While we recognize that this is an imperfect measurement (partially-completed issues and undocumented work are not accounted for), it is a rough gauge of team output.
We aim to only commit to work we believe can be completed within the 2-week iteration. As such, we will commit to less than our recent velocity and leave a buffer to account for urgent issues and interruptions. To start, each analyst will leave a buffer of ~2 days worth of work (an estimate based on the recent volume of unplanned work). High-priority issues exceeding the allotted buffer will have a material impact on our ability to complete planned work, so please plan ahead if you know that you will need assistance from the Product Analysis team.
As GitLab team members, we are encouraged to take PTO and observe public holidays in order to maintain a healthy work-life balance. Analyst capacity should be adjusted based on the number of days they are working in the iteration.
If an urgent matter comes up, please open an issue and tag your analyst contact (and/or
Please include why the issue is urgent, when it is needed by, what it will inform or how it will
be used, and who is the intended audience.
If you have not heard from the tagged analyst within 1 business day* (or earlier if the issue
requires a faster turn-around), please send a message in #s_growth_data
and feel free to tag
*Please keep in mind that we work across different timezones
Please keep the following in mind when working with the Product Analysis team:
Scope creep is a problem everyone faces. Please keep in mind that team capacity is a zero-sum game, so scope creep in one issue can mean that we are unable to complete other work planned for that iteration.
Additional scope (change in requirements, additional follow-ups, etc) that adds a material amount of work* to an issue will need to be captured as net-new work in a new issue. The new issue will then go through the normal prioritization and planning process. The best way to avoid scope creep is to have thorough, complete requirements in the issue when you initially open it. The issue templates should help guide you to include all relevant information.
*The threshold for a "material amount of work" is to be determined by the analyst working on the issue.
If an issue is blocked and it requires additional work* to diagnose or troubleshoot (ex: a data issue is uncovered), a new issue should be opened, assigned a weight and priority, and linked to the original blocked issue. The new issue can be added to the current iteration without going through the formal planning process at the analyst's discretion, but this can impact our ability to complete all issues in the iteration.
*The threshold for "additional work" is to be determined by the analyst working on the issue.
Experimentation analysis issues are naturally blocked by the experiment actually running (we have to wait until we have sufficient data in order to perform the analysis). In order to enable a more accurate measure of velocity, we will divide the work into 2 separate issues*:
*At this time, PMs should continue to open a single issue and analysts will separate accordingly.
Please open an issue for all Product Analysis requests. Requests made via comments in Google Drive are extremely difficult to track, and Slack history is gone after 90 days. In addition, these requests are not planned or accounted for in team velocity. Your informal request might mean that we are unable to complete work we committed to for another stakeholder.
By keeping a formal record of requests (via issues), we are able to identify frequently asked questions (which could lead to building a self-service solution) and quickly replicate past work.
As the Product Analysis team is still fairly new and small, we expect most PMs to self-serve on analysis and only create Product Analysis issues for critical asks. As the group grows, so will our ability to support additional asks and analyses.
In order to start supporting more PMs across GitLab, the Product Analysis team is launching an office hours pilot. Office hours will be held every other Wednesday, alternating between 8 am PT and 1 pm PT. While the pilot is intended to enable us to support PMs across the organization, all GitLab team members are welcome to join.
The intent of office hours is to give PMs faster access to the team and get support for smaller tasks, brainstorming, and data self-service. More formal requests that answer more complex questions are captured in issues and go through a more Unlike more formal requests that we capture in issues, office hours is intended to help PMs with smaller tasks, brainstorming, and data self-service.
This is currently a pilot program. We expect to make adjustments and iterate over time to maximize our level of support.
The agenda is first-come, first-served. Please add your name and topic (or question) by EOD Monday before the next office hours. This allows the team time to review new agenda items ahead of time.
Topics will be time-boxed to 30 minutes in order to ensure that, at minimum, we are able to help 2 stakeholders. (An exception will be made if there is only 1 item on the agenda). If topics are too large to be covered in 30 minutes, a team member will reach out to the stakeholder to either reduce the scope or to open an issue for the team instead. Stakeholders are welcome to leverage office hours to discuss and define the new issue, which can help reduce async back-and-forth communication in the issue itself.
To respect everyone's time, the team will set the schedule ahead of time and notify the stakeholders we have slated for discussion. We will also pull in 1-2 "on deck" topics – those that we might be able to address, time permitting. If we are unable to cover a topic, it will be pushed to the following meeting.
Office hours is intended for smaller bodies of work, brainstorming, and assistance with data self-service. Since topics are limited to 30 minutes, we ask that stakeholders be mindful of the types of items they add to the agenda. Here are some examples of topics for office hours:
Here are some examples of topics not suited for office hours. These topics are too broad to be addressed during office hours and should be captured in an issue. Please note that stakeholders are welcome to come to office hours to discuss the scope and details of the subsequent issue (see example topic 6 above).
What is the difference between topics for office hours and formal data requests?
Office Hours is intended to help PMs with smaller tasks, provide a venue for brainstorming, and help folks looking to learn more about data self-service. The benefit is that the agenda is first-come, first-served, the prioritization process is bypassed, and the wait time is minimal.
Formal data requests are larger bodies of work captured in issues in the Product Analytics project. They can help answer more complex questions, but go through more robust intake and planning processes. As such, there is a longer turn-around time given team size and capacity.
What if I don't know if my topic is best suited for office hours or whether I need to open an issue?
Feel free to ask your analyst partner (if applicable) or in #s_growth_data. In addition, we will review agenda items before office hours, and will flag any topics that are too broad to be covered in office hours.
@gitlab-org/growth/data-analysts- Notifies the entire Product Analysis team