In Strategic Marketing, we have several processes to manage the work the team does
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'.
The process is simple:
Here's a short overview of the process:
The process is simple:
Strategic marketing request review and assignment flow (note: the label
sm_request indicates a request for Strategic Marketing support)
sm_req::triageand the team label (
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:
sm_req::backlogfor 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!
sm_req::assignedto 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!
sm_req::transferredfor requests that belong in a different team (Field Marketing, Sales, Ops, etc). Once an issue is transferred, it should be closed
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.
When complete, the team member will update the issue with
sm_req::completed and Close the issue
We are actively working to leverage GitLab insights in order to monitor how the process is working, learn, and improve over time.
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.
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:
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.
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:
pmm::ARAnalyst Relations (briefing, inquiry, and research)
pmm::collateralDeveloping collateral such as white papers, data sheets, etc.
pmm::DeckDeveloping slides and presentations
pmm::EnableDeveloping and delivering enablement (mainly to the field)
pmm::EventsDeveloping and delivering content at events (online and in person)
pmm::messagingDeveloping positioning and messaging
pmm::PRBriefing and updating press and media
pmm::ResearchPlaning and conducting market research
pmm::SalesDirect support of sales with customers
pmm::WebDeveloping content for web pages (blogs, web pages, etc)
pmm::other Other work that doesn't fit above
Through this, we can track our work and improve our balance and focus:
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
At this point, we have three "Priority" labels in Strategic Marketing. These are both
scoped labels (so you can't have both
P::2) at the same time. The labels are also defined as "Priority", so they will sort issues where they are assigned.
Over time, we will be establishing guidelines about how we consistently use these labels to communicate priority within the team.
Some of us in the team use GitLab Issue Boards to manage our workflow. Using the issue board and scoped labels such as
Closed, the issue board gives us a visual representation of issues assigned to us.
Closed: Issues that have already been completed and closed
Waiting: Issues that are waiting for input from other teams
Doing: Issues that we are currently actively working on
To-Do: Issues that we will pick up next
Open: Issues in our backlog
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.