Product Development
This section of the handbook is for content that is jointly shared by Product and Engineering. For any content wholly owned by only one division, please use the relevant sections: Product or Engineering.
Product Development Roles and Responsibilities
Successful product development requires and demands a unified commitment to shared outcomes across team members. The entire team must collectively embrace responsibility for the delivery of positive user impact, aligned to our GitLab value of delivering Results for Customers.
It’s a Team Effort
Responsibilities to Deliver High Quality Product
Quality is Everyone’s Responsibility
Who, What, Why, How, and When
For Product Development, we are leveraging the general-purpose questioning method of “who”, “what”, “why”, “how”, and “when” to aid in understanding how these roles with their respective responsibilities are working together on a continuous basis. In the figure below, we walk through an illustrative example of how Product Development team members contribute and collaborate in shaping a new product feature:
Our objective is to preserve each team’s freedom to leverage agile methods to develop and deliver customer value in our product, while introducing a synchronized planning process to ensure that we deliver with the predictability and quality that GitLab’s customers demand and deserve.
Role vs. Responsibility
There is an important distinction between a role (such as Product Manager, Engineering Manager) and a Lead’s responsibility area (such as Product, Technical, Delivery, Resource, UX). While roles such as ‘Product Manager’ and ‘Engineering Manager’ often align with specific leadership responsibilities, their areas of responsibility are not exclusive to their roles.
- Ex: while a team member with the ‘Product Manager’ role often fulfills the Product Lead responsibilities, they have other critical contributions beyond the demarcations of the Product Lead role. In some situations where a product is consumed internally and may not directly interface with end customers, the Product Lead role may be fulfilled by a Technical Individual Contributor (IC) or an Engineering Manager.
- Ex: a team member with an ‘Engineering Manager’ role often covers multiple responsibilities simultaneously - an Engineering Manager may fulfill some or all of the Technical Lead, Delivery Lead, and Resource Lead roles based upon the needs of their specific team.
With the caveats above, the general pattern we see within GitLab product development is:
- Product Division usually covers the responsibilities of:
- Product Lead - note: there can be exceptions here, especially in the infrastructure area.
- UX Lead
- Documentation Lead
- Engineering Division usually covers the responsibilities of:
- Technical Lead
- Delivery Lead
- Resource Lead
Within GitLab product development teams, we believe that “we win or lose as a team” - wins are team wins, and losses are team losses. The whole team owns the outcomes, and responsibilities assigned to a subset of the team are intended to drive execution excellence, and not meant to install rigid boundaries. One individual can cover multiple areas of responsibility on behalf of a team:
- Ex: Technical Lead may serve as the Delivery Lead
- Ex: Delivery Lead may also serve as Resource Lead for the team
- Ex: Technical Lead may serve as the Product Lead and Documentation Lead for technical excellence, reliability, scalability, or sustainability efforts.
Lastly, the specific needs that a product development team has for a specific responsibility may differ based upon the type of project, maturity of project, maturity of technology area and technology stack, maturity of developers, etc. The key is ensuring that each product development team has agreement and interlock on ownership and accountability for each of these responsibilities, regardless of how they are distributed among team members and across roles.
Key Events & Activities Mapping into Responsibilities
Hierarchy of Work
- Direction
- Big Initiative
- Top-level Epic
- Capability
- Composite Deliverables
- Atomic Deliverables
- Composite Deliverables
- Capability
- Top-level Epic
- Big Initiative
Legend
- ✅: driving
- ✔️: involved
# | Key Events & Activities | Product Management Lead | Technical Lead | Delivery Lead | Resource Allocation Lead | Product Design Lead | Technical Writing Lead | |
---|---|---|---|---|---|---|---|---|
1 | Define a one year Direction for their area of responsibility that aligns with: (1) company’s 3 year strategy, (2) their leader’s (CPO/CTO) direction, (3) current company objectives, (4) customer needs. | ✅ Product focus |
✅ Technical focus |
✅ User focus |
||||
2 | Break Direction into Big Initiatives that drive maturity of their area of responsibility | ✅ Product focus |
✅ Technical focus |
✔️ | ✅ User focus |
|||
3 | Break Big Initiatives into Top-level epics that allow for planning, refining, and scoping the next X amount of days ahead (where X can be 90 days, 180 days, etc.) | ✅ Product focus |
✔️ Technical focus |
✅ Technical focus |
✔️ | |||
4 | Break down Top-level Epics into Capabilities to get to the Top-level Epic goal with a focus on quality and user experience | ✅ Product focus |
✔️ Technical focus |
✅ Technical focus |
✔️ | ✅ User focus ✔️ |
✅ Docs focus |
|
5 | Prioritize a backlog of Capabilities to keep it up-to-date based on Top-level Epic | ✅ Product focus |
✔️ Technical focus |
✅ Technical focus |
✔️ | ✔️ | ✔️ | |
6 | Break Capabilities down into Composite Deliverables that can be assigned to a team of developers | ✔️ | ✅ | ✅ | ✔️ | ✔️ | ||
7 | Prioritize a backlog of Composite Deliverables to keep it up-to-date going into milestone planning | ✅ | ✅ | ✅ | ✔️ | ✔️ | ✔️ | |
8 | Interlock on Committed Deliverables for milestone | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
9 | Interlock on updated R&D roadmap based upon plan | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
10 | Break down Composite Deliverables into frontend, backend, infrastructure, etc. Atomic Deliverables that can be assigned to a developer | ✔️ | ✅ | ✅ | ✅ Docs focus |
|||
11 | Prioritize a backlog of Atomic Deliverables to keep it up-to-date going into milestone planning | ✔️ | ✅ | ✅ | ||||
12 | Assign Atomic Deliverables to developers | ✔️ | ✅ | ✅ | ||||
13 | Track and report progress of Atomic Deliverables during the milestone to key stakeholders | ✅ | ||||||
14 | Validate technical work and level of quality meet acceptance criteria and Definition of Done | ✅ | ✅ | ✔️ | ✅ | ✅ | ||
15 | Report status at the end of the milestone to help align planning of the next milestone | ✅ | ||||||
16 | Report status of Atomic Deliverables as part of achieving composite deliverables, as part of achieving Capabilities, and as part of achieving Top-level Epic | ✅ | ||||||
17 | Update progress against direction and initiatives based upon last milestone results | ✅ Product Focus |
✅ Technical focus |
✅ | ||||
18 | Interlock on updated R&D roadmap based upon actuals | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
19 | Engage with PMM and DevRel to ensure messaging is correct, updated, and support the creation of GTM materials as needed | ✅ Product Focus |
✔️ | |||||
20 | Present the parts of the product and related roadmap to customers in support of sales opportunities or updates for existing customers | ✅ |
Product Development Interlock for Roadmap Planning & Execution
Under construction - coming soon
Resource Allocation Framework and Prioritization
Under construction - coming soon
Roadmap Structure
Under construction - coming soon
Alignment Process and Timelines
Under construction - coming soon
31c0ad19
)