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::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!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!
sm_req::assigned::Queue are 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::InProgress are issues that the team member is actively working. They SHOULD be in a specific milestone.sm_req::assigned::Waiting These 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::completed and Close the issuesm_req::transferred for requests that belong in a different team (Field Marketing, Sales, Ops, etc). Once an issue is transferred, it should be closedsm_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 | /Label ~"sm_req::triage" ~pmm |
| Triage for the Tech PMM team | /Label ~"sm_req::triage" ~tech_pmm |
| Triage for the Partner Marketing team | /Label ~"sm_req::triage" ~"Partner Marketing" |
| Triage for the Competitive Intel team | /Label ~"sm_req::triage" ~"Competitive Intelligence" |
| Triage for Market Research/Customer Ref Team | /Label ~"sm_req::triage" ~mrci |
| Moving to backlog | /Label ~"sm_req::backlog" /Milestone %"SM - Backlog" |
| Assigning to a team member | /Label ~"sm_req::assigned" ~"status::wip" /Milestone %Q4FY20 /Assign @<TeamMember> |
| Completing an issue | /Label ~"sm_req::completed" /close |
We are actively working to leverage GitLab insights in order to monitor how the process is working, learn, and improve over time.
GitLab Product and Solution Marketing PMM Insights
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?
Priority
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::AR Analyst Relations (briefing, inquiry, and research)pmm::collateral Developing collateral such as white papers, data sheets, etc.pmm::Deck Developing slides and presentationspmm::Enable Developing and delivering enablement (mainly to the field)pmm::Events Developing and delivering content at events (online and in person)pmm::messaging Developing positioning and messagingpmm::PR Briefing and updating press and mediapmm::Research Planing and conducting market researchpmm::Sales Direct support of sales with customerspmm::Web Developing 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:
GitLab Product and Solution Marketing PMM Insights
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::1 and priority::2) at the same time. The labels are also defined as "Priority", so they will sort issues where they are assigned.
priority::1priority::2priority::3Over 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 Open, To-Do, Doing, Waiting, Closed, the issue board gives us a visual representation of issues assigned to us.
Closed : Issues that have already been completed and closedWaiting : Issues that are waiting for input from other teamsDoing : Issues that we are currently actively working onTo-Do : Issues that we will pick up nextOpen : 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.