Verify Product Group

Verify

Intent of this page

The Verify Product Group wants to increase sharing, findability, and encourage bias for async communication. We will use this handbook page as forum for showcasing our team processes while also providing an opportunity to encourage a open discussion between team members on our processes for retrospective.

Where can I reach you?

Slack: #s_verify

GitLab Project: Verify

Verify teams:

• Verify:Pipeline Execution
• Verify:Pipeline Authoring
• Verify:Runner
• Verify:Pipeline Security

What do y’all do?

The purpose of this product group are described by the Verify stage direction. This is inclusive, though not limited to, the pipeline experience, creating or authoring .gitlab-ci.yml files, executing jobs in a pipeline, and various testing capabilties in CI/CD.

Continuous Integration and Runner Boundaries (Ownership/DRI’s)

While generally the functions of Continuous Integration and Runners are interdependent (runners are the build agents that execute CI jobs), as Verify categories they represent distinct feature areas. However, it is sometimes difficult to discern which team or product manager is the DRI for a feature or capability that doesn’t seem to fit neatly within the high-level categories and this section aims to clarify those boundaries.

At GitLab, using RADCIE to assign responsibilities means everyone is Consulted and Informed, but to highlight critical team members who must be consulted the table below specifies who explicitly.

The noted DRI still owns decision-making and is still responsible for notifying/consulting critical team members, however the ‘Must be Consulted’ designee(s) takes the guesswork out of who to involve when these team members may not be part of the core engineering team aligned to the DRI product manager.

Workflow

We work in a Kanban-style aligning with Milestones and GitLab’s Product Development Flow.

Cross-Functional Partnership

We work across other teams often and are striving to get better at engaging with others. If you are interested in being a part of this dialogue - drop a line our #s_verify slack group!

Product Marketing Enagement

We partner really closely with Product Marketing Management. In the Verify Stage, we have a stable counterpart assigned, as defined in the PMM Team Structure, which aligns to the CI Use Case.

We have four main processes:

1. Semi-annual Stage-wide GTM & Strategy Positioning
2. Quarterly Sales Enablement
3. Quarterly Roadmap Alignment for Product Groups
4. Monthly Release Post and Market Positioning for Product Groups

Stage-wide GTM & Strategy Positioning

• Frequency: Twice a year
• Audience: Internal
• Assets Produced: Deck, Recording, and Issue Boards
• Goal: Deliver a 30-minute recording that aligns the half-year product strategy of the stage with the GTM sales motion and competitive landscape. Include any assets that will be helpful to sales teams for pitches and product managers for early selling in prospect calls.

We recently conducted our first joint stage-wide PMM and Product Positioning for FY22 1H, alongside a deck.

Sales Enablement

• Frequency: Quarterly
• Audience: Internal
• Assets Produced: Deck and Recording
• Goal: Deliver 10-30 minute recordings on various product topics for use in field enablement.

We recently participated in a discussion of building the bench for technical topics via cs-skill#116. These types of sessions would then be used in partnership with PMM to help build compelling stories for the Field.

Roadmap Alignment for Product Group

• Frequency: Quarterly
• Audience: External
• Assets Produced: Recording
• Goal: Deliver 10-30 minute recordings on various product topics for use in webinars, partner calls, or whitepapers.

These are intended to help guide themes and present opportunities to build stories in the market and not commitments, otherwise, these would be scheduled for a milestone.

Release Post & Market Postioning for Features

• Frequency: Monthly
• Audience: External
• Assets Produced: Copy/text
• Goal: Deliver written communication in Merge Requests with Product Manager in the Release Post Items or blog posts.

We sometimes ship feature specific blog posts such as Moving CI to Lovable…again or this expose on the Pipeline Editor. These are great opportunities to include PMM alongside the Release Post review and positioning.

Customer Success & Renewal Engagement

We have a CS <> Product feedback loop for Customer Success (SA/CSM) and Product Managers to sync on product feedback from prospects and customers. On a monthly cadence, we meet to discuss problems to solve as captured in issues created in the cs-product-feedback project and consolidated on this issue board.

Alliances Engagement

More details to come

Community Contributions

We want to encourage and support our open source community as nuch as possible. We have two measures of success:

1. Merged MRs from the community in the Verify Stage
2. MRARR

Our process for enabling merge requests from the community can be found on the Verify Team Page.

View page source - Edit this page - please contribute.