--- layout: handbook-page-toc title: Product Process --- ## On this page {:.no_toc .hidden-md .hidden-lg} - TOC {:toc .hidden-md .hidden-lg} ## Product Process Introducing changes requires a number of steps, with some overlap, that should be completed in order: ### Product Manager Onboarding Product Manager onboarding, beyond any [product specific steps in your first week onboarding ticket](https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/onboarding_tasks/department_product_management.md), is defined in the Product projects [PM Onboarding issue template](https://gitlab.com/gitlab-com/Product/blob/master/.gitlab/issue_templates/PM-onboarding.md). Onboarding issues can be tracked in the [Product Onboarding Issue Board](https://gitlab.com/gitlab-com/Product/-/boards/1283554?&label_name[]=onboarding). Iteration on Product Management Onboarding is encouraged by all team members. To do so, create an MR against one of the above files and assign it to your manager for review and merge. ### Important dates PMs should keep in mind See [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline). ### Planning horizon Aligned with the company [cadence](/handbook/ceo/cadence/#overview), Product planning follows: 1. [Mission](/company/strategy/#mission): 30 years 1. [Vision](/direction/#vision): 10 years 1. [Strategy](/company/strategy/#sequence-): 3 years 1. [Plan](/direction/): 1 year 1. [Milestones](/direction/#future-releases): quarter (we have issues assigned to specific release milestone for a rolling 3 months) 1. [Release](https://gitlab.com/gitlab-org/release-tools/blob/master/templates/monthly.md.erb): month (we try to not change the release that is started) Inspired by: - First part of [Dear PMs, It's Time to Rethink Agile at Enterprise Startups](http://firstround.com/review/dear-pms-its-time-to-rethink-agile-at-enterprise-startups/) - [The Nearsighted Roadmap](https://medium.com/@jobv/the-nearsighted-roadmap-57fa57b5906a) ### Dogfood everything The best way to understand how GitLab works is to **use it for as much of your job as possible**. Avoid [dogfooding antipatterns](/handbook/engineering/#dogfooding-antipatterns) and try to find ways to leverage GitLab (instead of an external tool) whenever possible. _For example:_ try to use Issues instead of documents or spreadsheets and try to capture conversation in comments instead of Slack threads. As a PM, but also as any GitLab team member, you should actively use every feature, _or at minimum_, all the features for which you are responsible. That includes features that are not directly in GitLab's UI but require server configuration. If you can't understand the documentation, or if you struggle to install something, would anyone else bother to do it? This hands-on experience is not only beneficial for understanding what the pain points are, but it also helps you understand what can be improved and what features GitLab is missing. #### When do we dogfood? When a feature is **_minimal_** and moving toward **_viable_**, designated GitLab team members (and anyone else interested!) should be using the feature extensively and actively providing feedback to the PM and team developing it. When a feature is **_viable_** and moving toward **_complete_**, designated GitLab team members should be using the feature **exclusively**, and actively providing direct feedback to the PM in situations where exclusive use is not possible. **Exceptions to dogfooding:** When a feature is **_planned_** and/or moving towards **_minimal_**, dogfooding is not required. GitLab _the company_ works in a specific way, but GitLab _the product_ is designed to work for lots of different companies and personas. When we have _validated through research_ that the wider GitLab community wants a feature that doesn't align with how our organization works, dogfooding is not required. #### For Product Team Members As a Product organization, it's also our responsibility to ensure that the entire company dogfoods our product. We do this by: 1. Promoting features internally when they are ready for everyday use to get as many internal users as possible. This is particularly valuable when you can get relevant teams using your feature in their daily work. This can be done by recording a demo of the new functionality and sharing it with the team, running through examples of usage on Product calls, or identifying current workflows or processes the feature could help improve. 1. Including top internal user issues in the relevant [category epics](/handbook/product/product-management/process/#category-direction) when they align with our strategy. 1. Maintaining a set of [internal customer DRIs](#internal-customer-DRIs) who represent GitLab team members who use GitLab for the purposes of developing and operating GitLab and GitLab.com. Working with internal stakeholders comes with the added benefit of getting immediate feedback that reduces cycle times and de-risks early investments in new categories and features. Beyond feature velocity, internal dogfooding saves the money that we would spend on third-party tools. Internal users can help quickly identify where workflows might break down or where potential usability or performance issues must be explored. We should heavily weigh internal feedback to shape our perspective on customer needs, and then compare it to what we know about both large and small customers (and if we’re unsure, then we should proactively ask). #### Internal Customer DRIs We define specific DRIs in the [categories.yml](https://gitlab.com/gitlab-com/www-gitlab-com/edit/master/data/categories.yml) file. Below are the responsibilities of an Internal Customer DRI: 1. Actively work to improve dogfooding of the features within your internal function and provide proactive feedback to the product managers 1. Be the authoritative voice on what is required to begin dogfooding a feature within your function, and the combined input from your function into prioritization 1. Respond to issue mentions in a timely fashion 1. Periodic meetings between DRI and product development group 1. Stay up to date on the changes in that feature area (i.e. watch the kickoff video / read the release post) #### Dogfooding Process 1. **Any GitLab team member** can create an issue labeled `Dogfooding` and spur a discussion with PM. This label should never be removed so that the decision-making process gets memorialized on the [Dogfooding board](https://gitlab.com/groups/gitlab-org/-/boards/1212116). 1. **PMs** will consider the issue, make an explicit decision, and **add** an appropriate label for next steps: 1. `Dogfooding::Build in GitLab` when a new feature should be built into GitLab 1. `Dogfooding::Rebuild in GitLab` when there is existing work (outside of GitLab) that needs to be rebuilt _inside_ of GitLab 1. `Dogfooding::Keep Outside GitLab` when a feature is okay to build _outside_ GitLab because they don't align with product vision 1. `Dogfooding::Use Existing Feature`: when a feature _already exists_, but isn't being used internally yet for whatever reason 1. Note: _Please do not remove the original `Dogfooding` label when adding the new scoped label._ 1. Note: _A good rule of thumb when considering effort to build in GitLab compared to building a tool outside is to use the '5x' rule. The '5x' rule states that if the effort to build the tool **inside of** GitLab is less than five times the effort to build it **outside of** GitLab, you should choose to build it inside of GitLab._ 1. If the decision is to `Build in GitLab` or `Rebuild in GitLab`: 1. **PMs** will provide an estimate of when a feature can be delivered, and Internal customers should be prepared to contribute to that effort in order to accelerate delivery. 1. **Internal Customers** can track the progress of the issue through the [Product Development flow](https://about.gitlab.com/handbook/product-development-flow/) 1. If the feature existed and was identified as `Use Existing Feature`: 1. **PMs** should interview team members to understand why they weren't using that feature already 1. Based on that feedback, the PM should create and execute a plan to solve those problems, such as: * Creating additional documentation in the handbook or product docs site * Recording walkthroughs or demos of the feature * Writing a blog post about how the feature works or can be used to solve a problem 1. Finally, when the feature is ready for internal consumption: 1. **PMs** should change the label to `Dogfooding::Promote Feature` and promote these features in the weekly Product call and in other relevant channels 1. **Product Directors/Group managers** should be actively promoting these features to other leaders throughout the company 1. **Designated team members** should work to provide immediate feedback to ensure the feature is serving our team's needs 1. On an ongoing basis, **product Directors/Group managers** should be reviewing the [Dogfooding Board]((https://gitlab.com/groups/gitlab-org/-/boards/1212116)) to: 1. Ensure that issues marked as `Dogfooding::Build in GitLab` or `Dogfooding::Rebuild in GitLab` are getting prioritized appropriately 1. Be aware of new issues marked as `Dogfooding::Keep Outside GitLab` to understand why these features are explicitly staying out of the product 1. Be aware of new issues marked as `Dogfooding::Use Existing Feature` to help their PMs promote these issues for internal usage To see all the `Dogfooding` work that is happening, [here is a board that collects all the scoped labels](https://gitlab.com/groups/gitlab-org/-/boards/1212116). Check out this 10 minute discussion about dogfooding: ##### Example: configuring GitLab Most of GitLab is configured through the file `gitlab.rb`. It's tempting to add a new parameter in this file - it's easy, fast to do, and won't require adding a new UI element to allow the configuration of this new setting. However, changing this file requires you to reconfigure GitLab. To do that, you have to login to your server and type in commands to reconfigure your instance, possibly multiple times if you have more than one server. This is not something that we can ask our customers to do. Only by using your own product and features will you realize that some practices should be avoided as much as possible. ### Product Development Flow GitLab follows a dual-track [product development flow](/handbook/product-development-flow/) spanning product, engineering, UX, and quality. This process should be both up front and on an on-going basis when building features. ### PM, EM, UX and SET quad DRIs GitLab is designed and developed in a unique way. Consistent with our value of [Efficiency](/handbook/values/#efficiency) the product is developed with [directly responsible individuals](/handbook/people-group/directly-responsible-individuals/) from Product, UX, Quality and Development working together. |Product Managers|Engineering Managers|UXers|SETs| |:-:|:-:|:-:|:-:| |Set priorities and define what Engineering works on | Own the definition of done; decide what gets merged into Product| Proactively identify small and large strategic UX needs to aid Product Management prioritization|Own and identify test strategy and requirements to complete the definition of done ### GitLab PMs aren't the arbiters of community contributions [PMs are the DRI for what GitLab Engineering team members work on](#pm-em-ux-and-qe-quad-dris). As a result contributions from the wider community and from other teams in GitLab are not subject to the processes described below nor are they prioritized by GitLab Product Managers. So long as an MR matches the [definition of done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done), changes may make their way into Product. ### Managing your Product Direction The product direction is an important part of each PMs work. PMs are expected to maintain the accuracy of their plan throughout the year through stakeholder conversations and other research. Your product direction is displayed as the [direction](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=direction) labeled issues for your group's categories which are displayed in the Section, Stage, and Category [direction pages of our website](/direction/). Around November, we begin the [annual planning cycle](/handbook/finance/financial-planning-and-analysis/#annual-plan), which ties closely into the [overall strategy](/company/strategy/). During this period we update the `direction` label and apply it to issues that have been identified as contributing to the plan that year. PMs are able to refine their plans and strategy throughout the year, but since the these are important to be aware of, major updates to the content that happen ad-hoc should also be communicated widely - for example, using the Product FGC meetings or other communication channels. #### What makes a Product Direction issue? It's important to note here that your plan _is not_ simply a list of new features and innovation. Those are included for sure, but so are issues related to all of your [sensing mechanisms](/handbook/product/product-management/process/#sensing-mechanisms). A category upgrade from minimal to viable or delivery of a top customer issue (for example) can contribute to your plan just as much as a brilliant new innovative feature can. It's up to PMs to balance this through a coherent longer-term strategy. Conversely, in a broad sense anything could move the plan forward in a general way. Product Direction items (i.e., with the label) should be direction-level items that move the strategy forward meaningfully. This is up to the PM to set the bar for, but there should be a clear step forward with real user value. Finally, issues are the substance of your plan. Epics can receive the label as well, to keep things organized, but we track the delivery of our plan on a per-issue basis. Ensure you are applying the label appropriately. #### Moving the product direction forward In each release, you should be moving your plan forward. At least one item with this label should be included; if not, it's possible you're getting off track from where you planned to go and should assess. Note that, by their nature, Product Direction items should not be sitting in the backlog or with no milestone. If they are this is a signal that either they are not as important as originally thought, or that something important is not getting due attention. ### Prioritization: Ahead of kickoff 1. Proper discovery has been done and requirements for the change are defined 1. Engineering has been involved in the discovery process (FE, BE, UX, as needed) 1. Technical architecture has been drafted and is agreed upon 1. Scoping and splitting up into actionable issues has happened 1. Issues that move your plan forward have the appropriate [Product Direction label](/handbook/product/#managing-your-product-direction) applied ### Kickoff meetings The purpose of our kickoff is to communicate with our community (both internal and external) a view of what improvements are being planned in the coming release. This can help other GitLab teams, community contributors and customers gain an understanding of what we are prioritizing and excited to deliver in our next iteration. While kickoffs are commonly used to ensure visibility of work across an internal audience, our connection to a broader community and commitment to transparency means we also serve an external audience. The process for preparing and presenting group and company wide Kickoff meetings is outlined in our [Monthly Kickoff issue template](https://gitlab.com/gitlab-com/Product/blob/master/.gitlab/issue_templates/Monthly-Kickoff.md). We create an issue from that template each month to collaborate on that month's Kickoff. ### Execution 1. Design 1. Backend development 1. Frontend development 1. QA and feature assurance 1. Deploy #### Content of an MVC Here are some guidelines to follow when exploring an [MVC](#the-minimally-viable-change-mvc): * The issue should be based off of the standard [Feature Proposal](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Feature%20proposal) issue template. * The issue should be the smallest iteration we can create to address the problem. * The MVC should be buildable in one iteration. * If the issue generates a lot of discussion, make sure that the issue description always reflects the latest decisions at the current point in time. * Feel free to edit the issue description without keeping a history of the previous content, as long as it reflects the latest decisions. If you really want to, you can copy old content into the discussion thread for posterity. * It's not shipped until it's documented, no matter what the change is. ![mvc.png](/handbook/product/mvc.png) Virtually every new feature must be maintained forever (the standard for sunsetting a feature is very high). Creating a new feature means that GitLab has to continually manage the costs of maintaining that feature. Making small changes with quick feedback loops reduces the risk of introducing a new feature where the value doesn't justify the long-term costs. A new feature also adds a tax on the user experience due to additional complexity in the product. Make sure that the benefits gained by users from the new feature more than cover the tax incurred, accounting for how frequently the new feature will be used. In particular, the new feature should satisfy this inequality: `(benefits * frequency) / (tax * (1-frequency)) > 1` Despite its minimal form, the change * Always requires documentation. * Must track usage from day 1, if the feature has a meaningful impact. You can find more information on how we think about monitoring feature engagement [here](/handbook/product/feature-instrumentation/). [![xkcd.com](https://imgs.xkcd.com/comics/optimization.png)](https://xkcd.com/1691/) #### Quickly converting ideas into MVCs There is a certain failure case for MVC issues that product managers need to be aware of and actively work to prevent. Because we don't have infinite capacity to work on everything and good ideas are always coming in, it's possible (if the PM is not watching closely) for issues with good ideas to slowly but inevitably decay into something that is difficult to understand and move forward with. As more and more comments are added, the issue slowly morphs from idea to idea without any direction from a product manager. Then, it becomes difficult to ever make complete sense of it again without losing some important context. It's also nearly impossible for someone who wants to make a community contribution to understand what the direction is. In other words, it becomes an undefined blob of ideas. To prevent this, it is the product manager's responsibility to quickly determine whether an open-ended issue aligns with our business model and is broadly useful. If the answer to those questions is "yes," then we must turn it into something actionable, deliverable, and truly MVC as quickly as possible. If the answer is “no,” then we must close the issue to [maintain our backlog’s hygiene](https://www.huffpost.com/entry/how-to-maintain-your-prod_b_9920692?guccounter=1). The guidance for product managers is to never let an idea issue persist longer than three months without having been converted into a clear MVC. If this has not happened, you should ask yourself why this is the case: Is the idea overly broad? Is there no clear immediate deliverable? Is it just not important enough to spend time on? These are all signals that should be acted on without delay, before the issue degrades to the point that it becomes unusable without significant rework. In practice, if the original issue was really broad and still contains great ideas, then simply converting it into an MVC that gets closed when it ships could be a disservice, because you lose valuable context when it's time to improve the MVC. In this case, consider creating a new issue for the MVC, so that it is crisp and concise, and leave the original issue as a post-MVC meta item. ### QA RCs on staging and elsewhere After the feature freeze, it's expected of each product manager to test their own features and perform quality assurance to the best of their ability and follow up where necessary. Product managers can use the staging environment once the release managers have deployed a release candidate to staging. Release managers should post in the #product channel in Slack that a new release candidate is available. Product managers can also use other environments as needed, such as GitLab provisioned on Kubernetes with GKE. ### Feature assurance Before a new feature is shipped, the PM should test it out to make sure it solves the original problem effectively. This is not about quality assurance (QA), as developers are responsible for the quality of their code. This is about feature assurance (FA). FA is necessary because sometimes there are misunderstandings between the original issue proposal and the final implementation. Sometimes features don't actually solve the intended problem, even though it seemed like it would, and sometimes solutions just don't feel as useful as intended when actually implemented. If you can test out the feature during development, pulling down branches locally (or with a review app!), that's great. But sometimes it's not feasible to test a feature until it's bundled into a release candidate and deployed to GitLab.com. If so, make sure to test out features as soon as possible so any new issues can be addressed before final release. Also, take the FA cycle into account when scheduling new milestone work. If you are looking to test code that has not been merged to GitLab.com or is not yet part of an RC, you can pull the branch down locally and test it using the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit). ### Dealing with security issues Product managers should set Milestones for issues marked with the `security` label to guarantee they are shipped by their due date, as defined in the [Security Team process](/handbook/engineering/security/#severity-and-priority-labels-on-security-issues). Product Managers are the DRIs for prioritization. As such they should deeply understand the implications and risks of security related issues and balance those when prioritizing. You may need to set a different milestone for security issues, for example because of low capacity, but before doing that you should engage a conversation with the Security Team. Priority labels and Due Date designations should not be modified by product managers in any case, since they are directly managed by the Security Team, and used to track metrics and progress. ### Cross-stage features Each Stage is responsible for building functionality that is _core to their value_. Even if some components of that functionality happen to cross in to spaces typically owned by other stages, they should still build it (if it's important to them). If the feature isn't _necessary or urgently needed to move forward_ (for example, it won't block another feature's development), then you can always consider putting it on the backlog of the stage that owns that feature. Here are some guidelines for thinking about "Which stage should do this work?": 1. If a stage wants to develop new functionality that is core to their value, even if it _happens to live inside_ a feature owned by another stage, they should still build it. 1. Alternately, if the functionality lives inside another stage's feature, but is also very-much a _"nice-to-have"_, they should consider putting it in an issue and labeling it appropriately. This way, the stage that owns that feature can prioritize it at a later date when it makes sense for them to do so. 1. External requests for integration with 3rd party systems will be handled by the [`Ecosystem` group](https://about.gitlab.com/direction/ecosystem/) by default. But again, if the feature is core to a stage's value proposition, they should go ahead and build it themselves. This model allows teams to be flexible and calibrate their priorities accordingly, and no team should ever be "blocked". Exceptions may be items where a change requires anything that a software engineer would not be allowed to do, such as a production change, in which case the infrastructure team would be the blocker. While any team can contribute features to any stage, it is recommended to loop in the most relevant PM from that Group to provide strategic support to help the contributing team align to the Group's broader plan and vision. ### Stages, Groups, and Categories [Stages, groups, and categories](categories/) serve as a common framework for organizing and communicating the scope of GitLab. #### Making changes to stages, groups, or categories Documentation on how to make changes to stages, groups, and categories, as well as what approvals are required, can be found in our [website handbook page](../marketing/website/#working-with-stages-groups-and-categories). #### Managing creation of new groups, stages, and categories After a change has been [approved](categories/#changes), we may need to [globally optimize](../values/#global-optimization) during the initial transition period, and ensure that important issues are not blocked. There are three common scenarios we may encounter during these transition periods: * Splitting a Stage into multiple Groups * Changing the Categories in a Stage * Adding a new Stage In each of these scenarios, a Group may become temporarily responsible for a future Group's issues and backlog. During this time, the responsible Group should balance the needs of our users and organization, prioritizing across the common backlog. ##### Splitting a Stage into multiple Groups As the group(s) working on a Stage grow in size, a new Group may need to be formed so group sizes remain manageable. For example, today there is a single group for `Manage`, but will be splitting into `control` and `framework` groups. To prepare for splitting a Stage into multiple Groups, we should: 1. Update `categories.yml` and `stages.yml`, assigning each Group a set of Categories 1. Ensure all issues remain labelled with the Stage name, like `devops::manage` 1. Ensure all issues also have a group label, like `Control` or `Framework` 1. Prior to the new groups being formed, the PM and EM prioritize the shared `devops::manage` backlog Once the first PM or EM is hired, the new Group should be formed: 1. The other PM/EM's will need to continue working across both Groups. For example if a backend EM is hired, the frontend EM and PM will continue to work across both Groups until additional hires are made. 1. EM's and engineers should work together and divide the existing engineering team to staff the new groups, like `Control` and `Framework`. Ideally, each group would have at least two backend engineers, but that is not always possible. 1. Update `stages.yml` and `team.yml` to reflect the current group members. You may need to add a member to the end of `_categories.erb`. 1. Create a Slack channel for each group, like `g_control` and `g_framework`, and close the previous Slack channel (e.g. `g_manage`) As the rest of the EM/PM's are hired, they take over that role for the respective group. ##### Adding a new category to a Stage The categories within a Stage will change over time, based on GitLab's direction and the market landscape. The groups within a Stage will need to be able to handle these changes, without issues falling in the cracks. When the categories change, we should: 1. Update `categories.yml` and `stages.yml`, ensure all categories are assigned to a Group 1. If two categories are merging, apply the new category label to issues from both of the old categories 1. If a new category is being added, create a new category label and apply it to relevant issues 1. Update category vision to reflect the new labels and categories 1. Review the handbook and other material which may link to old categories 1. Remove old category labels ##### Adding a new Stage When GitLab decides to address additional needs within the single application, a new Stage may need to be created. For example, `Defend` may be created to address additional needs beyond what `Secure` focuses on. When a new Stage is added, and its Group has yet to be formed, we should: 1. Ensure all issues for the new Stage are assigned with the Stage labels, like `devops::defend` and `Defend` 1. Identify an existing Group, like `Secure`, which will be initially responsible for the new Stage 1. The existing Group will prioritize across a common backlog of both Stages, in this example `devops::defend` and `devops::secure` 1. Update `categories.yml` and `stages.yml`, listing the new Stage with the members of the existing responsible Group. Update `_categories.erb` with the member name if necessary. Once the first PM or EM is hired, a new Group for the Stage should be formed: 1. The other PM/EM's will need to continue working across both groups. For example if a backend EM is hired, the frontend EM and PM will continue to work across both groups until additional hires are made. 1. EM's and engineers should work together to staff the new Group, like `Defend`. Each Group should have at least two backend engineers. 1. Now that the new Group is formed, both Groups can focus on their respective Stages. In this case, `Secure` on Secure and `Defend` on Defend. 1. Update `stages.yml` to reflect the new Group and its members. Update `_categories.erb` with the member name, if necessary. As the rest of the EM/PM's are hired, they take over that role for the new Group. ### Product support requests Throughout the customer lifecycle, customer facing teams (Support, Sales, Professional Services, Account Managers, etc.) may need the assistance of a product manager. This can include a detailed discussion of our direction, how to address specific use cases, or gaps in functionality, with an organization. To ensure these requests can be quickly triaged, easily scheduled, and later tracked, there is a standardized request process based on issues. #### Requesting support from Product Product support requests are tracked in the [Product team project](https://gitlab.com/gitlab-com/Product). To create a request: 1. Create a [new issue with the `Product-Support-Request` template](https://gitlab.com/gitlab-com/Product/issues/new?issuable_template=Product-Support-Request) 1. Fill out the form within the template, be sure to include relevant details and issues 1. Ensure the issue is confidential, save it. For time sensitive and high impact requests, please paste a link to the issue in the `#product` Slack channel, and @mention the recommended PM's in the template. #### Working with support requests When a support request is opened, labels will automatically be assigned to categorize the request. Three fields are particularly important when triaging requests: * Priority: How time critical the request is, `urgent` requests should be treated with a high priority. * Impact: Potential impact to the business, based on [total contract value (TCV)](../sales/#total-contract-value-tcv). * Stage: Which stage the request relates to. All product managers should ensure they are set up to receive label notifications for their respective stages: 1. List the [product project's labels](https://gitlab.com/gitlab-com/Product/-/labels) 1. Subscribe to relevant the stage labels. ## How to work as a PM If you follow the principles and workflow above, you won't be writing long, detailed specs for a part of the product for next year. So how should you be spending your time? Invest the majority of your time (say 70%) in deeply understanding the problem. Then spend 10% of your time writing the spec _for the first iteration only_ and handling comments, and use the remaining 20% to work on promoting it. A problem you understand well should always have a (seemingly) simple or obvious solution. Reduce it to its simplest form (see above) and only ship that. Once you've shipped your solution, both you and the community will have a much better idea of what can be improved and what should be prioritized for future iterations. As a PM, you're the person that has to kick-off new initiatives. You're not responsible for shipping something on time, but you _are_ responsible for taking action and setting the direction. Be active everywhere, over-communicate, and sell the things you think are important to the rest of the team and community. As a PM, you need to set the bar for engineering. That is, to push engineering and the rest of the company. You almost want engineering to complain about the pace that product is setting. Our default instinct will be to slow down, but we can't give in to that. As a PM you don't own the product; ask other people for feedback and give team members and the community the space to suggest and create things without your direct intervention. It's your job to make sure things are decided and planned, not come up with every idea or change. ### Where should you look when you need help? * The first thing you should do is read this page carefully, as well as the [general handbook](/handbook/). * You can ask questions related to Product in the `#product` Slack channel. * General questions should be asked in `#questions`. * Specific Git related questions should be asked in `#git-help`. * HR questions should be asked in `#peopleops`. ### Responsibilities and Expectations The responsibilities for [Product Managers, Sr. Product Managers, and Principal Product Managers](/job-families/product/product-manager/), [Group Manager, Product Management](/job-families/product/group-manager-product/) [Director of Product](/job-families/product/director-of-product/), [VP of Product](/job-families/product/vice-president-of-product/) and [VP of Product Strategy](/job-families/product/vp-of-product-strategy/) are outlined in our job families pages. The progression of responsibilities allocation between tactical, operational and strategic is well illustrated by this helpful chart. ![GitLab PM Responsibility Allocation Chart](/handbook/product/pm-allocation.png) *[Source File](https://docs.google.com/spreadsheets/d/19gAgPJVdXfBpXiFOlT1WqZLJB_eFU7W7slmAzodEuDM/edit#gid=1012729771). Note - Thanks to [Melissa Perri](https://twitter.com/lissijean/) for the inspiration* In addition, as a Product Manager you're expected to: - Use the product and deeply understand the features you're responsible for. - Follow the issues you've been involved with / are assigned to as a PM. That includes reading all comments. Use email notifications for this. - Make sure the issue description and title is updated when necessary. It should always reflect the current state of the issue. - Make sure issues are moved forward when needed. You should not only avoid being the bottleneck, you should also be the person moving issues forward when they get stuck or overlooked. - Make sure features solve the original problem effectively. - Make sure features are complete: documentation, marketing, API, etc. - Know when to cut corners and when not to. If we merge documentation a day later, that's usually acceptable. Conversely though, learning from a customer that documentation is lacking is not. - Excite and market new features and changes internally and externally. - Help build a plan and strategy for GitLab and GitLab's features. - Understand deeply whatever it is you're working on. You should be spending a lot of time learning about your subject matter. - Have regular meetings (at least once a week) with customers. - Make sure marketing materials related to your work are up to date. - Ensure that `data/categories.yml` is up to date, including accurate links based on the defined link [hierarchy](/handbook/product/categories/#more-details). Occasionally, Product Managers are asked to perform the role of "Life Support" Product Manager for a group. When doing so please refer to the [Life Support PM expectations](#life-support-pm-expectations). As we grow, Product Managers can be listed across multiple stages and be asked to perform the role of Product Manager across split or multiple teams in an "Interim" basis. While temporary and based on future hiring, these positions are not considered "Life Support" and thus the standard Responsibilities and Expectations apply. ### Scope of responsibilities The product team is responsible for iteration on most of GitLab's products and projects: - GitLab CE and EE - GitLab.com - about.gitlab.com - customers.gitlab.com - version.gitlab.com - license.gitlab.com This includes the entire stack and all its facets. The product team needs to weigh and prioritize not only bugs, features, regressions, performance, but also architectural changes and other changes required for ensuring GitLab's excellence. ### Key Performance Indicators (KPIs) The list of Product KPIs are [here](/handbook/business-ops/data-team/metrics/#product-kpis) and the definitions are [here](/handbook/product/metrics/). ### Objectives and Key Results (OKRs) Like all teams, the Product team participates in GitLab [OKRs](/company/okrs/). The Product team OKRs are tracked as issues in the [Product project](https://gitlab.com/gitlab-com/Product). The process for doing so is: - At the start of each quarter, after OKRs have been [reviewed and approved by the E-Group](/company/okrs/#how-to-achieve-presentation), Issues are created for each key result with the issue title started with `KEY RESULT TITLE => 0% (Tracking to 0%)`. All issues should be tagged with the `OKR` label and assigned the appropriate quarter Milestone (eg, `Q1 2019`) such that they appear on [this board](https://gitlab.com/gitlab-com/Product/boards/906048). - In the first two weeks of the quarter, every OKR should be assigned to a single [Product Leader](/handbook/product/leadership/). Most OKRs will consist of one or more sub-tasks required in order to satisfy the OKR and these sub-tasks will be assigned to individual Product Managers or the Director of Product Management. The [company OKR page](/company/okrs/#quarterly-okrs) will be updated with links to the issues. - While the [team is responsible for achieving the OKR](/company/okrs/#levels), the assigned individual is responsible for: - Driving progress against the OKR within the team - Requesting and providing updates in relevant [team](#weekly-product-management-meeting) and [leadership meetings](#weekly-product-leadership-meeting) - Weekly updates to the issues including scoring (in the title) updates when needed - Monthly scoring updates to the [active company OKR document](/company/okrs/#quarterly-okrs) - Final [scoring](/company/okrs/#scoring) is submitted in the final week of the quarter, and a retrospective is scheduled for the first week of the following quarter. ### Long Term Financial Success Criteria for GitLab.com The Product team is responsible for the direction and financial measurement of the Gitlab.com strategy but does not carry direct P&L responsibility. Long term financial success for GitLab.com is measured as: * 80% Gross Margin on paid users * 2% free user expense target as a percentage of revenue ### Prioritization As this document and the [direction page](/direction) shows, there are a million things we want to do. So, how do we prioritize them and schedule things properly? Roughly speaking, we balance the following priorities: <%= partial "includes/master-prioritization-list.md" %> Please also note the corresponding [Engineering handbook section](/handbook/engineering/#prioritizing-technical-decisions) about the relative importance and prioritization of availability, security, and feature velocity. To ensure we're providing an appropriate focus on security, data loss, and availability, PMs should consider: * **tracking the appropriate labels for each prioritization category**: Use a standing item to discuss these issues with an engineering manager and ensure you understand the impact of related issues in your area before planning a release. * **optimizing for quality once a merge request is ready for review**: This means ensuring that Engineering has sufficient time to meet our [definition of done](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/development/contributing/merge_request_workflow.md#definition-of-done) - including a [high-quality code review](/handbook/engineering/workflow/code-review/) - without cutting corners to get something into production. ### Using the RICE Framework [RICE](https://www.productplan.com/glossary/rice-scoring-model/) is a useful framework for prioritization that can help you stack rank your issues. The RICE framework is a great tool for prioritizing many issues that seem to be of equal value at first glance. In order to drive clarity and alignment in the prioritization of work across the entire DevOps platform, and to help prioritize items that may compete for resources from different teams, we have set a standard for the RICE factors so all prioritization decisions based on RICE are using the same metric. **Reach** How many customers will benefit in the first quarter after launch? Data sources to estimate this might include qualitative customer interviews, customer requests through [Support/CS/Sales](https://app.periscopedata.com/app/gitlab/480786/User-Requested-Issues), upvotes on issues, surveys, etc. Higher reach means a higher RICE score: * 10.0 = Impacts the vast majority (~80% or greater) of our users, prospects, or customers * 6.0 = Impacts a large percentage (~50% to ~80%) of the above * 3.0 = Significant reach (~25% to ~50%) * 1.5 = Small reach (~5% to ~25%) * 0.5 = Minimal reach (Less than ~5%) **Impact** How much will this impact customers? Impact could take the form of increased revenue, decreased risk, decreased cost, which makes it possible to compare revenue generating opportunities vs. non-revenue generating opportunities. Higher impact means a higher RICE score: * Massive = 3x * High = 2x * Medium = 1x * Low = 0.5x * Minimal = 0.25x **Confidence** How well do we understand the customer problem? How well do we understand the solution and implementation details? Higher confidence means a higher RICE score. * High = 100% * Medium = 80% * Low = 50% **Effort** How many person months do we estimate this will take to build? Lower effort means a higher RICE score. **Calculating RICE Score** These four factors can then be used to calculate a RICE score via the formula: (Reach x Impact x Confidence) / Effort = RICE Here is an example RICE calculation you can use to help prioritize work in your area. Feel free to embed this at the Epic level to provide context for why you did or did not prioritize. | **RICE Factor** | **Estimated Value** | | ------ | ------ | | Reach | `1,000` | | Impact | `.5` | | Confidence | `80%` | | Effort | `2 month` | | ------ | ------ | | Score | (1,000 x .5 x .80) / 2 = **200** | Other important considerations: - Is this in support of a company or team [OKR](/company/okrs/)? - Does it bring our [vision](/direction/#vision) closer to reality? - Does it help make our community safer through [moderation tools](https://gitlab.com/gitlab-org/gitlab/issues/15326)? - Does it meaningfully improve the user experience of an important workflow? - Is it something we need ourselves? - Is it particularly [important to customers](#issues-important-to-customers)? - The technical complexity is acceptable. We want to preserve our ability to make changes quickly in the future so we try to avoid complex code, complex data structures, and optional settings. - It is orthogonal to other features (prevents overlap with current and future features). - The requirements are clear. - It can be achieved within the scheduled milestone. Larger issues should be split up, so that individual steps can be achieved within a single milestone. We schedule a prioritized issue by assigning it a milestone; for more on this see [Planning a Future Release](#planning-future-release). #### Issues important to customers For prioritizing most issues, we should utilize the RICE framework noted [above](#prioritization), which will capture an aggregate of customer demand. In some cases however, we may become aware of a feature which is particularly important to deliver on by a certain date. Examples of this could include an issue necessary to embark on a new GitLab rollout, a feature needed by a partner to launch an integration, or a method to import data from a service which is being discontinued. In these instances, the responsible PM can apply the `planning priority` label along with a `due date` and initial `milestone`. This label can serve to indicate externally that the issue is particularly important, as well as a reminder for internal teams of its importance. Issues with the `planning priority` label should be: - Among the highest priority to deliver in a given milestone - Among the last to be delayed to future releases It is important to note that the `planning priority` label does not constitute a promise for the issue to be delivered in any given milestone or timeframe. #### Community Considerations GitLab is open-source, and while [PMs aren't the arbiters of community contributions](#gitLab-pms-arent-the-arbiters-of-community-contributions), encouraging and promoting a large ecosystem of contributors is critical to our success. When making prioritization decisions, it's important to heavily weight activities which will encourage a stronger community of contributors. Some of those activities are: * The creation of small primitives that can be utilized and iterated on by community members * The building of integration points which can entice independent third parties to contribute an integration * The addition of tools or features which make the contribution experience easier Product managers are not responsible for prioritizing contributions outside of their group. These contributions should be [reviewed and merged swiftly](https://docs.gitlab.com/ee/development/contributing/#contribution-flow) allowing everyone to contribute, including non-product teams at GitLab. ### Working with Your Group As a product manager, you will be assigned as the [stable counterpart](/company/team/structure/#specialists-experts-and-mentors) to a single [group](/company/team/structure/#groups). At GitLab we abide by unique, and extremely beneficial guidelines when interacting with our groups. These include: 1. Product Managers are the [DRI](/handbook/people-group/directly-responsible-individuals/) for all prioritization within their group including bug fixes, security issues, feature, tech debt, and discovery. They alone determine and communicate priority. The process for doing so is [documented](#prioritization) and standard across all groups. 1. Product Managers provide the what and when, Engineering (UX, Backend, Frontend, Quality) provide the how. This process is documented as part of our monthly [product](/handbook/product/product-management/process/), [engineering](/handbook/engineering/workflow/#product-development-timeline) and [UX](/handbook/engineering/ux/ux-designer/) cadence. We [define stable counterparts for each of these functions](/handbook/product/categories) within a group. As an all-remote company, our crispness when it comes to responsibilities throughout the Product Delivery process was born out of necessity, but it pays untold dividends. Some of the benefits include: * We avoid the ambiguity in handoffs between teams * We avoid the confusion of many responsible individuals * We avoid the slowness of consensus driven decision making * We avoid the disruption of frequent context switching * We gain the rigidity to be consistent * We gain the freedom to iterate quickly #### User Experience (UX) As the GitLab product matures, we know we must make important workflows easier to use. As part of this effort, the [UX department](/handbook/engineering/ux/) is collaborating with Product Management to select highly used workflows in stable areas of the product. We'll assess and score these workflows using the [UX Scorecards](/handbook/engineering/ux/ux-scorecards/) methodology and then work together to prioritize recommended improvements. This effort aligns with the [Category Maturity](/direction/maturity/) goals that move areas of our product from minimal to viable to complete and, finally, lovable. #### From Prioritization to Execution As described above, prioritization is a multi-faceted problem. In order to translate the priorities of any given group into action by our engineering teams, we need to be able to translate this multi-faceted problem into a flat list of priorities for at least the next release cycle. Product Managers are responsible for taking all these prioritization considerations and creating a clear, sequenced list of next priorities. This list should be represented as an [issue board](/product/issueboard/) so that each team has a clear interface for making decisions about work. From this list, UXers, Engineering Managers and Product Managers can work together to determine what items will be selected for work in the immediate future. This does not mean that items will be addressed in strict order - UXers, EMs and PMs need to be cognizant of dependencies, available skillsets, and the [rock/pebbles/sand](https://www.developgoodhabits.com/rock-pebbles-sand/) problem of time management to make the best decisions about selecting work. #### Reviewing Build Plans Together with your Engineering Manager, you will have an important role in ensuring that the Build Plans defined for issues are created with iteration in mind. [Iteration](#iteration) is highly valuable for the following reasons: 1. It can result in discovering ways to parallelize effort, resulting in less team WIP and increase throughput 1. It can result in shipping something of value during an iteration rather then delaying everything 1. It can re-risk unknown unknowns by bringing them to light sooner in the development process #### Prioritizing for Predictability {: #prioritize-predictability} As a company we emphasize [velocity over predictability](/handbook/engineering/#velocity-over-predictability). As a product manager this means you focus on prioritizing, not scheduling issues. Your engineering [stable counterparts](/handbook/leadership/#stable-counterparts) are responsible for velocity and delivery. However, there are instances when there is desire for predictability, including: - [Security](#dealing-with-security-issues), Bugs and Infra priorities with SLOs - [Customer Commitments](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=planning+priority) - Vision or Direction items for a launch As the DRI for prioritization, it is the Product Manager's job to prioritize for predictability when it is needed. You should do so by ensuring you prioritize a deliverable, and its dependencies, so that it can reasonably be expected to be delivered by any committed dates. If there is time pressure to hit a date, the PM should also explore de-scoping the issue to meet the deadline, rather than pressuring engineering to move abnormally fast or cut corners. #### Headcount Resets {: #prioritize-global} Individual product managers must consider, and advocate for [global optimizations](/handbook/values/#results) within the teams they are assigned to. If your assigned team requires expertise (remember [everyone can contribute](/handbook/engineering/#collaboration)) outside the team you should make all reasonable efforts to proceed forward without the hard dependency while advocating within the product management team for increased prioritization of your now soft dependencies. If you have a request for additional help within your group, it is your responsibility to advocate for it. It's important to avoid generic "we need another Developer in X group" statements. Instead, create an issue which includes a concrete list of critical issues for no more than the next three months ([example](https://gitlab.com/gitlab-com/Product/issues/84)). These issues should all be considered "top priority" and generally fall in one of the following three categories: - Customer Health - Issues identified by customers and the customer success team as critical to retaining or acquiring critical customers. - Product Direction - Issues the broader Product Organization has externally committed to deliver and you view as critical - Security - Issues that will significantly miss our security SLAs Include your proposal for other issues and groups outside of your own which should be considered a lower priority. Once you've reviewed the issue with your assigned Engineering Manager - ping your Product and Engineering Directors for review and refinement. If a global optimization which spans beyond your Department leaders is required, then the Senior Director of Engineering, VP of Product, and VP of Engineering should be pinged. Please note: this now called a "Headcount Reset" because it shifts team members from one team to another, and can have signficant opportunity costs. Taking people who are familiar with a task and putting them on a new, unfamiliar task instead of new hires (who are also not familiar with the task) is inefficient. ##### Exit Plan The following exit plan is an initial attempt to spell out when and how the loaned engineers will be released to their original teams. A new hire is expected to be brought up to speed in this context. The plan will be iterated and amended as necessary. Week 1 is the first week a new hire joins the team. | Phase | Timeline (recommendation) | What happens |Notes| | ------ | ------ | ------ | ------ | | Onboarding | Week 1 ~ 3 | On-loan engineer works full-time on receiving team to bring up new hire. | New hire's first week priority is onboarding. | | Collaboration | Week 4 ~ 5 | On-loan engineer works half-time on receiving team while new hire is able to submit MRs of low complexity issues. | On-loan engineer's time may be dedicated completely in pair programming or code review, not necessarily making direct contribution to issues. | | Handoff | Week 6 ~ 8 | New hire is now the owner. On-loan engineer transitions to a consultant role, reverting back to full-time in original team. | | #### Private tools and dashboards for monitoring and KPI tracking These information sources may be useful to help you prioritize. - [Feature usage](https://redash.gitlab.com/dashboard/feature-adoption) - [EE usage](https://version.gitlab.com/): dev.gitlab.org account - [Grafana](https://dashboards.gitlab.net): Google gitlab.com account - [Kibana](https://log.gprd.gitlab.net): dev.gitlab.org account - [S3stat](https://www.s3stat.com): GitLab 1Password account - [Sentry](https://sentry.gitlab.net): dev.gitlab.org account ### Managing creation of new groups, stages, and categories As GitLab grows we will need to create new groups, stages, and categories. During this transition period we need to [globally optimize](../values/#global-optimization), and ensure that important issues are not blocked during the creation of a new group. There are three common scenarios which may encounter these transition periods: * Splitting a Stage into multiple Groups * Changing the Categories in a Stage * Adding a new Stage In each of these scenarios, a Group may become temporarily responsible for a future Group's issues and backlog. During this time, the responsible Group should balance the needs of our users and organization, prioritizing across the common backlog. For every scenario above, we also need to ensure that the Engineering Metrics dashboard is updated to correctly track the new label. The label change affects both Issues and Merge Requests. The Stage and Group labels power the visualization and metrics in the [Quality](https://quality-dashboard.gitlap.com/groups/gitlab-org) and [GitLab Insights](https://gitlab.com/groups/gitlab-org/-/insights) dashboards. Please create a new issue in the [Triage Ops](https://gitlab.com/gitlab-org/quality/triage-ops) with the template [`label-change.md`](https://gitlab.com/gitlab-org/quality/triage-ops/blob/master/.gitlab/issue_templates/label-change.md). #### Splitting a Stage into multiple Groups As the group(s) working on a Stage grow in size, a new Group may need to be formed so group sizes remain manageable. For example, today there is a single group for `Manage`, but will be splitting into `control` and `framework` groups. To prepare for splitting a Stage into multiple Groups, we should: 1. Update `categories.yml` and `stages.yml`, assigning each Group a set of Categories 1. Ensure all issues remain labelled with the Stage name, like `devops::manage` 1. Ensure all issues also have a group label, like `Control` or `Framework` 1. Create a "Label change" issue in [Triage Ops](https://gitlab.com/gitlab-org/quality/triage-ops) listing affected label to have the change reflected retroactively in Engineering Dashboards. 1. Prior to the new groups being formed, the PM and EM prioritize the shared `devops::manage` backlog Once the first PM or EM is hired, the new Group should be formed: 1. The other PM/EM's will need to continue working across both Groups. For example if a backend EM is hired, the frontend EM and PM will continue to work across both Groups until additional hires are made. 1. EM's and engineers should work together and divide the existing engineering team to staff the new groups, like `Control` and `Framework`. Ideally, each group would have at least two backend engineers, but that is not always possible. 1. Update `stages.yml` and `team.yml` to reflect the current group members. Update `_categories.erb` with the member names, if necessary. 1. Create a Slack channel for each group, like `g_control` and `g_framework`, and close the previous Slack channel (e.g. `g_manage`) As the rest of the EM/PM's are hired, they take over that role for the respective group. #### Adding a new category to a Stage The categories within a Stage will change over time, based on GitLab's direction and the market landscape. The groups within a Stage will need to be able to handle these changes, without issues falling in the cracks. When the categories change, we should: 1. Update `categories.yml` and `stages.yml`, ensure all categories are assigned to a Group 1. If two categories are merging, apply the new category label to issues from both of the old categories 1. If a new category is being added, create a new category label and apply it to relevant issues 1. Create a "Label change" issue in [Triage Ops](https://gitlab.com/gitlab-org/quality/triage-ops) listing affected label to have the change reflected retroactively in Engineering Dashboards. 1. Update category strategy to reflect the new labels and categories 1. Review the handbook and other material which may link to old categories 1. Archive old category labels, this will be done by the Quality Department as part of the "Label change" issue. #### Adding a new Stage When GitLab decides to address additional needs within the single application, a new Stage may need to be created. For example, `Defend` may be created to address additional needs beyond what `Secure` focuses on. When a new Stage is added, and its Group has yet to be formed, we should: 1. Ensure all issues for the new Stage are assigned with the Stage labels, like `devops::defend` and `Defend` 1. Create a "Label change" issue in [Triage Ops](https://gitlab.com/gitlab-org/quality/triage-ops) listing affected label to have the change reflected retroactively in Engineering Dashboards. 1. Identify an existing Group, like `Secure`, which will be initially responsible for the new Stage 1. The existing Group will prioritize across a common backlog of both Stages, in this example `devops::defend` and `devops::secure` 1. Update `categories.yml` and `stages.yml`, listing the new Stage with the members of the existing responsible Group. Update `_categories.erb` with the member name, if necessary. Once the first PM or EM is hired, a new Group for the Stage should be formed: 1. The other PM/EM's will need to continue working across both groups. For example if a backend EM is hired, the frontend EM and PM will continue to work across both groups until additional hires are made. 1. EM's and engineers should work together to staff the new Group, like `Defend`. Each Group should have at least two backend engineers. 1. Now that the new Group is formed, both Groups can focus on their respective Stages. In this case, `Secure` on Secure and `Defend` on Defend. 1. Update `stages.yml` to reflect the new Group and its members. Update `_categories.erb` with the member name, if necessary. As the rest of the EM/PM's are hired, they take over that role for the new Group. ### Planning and Direction As a PM, you must plan for the near term milestones (more detailed) as well as for the long term strategy (more broad), and everything in between. Considered as a spectrum, these form a [nearsighted roadmap](https://medium.com/@jobv/the-nearsighted-roadmap-57fa57b5906a). This will enable you to efficiently communicate both internally and externally how the team is planning to deliver on the [product vision](/direction/#vision). #### Communicating dates Use [calendar year (CY) dates](/handbook/communication/#writing-style-guidelines) for your issues, milestones, and labels to communicate timelines. Fiscal year (FY) does not translate well outside the company and roadmaps and vision pages are intended for external consumption. If you'd like to denote that an issue will be completed within a fiscal quarter use the month or GitLab release number for the last month in the fiscal quarter. E.g. use `12.4 (2018-10-22)` instead of `FY20-Q3`. The issue can always be moved up in date and users/customers will seldom complain when functionality ships earlier than expected. #### Planning is indispensable but don't follow the plan Creating a thoughtful direction for your section, stage, or category is a useful thought exercise that can help focus efforts, aid in prioritization, and get large groups of people on the same page. But beware of simply executing your long term plan. Our industry is incredibly dynamic, and we learn new things every day that can and should cause us to re-think our long term plans. Stay focused on creating value each and every milestone, and be quick to adjust your longer term plans as you learn more. #### Section and Stage Direction Section leaders are responsible for maintaining Direction pages that lay out the strategy and plan for their respective section and stages. The direction pages should include topics outlined in this [template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/templates/product/section_direction_template.html.md), which include: * Overview - brief summary of the situation, including market size and share, competitive position, level of customer adoption, etc. * Challenges - competitive pressure, investment constraints, business performance issues, etc. * 3 year strategy - what do you expect the world to look like in three years, and what is our strategic response? Tech changes, market changes, competitive changes, etc. * Themes - what are the primary investment themes for your areas? Where do we plan to invest over the next 12 months? * One Year Plan - details on specific epics/projects that tie back to investment themes * Stages and Categories - brief explanation of the stages that roll up to the section, and links to category direction pages within each stage. * What's Next - auto generated roadmap for the next three milestones #### Category Direction A category strategy is required which should outline various information about the category including overall strategy, what's next, and the competitive landscape. The category strategy should be documented in a handbook page, which allows for version control of the category strategy as well as the ability to embed video assets. One of the most important pieces of information to include in the category strategy is a tangible next step or MVC in order to push the category up the category maturity curve. When creating a category strategy, it's important to focus your time and attention on specific actions and future iterations. It's natural to want to spend significant effort predicting the future, but [iteration is one of our primary values](/handbook/values/#iteration). Your category strategies should contain short paragraphs with lots of references to specific issues. [Here](/direction/release/release_orchestration/) is an example. We use this [category strategy template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/templates/product/category_direction_template.html.md) as the outline for creating the handbook pages. If additional headings are needed you are empowered to create and populate them in your category strategy. You must keep these categories in sync with `categories.yml` and for new categories. For categories that have already shipped, and that have a marketing product page, `categories.yml` should link to the product page, and the product page should then have a link to the category strategy (you can see an example for GitLab Pages with a Strategy button [here](/product/pages/)). You should also link to your category strategy from your [stage strategy](#stage-strategy) page. Category direction should be reviewed on a regular basis (at least monthly) by the responsible product manager. To indicate the last time a category direction page was reviewed, please ensure pages include `Content Last Reviewed: yyyy-mm-dd` at the top of the category content. Update this date with every review, even if other content on the direction page has not changed. Inside of the `categories.yml` file there are dates assigned for either achieved or anticipated maturity achievement. These should be kept inline with communicated dates for achievement and updated as required. Also inline with [GitLab's Strategy Sequence](/company/strategy/#sequence), 50% of categories were determined by Product Leadership to be capable of achieving loveable by `2023-11-18`. If one of your categories has this date for `Loveable` any changes to this should be discussed with your manager. #### Maturity Plans For each category, we track the improvements required to advance to the next level of maturity. These issues are indicated with an epic, and the planned feature set should be clearly visible from the corresponding category strategy page. e.g.: * Stage strategy (page) * Category strategy (page) * Category epic (epic) * Minimal maturity (epic) * Cool Feature/Capability A (epic) * Issue * Issue * Issue * Cool Feature/Capability B * Cool Feature/Capability C * Viable maturity (epic) * ... The category epic should include: * A link to the category strategy page, to bridge from issues to the category strategy pages, and to keep the strategy DRY * Sub-epics related to the category, to make navigation and discoverability easier for our users by leveraging the epic hierarchy * A link to a search query which can be used to find all issues with the category label Maturity plans adhering to the [maturity framework](https://about.gitlab.com/direction/maturity/) are highly encouraged - but not required - for [non-marketing categories](https://about.gitlab.com/handbook/marketing/website/#category-attributes). For specifics of how the category strategy page should look, see the [category strategy template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/templates/product/category_strategy_template.html.md). #### Next three milestones In order to plan effectively around releases, as a PM you should have 3 months of detailed milestones scheduled at all times. The issues contained in these milestones are the ones you should be spending the most energy on (fleshing them out, adding detail, discussing, etc). These issues will go through a refinement period where Product, Engineering, UX, and other parties will discuss the proposal until a proper MVC proposal is reached (see [Content of an MVC](#content-of-an-mvc) for more detail). Most of the communication should happen within the issue comments, but some may happen offline (such as via Slack). Ensure that any relevant information that arise as part of an offline conversation is added to the issue title and issue description. As a PM you must ensure that issues have enough detail added to them before they become actionable as part of an iteration. These next milestones will also help planning for capacity with engineering and UX in order to commit to the contents of the next release. #### Sensing Mechanisms Our ability to iterate quickly is a measure of our efficiency, but our effectiveness is just as critical. As a product manager you are critical to us not just working correctly, but working on the correct things. You do that by [prioritizing appropriately](#prioritization). Your prioritization decisions will be enhanced if you maintain a sufficient understanding of the context in which you make them. There is no limit to the amount of inputs you can utilize for making prioritization decisions. We've organized these mechanisms into three lists. One for those that primarily sense feedback from users, one that primarily senses feedback from buyers and another that senses internally generated feedback which could represent buyers or users. For new PMs consider these lists as guidance for places to ensure you are plugged in to maintain sufficient context. User - Engaging with our community alongside our [Community Advocates](/handbook/marketing/community-relations/community-advocacy/) and [triaging](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#issue-triaging) community generated issues and ideas - Reviewing [top up voted issues](#category-strategy) - Asking probing questions in customer discovery meetings - [Requesting](/handbook/engineering/ux/ux-research/#how-to-request-research) and analyzing [results](https://gitlab.com/gitlab-org/uxr_insights) from [UX research](/handbook/engineering/ux/ux-research/) via the [First Look](/community/gitlab-first-look/index.html) research panel. Checkout this brief [video tutorial](https://www.youtube.com/watch?v=9U7hhGzRscs&feature=youtu.be). - Engagement directly with [customers](#a-customer-expressed-interest-in-a-feature) and via the [customer](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=customer) label Buyer - Asking probing questions in sales support meetings - Reviewing Win/Loss reports - Reviewing the most requested issues from customers using the [Issue Impact Dashboard](https://app.periscopedata.com/app/gitlab/480786/User-Requested-Issues) - [Chorus transcriptions](/handbook/business-ops/tech-stack/#chorus) of sales calls and demos - Reviewing Customer Success [designated top issues](/handbook/customer-success/tam/cs-top-10) - Maintaining [competitive](/handbook/marketing/product-marketing/competitive/) and [market assessments](#analyst-engagement) as well as missing [features](/features/) in your category epics (competitive landscape section). Subscribing to your competitor's blogs to be aware of what they are releasing will help you here. - Tracking open source projects in the same space as part of your competitive analysis is important as well. You can [evaluate these open source options](#evaluating-open-source-software) not just for interesting features and ideas, but potentially to integrate them in our product. Internal - Leadership [OKRs](/company/okrs) set the direction for the company - Each PM should be having regular conversations with their [stage groups stable counterparts](/handbook/product/categories) to discuss their strategy and plan. Share this discussion with the company via our GitLab Unfiltered [YouTube](/handbook/communication/youtube/) channel. PMs should share your next three milestones, year-long plan, strategy, and relevant OKRs (with status) so everyone can contribute feedback. - Dialogue with [internal customers](#dogfood-everything), and review of the [internal customer](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=internal%20customer) and [rebuild in GitLab](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=rebuild%20in%20GitLab) labels #### Managing Upcoming Releases Refer to the [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline) for details on how Product works with UX and Engineering to schedule and work on issues in upcoming releases. #### Planning for Future Releases {: #planning-future-release} Product Managers assign milestones to issues to indicate when an issue is likely to be scheduled and worked on. As we consider more distant milestones, the certainty of the scope of their assigned issues and their implementation timelines is increasingly vague. In particular, issues may be moved to another project, disassembled, or merged with other issues over time as they bounce between different milestones. The milestone of an issue can be changed at any moment. The current assigned milestone reflects the current planning, so if the plan changes, the milestone should be updated as soon as possible to reflect the changed plan. We make sure to do this ahead of starting work on a release. Capacity is discussed between the PMs and the engineering managers. In general, closer-to-current-time milestones are assigned to issues that are higher priority. It's best to maintain prioritization of your groups issues using a fully prioritized issue board. The timing of prioritized items broken across releases reflects an approximate product direction, with more distant milestones reflecting increasing uncertainty. The milestones are: - Milestones associated with an actual upcoming release, e.g. `9.4`, `9.5`, etc. - `Next 3-4 releases` - `Next 4-7 releases` These assigned milestones should be used as a signal for GitLab stakeholders and collaborators, to help them with their own respective workflows. In addition, we have two special milestones: `Backlog` and `Awaiting further demand`. Product Managers assign these issues to milestones that they have reviewed and make sense, but do not fit within the upcoming release milestones due to either a lack of comparative urgency or because we have not yet seen enough user demand to prioritize the item yet. The best way to demonstrate urgency on either of these items is to vote on them and, if possible, add comments explaining your use case and why this is important to you. **Recommendation for when to change 'Awaiting further demand':** Consider the number of people who use, not just have access to, the area impacted by the issue. When you receive enough feedback to be equal to a percentage of the power users, it is likely to consider moving the issue forward. Often public feedback only comes from a small percentage of people using or evaluating a feature or product. There needs to be a balance between waiting too long and acting too fast. In addition, there may be a tendency for more negative feedback than positive feedback, remember that people are passionate enough to care about this issue and it should be taken constructively. **Recommendation when changing a previously planned issue to `Backlog`:** When moving a previously planned issue to `Backlog`, especially one planned for within the next release or two, consider the message that this may be sending to parties that were interested in this feature. In some cases, they may have been depending or planning upon the issue to be delivered around the assigned milestone, and with the change to `Backlog` that is now unlikely to occur. In these instances, it is best to concisely explain the rationale behind the change in a comment, so the community can understand and potentially respond with additional justification or context. It is also encouraged to move the issue to the `Backlog` as soon as it is clear that it will not be scheduled in the near future. This will help with understanding the change, as it will not seem like a last minute change. Again, the milestone of an issue can be changed at any moment, including for both of these special milestones. For a detailed timeline, see [the product development timeline](/handbook/engineering/workflow/#product-development-timeline). #### Shifting commitment mid-iteration From time to time, there may be circumstances that change the ability for a team to ship the features/issues they committed to at the beginning of the iteration. These steps also apply when an issue is broken into multiple issues. When this happens, as a PM you must ensure the impacted issues and their milestones are updated to reflect the new reality (for example, remove `deliverable` tag, update `milestone`, etc.). Additionally, notify your manager of the shift. #### Utilizing our design system to work autonomously Our [design system](https://design.gitlab.com) provides the means to work autonomously, without always needing UX insight and feedback. When problems can be solved using an already documented paradigm, you don't need to wait for UX approval to bring an issue to a reasonable state within a first iteration. If lingering questions remain, subsequent iterations can address any shortcomings the feature might have. #### Introducing a breaking change in a minor release As a product manager, you should carefully consider the costs and benefits when planning to introduce a breaking change. Breaking changes may heavily impact existing users, and it is your responsibility to minimize the negative effects. If you want to introduce an urgent breaking change in a minor release (e.g. you need to provide support for a new feature that cannot be backward compatible), you have to consider how many users will be affected by the change, and whether the change can wait until the next major release instead. If you evaluate that the impact on users is acceptable (e.g., you have evidence that the feature is not used significantly), and the change will allow many users to benefit of new features or to solve problems, follow this process: 1. Create an issue to discuss the breaking change, describing it in detail including the impact and benefits. 1. Consider if you really need to do a breaking change in a minor. Can you wait for the next major release? 1. Communicate the breaking change as soon as possible, for example: - Publish a blog post about the upcoming change, with a timeline and a simple way to recognize who is affected, and who is not - Ask to schedule tweets about the blog post in the `#twitter` Slack channel - Ask to reach out customers that may be affected by the change in the `#customer-success` and `#sales` Slack channels - Mention the problems customers may report and how to address them in the `#support_self-managed` and `#support_gitlab-com` Slack channels 1. Throughout this process, think like a customer. Figure out actions that could make the breaking change less painful from their point of view. 1. Always keep the issue up-to-date. ### Community participation Engaging directly with the community of users is an important part of a PM's job. We encourage participation and active response alongside GitLab's [Community Advocates](/handbook/marketing/community-relations/community-advocacy/). #### Conferences A general list of conferences the company is participating in can be found on our [corporate marketing](https://gitlab.com/gitlab-com/marketing/corporate-marketing/issues?label_name%5B%5D=Corporate+Event&sort=due_date) project. There are a few notable conferences that we would typically always send PMs to: - [KubeCon](https://events.linuxfoundation.org/) - [Atlassian Summit](https://www.atlassian.com/company/events/summit) - [GitHub Universe](https://githubuniverse.com/) - [DevOps Enterprise Summit](https://events.itrevolution.com/) - [Google Next](https://cloud.withgoogle.com/next) - [AWS Reinvent](https://reinvent.awsevents.com/) - [Velocity](https://conferences.oreilly.com/velocity) If you're interested in attending, check out the issue in the corporate marketing site and volunteer there, or reach out to your manager if you don't see it listed yet. ### Stakeholder Management #### Updated SSOT for stakeholder collaboration Stakeholder collaboration and feedback is a critical competitive advantage here at GitLab. To ensure this is possible, and facilitate collaboration, you should maintain an updated single source of truth (SSOT) of your stage direction, category strategies, and plan, at all times. This equips anyone who wants to contribute to your stage’s product direction with the latest information in order to effectively collaborate. Some sections and teams use the [scheduled Direction Update issue template](https://gitlab.com/gitlab-com/Product/blob/master/templates/DIRECTION-UPDATES.md.erb) to remind themselves of this task. Actively and regularly reach out to stakeholders. Encourage them to view and collaborate on these artifacts via these (non-exhaustive) opportunities: - Engage with users in epics, issues, and merge requests on GitLab.com. - [Meet with customers directly.](#customer-meetings) - Participate in the [CAB]. - Talk with GitLab team-members using GitLab. - Talk with GitLab team-members in [group conversations](/handbook/people-group/group-conversations/). - Talk with other PMs and [Product leadership](/handbook/product/leadership/) to align your stage’s product direction with the rest of GitLab. Here is some guidance for new PMs to ensure your stage direction, category strategies and plan are up-to-date and visible to critical stakeholders: - Seek feedback from the [CAB] once every six months. - Present your plan to your manager once a month. - Present the plan and stage/category strategies to your stable counterparts - Present your stage strategy and plan in a [customer meeting](#customer-meetings) once every two weeks. - Present changes to your stage strategy, category strategies, and plan to your stage group weekly meeting once a month. #### Customer meetings It's important to get direct feedback from our customers on things we've built, are building, or should be building. Some opportunities to do that will arise during [sales support meetings](#sales-support-meetings). As a PM you should also have dedicated [customer discovery meetings](#customer-discovery-meetings) with customers and prospects to better understand their pain points. As a PM you should facilitate opportunities for your engineering group to hear directly from customers too. Try to schedule customer meetings at times that are friendly to your group, invite them, and send them the recording and notes. ##### Sales Support Meetings **Before the meeting**, ensure the Sales lead on the account has provided you with sufficient background documentation to ensure a customer doesn't have to repeat information they've already provided to GitLab. **During the meeting**, spend most of your time listening and obtaining information. It's not your job to sell GitLab, but it should be obvious when it's the time to give more information about our products. For message consistency purposes, utilize the [Value Drivers](/handbook/marketing/#go-to-market-value-drivers-and-customer-use-cases) framework when posing questions and soliciting information. After the meeting, make sure all your notes and feedback land in issues. ##### Customer Discovery Meetings Customer discovery meetings aren't UX Research. Target them to broad-based needs and plan tradeoff discussions, not specific feature review. There are two primary techniques for targeting those topics: * **Top Competitors** - Identify the top 3 competitors in your categories and talk to customers using those competitor asking: What is missing to have you switch from X to us? We’re not aiming for feature parity with competitors, and we’re not just looking at the features competitors talk about, but we’re talking with customers about what they actually use, and ultimately what they *need*. * **User Need** - Identify GitLab users from key customers of your group's categories and features. Solicit them for what they love about the features and ask about their current pain points with both the features as well as the surrounding workflows when using those components of GitLab? **Set up a meeting** by identifying what you're interested in learning and prepare appropriately. You can find information about how customers are using GitLab through Sales and version.gitlab.com. Sales and support should also be able to bring you into contact with customers. There is no formal internal process to schedule a customer meeting, but if the need arises, we can formulate one. **During and after** spend most of your time listening and documenting information. Listen for pain points. Listen for delightful moments. Listen for frustrations. Write down your findings in GitLab issues. Read back and review what you've written down with the customer to ensure you've captured it correctly. **After the meeting** make sure all your notes and feedback land in appropriate issues. Make appropriate adjustments to category strategies, feature epics, and personas. Share your findings with your fellow product managers and the sales and customer success account teams for the customer. You can find some additional guidance on conducting Customer Discovery Meetings from these resources: * [How to Interview Your Customers](https://customerdevlabs.com/2013/11/05/how-i-interview-customers/) * [Effective User Interviews](https://www.productmanagerhq.com/2018/08/effective-user-interviews/) ##### Sourcing Customers PMs should also feel free to collect and evaluate custmer feedback independently. Looking at [existing research](https://about.gitlab.com/handbook/engineering/ux/ux-research/#how-to-find-existing-research) can yield helpful themes as well as potential customers to contact. You can use the following techniques to source customers directly: **GitLab Solution Architects** know our customers the best, especially from a technical perspective. **GitLab Issues** customers will often comments on issues, especially when the problem described by the issue is a problem they are experiencing firsthand. The best strategy is to capture their feedback directly on the issue, however, there are times when this is not possible or simply doesn't happen. You can find alternative contact info by clicking on the user's handle to see their GitLab user page; this page often includes contact information such as Twitter or LinkedIn. Another option is to directly mention users in issues to engage async. In popular issues you can just leave a general comment that you're looking for people to interview and many will often volunteer. **Gitlab Broadcast Message Placeholders** is a great tool for recruiting users from within the product. This tool alows users to be recruited durring or after interacting with specific workflows within the product. Currently, banner messages can be [targeted by URL](https://www.youtube.com/watch?time_continue=3&v=C4PuRUiQ6WU&feature=emb_logo), and [user information can be passed](https://www.youtube.com/watch?v=2NKsXgfLhqc&feature=youtu.be) in order to personalize the message as well as the response. **Gitlab Sales and Customer Success** You can ask for help in [Slack customer success channel](https://gitlab.slack.com/archives/C5D346V08/p1583438272202100/) or join the the Field Sales Team Call and the All CS Team Call to present a specific request via the Zoom call. **Zendesk** is a great tool to find users who are actively making use of a feature and either came across a question or an issue. Users who've had recent challenges using the product really appreciate PMs taking the time to learn from their expereinece. This establishes that we are willing to listen to users, even if they are not having a great experience. This is also a great opportunity to discuss the roadmap and provide context so that users understand what we are going to improve. The best way to request a chat is through the support ticket; however, you can also click on the user that initiated the interaction and their contact information will display on the left hand side panel. If you don't have a Zendesk account, see [how to request a light agent Zendesk account](/handbook/support/internal-support/#light-agent-zendesk-accounts-available-for-all-gitlab-staff). You can use [Zendesk's trigger feature](https://support.zendesk.com/hc/en-us/articles/115015611647-Trigger-conditions-and-actions-reference) to receive email alerts when specific keywords relevant to your product area are mentioned in a support ticket. Additionally, it is possible to create a simple dashboard that lists all the currently active support tickets that match the trigger. Reach out int #support-managers to receive some help in setting this up. **Social Media** can also be effective. If your personal account has a reasonable number of connections/followers, you can post your desire to connect with users on a specific question directly. When posting, remember to include the subject you want to discuss as well as how people can reach out. You can also reach out to the #social-media channel to have your tweet retweeted by the @gitlab account. ![twitter-contactpng](/handbook/product/twitter-contact.png) If you want to reach a wider audience, consider asking a community advocate to re-post using the official GitLab account for the relevant platform. You can reach advocates on the `#community-advocates` Slack channel. You can also reach out to authors of articles related to tech your team is working on, via various publications such as [Medium](https://medium.com). A clear and brief email via the publication website or LinkedIn is a good way to engage. If you've tried these tactics and are still having challenges getting the customer feedback you need, connect with your manager for support and then consider leveraging the [UX Research team](https://about.gitlab.com/handbook/engineering/ux/ux-research/#how-ux-research-and-product-management-work-together-on-problem-validation-research-single-stage-group-initiatives). **Non-users** are often more important than GitLab users. They can provide the necessary critical view to come up with ideas that might turn them into GitLab users in the end. The best non-users are the ones who don't even plan on switching to GitLab. You can reach these people at local meetups, conferences or online groups like, Hacker News. In every such case, you should not try to interview the user on spot, instead organize a separate meeting where nobody will be distracted, and both of you can arrive prepared. #### Customer Advisory Board Meetings One specific, recurring opportunity to get direct feedback from highly engaged customers is the [GitLab DevOps Customer Advisory Board](/handbook/marketing/product-marketing/customer-reference-program/#gitlab-devops-customer-advisory-board). You may be asked by the CAB to present your stage at these meetings. Here are some guidelines when doing so: - Since it will be sent out in advance of your presentation, take the opportunity to update your [stage strategy](#stage-strategy) video - Start the presentation with an overview of your stage strategy - Emphasize the importance of feedback and dialog in our [prioritization process](#prioritization) - Highlight recently completed plan items that were driven by customer feedback - Come prepared with five questions to facilitate a discussion about industry trends, plan tradeoffs, pain points and existing features - Don't simply look for places to improve, seek to clarify your understanding of what customers currently value and love #### Working with (customer) feature proposals When someone requests a particular feature, it is the duty of the PM to investigate and understand the need for this change. This means you focus on what is the problem that the proposed solution tries to solve. Doing this often allows you to find that: 1. An existing solution already exists within GitLab 1. Or: a better or more elegant solution exists Do not take a feature request and just implement it. It is your job to find the underlying use case and address that in an elegant way that is orthogonal to existing functionality. This prevents us from building an overly complex application. Take this into consideration even when getting feedback or requests from colleagues. As a PM you are ultimately responsible for the quality of the solutions you ship, make sure they're the (first iteration of the) best possible solution. #### Competition Channel When someone posts information in the `#competition` channel that warrants creating an issue and/or [a change in `features.yml`][features], follow this procedure: - Create a thread on the item by posting `I'm documenting this` - Either do the following yourself, or [link](#competition-channel) to this paragraph for the person picking this up to follow - If needed: create an issue - [Add the item to the `features.yml`][features] - If GitLab does not have this feature yet, link to the issue you created - Finish the thread with a link to the commit and issue #### How and when to reject a feature request Rejecting a feature request or a merge request is not an easy thing. People can feel quite protective of their ideas. They might have invested a lot of time and energy in writing those ideas. You can be tempted to accept a feature only to avoid hurting the people who thought of it. Even Worse, if you reject an idea too harshly, you might discourage other people to contribute, which is something we should strive to avoid. However, as the number of issues and merge requests grows incessantly, we should be diligent about rejecting features we are sure will not work out. It's better for everyone: for the product team, so we don't maintain a huge backlog of things we will never do anyway, and for the users who won't have to wait for our feedback indefinitely. Note: it's fine to not respond to issues that we think have potential until they gather momentum. Feature requests and merge requests can be rejected for the following reasons: * Not within our scope: the Direction page [lists all the areas](/direction/#scope) where GitLab, the product, won't go. Point the issue's author to this article and close the issue. * We don't want another setting: whenever we can, we try to [avoid having settings](#convention-over-configuration). Some settings are unavoidable, but most aren't. Ask the user to change how she approaches the feature in order to get rid of the setting. * Too complex: We want to have a simple, user-friendly product that does complex things, not the other way around. Tell the user to take a step back and think about the problem to be solved in the first place. Offer directions on what could be done instead. If she's not willing to do it, indicate that you will have to close the issue/merge request because it will go nowhere. * Brings an Enterprise exclusive feature to the Community Edition: this problem is already addressed in the [Stewardship page](/company/stewardship/#contributing-an-existing-ee-feature-to-ce). Indicate that we will investigate whether the feature can be ported to the Community Edition, discuss it with other teams members and come back to the user in a timely fashion. * Low priority: sometimes features are interesting but we simply don't have the capacity to implement them. In that case, simply tell the truth and indicate that we don't have enough resources at our disposal to do it at the moment. Don't forget to thank the authors for the time and effort taken to submit the feature request/merge request. In all cases and without exception, you should be nice and polite when interacting with users and customers. #### Analyst Engagement Part of being a product manager at GitLab is maintaining engagement with analysts, culminating in various analyst reports that are applicable to your stage. In order to ensure that this is successful and our products are rated correctly in the analyst scorecards, we follow a few guidelines: - Spend time checking in with the analysts for your area so they are familiar with our story and features earlier, and so we can get earlier feedback. This will ensure better alignment of the product and the way we talk about it will already be in place when review time comes. Remember, analysts maintain a deep understanding of the markets they cover, and your relationship will be better if it is bi-directional. Inquire with analysts when you have questions about market trends, growth rates, buyer behavior, competitors, or just want to bounce ideas off of an expert. - Make paying attention to analyst requests a priority, bringing in whoever you need to ensure they are successful. If you have a clear benefit from having executives participate, ask. If you need more resources to ensure something is a success, get them. These reports are not a "nice to have", ad-hoc activity, but an important part of ensuring your product areas are successful. - When responding to the analyst request, challenge yourself to find a way to honestly say "yes" and paint the product in the best light possible. Often, at first glance if we think we don't support a feature or capability, with a bit of reflection and thought you can adapt our existing features to solve the problem at hand. This goes much smoother if you follow the first point and spend ongoing time with your analyst partners. - Perform retrospectives after the analyst report is finalized to ensure we're learning from and sharing the results of how we can do better. It's important to be closely connected with your product marketing partner, since they own the overall engagement. That said, product has a key role to play and should be in the driver's seat for putting your stage's best foot forward in the responses/discussions. #### Internal customers Product managers should take advantage of the internal customers that their stage may have, and use them to better understand what they are really using, what they need and what they think is important to have in order to replace other products and use GitLab for all their flows. We want to meet with our internal customers on a regular basis, setting up recurring calls (e.g., every two weeks) and to invite them to share their feedback. This is a mutual collaboration, so we also want to keep them up to date with the new features that we release, and help them to adopt all our own features. ### Roadmaps, Boards, Issues & Epics #### Roadmaps You should strive to maintain an updated Epic [roadmap](https://docs.gitlab.com/ee/user/group/roadmap/) for your group (here's [an example](https://gitlab.com/groups/gitlab-org/-/roadmap?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Ageo)). This can take considerable effort but doing so will ensure your issues are well organized according to the principals laid out below. #### Boards As part of our [planning](#planning-future-release) process it is important that you maintain a prioritized [issue board](https://docs.gitlab.com/ee/user/project/issue_board.html) for your group. It's customary to call these boards `STAGE - GROUP - Planning` and to configure them to filter to all issues with your group label and with each milestone as a column (here's [an example](https://gitlab.com/groups/gitlab-org/-/boards/1131777?&label_name[]=group%3A%3Ahealth)). As the [DRI](/handbook/people-group/directly-responsible-individuals/) for prioritization it is your responsibility to ensure that all items on your Planning board are scheduled to a [milestone](#milestones) and are prioritized both within and across milestones. This means the lowest priority in the current milestone would generally be the top priority in the next milestone. In this regard your planning exercise is a complete prioritization of the near term issues. #### Epics Issues related to the same feature should be bundled together into an into an [epic](https://docs.gitlab.com/ee/user/group/epics/). ##### Epics for a single iteration Features may include multiple issues even if we are just targeting an MVC. In this case, we should use an epic to collect all of them in one single place. This epic should have a start and an end date, and it should not span more than 3 releases, otherwise we run the risk of having epics drag on indefinitely. When these issues are finished and closed, we should have successfully achieved the epic's goal. A good example of this kind of epic is the first iteration on a new feature. Epics representing MVCs should clearly state `MVC` at the end of the title and should have a parent epic relationship towards a category strategy or a meta epic. ##### Meta epics for longer term items We use epics to track many issues related to a specific topic, even if there isn't a specific timeline for shipping. These epics should be marked as ~meta, they may not have a specific start or end date, and may contain single iteration epics. This is useful to have an overview of the future so participants and observers can understand how the pieces fit together. It can be really useful to understand the context of where we think we’re going so we can do a good job with the MVC. Also, it conveys confidence internally and externally that we understand what we need to do when the MVC is particularly minimal. But don't get too caught up in long-term epics as you risk making proposals too complex, and overrepresenting certainty in the solution. Don't work too far in the future; we'll know better once we ship something small. When creating a meta epic, there's a natural tendency to capture it as quickly as possible and then move on, but we must always strive to create a more specific epic for the first iteration, or the next iteration if something already exists. Describing an MVC means that the community can contribute more easily. Also, after distilling things down to a first iteration, you might realize it’s a lot easier than you thought, and prioritize it earlier. You can have an MVC without a meta issue. But **you can't have a meta issue without an MVC**. #### Issues We use issues to define narrowly scoped items of work to be done. Issues can focus on a variety of different topics: UX problems, implementation requirements, tech debt, bugs, etc. A good guideline for experience-related issues is that they should address no more than one user story. If an issue includes multiple user stories, then it is likely an epic. ##### When to create an issue You should create an issue if: - There isn't already an issue for what you're intending to write. Search first. - A feature is mentioned in chat channels like #product, #competition or elsewhere - A customer requests a particular feature You should consider **not** creating an issue when: - It's an iteration on something we haven't built yet. - You're planning very far ahead and it's something specific. The further away something is, the more vague or encompassing the issue should be. So, for example, create just one issue for a distant new feature, rather than several issues that will follow each other. This will reduce the total amount of issues. - There is already an existing issue. Even if the quality is low, people might have linked to it. Consider rewriting the description instead and leaving a comment that you did so. Closing issues to reopen the same issue is generally not a good idea. Consider whether an issue is [a missing feature, or a bug](/handbook/product/product-management/process/feature-or-bug.html). ##### Issue state When an issue is open, this signals that we're intending or considering implementing that change. It's important to close issues that we're not considering implementing in the near future, so that we avoid creating uncertainty with customers and colleagues. When closing an issue for this reason, make sure to update the issue body and leave a comment explaining why the issue is being closed. Issues can be reopened if we change our stance on them. ##### Prioritizing older issues Sometimes, you'll end up prioritizing an issue that was created a significant time ago. When you move these issues into an upcoming milestone, look closely to see if they need to be groomed again, so that they include current information. A good rule is to review any issue you didn't personally create or that has been open longer than 3 months. ##### When to close an issue To clearly communicate to our stakeholders what we are going to do, it's critical that you not only provide the positive view (what we will do), but also articulate the negative view (what we will not do). While this should be communicated in [stage](#stage-strategy) and [category](#category-strategy) strategies, it starts with issues: As a Product Manager you should close issues that are: 1. Duplicated elsewhere. 1. No longer relevant due to other reasons. 1. 'Not the next iteration': an iteration on a proposed feature that is unlikely to ship in the next few months. 1. 'Won't do': An issue that we have [no intention of implementing](https://gitlab.com/gitlab-org/gitlab-ce/issues/12736#note_50662947), because it does not fit within or is antithetical to our [vision](/direction/#product-vision), it presents a security risk, or other reasons you outline in the issue. When closing an issue, leave a comment explaining why you're closing the issue, and link to anything of relevance (the other duplicate, the original feature that this is an iteration on, etc). The 'not the next iteration' issues are the most important ones to resolve. It is very easy to create a large, comprehensive change with meta issues and lots of improvements, but it is essential that we iterate and ship the _minimum viable_ change. We have to ship the iteration, wait for it to be used, and ask for feedback. As a product manager, you must think about the bigger picture when making a proposal to improve the product. It's important to avoid writing this down as a bunch of issues. Come up with a direction, but only record the first step. This way we can preserve the efficiency of [our value of iteration](/handbook/values/#iteration). Closing issues whenever possible is an important part of your job and helps to keep a clear view of what is next. Consider using the following template to close an issue: > Closing this because XXX is something we should do first. When that feature is finished, we can learn from observing it in use. If we learn that this issue is still relevant, we can then reopen it. See /handbook/product/#when-to-create-or-close-an-issue for more detail about this policy. ##### How to submit a new issue 1. If you have time, the first thing you should do is search the [GitLab project](https://gitlab.com/gitlab-org/gitlab/issues) to see if a similar issue already exists. We shouldn't create duplicates if we can avoid them. 1. Identify if the issue is about GitLab Community Edition (CE) or GitLab Enterprise Edition (EE), although this can easily be changed later. 1. The title should highlight the wished change (or target state), not the initial problem. If you don't know the wished change yet, then it's ok to have the title reflect the initial problem to solve, but before release the issue title should be updated to reflect the wished change. 1. The body should clearly state what the current pain point is and why it's important to solve. 1. The initial issue should be about the problem we are solving. If a separate [product discovery issue](#product-discovery-issues) is needed for additional research and design work, it will be created by a PM or UX person. 1. If the body contains too many paragraphs, it can surely be rewritten to be shorter. 1. Do not use acronyms or abbreviations. Everyone should be able to jump on the issue and participate without needing a glossary. 1. Choose labels which are relevant to the issue. If you are unsure about what certain labels are for, check the [labels page](https://gitlab.com/gitlab-org/gitlab/labels)), and read the descriptions. The [issues workflow doc](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/contributing/issue_workflow.md) provides a breakdown of the label types and how to choose the right label. 1. Unless you know what you are doing, do not - assign someone to the issue - assign a milestone - set a due date - add weight - weight represents the technical complexity and should be defined by our developers 1. Mention the different stakeholders in the body of your issue. In most product related issues, we usually mention the product manager, the design, frontend, and backend managers as appropriate. Some teams have [experts](/company/team/structure/#expert) or [liaisons](/job-families/liaison) that can be mentioned instead of the managers. Mentioning the people in the body of the issue will trigger the notification mechanisms chosen by the people who are mentioned - therefore there is no need to notify people in another channel after the issue has been created (Slack, email). #### Product Discovery Issues A discovery issue is intended for UX, PM, FE, and BE to discuss the problem and potential solutions. Doing product discovery without the full team is generally not an effective approach. The final output for this issue could be a doc of requirements, a design artifact, or even a prototype. The solution will be developed in a subsequent milestone. When a product discovery step is needed to design a feature, PMs should create a separate issue (linked to the epic and implementation issue) for that research and design work to occur. We should not repurpose or otherwise reuse the existing implementation issue; doing so creates a risk of the issue being closed when the design work is complete and thereby losing track of the actual delivery of the item. It's also important to ensure that product discovery issue is really even needed. It's possible in many situations to simply use the initial ticket for any design discussions - this will ensure all of the back and forth is in one place, avoiding the risk of losing track of parts of the discussion. If you find you are creating a issue simply to reserve time or people for execution, consider trying to secure the capacity in another way. Be sure to follow the [contribution guidelines](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/contributing/design.md) on correct labeling practices for the ``product discovery`` label. #### Wireframes When relevant, you can include a wireframe in your issue to illustrate what you're thinking about. But you don't need to create wireframes on your own; our UX team has a designer embedded in every stage group who will help you figure out how to solve the problem you're addressing. They should actively participate in your planning processes, so your request won't be a surprise. If you do want to create a wireframe, we like [Balsamiq](https://balsamiq.com/) for its simplicity and low fidelity. If you are struggling for inspiration, you can also paste screenshots of similar features in other products. #### Long-lasting issues A general guideline is that an issue should only span one release. If we know an issue is going to span multiple releases, split it up into multiple issues. Epic issues are the exception to this rule, but should be kept to a minimum and only serve to guide broader subjects, not a single feature over multiple releases. This is to make sure we stick to our values of the [minimally viable change](#the-minimally-viable-change). This means that feature issues should be closed after the first iteration whenever possible. We'll know more in the future and this keeps any remaining issues short and actionable. In addition, it's often a good idea to throw away an original plan and start fresh. Try to do this more often, even more than you're comfortable with. Close the issue and create a new one. #### Which issue should you be working on? When you don't have any specific tasks assigned, you should work on issues that are labeled `Product work`, in both the EE and CE projects. These are issues that need our attention the most. ### Product Communication See the [Product Communication](/handbook/product/communication/) page for how to communicate about your features. ### Life Support PM Expectations When performing the role of Life Support PM only the following are expected: - Management of next three milestones - Attend group meetings or asynch discussion channels - Provide prioritization for upcoming milestones - MVC definition for upcoming milestones - Increase fidelity of scheduled issues via group discussion - Ensure features delivered by the group are represented in the release post Some discouraged responsibilities: - Long-term MVC definition - One year plan - Category Strategy updates - Direction page updates - Analyst engagements - CAB presentations ### Team Meetings #### Weekly Product Management Meeting There is a weekly product management meeting open to any GitLab team-member. If you would like to join the call to discuss a specific agenda topic, please add it and any relevant context to this [GoogleDoc (internal only)](https://docs.google.com/document/d/1feF46WvqBuWJ-bYnA-BuCD4gq_J5UagupNHJYTBtII8/edit)[internal] in advance of the meeting. The Zoom Link and meeting time are in the GoogleDoc. The structure of the meeting is as follows: 1. New hire announcements, bonuses, promotions and other celebrations 1. The EVP Product will prioritize the discussion items, and any items we can't get to in the allotted 50 min will be moved to the following week. We take notes on discussion items. 1. `READ-ONLY` announcements which require no synchronous discussion and are for information sharing only. If any action is required, this should be highlighted specifically by the reporter. If you are a Product team member and are unable to attend the call, you may add items for `READ-ONLY` to the agenda. #### Weekly Product Leadership Meeting The VP of Product and their direct reports track our highest priority Product Team initiatives in the [Product Leadership Issue Board](https://gitlab.com/gitlab-com/Product/boards/1021790?&label_name[]=Product%20Leadership). In order to maintain strategic focus, there is a WIP limit of 6 for Product Leadership items with the `Doing` label. The VP of Product uses this board to ensure we are progressing key initiatives. If one of those initiatives needs to be discussed synchronously the assigned individual should add it to the meeting's [GoogleDoc agenda](https://docs.google.com/document/d/1yN2n1ei24HiM5G7tBxaqK4yNPYreKpLZ3CG3nsEFOR4/edit#heading=h.384zmpcao5l6). Directors can delegate and coordinate cross-product initiatives as needed based on the issues in this board. As part of this Product Leadership Meeting we also [review progress towards our OKRs](https://gitlab.com/gitlab-com/Product/issues/187). Non-public items for discussion should be added directly to the [agenda document](https://docs.google.com/document/d/1yN2n1ei24HiM5G7tBxaqK4yNPYreKpLZ3CG3nsEFOR4/edit#heading=h.384zmpcao5l6) for the meeting. ### Product Manager Buddy System In order to avoid suffering in silence, encourage growth in your trade and foster collaboration and understanding across groups and stages we have a Product Buddy System whereby we designate pairs of Product Managers. These pairs should consider working together on: * Reviewing each others' MVCs * Reviewing each others' monthly milestone prioritization * Reviewing each others' direction items * Participating in Think Big exercises about each others' groups The pairing for this buddy system is defined in the [Product Buddy System Google Doc (internal only)](https://docs.google.com/spreadsheets/d/1g52exL3Wi0q1JZQDZOzaw4H26bywG0A4kZ917DIQ9Po/edit#gid=1777807595). ### MVC and New Config Reviews Product Managers are fully empowered to define the what and priority of what they are building. Making PMs the DRI enables our entire company to iterate faster and drive more value for users. There are two instances where it is helpful to have an outside review of your scheduled issues. Those are: * **MVCs** - Creating the smallest iteration possible is difficult, especially when you've been working with a problem for sometime. It's natural to think what you've come up with is the smallest, and takes collaboration with others to get to something even smaller. * **New Configs** - It's easy to think of all the possible options users might want with a feature. When introducing new configuration it's natural to get into a local-optimization mindset that some users want to be able to adjust this setting so why not add a new config option? It is helpful to have an outside perspective to bring a slightly more global view of the addition of a new config option, and the possibility of eliminating it or supplying an appropriate default. As a result, the [Ops](/handbook/product/categories/#ops-section) and [CI/CD](/handbook/product/categories/#cicd-section) sections utilize an [MVC & New Config issue](https://gitlab.com/gitlab-com/Product/blob/master/templates/MVC-CONFIG.md.erb) to encourage additional review of upcoming issues that are MVCs or introduce new configuration. ### Build vs "Buy" As a Product Manager you may need to make a decision on whether GitLab should engineer a solution to a particular problem, or use off the shelf software to address the need. First, consider whether our users share a similar need and if it's part of GitLab's scope. If so, strongly consider [building as a feature in GitLab](/handbook/values/#dogfooding): * [Evaluate open source options](#evaluating-open-source-software) to utilize. * If time to market is an issue, a [global optimization issue](/handbook/product/product-management/process/#prioritize-global) may also be opened to assist with prioritization. * For a potential acquisition, follow the [acquisition process](/handbook/acquisitions/acquisition-process/). If the need is specific to GitLab, and will not be built into the product, consider a few guidelines: * Necessity: Does this _actually_ need to be solved now? If not, consider proceeding without and gathering data to make an informed decision later. * Opportunity cost: Is the need core to GitLab's business? Would work on other features return more value to the company and our users? * Cost: How much are off the shelf solutions? How much is it to build, given the expertise in-house and opportunity cost? * Time to market: Is there time to engineer the solution in-house? If after evaluating these considerations buying a commercial solution is the best path forward: 1. Consider [who owns the outcome](/handbook/finance/#how-spend-is-allocated-to-departments), as the spend will be allocated to their department. Get their approval on the proposed plan. 1. Have the owning party [open a finance issue](https://gitlab.com/gitlab-com/finance/issues/new) using the `vendor_contracts` template, ensure the justification above is included in the request. #### Evaluating Open Source Software When considering open source software in build vs. "buy" decisions we utilize the following general criteria to decide whether to integrate a piece of software: * **Compatibility** - Does the software utilize a [compatible open source license](https://docs.gitlab.com/ee/development/licensing.html#acceptable-licenses)? * **Viability** - Is the software, in its current state, viable for the use case in question? * **Velocity** - Is there a high rate of iteration with the software? Are new features or enhancements proposed and completed quickly? Are security patches applied regularly? * **Community** - Is there a diverse community contributing to the software? Is the software governed by broader communities or by a singular corporate entity? Do maintainers regularly address feedback from the community?