Simplify Groups & Projects Working Group
|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|
|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.
- 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.
(✅ Done, ✏️ In-progress)
- 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? ✅
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|
Meetings are recorded and publicly available on YouTube in the Simplify Groups and Projects Working Group playlist (TBD).