| Stage | {{< label name="devops::plan" color="#e44d2a" >}} <br> {{< label name="devops::create" color="#e44d2a" >}} <br> {{< label name="devops::verify" color="#e44d2a" >}} <br> *more labels available in series....*| Specifies which product stage is responsible for the work; enables stage leaders to view all commitments for their area |
| Group | {{< label name="group::authorization" color="#a8d695" light="true" >}} <br> {{< label name="group::dedicated" color="#a8d695" light="true" >}} <br> {{< label name="group::knowledge" color="#a8d695" light="true" >}} <br> *more labels available in series....*| Identifies the specific team responsible for implementation; allows teams to filter for just their own commitments |
| Interlock priority | {{< label name="Interlock Priority::E1" color="#cd5b45" >}} <br> {{< label name="Interlock Priority::E2" color="#cd5b45" >}} <br> {{< label name="Interlock Priority::E3" color="#cd5b45" >}} <br> {{< label name="Interlock Priority::P1" color="#cc338b" >}} <br> {{< label name="Interlock Priority::P2" color="#cc338b" >}} <br> {{< label name="Interlock Priority::P3" color="#cc338b" >}} | Interlock Priority labels indicate the level of confidence and commitment for both Product-driven (P1/P2/P3) and Engineering-driven (E1/E2/E3) initiatives. <br><br> - P1/E1 indicates 100% confidence in delivery with full resource commitment. <br> - P2/E2 indicates 80% confidence in delivery. <br>- P3/E3 indicates 50% confidence and may be deprioritized if P1/P2 or E1/E2 items are at risk. <br><br> Product priority (P) labels are used for customer-facing features, while Engineering priority (E) labels are used for technical improvements with internal visibility only. |
| Go-to-market tier | {{< label name="GTM tier::Tier 1" color="#067aef" >}} <br> {{< label name="GTM tier::Tier 2" color="#067aef" >}} <br> {{< label name="GTM tier::Tier 3" color="#067aef" >}} | GTM tier labels apply to a subset of Product-driven initiatives that will be communicated externally to customers and stakeholders. They represent Go-To-Market priority and visibility: <br><br> - Tier 1: Requires GA of capability, validation through the Early Access Program, customer references and tells a story of differentiation; Need the highest confidence of delivery and is externally communicated commitments <br> - Tier 2: includes key feature updates that help tie together a story. These are considered less strategic, however may be noteworthy enough for a blog post or media interviews. They do not need to go through a formal early access or beta program, but must be available broadly with customer references as a "better" vs a requirement. Need high confidence items communicated to customers <br> - Tier 3: Directional items that may be communicated externally. Regular monthly release items that do not warrant a full GTM motion but should be included in communications, such as monthly release notes and potentially a blog post. <br><br> GTM tiers may be discussed during the collaboration phase, then finalized during the GTM Alignment Discussion (Week 10) by Marketing and Sales leadership. GTM priority tiers should never be higher than their corresponding Product priority (P1-P3) to avoid priority inversion.|
| Go-to-market tier | {{< label name="GTM tier::Tier 1" color="#067aef" >}} <br> {{< label name="GTM tier::Tier 2" color="#067aef" >}} <br> {{< label name="GTM tier::Tier 3" color="#067aef" >}} | GTM tier labels apply to a subset of Product-driven initiatives that will be communicated externally to customers and stakeholders. They represent Go-To-Market priority and visibility: <br><br> - Tier 1: Requires GA of capability, customer references and tells a story of differentiation; Need the highest confidence of delivery and is externally communicated commitments <br> - Tier 2: includes key feature updates that help tie together a story. These are considered less strategic, however may be noteworthy enough for a blog post or media interviews. They do not need to go through a formal early access or beta program, but must be available broadly with customer references as a "better" vs a requirement. Need high confidence items communicated to customers <br> - Tier 3: Directional items that may be communicated externally. Regular monthly release items that do not warrant a full GTM motion but should be included in communications, such as monthly release notes and potentially a blog post. <br><br> GTM tiers may be discussed during the collaboration phase, then finalized during the GTM Alignment Discussion (Week 10) by Marketing and Sales leadership. GTM priority tiers should never be higher than their corresponding Product priority (P1-P3) to avoid priority inversion.|
| Investment theme | {{< label name="Investment theme::AI across SDLC" color="#1b694f" >}} <br> {{< label name="Investment theme::Core DevOps" color="#1b694f" >}} <br> {{< label name="Investment theme::Security & Compliance" color="#1b694f" >}} | Connects work to company's strategic investment areas as outlined in the FY26 company strategy; enables filtering to track progress on key company initiatives |
| Subscription tier | {{< label name="GitLab Free" color="#8e44ad" >}} <br> {{< label name="GitLab Premium" color="#8e44ad" >}} <br> {{< label name="GitLab Ultimate" color="#8e44ad" >}} | Specifies which GitLab subscription tier(s) will include the feature; helps with planning go-to-market activities |
| Platform| {{< label name="platform: GitLab.com" color="#f2be02" light="true" >}} <br> {{< label name="platform: dedicated" color="#f2be02" light="true" >}} <br> {{< label name="platform: dedicated for gov" color="#f2be02" light="true" >}} <br> {{< label name="platform: self-managed" color="#f2be02" light="true" >}} | Indicates in which delivery platform the feature will be available |
The GitLab Early Access Program aims to increase engagement with early adopters, create brand ambassadors while also increasing the level of feedback received on non-GA high-priority features.
In a secondary priority, this helps to [cultivate contributions from the Wider Community](/handbook/engineering/devops/create/remote-development/community-contributions/) in alignment with GitLab's dual-flywheel strategy & GitLab's [Developer Relations strategy](https://internal.gitlab.com/handbook/marketing/developer-relations/#accountabilities)
## Key group that formed alignment on product direction
* Emilio Salvador
* Justin Farris
* Nick Veenhof
* Steve Evangelista
* Valerie Karnes
## Alignments
1. There are multiple categorizations of how customers and users access features:
1. Generally Available: These are features that are widely available to all customers and users, they may be only available via a paid subscription but otherwise won't be designed with any tag. We will offer full customer support for these features aligned with our support policy.0
1. Experiment, Beta: These are features any user can opt in and test independent of the Early Access Program; more detail on what distinguishes Experiment & Beta is included in our [Feature Support](https://docs.gitlab.com/policy/development_stages_support/) page.
1. Early Access Program Features: PMs & Product Leadership might select features to require an opt-in to the Early Access Program. Guidance is that this feature must be behind a feature flag so it can be rolled out to a select group of interested customers.
1. The existing process of accepting the terms & conditions of our testing agreement will be followed.
1. Guidance from UX & Product should be followed how this gets implemented for a consistent user experience. We should avoid adding friction.
1. Guidance from Legal should be followed to help decide on appropriate risks.
### FYI
For guidelines on how features are marked as Beta or Experimental, along with their legal and support status please refer to the following pages: https://docs.gitlab.com/policy/development_stages_support/
## Program nurturing activities
The following list is not complete and up for iteration. It serves as an example of activities that could be executed once we are able to communicate with our users is in place.
* We aim to obtain quotes & feedback from customers that use pre-GA features in press releases, blog & release posts.
* Incentive is joint-publicity.
* Through engaging and building a specific early-access community, we can re-use existing recognition & incentive mechanisms built by Developer Relations.
* Incentive is swag or donating trees when X testing activities are performed, when Y feedback items were created, leaderboards etc..
* Through nurturing campaigns of active members we guide them to becoming a contributor.
* Wider Community Contribution licenses can be granted for those that want to fix bugs or iterate on the features.
## Traffic Drivers
The following list is not complete and up for iteration. It serves as an example of traffic drivers that could be executed once we are able to communicate with our users is in place.
* Contributor Events such as GitLab Hackatons can be tuned to test pre-GA features and reward participants
* Inclusion in our Community Office Hours
* Increased social presence, blogs & social media campaigns
@@ -823,17 +823,16 @@ If you would like to improve your skills or expand your knowledge on topics rela
## 👣 Iteration {#iteration}
[Merriam-Webster](https://www.merriam-webster.com/dictionary/iteration#:~:text=%3A%20the%20action%20or%20a%20process,closer%20to%20a%20desired%20result) defines iteration as the "the action or a process of iterating or repeating: such as a procedure in which repetition of a sequence of operations yields results successively closer to a desired result." At GitLab, we iterate to do the [smallest valuable thing to get fast feedback and efficiently reach a desired end goal](https://lowrysolutions.com/blog/how-to-be-iterative-in-your-thinking/#_edn1). Feedback can be from internal users (dogfooding), a limited number of external users (through our [early access program](https://about.gitlab.com/community/early-access/)), or through feedback from our broader user community. We validate each iteration and adjust, but not at the expense of the user experience that we deliver to our customers.
[Merriam-Webster](https://www.merriam-webster.com/dictionary/iteration#:~:text=%3A%20the%20action%20or%20a%20process,closer%20to%20a%20desired%20result) defines iteration as the "the action or a process of iterating or repeating: such as a procedure in which repetition of a sequence of operations yields results successively closer to a desired result." At GitLab, we iterate to do the [smallest valuable thing to get fast feedback and efficiently reach a desired end goal](https://lowrysolutions.com/blog/how-to-be-iterative-in-your-thinking/#_edn1). Feedback can be from internal users (dogfooding), or through feedback from our broader user community. We validate each iteration and adjust, but not at the expense of the user experience that we deliver to our customers.
When we iterate at GitLab, we break up the work that we know we need to do into smaller chunks to iterate toward a targeted end state:
1. Have some external users (early access program)
1. Ensure global optimization (use standardized systems)
1. Plan beyond the iteration
Iteration does not require us to ship features that are open to all users from day one. Feedback can come from internal users or a limited number of external users (early access program). Moving through the [release process is not iteration](#the-release-process-is-not-iteration) though. Iteration is also not a [replacement for having a plan](#iteration-is-no-substitute-for-planning). We expect you to know where you are going, but you can iterate to get there.
Iteration does not require us to ship features that are open to all users from day one. Feedback can come from internal users first. Moving through the [release process is not iteration](#the-release-process-is-not-iteration) though. Iteration is also not a [replacement for having a plan](#iteration-is-no-substitute-for-planning). We expect you to know where you are going, but you can iterate to get there.
An iteration might be additive (adding something) or subtractive (removing something). If you make suggestions that can be excluded from the first iteration, turn them into a separate issue that you link.
