The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
As part of our overall 3 year Strategy GitLab is striving to build a Customer Centric DevOps platform through Strong Data Insights. In order to empower our customers to achieve their goals, and ultimately enable GitLab to ship a world class DevOps product, we must provide the necessary data and reporting so all teams within the business can identify opportunities, mitigate risks, and make the right decisions. By providing robust and accurate reporting we can reduce the cycle time from when we release a change, to when we know its impact to overall product usage, and customer experience, helping all of GitLab reach our goals through operational efficiencies, R&D allocation/investment, development priority, etc.
To accomplish this, we aim to leverage our deep expertise, tied with investments in a strong technical foundation to enable all teams within GitLab to produce, analyze, and report on product data by FY23-Q4. Like many top software/SaaS companies we are moving to be a product-led and data-driven organization. Through a partnership with our Data Team and collaboration with Product and Engineering we are cultivating a strong data focused culture within GitLab, driving to support our 30 year BHAG company goal of "becoming the most popular collaboration tool for knowledge workers in any industry".
The key thesis of our group is that providing more visibility into how GitLab is used allows us to make better decisions which lead to better business outcomes for ourselves and our users. In order to build the best DevOps product we can and provide the most value for our customers, we need to collect and analyze usage data across the entire platform to investigate trends, patterns, and opportunities. Insights generated from our Product Intelligence program enable GitLab to identify the best place to invest time and resources, which categories to push to maturity faster, where our UI experience can be improved, and how product changes effect the business.
We understand that usage tracking is a sensitive subject, and we respect and acknowledge our customers' concerns around what we track, how we track it, and what we use it for. We will always be transparent about what we track and how we track it. In line with our company's value of transparency, and our commitment to individual user privacy, our tracking source code and documentation will always be public.
A key aspect of aligning on our direction is understanding who we are building for. This allows us to best understand the problems they may have and the context that they will be approaching our offerings with.
Product groups within GitLab consist of a Product Manager, Engineering Manager, engineers, and other stable counterparts. These groups implement new features in GitLab and want to understand how users interact with those features. These teams have understanding of how the GitLab code base works as it relates to their features, but not necessarily how the instrumentation APIs and architecture work. They are not necessarily aware of the end-to-end story about how information flows from when a user clicks a button to a result being shown in Sisense or a report.
These product groups are our primary customer that we are serving and developing solutions for.
Consider reading more about Parker, our Product Manager persona.
Product Managers within these groups will have an understanding of how their group's features work from a user perspective, the problem those features solve, and what sorts of actions result in a user "succeeding" at the job to be done, and have growth and usage goals for that feature. They will be able to describe a user journey and key points that should be instrumented along that journey to measure success or need for improvement. They will not necessarily understand what the underlying code for the feature looks like or how all the technology pieces fit together. They need to be able to easily understand which kinds of tracking are available and how they are differentiated to be able to understand the resulting data. If they find it difficult to add the instrumentation they want, they will instead rely solely on qualitiative analysis, such as direct user conversations, rather than a blend of both qualititative and quantitative analysis.
Consider reading more about Sasha, our Software Developer persona.
Engineers within these groups will have an understanding of how GitLab is built and run but likely are not familiar with the product instrumentation architecture nor APIs. They heavily rely on documentation, examples, and previous MRs to add instrumentation that their PM requests. When they are unable to self-serve, they will ask the product intelligence group for help or give up.
This persona relies on what we provide to them, which means it is critical for us to keep examples up to date and have clear guidance around deprecated APIs so that engineers use our newer, preferred APIs instead of older ones.
The GitLab data program is responsible for surfacing data and data-driven insights to the business. They have expertise in building data pipelines, models, and managing data once collected. They are not necessarily familiar with the GitLab code base and rely on product groups to add instrumentation for new metrics or update existing ones. They rely on Product Intelligence to effectively collect and send data to Snowflake, which is their main interface with the data.
External GitLab users are a broad category of individuals with different needs and who have different skill sets. These users may be interested in reading about what data we collect and how to interact with it. In the future, external users will use the application instrumentation SDKs our group provides to be able to instrument their own apps.
External users rely on our handbook pages and sites like metrics.gitlab.com to understand what data is collected from their GitLab use, how to view it, and how to interact with it. If they are unable to get clear answers to their questions, they become frustrated. In that case, they may reach out to their account manager to help them, post on a forum, or stop using GitLab.
External users will use the application instrumentation SDKs we provide to instrument their apps. These teams will be similar to our own product groups within GitLab. That is, PMs will understand user journeys about their features, developers will understand how their own app is built, but neither will be familiar with our instrumentation SDKs. They will rely heavily on our documentation and examples or else they will give up and do something else.
GitLab's single application approach to DevOps creates a product that is both wide and deep, encompassing a large collection of features used by many teams within an organization, which are composed of different types of users.
Watch a walk-through of our FY23 roadmap (recorded 2022-03-24), or access a live and up-to-date view of where we're headed in this epic roadmap view in GitLab.
| 12 Month Vision | 3 Year Vision |
|---|---|
| Build reliable and scalable data instrumentation, collection and delivery tools across platforms,which enable developers and product teams to glean insights from their development efforts. | Build a product usage data framework which sits at the core of how we build product at GitLab; powered by intelligent instrumentation, exhaustive events collection, reliable and understandable data outputs with self-serve discovery and analysis capability. |
Business Outcome. In rapid development environment GitLab team members needs as broad data available as possible in order to flexibly adapt to new features, stages and use cases emerging without need to manually instrument tracking. Teams Involved. Product Intelligence, Data, Infrastructure
Problems to Solve.
FY23 Roadmap.
Business Outcome. GitLab team members needs trust worthy data to build analysis upon. Whenever data is lost it causes distortion and reduce trust. Teams Involved. Product Intelligence, Data, Infrastructure
Problems to Solve.
FY23 Roadmap.
Business Outcome. Increase product usage data coverage. Comprehensive product usage data will allow us to make better product decisions. Teams Involved. Product Intelligence, Data, Product, Product Data Analysts
Problems to Solve.
FY23 Roadmap.
Business Outcome. GitLab team members need the ability to measure product usage using a common method for customers on both self-managed and SaaS platforms. Teams Involved. Product Intelligence, Data, Customer Success
Problems to Solve.
FY23 Roadmap.
For more information on Product Intelligence, you can checkout our Product Intelligence Guide which details a high-level overview of how we make data usable, the Collection Frameworks we leverage, our Metrics Dictionary, and much more!
Product Intelligence provides the necessary frameworks, tooling, and expertise to help us build a better GitLab. Naturally we sit in the middle of many projects, initiatives and OKRs at GitLab. In order to provide clarity and realistic expectations to our stakeholders and customers we practice ruthless prioritization(per Product Principle #6), identifying what is above the line, what is below, and what is unfunded and not possible for us to action on in a given timeline.
This table lists recurring activities that are part of working groups and cross-functional initiatives. Use this spreadsheet to edit this markdown table.
| Activity | Cadence | Type | Teams Involved |
|---|---|---|---|
| GTM Product Usage Data Working Group | Weekly | Sync | Fulfillment PMs, Product Intelligence, Data, Customer Success, Sales |
| Data & Analytics Program for R&D Teams | Every 2 Weeks | Sync | Fulfillment PMs, Product Intelligence, Growth, Data |
| Product ARR Drivers Sync | Monthly | Sync | Customer Success, Sales, Product Leadership |
| Resource | Description |
|---|---|
| Product Intelligence Guide | A guide to Product Intelligence |
| Service Ping Guide | An implementation guide for Usage Ping |
| Snowplow Guide | An implementation guide for Snowplow |
| Metrics Dictionary | A SSoT for all collected metrics from Usage Ping |
| 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 Development Process | The development process for the Product Intelligence groups |
| Project resposibilities | List of several projects that our group is the DRI for |