The Product Intelligence Groups are part of the Growth section.
Product Intelligence Group is responsible for the collection and analysis of data to improve GitLab's product which includes being the primary caretaker of the versions app.
How we work:
I have a question. Who do I ask? Questions should start by @ mentioning the product manager for the Product Intelligence Group or by creating an issue in our workflow board.
The following people are permanent members of the Product Intelligence Groups:
| Person | Role |
|---|---|
| Jerome Ng | Backend Engineering Manager, Product Intelligence |
| Axel García | Frontend Engineer, Plan:Product Planning |
| Alishan 'Ali' Ladhani | Backend Engineer, Product Intelligence |
| Mikołaj Wawrzyniak | Backend Engineer, Product Intelligence |
| Alina Mihaila | Backend Engineer, Product Intelligence |
Our team uses a hybrid of Kanban for our project management process. This process balances the continuous flow of Kanban with GitLab's monthly milestone release cycle.
Our teams use the following stages defined in the Product Development Flow:
~"workflow::validation backlog"~"workflow::problem validation"~"workflow::design"~"workflow::solution validation"~"workflow::planning breakdown"~"workflow::ready for development"~"workflow::In dev"~"workflow::In review"~"workflow::staging"~"workflow::production"~"workflow::blocked"We specifically pay close attention to the Completion Criteria and Who Transitions Out. We also emphasize having engineers involved earlier in the process to provide feedback in ~"workflow::design".
We use workflow boards to track issue progress. Workflow boards are our single source of truth for the status of our work. Workflow boards should be viewed at the highest group level for visibility into all nested projects in a group.
There are three groups we use:
| gitlab-org | gitlab-com | gitlab-services | all groups |
|---|---|---|---|
| Product Intelligence Workflow | - | Product Intelligence Workflow | - |
The work done by our teams mainly fall into two categories: product initiatives and engineering initiatives.
Product initiatives: This work is primarily related to driving value for our customers. This work is defined by a product manager and is outlined in the team's product roadmap.
Engineering initiatives: This work is primarily related to driving value for internal teams. This work is defined by an engineer and can include bug fixes, follow-up issues, refactoring, career development work, or anything an engineer thinks is important enough to be worked on.
We prioritize our product roadmap using milestone priority labels:
~"milestone::p1"~"milestone::p2"~"milestone::p3"~"milestone::p4"Prioritization of our product roadmap is determined by our product managers. Every epic and issue that is part of a product roadmap should have a priority label. If an issue belongs to an epic, the issue priority should match the epic's priority.
We work from the highest to the lowest priority when working on product initiatives. For design prioritization, see priority for UX issues.
We follow the estimation process outlined by the Growth sub-department.
To properly set expectations for product managers and other stakeholders, our team may decide to add a due date onto an issue. Due dates are not meant to pressure our team but are instead used to communicate an expected delivery date.
We may also use due dates as a way to timebox our iterations. Instead of spending a month on shipping a feature, we may set a due date of a week to force ourselves to come up with a smaller iteration.
Refinement is the responsibility of every team member. Every Friday, Slack will post a refinement reminder in each group's channel. During refinement, we make sure that every issue on the workflow board is kept up to date with the necessary details and next steps.
Our groups still pay attention to certain dates in the Product Development Timeline:
These dates are important to understand when features are released on self-managed instances and when we conduct our team retrospectives.
We have monthly roadmap planning sessions to ensure our team is aligned on what's coming next. Monthly roadmap planning takes place as a part of our weekly sync meetings and it occurs on the first meeting of every month.
To help our team be efficient, we explicitly define how our team uses epics and issues.
We aim to create issues in the same project as where the future merge request will live. And we aim to create epics at the topmost-level group that makes the most sense for its collection of child epics and issues. For example, if an experiment is being run in the CustomersDot, the epic should be created in the gitlab-org group, and the issue should be created in the gitlab-org/customers-gitlab-com project.
We emphasize creating the epic at the topmost-level group so that it will show up on our epic roadmap. And we emphasize creating the issue in the right project to avoid having to close and move it later in the development process. If the location of the future merge request cannot be determined, we will create the issue in our catch-all growth team-tasks project.
We used to aim for a 1:1 ratio between issues and merge requests, mainly for the sake of status visibility at the workflow-board level. We have since moved to using epics and the epic roadmap for product management visibility, and we are comfortable with the amount of status updates received during our weekly sync meetings as well as through comments within issues themselves.
If an issue requires multiple merge requests, we no longer recommend splitting the issue itself up in order to maintain a 1:1 ratio of issues to MRs. The advantage is that an engineer is able to create an arbitrary number of MRs for a single issue and can move much more quickly through them. The trade-off is that doing so makes it more difficult to communicate the overall status of the issue itself. It is the engineer's responsibility to make sure that the status of each issue they are working on is effectively communicated to their Product Manager.
We group related issues together using parent epics and child epics, providing us with a better visual overview of our roadmap.
[ENG], [UX] and [Product] to indicate their area of focus. The prefixes can be combined if the epic holds issues of different areas, e.g. [ENG][UX].Engineering and UX to easily filter epics.After a design is done, the design issue needs to be set to workflow::planning breakdown and engineering takes over the process of breaking it down. The design issue can be closed after break down is done.
Epics can contain issues and/or child epics. A child epic could for example be the first iteration of the parent epic. An example of how the structure of an epic could look:
Epics have the following limitations:
gitlab-org from an epic created in gitlab-org/growth.gitlab-org can't link to an issue created in gitlab-services.To overcome this, we will:
gitlab-org, gitlab-com, or gitlab-services.The parent epic should live on the top-level group where most of the issues and child epics will be created.
We use issue labels to keep us organized. Every issue has a set of required labels that the issue must be tagged with. Every issue also has a set of optional labels that are used as needed.
Required labels
~devops::growth~group::product intelligence~"workflow::planning breakdown, ~"workflow::ready for development, ~"workflow::In dev, etc.Optional labels
~growth::experiment~"experiment::active, ~"experiment::validated, etc.~DeliverableUXMR labels can mirror issue labels (which is automatically done when created from an issue), but only certain labels are required for correctly measuring throughput.
Required labels
~devops::growth~group::product intelligence~security, ~bug, ~feature, ~backstageWe tag each issue and MR with the planned milestone or the milestone at time of completion.
We always push ourselves to be iterative and make the minimal viable change. Defining the minimal viable change takes practice.
The image above illustrates how we iterate. The goal is to build something quick and functional. Our first iteration gets us from A to B even though it doesn't have all the bells and whistles. A skateboard is not as fast as a car, but it is fully functional. Each subsequent iteration provides the user with more speed, more control, and a better aesthetic.
Building a skateboard is low complexity and can be assembled in a day. Building a car is high complexity and takes thousands of parts and a much longer assembly time. Start with the skateboard first, iterate to the scooter next, then continue iterating and eventually you can build a car.
A common misconception of iteration is that there is no waste. Using the example above, the parts of a skateboard can be reused in a scooter, however, they cannot be reused in a car. Iteration often requires us to throw away code to make way for a better product.
Technical debt: It's common to discover technical debt during development of a new feature. In the spirit of "minimum viable change," the resolution of technical debt can be deferred to a follow-up issue.
Groups hold synchronus meetings at least once a week to gain additional clarity and alignment on our async discussions.
Meeting agenda
The agenda for each meeting is structured around the Product Development Flow.
~workflow::start, ~workflow::problem validation, ~workflow::design, workflow::solution validationworkflow::planning breakdown, workflow::blocked, workflow::ready for development, workflow::In dev, workflow::In reviewMeeting rules
We have daily asynchronous standups. Team members are using either status hero or geekbot for their daily standups. The purpose of these standups are to allow team members to have visibility into what everyone else is doing, allow a platform for asking for and offering help, and provide a starting point for some social conversations.
Three questions are asked at each standup:
One of our main engineering metrics is throughput which is the total number of MRs that are completed and in production in a given period of time. We use throughput to encourage small MRs and to practice our values of iteration, although we do not necessarily equate one MR to one complete iteration. We recognize that just as an issue may be broken down into multiple merge requests, so can iteration of a feature be spread across several MRs, especially with the use of feature flags. Read more about why we adopted this throughput model.
We aim for the current development department MR rate which is tracked using our throughput metrics dashboard.
| Resource | Description |
|---|---|
| Product Intelligence Guide | A guide to Product Intelligence |
| Usage Ping Guide | An implementation guide for Usage Ping |
| Snowplow Guide | An implementation guide for Snowplow |
| Event Dictionary | A SSoT for all collected metrics and events |
| Privacy Policy | Our privacy policy outlining what data we collect and how we handle it |
| Implementing Product Performance Indicators | The workflow for putting product performance indicators in place |
| Product Intelligence Direction | The roadmap for Product Intelligence at GitLab |
| Product Intelligence Development Process | The development process for the Product Intelligence groups |
| Growth Product Direction | The roadmap for Growth at GitLab |
| Growth Product Handbook | The product process for the Growth sub-department |
| Growth Sub-Department Development Process. | The development process for the Growth sub-department |
| Growth Sub-Department Performance Indicators Process | The performance indicators for the Growth sub-department |
| Growth UX Process | The UX process for the Growth sub-department |
| Growth QE Process | The QE process for the Growth sub-department |
