Product Section Direction - Dev

Last Reviewed: 2020-07-22

Dev Overview

Dev Section Overview

The Dev Section is made up of the Manage, Plan, and Create stages of the DevOps lifecycle. The scope for the Dev section is wide and encompasses a number of analyst categories including Value Stream Management, Project Portfolio Management, Enterprise Agile Planning Tools, Source Code Management, IDEs, Design Management, and even ITSM. It is difficult to truly estimate TAM for the Dev Section, as our scope includes so many components from various industries, but research from IDC indicates the estimated TAM in 2019 is roughly ~$3B, growing to ~$7.5B in 2023 (26.5% CAGR). Alternatively, the Dev product management team has conducted a bottoms up Total Addressable and Servicable Addressible market analysis which estimates GitLab's SAM for Dev to be 19.5B in 2019 growing to 27.5B in 2023. Analysis: Manage Plan Create

Based on DevOps tool revenue at the end of 2018 and comparing to GitLab annual recurring revenue at the end of FY20 Q3, our estimated market share is approximately 1.5% based on revenue. (Note: this assumes we can attribute 100% of GitLab revenue to Dev stages.) Market share based on source code management is somewhere in the 30% range.

Nearly half of organizations still have not adopted DevOps methodologies, despite data that indicates far higher revenue growth for organizations that do so. Migrating a code base to a modern, Git-backed source control platform like GitLab can often be the first step in a DevOps transformation. As such, we must provide industry-leading solutions in source code and code review, as this is not only the entry into DevOps for our customers, but typically the entry into the GitLab platform. Once a user has begun utilizing repositories and code review features like Merge Requests, they often move “left” and “right” to explore and utilize other capabilities in GitLab, such as CI and project management features.

Per our Stage Monthly Active User data we know that Create has the highest usage amongst GitLab stages, alongside Manage, which all users in groups uses. As such, these stages must focus on security fixes, bug fixes, performance improvements, UX improvements, and depth more than other areas of GitLab. Plan, while introduced in 2011 with the release of issue tracking, still falls behind market leaders who have better experiences for sprint management, portfolio management, roadmapping, and workflows although we are rapidly making progress here.

Other areas, such as Value Stream Management are nascent to both GitLab and the market, and will require more time devoted to executing problem and solution validation discovery.

Over the next year, Dev will require focus on both breadth and depth activities, and each stage will require significant investment to accelerate the delivery of security issues, performance issues, and direction items.

Within each stage, the listed items in the FY21 plan are in order of priority. The top priority for each stage is:

Is Our Dev Strategy Any Good?

In December of 2019, we released a blog with most of the content on this page and asked readers of the blog for feedback. To solicit the feedback, we asked our users on a scale from 1-5 how likely they were to recommend GitLab to a friend or colleague based on the strategy and the primary reason. 84% of survey particpants responded with a 4 or 5 vote. Here are the full results:

Survey Results

The primary reasons for the numbered score above were:

Who is it for?

We identify the personas the Dev section features are built for. In order to be transparent about personas we support today and personas we aim to support in the future we use the following categorization of personas listed in priority order.

Today

To capitalize on the opportunities listed above, the Dev section has features that make it useful to the following personas today.

  1. 🟩 Sasha - Software Developer
  2. 🟩 Devon - DevOps Engineer
  3. 🟩 Delaney - Development Team Lead
  4. 🟩 Parker - Product Manager
  5. 🟨 Presley - Product Designer
  6. 🟨 Cameron - Compliance Manager
  7. 🟨 Rachel - Release Manager
  8. 🟨 Simone - Software Engineer in Test
  9. 🟨 Allison - Application Ops
  10. 🟨 Priyanka - Platform Engineer
  11. 🟨 Sidney - Systems Administrator

Medium Term (1-2 years)

As we execute our 3-year strategy, our medium term (1-2 year) goal is to provide a single application that enables collaboration between cloud native development and platform teams.

  1. 🟩 Sasha - Software Developer
  2. 🟩 Devon - DevOps Engineer
  3. 🟩 Delaney - Development Team Lead
  4. 🟩 Parker - Product Manager
  5. 🟩 Presley - Product Designer
  6. 🟩 Cameron - Compliance Manager
  7. 🟩 Simone - Software Engineer in Test
  8. 🟨 Rachel - Release Manager
  9. 🟨 Allison - Application Ops
  10. 🟨 Priyanka - Platform Engineer
  11. 🟨 Sidney - Systems Administrator

3 Year Strategy

In three years, the Dev Section market will:

As a result, in three years, GitLab will:

3 Year Themes

Our direction for the Dev section is to provide the world’s best product creation and management platform. We believe we have a massive opportunity to change how cross-functional, multi-level teams collaborate by providng a solution that breaks down organizational silos and enables more effective, efficient value delivery. We want to provide a solution that enables higher-quality products to be more quickly iterated upon. We also want to make it effortless for companies to migrate to GitLab. In order to obtain adoption at scale, GitLab has to provide substantially more value than our competitors. Additionally, we believe the majority of value can likely be delivered by substantially fewer features than our competition. The following themes listed below represent how we believe we will deliver this value and is our view of what will be important to the market and to GitLab over the next 3 to 5 years. As such, they will be the cornerstone of our 3-year strategy, and all activities in the 1-year plan should advance GitLab in one or more of these areas.

Efficient and Automated Code Review

Code review should be a delightful experience for all involved in the process. Over time, we expect the code review process to evolve from where it is today to become a mostly automated process in the future. Along the way, incremental improvements will occur, where developer platforms like GitLab will focus on performance and usability of the code review tools. Code review should be an efficient process, and the easier GitLab can make code review, the more efficient dev teams become. Research has shown that better code review should reduce the number of bugs and increase the amount of higher-quality features an organization can ship. The code review process will continue to provide a venue for developers to learn and collaborate together.

As examples, GitLab will:

Measurement and Increased Efficiency of the Value Stream

Peter Drucker has stated “If you can’t measure it, you can’t improve it.” Many software development teams have no way of measuring their efficiency, and even if they do, there is not enough feedback, information, or actionable insights to improve the efficiency of their team. Even then, once efficiency is improved, it can be difficult to tell if a team’s performance is good or bad, as there is often no point of comparison. Even the best performing team in an organization could be worse than the competition. Increasing efficiency is paramount to companies increasing their time to value and helping organizations answer “Is my DevOps transformation working?”

We believe efficiency can be improved in two ways. The first way is to reduce cycle times for existing value stream activities. The second is to question and optimize the value stream into higher value-added activities at each step. GitLab’s vision is to help answer both of these questions: “Am I doing things fast enough?” and “Am I doing the right things?”

Today, value stream management is largely focused on visualizing the value chain through deployment. GitLab is uniquely positioned to also visualize, track, and measure value chain activities from the strategic initiative level all the way to captured value from an organization's customer. For example, the value created by post launch activities, such as press releases, blog posts, marketing campaigns, and customer engagement should funnel into value stream management; providing the business with insights and data to continuously improve each step of their value chain.

As examples, GitLab will provide:

DevOps for More Personas

DevOps started with the merging of Development and Operations and has since been augmented to include Security in some circles, highlighting DevSecOps as the next trend. There are many other personas that are involved in software development, such as product managers, project managers, product designers, finance, marketing, procurement, etc. These personas will continue to expand until nearly every role at knowledge-work companies touches some facet of the DevOps lifecycle. Over time, organizations will realize that teams who work out of the same platform/set of tools are more efficient and deliver faster business and customer value.

Because of this trend, each persona of the DevOps lifecycle should ultimately be treated as a first-class citizen in GitLab.

As examples, GitLab will provide:

Enterprise Compliance

Most enterprise customers have custom requirements that GitLab does not solve for today. This is a wide-ranging set of custom controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a flexible DevOps platform that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a “convention over configuration” approach, living with the cognitive dissonance that sometimes flexibility will be required in areas we have not been willing to venture into thus far.

Additionally, compliance, auditing, and surfacing evidence of security/compliance posture will become more important as more GDPR-like legislation is enacted and passed into law. GitLab should make it easy to not only surface and deliver evidence for GitLab controls (i.e. who has access to GitLab, who did what on what group, etc.), but also to track and manage compliance requirements for various legislation our customers may be bound to.

As examples, GitLab will provide:

Project to Product

Product Managers often struggle with answering the question, "Is the product or feature I just launched successful?" There are many sensing mechanisms to help answer this question, including revenue, users, customer feedback, NPS, etc., but no product currently helps product managers exhaustively manage the product development lifecycle from end-to-end. Many products assist with planning, delivery of code, and deployment, but feedback and iteration are equally as important to product managers as shipping the first iteration. Getting the first iteration out is traditionally celebrated, but is only one of many steps to true product development lifecycle management.

Imagine an experience where product managers can log in and view the "health" of their entire portfolio on one dashboard. It is clear which features have the most value to customers (and by extension to the business) as measured by key metrics, assisting PMs with priortization activities. PMs can quickly identify features or products within their portfolio that need more attention and drill into them, identifying the correct next action to take, whether it's iteration on the feature or perhaps sunsetting it. PMs can quickly create an issue for the next iteration, version control features, view security incidents, respond to customer feedback, drill down into analytics, control A/B tests of the feature, and even interact with users of the feature or product directly by creating ad-hoc surveys or questions for users to answer. Additionally, the experience should allow for ROI analysis and tracking of the ROI after capital has been expended.

Within three years, project management tools will begin evolving to provide this experience and help PMs answer tough product questions. These tools will also assist with measuring and predicting value to the organization before a feature is prioritized by the PM. The ideal solution most likely uses data science, natural language processing (NPL), machine learning, and predictive analytics to assist product managers with decisions both before and after a feature is launched.

As examples, GitLab will provide:

Remote Development

Local dev environments can be tricky to set up and often require hours to troubleshoot to set up development kits. Even when successfully configured, the "works on my machine" problem can arise as there are likely many differences between production and local environments.

We believe remote development will become a more popular development paradigm over the next few years and will manifest itself in this way: devs will code in places they are comfortable, such as local IDEs and will run code in Kubernetes environments that their IDE is connected to. Okteto is an interesting tool that is solving for this right now.

GitLab is uniquely positioned to serve as a remote development environment as we have a tight integration with Kubernetes as well as a VSCode Plugin in addition to an in-app editing experience in our Web IDE.

As examples, GitLab will provide:

1 Year Plan: What’s Next for Dev

Please see the categories page for a more detailed look at Dev's plan by exploring Direction links in areas of interest. This page will highight direction themes for both one year and three year timelines.

Manage

Primary Personas Served:

  1. Delaney - Development Team Lead
  2. Cameron - Compliance Manager
  3. Sasha - Software Developer

1. Enterprise readiness: GitLab must be seen as a platform that enterprises can use out of the box for both GitLab.com and self-managed deployments. We're doing this by focusing on improvements in several key areas:

Growth driver: Initial purchase

2. Providing a great import experience: Few instances start from scratch - for most, one of the earliest tasks for a GitLab administrator is importing information from outside the application. We'll win by creating easy paths to adopt and fall in love with GitLab:

Growth driver: Initial purchase

3. Actionable analytics: We've made great improvements over the first half of 2020 by releasing code review analytics, value stream analytics customization and filtering, and adding lead time and cycle time. One of our top focuses right now is working dogfooding our analytics features. This means we want our GitLab organization to use (and enjoy using) the analytics features inside of GitLab. We'll start by providing better throughput metrics and will continue by iterating on other existing analytics features as well.

Growth driver: Retention

Plan

Primary Personas Served:

  1. Delaney - Development Team Lead
  2. Parker - Product Manager
  3. Sasha - Software Developer

1. Support for better Agile Planning: GitLab users are able to assign a single milestone to an issue; however, many Agile methodologies require multiple timeboxes in order to support the process. For example, a story can be assigned to a longer term milestone, while also being part of a one week sprint. In GitLab 13.2 we're releasing our MVC of Iterations in order to allow users the ability to timebox with Milestones and a separate timebox for an Iteration. We'll continue to [iterate on this functionality(https://gitlab.com/groups/gitlab-org/-/epics/2422)] by providing better reporting and insights in the way of burn up and burn down charts, reports, metrics based on time/weight, and progress indicators for each iteration.

Growth driver: Initial purchase & Expansion

2. Best in class planning boards: Current project management tools are capable, but few enjoy the experience. Trello made significant gains by focusing on the user experience. Unfortunately, Trello chose to be a general tool which left some software teams wanting features designed specifically to help with software development and delivery. GitLab has an opportunity to re-design board-based workflows for product development teams. Our boards need to evolve to be a primary interface, an experience where:

Our near term work includes adding Epic Swimlanes and Epic Boards.

Growth driver: Retention with a transition to initial purchase

3. Enhancing Portfolio and Group Roadmaps: Provide easy-to-use, cross-team roadmaps at the portfolio, project, and epic level that allow users across the organization to see how work is progressing and identify dependencies and blockers. Organize and prioritize work though dynamic roadmaps in real time. Our current roadmap product works fine for epics, but only provides basic functionality. Roadmaps need to include all the necessary information to assess and react to your development plans (milestones, progress, timeboxes, dependencies, etc.) We've made improvements on this initiative by making milestones and weights available on the roadmap view.

Growth driver: Expansion

4. Strategic Planning with Initatives and Epics: Enhanced portfolio management experience allowing customers to start planning from the top; creating strategic initiatives, projects, and epics while laying them out on a roadmap prior to issues and milestones being created. Provide analytics at each level, and allow linking of each object to surface deeper dependency mapping across multiple teams and projects. Enable users to manage strategic initiatives, assign work, measure impact, and allocate resources to each to help deliver tangible business results. In FY21 we've already made substatial improvements by releasing several quality of life improvements for epics, such as the ability to more easily add issues to epics and by releasing issue/epic health status.

Growth driver: Expansion

5. Requirements & Quality Management: Many regulated customers desire to use GitLab for requirements mapping, dependencies, and process management. In 12.10, we released our MVC of requirements management, providing users the ability to create and archive requirements and are continuing to iterate on tying these requirements to tests. Additionally, we'll be launching the MVC of Quality Management in Q3, focusing on dogfooding of quality management features by our own quality team.

Growth driver: Initial purchase

Create

Primary Personas Served:

  1. Delaney - Development Team Lead
  2. Sasha - Software Developer
  3. Devon - DevOps Engineer
  4. Presley - Product Designer

1. Git availability and performance: Git is a critical component in the deployment process when practicing Continuous Deployment. As such, service degradations or outages that prevent access to Git cannot be tolerated. To this end, making Git storage fault tolerance and high performance at massive scale is of the utmost importance, and secondarily, improve the handling of extreme read pressures exterted by highly parallelized CI loads that cause performance degradations. We released general availability for Gitaly Cluster in GitLab 13.0 and are currently working towards distributed reads, strong consistency and incremental git backups.

Growth driver: Initial purchase

2. Provide a great experience for large repositories and monorepos: To gather more market share from industries that currently use Perforce or SVN, or from customers that just have huge monorepos, we must invest in making the large repository experience in Git excellent. Large files should “just work” without configuration or specialized hardware. We've made huge strides here by providing native support for git partial clone with granular blob filters. We're also working on providing better tooling for management of larger repos.

Growth driver: Initial purchase

3. Enhancing the code review experience: In FY21, we must focus code review to be more performant and intelligent. We will do this by investing in performance improvements, adding additional code review functionality such as jump to definition, identifying references, displaying function documentation and type signatures, and adding support for first-class reviewers. Code review should be an "IDE like" experience. Additionally, we should invest in enhancing language specific experiences such as improving syntax highlighting and webpacks. The Merge Request is a point of unification in the product and provides experiences for pipeline results, security scans, code review, discussions, and branching. As such, it's incredibly important that we care about the UX, performance, and usability of this object. We recently added functionality to comment on multiple lines in a diff and in Q2 have a product OKR to prioritize UX work for merge requests.

Growth driver: Retention

4. Focusing on the gaps in the design management workflow: Most designers use a sketch or prototyping tool already, but version controlling assets alongside code and providing a workflow to compare those assets to what front-end teams ship is a gap in the market. We are uniquely poised to capitalize on this gap; think visual review apps checked against the mockups checked into the repository. Additionally, we will continue to make improvements to the collaboration aspect of designs and consider other features such as simple sketch functionality inside of issues and MRs. We're currently focusing on improvements to design management that are focused on dogfooding internally, but are closing on solution validation for bringing designs into merge requests and allowing for comments on review app DOMs. We recently launched a Figma plugin to let designers seamlessly upload designs into GitLab issues and are continually making the discoverability and usability of design management better in many ways.

Growth driver: Expansion

5. Bolstering the Web IDE experience: Our current Web IDE experience is useful for small changes, but has not proven itself useful as an actual replacement for a local IDE. Over the next year we will streamline our editing experience, sunsetting the ACE, single-file editor. The team will also be investing in quality of life changes, such as adapting syntax highlighting preferences, moving information to areas in the Web IDE where they would be on local editors, and providing tools for easier code creation. Additionally, we recently moved to GitLab.com hosting the required components for the Live Preview capabilities already inside of the Web IDE. Functionality was released recently to check for valid syntax of gitlab-ci.yml files in the Web IDE and we're continuing to work on extending this to allow for custom schemas to be uploaded for syntax checking.

Growth Driver: Expansion

6. Creating a static site editing experience: Projects in GitLab aren't always leveraged by pure engineering teams. Groups like marketing, sales and others often have needs for projects that more closely resemble marketing websites or documentation. While GitLab Pages enables the deployment of many popular static site generators, the editing experience is still geared towards technical users. Enabling a more WYSIWYG content management editor will help support non-technical personas use GitLab for non-engineering driven projecs. We'll also ensure this experience is dogfooded by our GitLab Handbook and available on both mobile and tablet devices. In GitLab 12.10, we shipped the MVC for the static site editing experience and are continuing to iterate on it. Users can now use the Static Site Editor to modify single pages using the Middleman static site generator. In GitLab 13.3, the entire GitLab Handbook will be able to be modified using the static site editor!

Growth Driver: Expansion

7. Better Integrations: While GitLab is a complete DevOps platform delivered as a single application, we realize that many other tools are used to aid in the product development process and that in certain situations, these tools cannot be replaced. In early 2020, the Ecosystem team moved into the Dev section and is focused on "mass integration" at the Instance and Group level in addition to better integration with popular tools on the market such as Jira.

Themes that cross all Dev stages

Performance and availability: We must invest in the performance, stability, and availability of our application. We will do this by focusing on application limits, diff load times, and ensuring availability is top of mind.

Growth driver: Retention

What we're not doing next year

Choosing to invest in the above areas in 2020 means we will choose not to:

Stages & Categories

Manage

Learn more about our vision for the Manage stage at https://about.gitlab.com/direction/manage/.

Plan

Learn more about our vision for the Plan stage at https://about.gitlab.com/direction/plan/.

Create

The Create stage is made up of several categories:

ソースコード管理

ソースコード管理によって、ソフトウェア開発チーム全体での作業調整、情報共有、コラボレーションが可能になります。 ブランチの追跡とマージ、変更の監査、並行作業を可能にし、ソフトウェアのデリバリーを加速します。 This category is at the "lovable" level of maturity.

Priority: high • Learn moreDocumentationDirection

コードレビュー

非同期でレビューやコメントができることにより、分散したチーム間でコードをレビュー、変更点について議論、知識を共有、コードの不具合の特定ができます。 コードレビューの追跡とレポートを自動化できます。 This category is at the "lovable" level of maturity.

Priority: high • Learn moreDocumentationDirection

Wiki

組み込みのWikiで、ドキュメントや組織の情報を共有できます。 This category is at the "viable" level of maturity.

Priority: low • DocumentationDirection

静的サイトエディタ

静的サイトの編集とビルドのための、素晴らしいユーザー体験を提供します。 This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection

GitLabハンドブック

GitLabハンドブックの改善に注力しています。

Priority: medium • DocumentationDirection

GitLabドキュメントサイト

GitLabドキュメントサイトの機能、スタイル、ビルドプロセスを改善、保守しています。

Priority: medium • DocumentationDirection

Web IDE

フル機能の統合開発環境 (IDE) がGitLabに組み込まれているため、ローカルの開発環境に必要なパッケージをインストールするのに何日も費やす必要がなく、すぐに貢献を開始できます。 This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection

エディタ拡張

開発者がどこでどのようにGitLabと連携するかをサポートするツールです。

Priority: medium • DocumentationDirection

ライブプレビュー

Web IDEでシンプルなJavaScriptアプリケーションや静的サイトをプレビューし、変更点をリアルタイムに確認できます。 This category is at the "minimal" level of maturity.

Priority: low • DocumentationDirection

スニペット

ちょっとしたコードやテキストを保存し、他のユーザーと共有することができます。 This category is at the "viable" level of maturity.

Priority: low • DocumentationDirection

デザイン管理

デザインアセット(資産)をGitLabの課題にアップロードして、唯一の信頼できる情報源として使用することができ、デザインのコラボレーションを容易にできます。 This category is at the "minimal" level of maturity.

Priority: medium • DocumentationDirection

デザインシステム

デザインシステムとコード化されたコンポーネントの管理と文書化

Priority: medium • DocumentationDirection

Gitter

Gitterは、オープンソースの開発者向けインスタントメッセージングアプリケーションで、オープンソースとソフトウェア開発コミュニティをつなぐ場です。

Priority: low • Learn moreDirection

Gitaly

GitalyはGitLabからのgit呼び出しをすべて処理するためのGit RPCサービスです。

Priority: high • DocumentationDirection

インテグレーション

インテグレーションとは、GitLabと他の製品の機能やサービスと接続することです。 インテグレーションは、これらの製品間でシームレスな体験をお客様に提供することを目的としており、プロジェクトのSlack通知のような軽量な機能から、GitLab全体のさまざまな機能をAtlassian JIRAと接続する複雑で深いインテグレーションまで、さまざまなものがあります。

DocumentationDirection

API

GitLab APIを利用することで、他の製品やサービスとGitLabとの連携が可能になります。

DocumentationDirection

GDK

GitLab Development Kit(GDK)は、開発のためにGitLabをインストールして管理するためのスクリプトやその他のリソースをまとめて提供しています。

DocumentationDirection

FE/UXの基礎

GitLabのデザインシステム(Pajamas)とフロントエンドアーキテクチャ:webpack、PWAのモバイル対応の改善ニーズなど。

DocumentationDirection

Pricing

The Create stage pricing strategy balances the needs of individual contributors, with the needs of enterprises, to create a cycle where individual contributors gladly and rapidly adopt GitLab, and naturally create the business case for upgrading to a suitable tier, typically Premium and above. The core pillar of the Create stage is the merge request based development workflow. This touches Source Code Management, Code Review, Gitaly and the Web IDE, and is heavily influenced by individual developers, and managers who implement access controls for efficiency, quality and compliance purposes. Our investment and pricing philosophy is to:

Core/Free

The tier for individual contributors, personal projects, or small teams trialing GitLab, Core/Free is important for expanding (measured by GMAU and SMAU) the number of contributors in GitLab to include designers (Design Management), and marketers (Static Site Editor), and retaining our core users Developers (SCM, Code Review, Web IDE). Expanding support for different markets and use cases through improved binary file and monolithic repository workflows begins at the individual contributor level, as does supporting new personas like designers and marketers.

Examples:

Starter/Bronze

The tier for Managers of small teams, small start ups, Starter/Bronze is already a very capable tier and not a focus for investment.

Many features our competitors market in this tier already exist in the Core/Free version of GitLab.

Premium/Silver

The tier for Directors at medium and large enterprises, or organizations with multiple teams, Premium/Silver is enterprise ready and delivers important access controls and workflow controls needed for multiple teams to collaborate on the same large project. The Premium tier features for Source Code Management, Code Review and Gitaly are already mature, and very valuable to medium and large enterprises. Many feature requests and improvements driven by Premium/Silver customers are improvements to the experience of individual developers, which facilitates growth through expansion and standardization on GitLab.

Examples:

Ultimate/Gold

The tier for Executive buyers with strategic objects for their business, this tier is primarily supported through Audit and Compliance capabilities that extend project level access control features.

At present there are no Ultimate features planned for implementation by groups in the Create stage. This is due to support from the Manage stage, and demand from new and existing customers being focused on the individual developer experience, or access controls that meet the Premium/Silver tier definition.

What's Next

13.5 (2020-10-22)

Manage

Plan

Create

13.6 (2020-11-22)

Manage

Plan

Create

13.7 (2020-12-22)

Create