Product Marketing communicates GitLab business value internally and externally to position GitLab as a DevOps partner and solution. The team is responsible for product positioning, value messaging, and go-to-market strategy to support sales and outbound messaging with analysts, press, and prospects. Product Marketing also facilitates market feedback as key inputs into the GitLab product roadmap.
Specifically, product marketing develops and delivers messaging, positioning, and compelling collateral/content such as:
Product marketing operates at the intersection of the Market demands based on a) understanding the enterprise development team challenges and specific their challenges / use cases, and b) Understanding the product categories, features, and capabilities and how they deliver value in specific use cases.
In general, product marketing supports three main groups:
Customer 'use cases' are a customer problem or initiative that needs a solution and attracts budget, typically defined In customer terms. In Product Marketing, we build content and messaging that engages prospects who are looking for solutions to specific challenges they face. In product marketing, we:
A core element to use cases is effective objection handling against major competitors in the narket. In order to effectively support this effort, a partnership between Product Marketing and Product Management to maintain adding competitior walkthroughs and competitive content to the existing use cases is critical. To date we have competitive sections on the following uses cases:
DevOps stages and categories organize and define how we plan and engineer new GitLab features.
Health Status Definitions for Product Marketing:
Flagging Risk is not a Negative
We feel it is important to document and communicate that changing of any item's Health Status to "Needs Attention" or "At Risk" is not a negative action and should not cause anxiety or concern. Raising risk early helps the team to respond and resolve problems faster and should be encouraged.
At the end of a Sprint, any unfinished items will be rolled over into the next Sprint, unless circumstances have altered that item's priority (for example, if the feature is no longer needed or a new company priority supersedes all others).
Twice per month, the PMM team will designate a portion of one of their weekly team meetings to a Sprint Retrospective, where they will review what went well, what could be improved, and what they will commit to change in upcoming sprints.
Customer use cases are our primary focus, as we strive to communicate the value of GitLab and how it helps customers address specific challenges they are facing. All of the GitLab stages and categories support various use cases in different degrees. By focusing on Use Cases, we intend to remain connected to the market and our customers while educating them about how GitLab can solve their specific challenges.
|Sr. PMM||Agile||SCM||CI||CD & Release||Dev Sec Ops||E2E DevOps (Simplify DevOps)||Cloud Native||IaC||Public Sector/ Regulated Industries|
|PM section alignment||
In this model, Senior PMMs are responsible for both the collateral and messaging supporting a specific Use Case and also one or several stages. Detail stable counterparts assignments between product marketing and specific product groups is maintained in the Product Categories page. PMMs support the team with messaging and go to market efforts, leading research, writing, and collateral development.
This model helps to define several stable counterpart relationships with the product and engineering teams, where specific use cases map to current sections in our hierarchy.
A product release, and a marketing launch are two separate activities. The canonical example of this is Apple. They launch the iPhone at their yearly event and then release it months later. At GitLab we do it the other way: Release features as soon as they are ready letting customers use them right away, and then, do a marketing launch later when we have market validation.
|PM Led||PMM Led|
|New features can ship with or without marketing support||Launch timing need not be tied to the proximity of when a feature was released|
Since at GitLab we release a lot, alot at GitLab we ought to strive to communicate and promote whatever makes a difference to our community, our clients and the market at large. Regardless of what constitutes a launch – a consensus reached internally at the group level based on different reasons – progressive delivery a la GitLab requires that only categories or features that reach the maturity level of viable require the following marketing activity cascading:
|Does this release require a change in the Handbook?||Update Handbook|
|Does this release require to update the Docs?||Update Docs|
|Does this release require a edit of the publicly available marketing collateral?||Edit the webiste||Edit the website|
|Does this release require a to update, edit or create new sales enablement?||Schedule a session|
|Does this release require analyst to be updated?||Schedule a briefing|
Who should I contact?
Listed below are areas of responsibility within the product marketing team:
|Who||Solution/Use case||Persona||Industry/domain||Product Management Group||Field Region|
|Brian||Data Science||tbd||Science||Dev||AMER West (PacNorWest)|
|Cormac||Agile||tbd||tbd||Dev||AMER West (NorCal/ SoCal/ Rockies)|
|Cindy||DevSecOps||tbd||Energy||Sec||AMER EAST (SE)|
|John||Version Control & Collaboration||tbd||tbd||Dev|
|Parker||Continuous Integration||tbd||tbd||Ops||AMER EAST (NE)|
|Saumya||Continuous Delivery||tbd||tbd||Ops||APAC, EMEA|
|Traci||Public Sector||tbd||Public Sector / Regulated Industries / FinServ/FinTech||All||Pub Sector|
|William||GitOps, Cloud Native||tbd||tbd||Ops||AMER EAST (Central, Named)|