In Product and Solution 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:
Anyone can open an SM Support Request Issue this link will the A-SM-Support-Request template.
The Product and Solution 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.
Strategic marketing request review and assignment flow (note: the label
sm_request indicates a request for Product and Solution Marketing support)
sm_req::new_request. New requests will generally EITHER be assigned to a team and team member or put in the strategic marketing backlog
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::assigned::Queueare issues in an individual team member's personal backlog/ queue. They are managing their work flow and this issue is in their queue to add to a sprint/milestone and then deliver.
sm_req::assigned::InProgressare issues that the team member is actively working. They SHOULD be in a specific milestone.
sm_req::assigned::WaitingThese issues are in progress, but are blocked, waiting for some other contribution in order to progress. (such as waiting for an external approval, a design, draft, engineering, etc.) These issues SHOULD typically be in a milestone, and would typically move to the next milestone if the blocker is not resolved.
sm_req::completedand Close the issue
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.
sm_req::canceled- 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.
GitLab provides several ways to visualize and manage our work:
Quick actions are very,very helpful and efficient when you want to make multiple changes to an issue and have the issue open. Here are a few handy quick actions for Product and Solution Marketing:
|Step / Action||Quick Action Code|
|Triage for the PMM team||
|Triage for the Tech PMM team||
|Triage for the Partner Marketing team||
|Triage for the Competitive Intel team||
|Triage for Market Research/Customer Ref Team||
|Moving to backlog||
|Assigning to a team member||
|Completing an 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.
The Product and Solution Marketing team uses a 2-week sprint model, scoping and weighting work items (Issues) to produce the greatest increment of value at the end of each sprint. While our process is similar in many regards to Scrum, we do not practice Scrum Events as separate ceremonies, instead working them into our existing meeting workflow.
We plan, manage, and track our work in the Product Marketing - Overview Issue Board.
On an ongoing basis, individual DRIs update the status of all active items that are assigned to them as the DRI in the Product Marketing backlog. Before the end of one Sprint, they will estimate which items are most appropriate for the following Sprint (Sprint Planning) and confirm this Sprint Backlog with their manager in a weekly 1:1 meeting.
In order to plan future work it is important to ensure that the request is a) Clearly written and unambiguous, b) What "Done" for the issue is clearly defined. b) The issue/work is free of constraints, and d) the request can be completed in a 2 week sprint. Issues are "Refined" when these questions have been addressed.
Where ANY issue that has not been refined (DRI, clarity, completable, unconstrained, achievable, prioritized) would start with "unrefined"
The first step is to identify a DRI. The DRI then owns checking the remaining boxes for the issue.
#### Refinement - [ ] **DRI**: Has a DRI been identified and do they accept responsibility? - [ ] **Clear**: Are the expectations and work required unambiguous and clearly defined? - [ ] **Completable**: Is there a clearly-stated definition of done? - [ ] **Unconstrained**: Is the work free of blockers and dependencies? *If not, address blockers first or leave in Product Backlog until blockers are removed.* - [ ] **Achievable**: Is the issue something that can be completed within a 2-week timebox? *If not, decompose it.* set the refined label
Has the value of the feature been assessed based on input from key stakeholders?
Once an Issue has been labeled 'defined' and assigned a 'priority' it is ready for inclusion in a sprint.
The goal of the 2 weeks sprint is to agree on what can be completed in the sprint, and commit to delivery. The goal is to limit adding new work in progress and focus on delivering the committed scope of work in the sprint. Urgent and unexepected stuff happens, so we will always need to have flexiblity in our approach and capacity on our team to respond to short notice changes. But, the general patern should be that we don't add scope to the sprint, unless all the work is completed.
To provide insight and clarity on status we will leverage Issue/Epic Health Status on priority issues.
At the beginning of the Sprint, DRIs will assign the 'On Track' status to agreed-upon priority issues. As work progresses, anyone contributing to the work should update the Health Status as appropriate to surface risk or concerns as quickly as possible, and to jumpstart collaboration on getting an issue back to "On Track".
After each sprint, the team should reflect and document learnings about what worked, what didn't work and how to improve. Asynchronously, we will document what we learn in this retrospective document and improve.
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 Product and Solution Marketing. These are both
scoped labels (so you can't have both
priority::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.