Define Release Stage PI Structure
Intent
Let's make sure we are focused on capturing metrics that are useful (help us be more effective in future R&D), not just those that are representative (help us gauge value fo previous R&D). We have the benefit of Release Stage SMAU (users triggering deploys) that is broadly representative - as a result we can focus on useful GMAU instrumentation for our current product feature focuses.
Product Performance Metric Types
SMAU
- AVAILABLE TODAY: Unique Count of Users triggering deploys
- BUILD TOWARDS: Unique users in the union of all stage AMAUs
AMAU (Action Monthly Active User)
These AMAUs are for more useful, they allow you to focus on understanding the funnel for these current priorities and discover where there is drop-off to the adoption of these features.
- Feature Flag interactions
- Vault Secret Pipeline interactions
- Release interactions
- AWS Deployment pipeline interactions
- Users triggering deploys
GMAU
- Progressive Delivery GMAU = Unique users in the union of 1,4
- Release Management GMAU = Unique users in union of 2,3
Pros/Cons
This model allows for each group to think of their GMAU as their north star metric, and to build that based on actions in their stage which drive use of their feature focuses. It also gets us away from the "each Group can only have a single AMAU" which isn't appropriate for Release Stage groups that have a broad breadth. It has the Con that not all stage SMAU is immediately captured in the union of each GMAU but I think that is fine and we have stage SMAU available for representative or comparative assessments with other stages.
Actions
Add AMAUs for categories to Ops Section PI Page
-
Progressive Delivery - @ogolowinski www-gitlab-com!58450 (merged) -
Release Management - @jmeshell www-gitlab-com!58469 (merged)