Revise PM doc with input from Mike P and Sherry (elastic#1112)

* Revise PM doc with input from Mike P and Sherry * update with feedback from Sourin * make small copy edit Co-authored-by: Melissa Burpo <melissa.burpo@elastic.co>
MadameSheema · May 12, 2021 · 5532471 · 5532471
1 parent 076c80a
commit 5532471
Showing 1 changed file with 101 additions and 25 deletions.
diff --git a/docs/functions/product-management/README.mdx b/docs/functions/product-management/README.mdx
@@ -3,42 +3,121 @@ This page describes some common Product Management activities for the Security t
 
 > Note: This page is still under development. 
 
-## Feature Lifecycle
-This section describes the common flow of a new feature, as it moves from an idea into production, and it describes possible activities and artifacts that may be produced along the way. This list should not be considered exhaustive or required, but it is helpful as a reference. 
+TOC:
+
+- [Product vision and roadmap](#product-vision-and-roadmap)
+- [Working in GitHub](#working-in-github)
+  * [GitHub issues](#github-issues)
+  * [ZenHub](#zenhub)
+    + [ZenHub Workspaces](#zenhub-workspaces)
+    + [ZenHub Epics](#zenhub-epics)
+- [Feature planning](#feature-planning)
+  * [1 - Discovery](#1---discovery)
+  * [2 - Epic definition](#2---epic-definition)
+  * [3 - Meta definition](#3---meta-definition)
+  * [4 - Team planning](#4---team-planning)
+  * [5 - Grooming](#5---grooming)
+  * [6 - Implementation](#6---implementation)
+  * [7 - Iterative Reviews](#7---iterative-reviews)
+  * [8 - Release testing](#8---release-testing)
+  * [9 - Release](#9---release)
+- [Deal Support Requests (DSRs)](#deal-support-requests-dsrs)
+
+## Product vision and roadmap
+The Security team’s product vision and roadmap is tightly aligned with the goals established by our Security leadership team. The vision fits within this general hierarchy, which defines and categorizes the work needed to reach our goals:
+
+- Goal 
+- Pillar
+- Initiative 
+- Theme
+- Epic 
+
+As an example, the image below is pulled from our 3-year planning mindmap and shows how these connect, starting from a single goal: 
+
+<img width="960" alt="goal-hierarchy" src="https://user-images.githubusercontent.com/5898424/117508483-454e4780-af4e-11eb-9844-fe3b09062366.png">
+
+
+You can also see this structure reflected in the 7.last release plan: [Elastic Security 7.last](https://docs.google.com/document/d/1q_q3hYRG7NowYbATOP9IGFm3jGWJdbO10J3QSnTaLiE/edit#) 
+
+## Working in GitHub
+GitHub issues drive much of our day-to-day work. It’s how we communicate requirements, establish priorities, and build out plans. Because GitHub issues have a flat structure (i.e. there is no hierarchy of relationships between issues), we use labels extensively to group issues, and we use ZenHub, an addon tool for GitHub, to help with planning and prioritization work.
+
+### GitHub issues
+We use this general hierarchy for GitHub issues: 
+
+- Epics → 
+  - Meta issues → 
+    - Task issues
+
+PMs primarily develop Epics, while Engineering primarily creates meta and task issues, but this process may vary by teams.
+
+The `security-team` repo has several GitHub issue templates, including ones for Epics and Meta Tasks. These can help you get started when writing a new issue.
+
+We commonly use GitHub labels that identify the following:
+
+- **Teams**: The development team working on the issue.
+- **Themes**: These labels usually reflect themes established as part of the Security team's vision and roadmap.
+- **Release targets**: The target release date; e.g. `7.14 candidate`
+- Other miscellaneous items that identify a need; for example, “needs design”
+
+
+### ZenHub
+ZenHub is a tool that helps us to give more shape to GitHub issues. It enables PM’s to specify user stories and requirements at an “epic” level, focused on user outcomes, problems to solve, etc., and it helps the team to collaboratively define the security solution capabilities of each Stack release between PM and engineering. We also use it as a communication tool, both for internal roadmap planning with other Security PMs and for communication with management and senior leadership to understand what capabilities are included in a given release of Elastic Security.
 
-### 1 - Feature discovery
-Starting from an initiative that has been established for the Security group, discover features that would align to the initiative goals. This process can take input from multiple streams as appropriate, like user feedback, field requests, research, etc.
+Usage of the tool is currently restricted to PMs and Tech Leads (for the most part). At some point licenses may be extended to the full team, but that is TBD.
 
-**Output**: Feature ideas aligned to initiative goals.
+The Security PM group primarily uses ZenHub to track epic issues and does not currently track sub-tasks. Make sure you convert any epics into a ZenHub epic, and create your own Workspace for tracking epics. Details below.
 
-### 2 - Feature definition
-Identify the business problem that needs to be solved and provide research materials to support the need for the feature. Identify what telemetry you can capture related to the new feature.
 
-The output for this phase commonly includes shared Google docs to drive discussion and collaboration and ultimately Meta issues.
+#### ZenHub Workspaces
+[Workspaces](https://help.zenhub.com/support/solutions/articles/43000504792-workspaces-overview) help to organize issues in GitHub. Each workspace can have its own workflow and pipeline structure as issues move from the left to the right. Note, however, that this status is only viewable within ZenHub. For example, if you have a column for Prioritized, that status can only be seen on the ZenHub Workspace. 
 
-_Meta issues_
+Create your own Workspace to track your team’s epics. You can customize the [pipelines](https://help.zenhub.com/support/solutions/articles/43000206560-customizing-board-pipelines) (e.g. column names) to match your preferred workflow.
 
-A Github meta issue describes a large scope of work that needs to be broken down further. Meta Issues are similar to an Epic in traditional Agile development.
+#### ZenHub Epics
+[Epics](https://help.zenhub.com/support/solutions/articles/43000010341-an-intro-to-zenhub-epics) are a theme of work that contain sub-tasks required to complete the larger goal. 
 
-- Meta issues can be created by anyone on the team. 
-- The goal is to define the meta issue within 2 weeks before it's prioritized and review this with cross-functional leads.
+You can create ZenHub Epics in two ways:
+
+- Create a new Issue from ZenHub and set the _Type_ to _Epic_, or 
+- Open an existing GitHub issue, and under the _Epics_ section on the right (only visible if you're signed into ZenHub), click the cog icon, then select _Convert to Epic_. 
+
+Note that the _Epic_ label in GitHub does not make it a ZenHub Epic. You must do one of the above for it to show up as an epic in ZenHub.
+
+Characteristics of a good ZenHub epic:
+
+- **Title**: The Title of the epic should be descriptive and high level enough that someone at the management level can look at the board of epics we have planned for a release and have a good idea of what’s going to be delivered.
+- **Sizing**: Epics can be big or small; i.e. it may take one or more meta issues to implement it. You should consider making an issue an epic if you want to make the change visible to the larger team. For example, if the issue is something that the Security leadership team would want to know about for a release, that justifies making it an epic. 
+- **Subject**: Epics can address new features, tech debt (e.g. if you want to track a list of tech smaller tech debt items all related to a common area), UX Reviews (e.g. if you want to request a review and identify resulting change requests), or other subjects as needed - it’s up to the team. Epics are good communication vehicles and can be used accordingly.
+
+## Feature planning
+This section describes the common flow of a new feature, as it moves from an idea into production, and it describes possible activities and artifacts that may be produced along the way. This list should not be considered exhaustive or required, but it is helpful as a reference. 
+
+### 1 - Discovery
+Discovery is the process of researching and validating ideas before defining the work that needs to be done. This process can take input from multiple streams as appropriate, like user feedback, field requests, research, etc. 
+
+**Output**: The output for this phase commonly includes shared Google docs and other materials to drive discussion and collaboration with your team.
+
+### 2 - Epic definition
+Once you know what you want to build, break the work down into epics. The epic should clearly describe the user problem this work is trying to solve, the value and impact of doing the work, and the success criteria. PMs usually write epics for their team.
+
+**Output**: Epics defined in GitHub and visible in ZenHub
+
+### 3 - Meta definition
+Meta issues are the smaller pieces of work that implement an epic. 
+
+- Anyone on the team can write a meta issue.
 - Meta issues are prioritized by the team lead, tech lead, and product lead for a given product or area.
 - Meta issues should be scoped to what can be delivered in a single release or smaller.
 - Meta issues can be user-focused (e.g. an enhancement or new feature that impacts use of the system) or technically-focused (e.g. a technical implementation or modification that may not impact user workflows or UIs).
 - Depending on the type of issue, usually the team's PM or Tech Lead owns shepherding meta issues from definition through to completion.
-- Meta issue requirements can come from a variety of sources (e.g. from field research, the dev team, the marketing team, the field enablement team, etc.) 
 - Apply Labels to the Meta Issue to denote the following:
   - Area Team
-  - Release Number
+  - Target
   - Issues Type
-  - Others
+  - Others as needed
 
-### 3 - Feature prioritization
-Work with the PM team and Team Lead to prioritize the meta issue/features in relation to the rest of the Security roadmap.
-
-**Output**: Prioritized cross-team roadmap
-
-### 4 - Feature planning 
+### 4 - Team planning 
 Work with the development team to break down the meta issue into tasks. This should include dev tasks, [doc tasks](https://docs.google.com/presentation/d/1zDNzmWjlmJR9nNDTVCHNYbgAL5GLwBvK2ubmE6RK1V4/edit#slide=id.g6eae63e93f_4_112), design tasks, and other tasks as needed to complete the feature.
 
 **Output**: Release backlog. The backlog can include features, bugs, tech debt, and non-technical requirements (e.g. UX mocks, architecture, discussion items, spikes, etc.). At this point, work items are likely not dev-ready. Each team has their own process, but the next step likely includes the PM and the team collaborating to better define the work. This often takes place in Grooming sessions or other async methods (like Github comment discussions), as needed.
@@ -74,6 +153,7 @@ The release is the bundled result of completed issues and meta issues, fully doc
 
 A release often requires the production of several artifacts, including: 
 
+- Launch plans
 - Field enablement materials
 - Technical deep dives
 - Release briefs
@@ -82,10 +162,6 @@ A release often requires the production of several artifacts, including:
 
 ***
 
-## PM Onboarding
-
-_<< content TBD >>_
-
 ## Deal Support Requests (DSRs)
 
 On occasion, people in Field Operations (e.g. Sales, Account Executives, Solution Architects) need help with security deals. For example, they may need in-depth knowledge about a product, implementation input, or other product info to move the deal forward.