Skip to content

WIP: proposing Build-Deploy-Run for EE Plans

John Jeremiah requested to merge update-EE-pricing-plans into master

Problem The EE pricing plans should drive product features alignment, messaging, go to market strategies, and sales plays in the field. The current pricing plans are tied to the ‘size’ of the organization (https://about.gitlab.com/handbook/product/#enterprise-edition-plans), where the idea is that larger organizations align to higher plans. There are problems with this model:

  1. Organization size does not dictate a specific need for a feature.
  2. Size does not correlate to specific needs based on DevOps adoption/maturity.
  3. Size limits ability to upsell Higher plans to smaller organizations

Proposal

1.Base the EE plans on the capabilities that an organization would need as they matured in their DevOps transformation.

Version: Emphasis
Starter = Build Optimize Version Control and CI / Quality
Premium = Deploy Optimize Continuous Delivery
Ultimate = Run Secure and Optimize Operations (how you run your application) and Portfolio Mgt (how you run your organization)

2.Align both current and future features based on Plan and Pillar alignment. Plan(Build, Deploy, Run). Pillar (Visibility, Efficiency, Governance) see grid below illustrating the linkage.

Plans -> Starter (Build) Premium (Deploy) Ultimate (Run)
Visibility CI Pipelines, Burndown charts, code quality Deploy boards, canary deploys monitoring, dashboards
Efficiency Automated Build, Automated Testing, SW QA, CI Includes, Repo Mirroring CD Pipline, ? Container Security, SAST, DAST, Resource Management, Ops Dashboards, Service Desk
Governed Auditing, LDAP, Multiple Merge approvals, Security controls Deploy approval auditing, License management, Env Secret variables Prioritization, Portfolio Tracking, Enterprise auditing and compliance

3.If a feature doesn’t match an EE plan / pillar, then it goes to core.

Pros

  1. Any EE plan could be sold to any organization, regardless of size
  2. Aligns to a common DevOps adoption path.
  3. Establishes a path for future upselling as organizations mature
  4. Simple to explain
  5. GitLab differentiation pillars (Visible, Efficient and Governed) applies to each of the plans.
  6. Aligns more closely to industry analyst segmentation (Forrester CI, Gartner ARO, etc)
  7. Helps to differentiate Core from EE. If a feature significantly adds to a differentiation Pillar, there is an argument for it to go in EE

Cons

  1. There is no ONE way to adopt DevOps, some organizations start with automating infrastructure.
  2. Separating CI from CD introduces complexity
  3. May require several features to move from plan to plan.
  4. Any change to where features exist in our current plans could be disruptive to current customers and current sales efforts.

see https://docs.google.com/document/d/1N-jcVplZojYpr0RRbr2_hsv7jGKmJXykc5AyDbVxiwU/edit?usp=sharing for more detailed example of how Build-Deploy-Run might work

Edited by John Jeremiah

Merge request reports