The Manage stage in GitLab delights business stakeholders and enables organizations to work more efficiently. Managing a piece of software is more than maintaining infrastructure; tools like GitLab need to be adoptable by companies of all sizes and be easy to operate. Setting up your processes shouldn’t be a struggle, and administrators shouldn’t have to compromise on security or compliance to prevent tools from hindering their velocity.
Delighting the business: to make GitLab adoptable by organizations of any size, it must excel at meeting table stakes that are set by the business. A skyscraper with many people in it can only be enabled by a solid, secure foundation - an application serving a similar scale isn't any different. GitLab needs to support the access control, onboarding, security, and auditing needs that enables enterprise-level scale. We also need to make the foundation easy to lay; constructing a building is slow and arduous when it's done brick-by-brick. Adopting GitLab should be fast and reliable and show a quick trail to getting an amazing return on your investment in GitLab.
Working more efficiently: while we want to fulfill foundational needs, GitLab strives to give you the ability to work in new and powerful ways. We aspire to answer valuable questions for users and to automate away the mundane. It’s not enough to give instances the ability to meet their most basic needs; as a single application for the DevOps lifecycle, GitLab can exceed the standard and enable you to work in ways you previously couldn’t.
Manage is composed of 4 distinct groups that support our mission of delighting business stakeholders and enabling organizations to work more efficiently:
We plan with 3 timeframes in mind:
|Stage Vision||3 years||Group Manager|
|Stage Goals||1 year||Group Manager|
|Group Vision||3 years||Product Managers|
|Group Goals||1 year||Product Managers|
|Focus Areas||3 months||Product Managers|
All of these sections are intended to be short (no more than a few bullets) and help guide our decisions toward our goals and vision. They live in parallel with our category direction pages, which go into more detail on specific capabilities and are not constrained to specific timeframes.
Access provides leadership on some of GitLab's most foundational capabilities - access control, authentication/authorization, permissions, and subgroups - that enable users to get into GitLab quickly and start getting work done. If we're doing our job correctly, an instance should be able to get a new user onboarded into GitLab without friction: at the right time, with the right level of permissions, to the right resources - all with a great user experience for the new user and the administrator doing the configuration and maintenance.
Creating isolation between top-level namespaces. Especially important for GitLab.com, organizations frequently express a desire to have control and auditability over the users they pay for. While we previously implemented group managed accounts as a solution for this, we're moving toward an identity model that does not require users to maintain separate accounts.
Expanding SCIM/SSO capabilities and support for specific providers. SAML SSO remains an important feature for large organizations on GitLab.com, and we'll continue to invest in capabilities like group sync.
Access uses a single epic to highlight issues we're prioritizing or refining. If you're not confident an important Access issue is on our roadmap, please feel free to highlight by commenting in the relevant issue and @ mentioning the relevant PM.
Import's goal is to make the transition into GitLab seamless. Instances rarely begin completely from scratch; almost every organization has existing repositories, projects, and resources that sit on the outside of any new tool after its been adopted. The more we do to help new instances and users start flying in GitLab, the faster they're able to realize value out of the application - and the longer they'll stay.
Historically, managing compliance programs has been complex and unfriendly. GitLab, as a complete DevOps platform, is well-positioned to take the friction out of managing compliance for your organization's activities and processes within GitLab. The data you need is already unified within GitLab and not aggregated from disparate data sources, which makes the compliance management process simple and friendly.
We will automate compliance within GitLab to save time for compliance professionals and remove friction for developers, so they can all focus on the most valuable uses of their time. We will make compliance fast, simple, and friendly and reduce the amount of time spent on compliance activities by at least 50%.
GitLab is currently focused on managing compliance for the activities and processes that exist within GitLab. In the future, we would like to provide similar compliance features and automation for the things you ship from GitLab.
This could include Infrastructure as Code (IAC) templates, deployments, and real-time monitoring of your infrastructure compliance.
Towards this vision, the Compliance group at GitLab is focused on three key areas:
The concept of separation of duties is the idea of requiring more than a single individual to complete a task; ensuring there is oversight and review by multiple individuals to catch errors or prevent fraud. This separation can occur at various points throughout an organization. At GitLab, this separation may need to occur in the following places (not an exhaustive list):
Current work underway at GitLab for separation of duties
|Initiative||DRI & Implementation Group|
|Separation of Duties in Deployment||Release:Release Management|
|Separation of Duties in CI: Include Child pipelines in DAG view||Verify:CI|
|Separation of Duties in CI: Parent of Child pipelines missing Child artifacts||Verify:CI|
|Separation of Duties with Compliance Templates||Manage:Compliance|
workflow::ready for developmentissues by spending 50% of our time on issue refinement each milestone.
To ensure we build a cohesive Compliance experience at GitLab, the following points of view are a baseline for other GitLab product groups to consider.
Given the inherent nature of compliance and its relationship to all areas of an organization, the Compliance group will take the lead on validating compliance problems.
In the majority of cases, the Compliance group will function autonomously as other product groups do to validate and build solutions to these customer challenges. However, the best solution for our users may involve specialized knowledge or significant engineering work in other areas of the product more closely maintained by other groups. In these cases, the Compliance group will recommend those groups (such as Manage:Access, Verify:CI, Release:Release Management) lead on the engineering effort. In order to be crisp on scope and expectations - all Compliance improvements described here will be validated and built by the compliance team - except those mentioned here.
The Analytics group (part of the Manage stage) in GitLab helps organizations more quickly recognize the value of their innovations in two ways:
Counter-productive local optimizations are a natural result of a limited field-of-view. By creating situtional awareness informed by analytics and value-stream thinking, we give every GitLab user the superpower of extraordinary insight and efficiency.
Within 3 years, organizations using GitLab will be able to provably plan, deliver, and deploy defect-free software faster than any other tool.
In order to reach our vision, we need to:
In pursuit of these goals, Analytics is currently focused on 3 initiatives:
Dogfooding: focus on internal customers by prioritizing improvements that increase the efficiency of engineering teams. By succeeding with our internal customers and refocusing the group's efforts on dogfooding, we'll also delight other engineering teams with powerful new capabilities. The value of this work should be immediately apparent to GitLab's Engineering and Quality Departments, and also help our customers track and optimize their engineering processes.
Enterprise DevOps reporting: understanding instance-level adoption of GitLab is a blind spot for customers of large instances. We'd like to solve for two main problems for executives and leaders: tracking GitLab's ROI and helping find centers of excellence. We'll prioritize work like an instance-level MVC.
Value stream analytics: we're also prioritizing Value Stream Analytics as the centerpiece of value stream management in GitLab, and we're pursuing improvements to make this feature easily understood and immediately useful.
3 years from now, software will be eating the world faster than ever. As Satya Nadella said, "every company is a software company", reinforcing a trend that's had decades to mature. It's a trend that's only accelerating: exogenous events like COVID-19 are putting even greater emphasis on automation and collaboration, even in more traditional industries. Knowledge workers across geographies and industries will thrive, with work becoming more distributed and asynchronous than ever.
While the pie grows, the increasing demand for software increases the spectrum of customer needs in tools like GitLab. New types of customers lead to new requirements - security and compliance, for example - and GitLab will be challenged to continue to expand the needs of these industries and new use cases. DevOps spending is predicted to grow at 23.5% CAGR between 2018 - 2023 (IDC 2019), and a rapidly expanding pie means both catering to these new customers and deepening our relationship with existing personas.
The growth in DevOps spending is predicted to be led by cloud deployment, and for good reason. All things equal, few organizations want to maintain their own tooling infrastructure. A need for control, compliance, and security compels organizations to self-hosted deployments; over the next 3 years, we'll make progress against each of these needs by:
Ultimately, tools that engineers build serve an organization's goal. Whether you're part of a non-profit, a public sector organization, or a for-profit corporation, software is built for a purpose. GitLab's aspiration is to help you measure your progress against that goal better than any other tool. The DevOps toolchain crisis is real, and it doesn't stop at software development - it extends to the many tools companies use to accomplish their goals. While our 3-year goal may not to be displace specific tools well beyond the development workflow, our aspiration is to delight a continually broader swathe of personas in our tool. Delighting business-minded personas are next on the list, by:
According to a 2019 IDC report, only 11% of survey respondents had security and compliance embedded into their DevOps processes. Most see these steps as frustrating, time-consuming bottlenecks that take many people-hours to resolve. Like security, compliance is a team effort - and when shifted left, becomes significantly more painless and cost-effective. We'll build on our compliance roadmap by:
On theme with a wide variety of industries adopting DevOps, our goal is getting customers into the product, getting them started, and getting out of the way. Our challenge is to make GitLab intuitive and easy to use without a steep learning curve; we've built our application on a foundation of small primitives, and our goal is to reduce the amount of configuration and setup you need to get your team productive. We'll get users and organizations to their "ah-ha" moment faster by:
In 2020, the Manage stage will provide such compelling, must-have value to large customers that we will be able to attribute over $100M in ARR to Manage capabilities by end of year. This means that Manage is a must-have part of the feature set that supports that customer, or Manage was a key part of their adoption journey.
3 themes will guide Manage in 2020:
We're going to focus on increasing and retaining the number of customers with enterprise-grade needs by solving their most compelling problems. We're doing this by focusing on:
Success in this theme looks like:
You can track progress against this theme here.
We're going to drive an Ultimate story that creates obvious, compelling value. Currently, the majority of Ultimate's value lies in application security. We will strive to improve the breadth of this tier's value proposition by driving more value in Ultimate, such as:
Success in this theme looks like:
You can track progress against this theme here.
Manage will create easy paths to support our land-and-expand strategy. There's a starting point for any organization with an expansive new tool, and Manage will make this transition easy by supporting natural starting points - ideally in Core, for all groups - that get our customers started and hooked on GitLab:
You can track progress against this theme here.
To support our goals in 2020 and our 3-year strategy, Manage's focus will skew towards paid tiers. Electing to focus on enterprise-level themes like compliance and value stream management is intended to drive company-level financial goals, and we'll prioritize valuable features that customers using GitLab can land and expand into.
We'll also prioritize an approach that doesn't require an enterprise-grade customer to immediately pay for GitLab to realize value. Customers of any size should be able to adopt GitLab and fall in love with it, for free.
Each Manage group should use our Core/Free tier as the primary way to build GMAU and allow our target customer to land in our product. For the most part, features that tend to be "table stakes" for organizations of any size should land in Core/Free - we won't gate GitLab adoption behind a paid tier.
Noting that our pricing strategy directs Core/Free toward the individual developer, we also want to ensure that enterprises can quickly realize value from Manage before expanding further. Examples:
Not a significant part of Manage's pricing strategy, we'll use this tier to appeal to managers of small teams by positioning capabilities into this tier that help with team management. Managers of teams can benefit from project-level capabilities that help them manage their direct team, but most of Manage's future roadmap is targeted toward directors of larger enterprises in Premium. Examples:
The default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We'll direct features that solve for typical entry-level enterprise needs: reporting and analytics, operational efficiency, security and compliance, and other needs that are must-haves for medium to large organizations. While this type of organization should be able to get started in GitLab at lower tiers, they won't be able to thrive at scale. Examples:
Directed toward an executive likely buyer, Manage will direct capabilities into Ultimate/Gold that serve the organizational needs of the complex enterprise operating a large GitLab instance. The difference between a Premium and Ultimate feature is operational efficiency: a large enterprise instance has everything they need to thrive in Premium, but Ultimate features automate and make that same instance much easier to manage, optimize, and operate. Examples:
Manage uses Stage MAU as a primary measure of success. This represents the unique number of users getting value from the stage; all groups should be able to contribute to improving this number.
Manage's Stage MAU is currently being improved. Please see this issue to track progress.
Individual groups track progress against a number of group-specific performance indicators:
Manage operates under GitLab's values, but is a stage that seeks to particularly excel in certain areas that support our goals above. We seek to be leaders at GitLab by:
You can track our operational goals here.
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
プロジェクトを整理し、管理するリソースへのアクセスを制限できます。 This category is at the "lovable" level of maturity.
レビューやコンプライアンスのために重要なイベントを誰がいつ実行したかを追跡できます。 This category is at the "viable" level of maturity.
コンプライアンスを管理するために必要なツールと機能をお客様に提供します。 This category is at the "minimal" level of maturity.
組織がDevOpsをどの程度適用しているか、また開発スピードにはどの程度影響しているかを表示します。 This category is at the "viable" level of maturity.
DevOpsのライフサイクルのバリューストリーム（価値の流れ）を可視化、管理、最適化できます。 This category is at the "viable" level of maturity.
This category is at the "viable" level of maturity.
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!
import/exportCloud-Native: use remotely stored