Simplify Groups & Projects Working Group

Learn about GitLab Simplify Groups & Projects Working Group business goals, problems to solve and more.

Attributes

Property	Value
Date Created	May 22, 2020
Date Ended	Oct 30, 2020
Slack	#wg_simplify-groups-and-projects (only accessible from within the company)
Google Doc	Working Group Agenda (only accessible from within the company)
Docs/Epics	Epic, Opportunity Canvas
Feature Issue	TBD
Associated OKRs	Increase Stages per Active Namespace for accounts less than 90 days old to >1.7

Problem To Solve

Groups, sub-groups, and projects as they are organized today are confusing to our users and are negatively impacting adoption, onboarding, and retention for Plan and numerous other stages.
We currently have a lot of requests to “implement [insert existing project feature here] at the Group level” as a way to try and solve some of this. We are duplicating capabilities that already exist at the Project level but not within the Group.
When we do this, we end up not cleanly recreating the same experience at the Group level, resulting in defects, missing capabilities, and poor UX that leads to incomplete and painful critical paths for our customers.
External: GitLab is inflexible to how companies organize their teams and workflows. Internal: We are/will be spending millions of dollars on implementing (or paying down technical debt related to) project level features within Groups (or vice versa).
See “Pain” and corresponding customer perspective from Opportunity Canvas.

Business Goal

Instead of this complex organizational model, users can structure GitLab like this simplified organizational model without having to duplicate base functionality (Issues, Wikis, Epics, etc.) between Groups and Projects.
Increase Stages Per Active Namespace / Stages Per User.
Improve NPS/SUS scores around usability and performance.

Exit Criteria

(✅ Done, ✏️ In-progress)

Identify high level vision, MCV, and an iteration plan to solve the problem `=> 100%`

Issue

Business viability: Does the solution work for our business? ✅
Technical feasibility: Can we build it? ✅
Usability: Can the user figure out how to use it and is it better received than our current approach to Groups and Projects? ✅
Value: Will this drive an increase in key business metrics such as SpU, SPAN, SMAU, and AMAU? ✅

Opportunity Canvas: https://docs.google.com/document/d/1a2xuEMAsWzPK-cb_wnS9DWh9YHXZLs34Lp7jdetODR4/edit (internal)

Roles and Responsibilities

Because of the wide sweeping implications of solving this problem – and that it spans the entire product – we would like at least one Member per section and ideally one Member per stage.

Working Group Role	Person	Title
Executive Sponsor	Anoop Dawar	VP Product Management
Facilitator	Justin Farris	Group Product Manager, Plan
Functional Lead	Liam McAndrew	Engineering Manager, Manage:Authentication and Authorization
Functional Lead	Gabe Weaver	Senior Product Manager, Plan
Functional Lead	UX Mike Long	Product Design Manager, Dev:Plan & Dev:Manage
Member	Melissa Ushakov (Manage)	Senior Product Manager, Authentication and Authorization
Member	Alex Pooley (Manage)	Senior Backend Engineer, Authentication and Authorization
Member	Christen Dybenko (Create)	Senior Product Manager, Knowledge
Member	Natalia Tepluhina (Create)	Staff Frontend Engineer, Knowledge
Member	Markus Koller (Create)	Backend Engineer, Knowledge
Member	Keanon O’Keeffe	Senior Product Manager, Plan
Member	Mark Wood	Senior Product Manager, Plan
Member	Donald Cook	Frontend Engineering Manager, Plan