Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Product Stage Direction - Plan


As the broader GitLab organization pursues its vision of replacing disparate DevOps toolchains with a single application, the Plan stage aspires to build robust planning tools that meet the needs of our customers and tie directly into the broader DevOps lifecycle. This document outlines the overall direction of our stage, the market we’re after, and our vision of a loveable DevOps planning solution within GitLab.

Scope and Context

Planning tools are a diverse and complex product segment with far-reaching niches that solve unique problems for different types and sizes of teams. Today most GitLab customers arrive and adopt Create (source code management) or Verify (continuous integration) first. Since the primary customer is typically a software development organization and GitLab’s branding, marketing strategy, and adoption patterns align with those personas, Plan will focus on building a solution for software teams. That said, we've seen great success with non-software teams adopting Plan to meet their needs. Our own Marketing team dogfoods Plan to successfuly manage large marketing programs.

Today our stage is organized into three groups: Project Management, Product Planning, and Certify. For the purposes of this page, we’re going to scope our vision around our Jobs to Be Done which may cross-section multiple groups and categories. Overtime we may shift and evolve our groups and categories to attack this ambitious vision but this framing should keep us rooted in the capabilities our product needs to deliver for our customers.

Today many users already find a lot of value within our Planning capabilities. Customers across different industries have adopted Plan within their organizations and are already reducing cycle time, increasing PM and developer happiness, and extracting value from the deep integration with their primary SCM and CI/CD tooling. They’re bought in and love the fully integrated toolchain. That said, we still have a long road to travel. In some areas we fall short and need to mature on the basics, in others we'll look to lead and innovate leveraging GitLab's unique position in the market. While the basic building blocks for the Plan stage have existed since the very beginning, we feel like we're just getting started.

Problem and Jobs to be Done

So… what is Plan and what problems are we really trying to solve? Plan facilitates a connection between Dev and Ops. It can start simply as an issue that turns into a code change via an MR, merged, deployed and eventually delivered to a customer. As organizations and products grow, what goes into deciding what to change and how to change it becomes much more complex. Product Managers and Development Managers need to weigh tradeoffs, effectively prioritize, understand their velocity and realize the value they end up delivering to their customers. This is where Plan can contribute to a high performing team, and where the problems and challenges to solve for our customers become complex.

To best frame these problems we’ve compiled a set of Jobs To Be Done (JTBD) that represent the jobs our users are hiring us for. If you’re unfamiliar with JTBDs take a look at this article.

Map business and portfolio plans to market opportunities

Job statements Maturity Confidence Source
When preparing for planning or strategy review, I need to understand how previous work was performed and what was delivered, so I can make informed decisions on where we need to focus in the future. Badge level b Researched Issue
When crafting my strategic plan, I need to validate to business owners that I am providing a return, so I can increase trust with stakeholders and promote confidence in my plans. Badge level - Issue
When working through a list of ideas, I need to be able to validate that an opportunity is valuable and worth funding a solution, so I can deliver value to my customers and drive success for the org. Badge level c Researched Issue
When working through a list of validated opportunities, I need to be able to understand effort and map ROI for each, so I can prioritize the right sequence of work. Badge level - Issue

Plan and Collaborate On Value Delivery


Job statements Maturity Confidence Source
When creating or revising an initiative's operational plan, I need to allocate resources to it so it is clear what the projected costs will be and what capacity is available to complete work on an ongoing basis. Badge level - Issue
When conducting Product Increment or Sprint planning, my team needs to convert prioritized initiatives and their business objectives into estimate-able work items to be delivered, so that we can sequence work according to available capacity and relative ROI. Badge level c Researched Issue
When conducting Product Increment or Sprint planning, my team needs to commit to delivering a realistic amount of work within a given time period, so that stakeholders can understand what will be delivered and when. Badge level d Researched Issue

Report On Output

Job statements Maturity Confidence Source
When monitoring a team's work in flight, I need to be able to easily review and digest the current progress so that I can confidently report to stakeholders and leadership. Badge level d Researched Issue
When reporting status, I need to be able to ensure my status is accurate, current, and quantifiable so I can maintain a high level of trust with stakeholders. Badge level c Researched Issue

Improve Output Processes

Job statements Maturity Confidence Source
When reviewing a plan, I need to ensure that high risk items can be identified and continually monitored so I can validate and modify mitigation plans. Badge level c Researched Issue
When implementing to a plan, I need to monitor progress (velocity) so I can demonstrate that the team is efficiently capturing value for our stakeholders. Badge level - Issue
When reviewing a prior cycle, I can easily reflect on and improve my team's effectiveness. Badge level - Issue

Measure Outcomes and Learn

Job statements Maturity Confidence Source
When reviewing progress against our objectives, I can easily measure the success of our past work which informs future plans Badge level - Issue
When my team completes a unit of value, we need to get feedback as quickly as possible on whether or not what we delivered was valuable to the end user, so that we can make incremental progress towards our business objectives. Badge level - Issue

You’ll notice these Jobs to be Done don’t line up with a specific feature or tool that we or one of our competitors offer. This is intentional - customers are not hiring us to be a better issue tracker, they’re hiring us to help them deliver value to their customers faster with more consistent results in conjunction with our other Stages across the DevOps Lifecycle. That said, there are common tools and feature sets that the industry has widely adopted (hired) to complete these jobs. We don’t see a departure from issue trackers coming anytime soon, and teams will still need a way to organize their work on a backlog for a given iteration. That said, we must evaluate ourselves against how well we meet the needs of that set of jobs. If we do well, the details will fade into the background and our customers will love GitLab’s planning tools because they ‘just work’.

The Plan Market

When you look across the landscape of planning tools you’ll find a few things. First, there are some large incumbents. Along the lines of Jira and Rally, these solutions have been in the market for many years and have very large customer bases. It’s often difficult to find customers of these tools that say they ‘love’ one of these competitors - but they’ll quickly rattle off the capabilities they need that only that competitor provides. This uncovers both a unique challenge and opportunity. When customers don’t love who they currently hire for a job the opportunity is ripe for disruption, but with the nuance of planning methodologies and adherence to specific capabilities, it can be challenging to break through.

You’ll also find countless upstarts who aim to make tools that software teams won’t hate. Companies like Clubhouse or Wrike take a less software-oriented approach to planning (but still sell heavily into software teams). The wildcards are the startups like Airtable and Notion that avoid a strict point of view on methodologies and let teams configure their tools to solve numerous use cases for their business.

As GitLab continues to mature and gain market share across our existing Stages, we see a strong opportunity to extend the value proposition of a “single application for the entire DevOps lifecycle” into the $35B Enterprise Resource Planning (ERP) and $48.2B Customer Relationship Management markets.

Competitive Landscape

There are several entrenched market leaders as well as new startups entering the space on a regular basis. Among the largest competitors are:

Our Vision of a Loveable Solution

The Power of Planning within a Single DevOps Application

As an end to end DevOps platform, GitLab is uniquely positioned to deliver a planning suite that enables business leaders to drive their vision and development teams to quickly deliver value while improving how they work iteration by iteration. Our unification of the DevOps process allows us to interlink data across every stage of development; from initial analysis, to planning, implementation, deployment, and monitoring.

For enterprises and growing SMBs, the complexities and difficulties of managing multiple teams and projects across your portfolio are monumental. Not only do organizations need access to detailed information on the progress of individual teams, they need to aggregate it up to consumable views for leaders to review and make informed decisions against.

This shared environment allows us to directly relate individual contributions and merge requests to larger company goals and directives. Leveraging these relations, GitLab aspires to provide planning functions that bridges the gap between individual contributors and the executive suite. We aim to surface the right information at the right level, empowering your business to quickly adapt to changing market conditions without multiple integrations and licenses across a suite of bloated solutions.

In order for teams to accelerate software delivery and have a greater ability to manage changing priorities, team-level planning tools and methodologies need to focus on helping teams collaborate effectively in order to decrease their time to value. We believe efficiency can be improved in two ways. The first way is to improve the efficiency of work that teams flow through existing value streams. This focuses on continuously optimizing the planning and execution processes to make them as fast as possible while maintaining high quality standards to enable faster innovation cycles in the future. The second way is to question and change the value stream into higher value-added activities at each step of the software delivery process. GitLab’s vision for Project Management is to help teams answer both of these questions: “Am I doing things fast enough?” and “Am I doing the right things?”

We are deliberately investing in improving GitLab to address the unique challenges that project, delivery, and product managers face – including feature management, mapping to business value and outcomes, and synthesizing input and feedback from dozens of disparate channels into outcome driven, actionable roadmaps that are tightly aligned to the larger portfolio objectives and key results with their organization.

Goals for 2021

Project Management

Best in class 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; think of how Jira could work if it were designed by Trello as opposed to the other way around. Our boards need to evolve to be a primary interface, an experience where:

Iterate sustainably

Better support Scrum while being inclusive of other methodologies that use timeboxes such as XP. Make Iterations great.

Provide dashboarding and analytics for project and portfolio management, allowing business to track and communicate progress on work in flight, capacity of teams and projects, and overall efficiency across their full portfolio. Board work in progress limits were the first step here, but expansion of the milestone page to have more historically accurate insights into sprint velocity, scope movement, and plans vs. actuals are important for product development teams.


Supplementing the above focus areas, an agile team using boards to deliver work from week to week should find the experience delightful. We're making usability an area of focus by leaning on user feedback for guidance on points of friction that need sanding down. Over time, we'll eliminate paper cuts we hear from users directly and in our periodic SUS survey.

Furthermore, the entire experience should be self-discoverable by our targeted persona. It's currently too challenging for our customers to get flying without help. If customers can't self-serve our Plan capabilities, it'll be a constant challenge to drive usage to the capabilities we're investing in above.

Unify projects and groups

A usability focus area worth highlighting will be combining projects and groups, two of GitLab's most important small primitives, into a single object that we can use throughout the product. This has the potential to simplify the product experience and introduce massive efficiencies for GitLab by removing the need to build features at both the project and group level.

Product Planning & Certify

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.

Strategic Planning with Initiatives 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.

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 test. Additionally, we'll be launching the MVC of Quality Management in 13.7, focusing on dogfooding of quality management features by our own quality team.

We aim to draw on the strengths of a single DevOps platform by creating a unified approach requirements management and quality management.

Being able to clearly document your products requirements should be simple and intuitive and will enable users to show certification to the guidelines, standards, and potential regulations imposed by your organization or customer. These requirements should be easily to organize and allow for flexible classifications. It should be simple for architects and engineers to link requirements to other higher and lower level requirements to create an easy to visualize hierarchy.

In parallel with implementation, we will allow for testing to be organized in a hierarchical manner utilizing test suites, test groups, and test cases. Utilizing automated means, test sessions can be created and run, with status reported in a clean and efficient manner.

To unify the certify package, requirements will be able to trace to test cases. This will allow for requirements to automatically be identified as satisfied when the linked testing has completed and passed. In this way, showing requirements verification will be greatly simplified, saving precious and resources compared to current manual offerings. This will also allow for simplified auditing as selecting a requirement will show traced code files, traced tests, as well as the status of these tests.

This has three significant benefits for organizations:

  1. Their teams can work in an agile continuous testing / delivery mindset, and have their requirements coverage information be collected for them. This raises the teams efficiency tremendously and effectively eliminates the manual steps of tracing requirements to code / test.

  2. Since the software teams no longer need to utilize expensive external tools, program costs can be reduced significantly.

  3. Systems teams can maintain their existing requirements tool chains for industry conformity and complex analysis (where these tools make sense).

Plan Categories


Plan, organize, and track project progress with issues, labels, weights (story points), milestones (sprints and releases), time tracking, due dates, and assignees using Scrum, Kanban, SAFe, and other methodologies. This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection


Estimate, track, and report on time spent on issues. This category is at the "viable" level of maturity.

Priority: low • Learn moreDocumentationDirection


Visually prioritize, manage, and track work execution with powerful and flexible boards. This category is at the "viable" level of maturity.

Priority: high • Learn moreDocumentationDirection


Plan upcoming work by creating Epics and mapping all relevant Issues to them. Create and track against multiple milestones at the portfolio level to see status overtime and review progress towards your goals This category is at the "complete" level of maturity.

Priority: high • Learn moreDocumentationDirection


Visually plan and map projects in a roadmap view which can be used for tracking and communication. This category is at the "minimal" level of maturity.

Priority: high • Learn moreDocumentationDirection


Connect your team using GitLab issues, to external parties directly via email for feedback and support, with no additional tools required. This category is at the "viable" level of maturity.

Priority: low • Learn moreDocumentationDirection


Gather and manage the use cases and requirements to meet business objectives. This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection


Plan and track testing and quality of your product. This category is at the "minimal" level of maturity.

Priority: low • DocumentationDirection


Access and manage your projects.



Upload design assets to GitLab issues for easy collaboration on designs with a single source of truth. This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection

Plan Stage Pricing Strategy

The Plan stage pricing strategy balances growing usage adoption across all personas while delivering the enterprise-level capabilities our larger customers demand. This approach enables small teams to be successful with GitLab Plan without upgrading to a higher tier. Teams of any size should be able to effectively plan work local to their team and deliver more value to their customers with core features like issue tracking and labels. As organizations grow and mature their adoption of the DevOps lifecycle we offer robust enterprise-grade planning capabiliites that align closely to their needs. Features like Requirements Management and Multi-Level epics offer feature functionality that uniquely benefit larger organizations.

As we continue to mature our categories we'll consider three major pricing principles:

  1. **We aim to have an offering for each category at each tier. This aligns closely with GitLab's buyer model. That said for Plan, the majority of our features aim to make 'teams' more successful within the DevOps lifecycle.

  2. If a feature adds unique value to more complex planning strategies we should aim towards a higher tier. A good example of this are Roadmaps. Roadmaps are often deployed with multi team organizations that need to plan work across disparate functions and sub-organizations. Roadmaps offers a unique view that benefits executive teams and product leaders to better understand the delivery timelines of various Epics across an organization. They are available in Premium.

    • We build value upon existing primitives that start at a lower tier, and as the product matures we consider moving its primitive capabilities down. Issues are a great example, as most features in Premium/Ultimate tiers require broad adoption of the issue primitive.


An Individual Contributor, Personal Projects Free tier should be considered a primary driver for adoption (measured in GMAU or SMAU). If a feature aligns with a basic planning action that an individual contributor would benefit from, then target Free. Any individual should be able to get up and running easily with some basic planning features and find value within the first few weeks without needing to upgrade. This includes importing issues, along with core issue management features like labels, assignees, and templates.

If we're able to deliver meaningful value at Free we'll see continued growth and adoption as measured by SMAU.


Teams of any size The Premium tier begins to unlock capabilities that make sense for managing complex projects across a single team. Targeting this tier still has the opportunity to drive adoption through a land and expand model as teams begin to adopt Plan. Especially in the case where an organization's first Stage is Create, as they move repos over and find value in managing their code they'll benefit from the ability to tie in planning activities within the same tooling. This tier should make available anything an individual team needs to effectively develop software with basic Agile methodologies like Scrum or Kanban. Premium is the team-level paid tier for Plan. We use this tier to offer unique functionality that aligns closely with the needs of teams and the varying organization structures that can exist within them. Features at this tier will enable product teams to effectively plan broadly across teams, map dependencies, and report on business outcomes as they deliver value to their customers.


Mature enterprises who have adopted advanced planning methodologies The Ultimate tier targets enterprise customers who have adopted Portfolio SAFe (or equivalent framework) and need to align teams across many departments. The Plan stage has only begun to bring value to this tier so we are still early in building out maturity, with a great roadmap in front of us. This year we've begun to deliver capabilities like Requirements Management, enhancing our Roadmaps and Epics, enabling enterprises to plan at the portfolio level.

This tier has the most IACV upside and requires us to build mature offerings for core capabilities to capture that value.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license