WIP: proposing Build-Deploy-Run for EE Plans
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:
- Organization size does not dictate a specific need for a feature.
- Size does not correlate to specific needs based on DevOps adoption/maturity.
- 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
- Any EE plan could be sold to any organization, regardless of size
- Aligns to a common DevOps adoption path.
- Establishes a path for future upselling as organizations mature
- Simple to explain
- GitLab differentiation pillars (Visible, Efficient and Governed) applies to each of the plans.
- Aligns more closely to industry analyst segmentation (Forrester CI, Gartner ARO, etc)
- 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
- There is no ONE way to adopt DevOps, some organizations start with automating infrastructure.
- Separating CI from CD introduces complexity
- May require several features to move from plan to plan.
- 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