Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Strategic Marketing Project Management Overview

On this page

Project management overview

In Strategic Marketing, we have several processes to manage the work the team does

  1. Commitment management - how do we know what we're committed to
  2. Epics (larger projects) - how do we plan big projects
  3. Monitoring and reporting progress - how do we track progress
  4. Using Labels and keeping them clean - how do we keep our labels
  5. Priority - how do we indicate what's most important
  6. Managing Workflow - how do we manage our workflow

Commitment management

We are often asked / requested to work on multiple efforts, across the company. For example,

Either way, a real challenge is how to manage and track our commitments to support other workstreams.

We've established the following workflow/process in order for us to consistently capture requests and manage our commitments.

The bottom line: If we don't have a SM_Request Issue that captures our Commitment, then it's invisible and not really a 'commitment'.

SM Request Process

The process is simple:

SM Request Flow

Here's a short overview of the process:

The process is simple:

  1. Open an SM Support Request Issue this link will the A-SM-Support-Request template.
  2. The Strategic Marketing leadership team will review the request(Daily), assign it to the ideal SM Team, prioritize the work and plan how to support your requests.

sm_reqest board

Strategic marketing request review and assignment flow (note: the label sm_request indicates a request for Strategic Marketing support)

  1. New requests start with the label sm_req::new_request.
    1. Triaged to one of the Strategic Marketing teams (PMM,TMM, Competitive Intel, Partner Marketing, Market Research/Cust Insight) sm_req::triage and the team label (pmm,tech-pmm,Competitive Intelligence, Partner Marketing, mrci) who will determine if there is enough detail to prioritize and plan the work - is it clear? Then the issue will be route to either:
    2. Backlog sm_req::backlog for future scheduling, sequencing, and implementation. note: add issue to the SM_Backlog milestone for tracking. NOTE: Issues in the backlog are NOT yet committed to be done!
    3. Assigned sm_req::assigned to team members. When an issue is assigned, it is added to the quarter milestone so we can track status of all the work in flight. NOTE: Assigned issues should be considered committed to be done!
    4. Transferred sm_req::transferred for requests that belong in a different team (Field Marketing, Sales, Ops, etc). Once an issue is transferred, it should be closed
    5. declined sm_req::declined - when an issue is in the backlog and it is no longer relevant or does not make sense anymore. Close the issue when you decline it.
  2. When complete, the team member will update the issue with sm_req::completed and Close the issue

  3. Daily Triage Standup. 15 min standup, where the leadership team reviews New Requests to triage them to the most appropriate team. From there, team leads either move to the backlog or assign for immediate work.

SM Request insights

We are actively working to leverage GitLab insights in order to monitor how the process is working, learn, and improve over time.

SM Request Overall

SM Request Overall-by team

SM Request Assigned-by team

GitLab Strategic Marketing PMM Insights

Epics and Milestones - planning and tracking our work

Regular Work

For example, in order to visualize all our regular work in a given quarter, we have a "Quarter Milestone" that makes it possible to visualize and summarize all the work within a given quarter. This is an experiment to decide how to best use milestones in our regular work. In the near future (12.10 or 13.0), GitLab will support assigning Multiple milestones to a given issue, which will open the door to both managing real "Sprints", and other topics through the Milestone feature in Gitlab. (Today - the limit is 1 Milestone per Issue)

The first time we applied a milestone to regular work was in Q4-FY20, where we saw the pattern of new work flowing in, while other work was completed and closed.

SM Q4FY20 Milestone

In Q1-FY21, we are continuing to use a milestone to track regular work, and as we learn about our patterns and flow, we believe we will be able to increase our velocity and flow.

As of 13 April:

SM Q1FY21 Milestone

Complex projects

When we have large and complex projects, we manage the work through:

For example the UseCase GTM Project to build out the messaging, demos, comparisons, case studies and proof points for the Use Cases. Here specific the Epic for a given use case is broken down into sub epics, and then issues are created and associated with the correct epic.


We've organized our UseCase GTM work by month, and have a Monthly "Sprint"/Milestone that helps us track completion of the issues/deliverables.

For example this "Milestone" - shows a summary of ALL the usecase work in the Month of April.


Here is a link to the current UseCase 2020-3 milestone.

Metrics and KPIs (GitLab Insights)

We are experimenting how to utilize GitLab Insights

For example, one experiment in Product Marketing is tagging our work based on specific outputs / domain. We're using scoped labels "pmm::xyz" to tag issues based on the type of output and objective:

Through this, we can track our work and improve our balance and focus:

PMM Insights - (Internal vs External)

pmm insights Internal vs External

PMM Insights (External details)

pmm insights External Details

PMM Insights (Details)

pmm insights Details

GitLab Strategic Marketing PMM Insights

Labels and Label Hygiene

We have adopted the GitLab Triage bot as a way to establish clear policies for labels and issue hygiene. This allows us to create a set of process rules and policies and then automatically apply them to our issues. This helps us to keep issues in the expected state with the expected labels.

See this summary of how to set up and use the GitLab Triage Bot

Priority and Prioritization

At this point, we have three "Priority" labels in Strategic Marketing. These are both scoped labels (so you can't have both P::1 and P::2) at the same time. The labels are also defined as "Priority", so they will sort issues where they are assigned.

  1. P::1
  2. P::2
  3. P::3

Over time, we will be establishing guidelines about how we consistently use these labels to communicate priority within the team.

Example of managing our workflow

Some of us in the team use GitLab Issue Boards to manage our workflow. Using the issue board and scoped labels such as Open, To-Do, Doing, Waiting, Closed, the issue board gives us a visual representation of issues assigned to us.

  1. Label Closed : Issues that have already been completed and closed
  2. Label Waiting : Issues that are waiting for input from other teams
  3. Label Doing : Issues that we are currently actively working on
  4. Label To-Do : Issues that we will pick up next
  5. Label Open : Issues in our backlog

pmm Issue Board

We move issues across these stages based on the progress and order them within the stage based on our priority of working on them. This helps team members to manage the issues assigned to them better as well as managers to asynchronously get a view of what's in progress and what's blocked.