This document describes how to engage with the product management team.
#product chat channel for questions that don't seem appropriate for the issue tracker.Please see the Product Categories to know which product manager handles which category.
At GitLab, the PMs lead their specialization. That is, the Create PM decides what the Create group works on, for which release, and makes sure this furthers our goals. This includes bugs, features, and architectural changes.
The PM can't be expected to parse every single bug or issue that comes by, so they have to rely heavily on the input of the various stakeholders. To be able to achieve this, both the PM and the stakeholders have to actively work together. It's a two-way street.
In general terms, if you require something to happen with the product or if you need engineering staff for a particular change, you approach a PM. Preferably through creating an issue (the GitLab way), and mentioning them there.
In the same vein, PMs are required to ask for feedback from the stakeholder on particular changes. If a change will affect GitLab.com and its maintenance, a PM should proactively reach out to infrastructure engineers to help with the scope, design, and decisions regarding this change.
It is then up to the PM to weigh all these inputs and decide on a prioritization. It is to be expected that they are the best equipped to make this prioritization, while also keeping in mind all goals of GitLab.
Generally speaking, all product feedback should be provided via issues. For detailed overview of how to create an issue, please read this section on the process. If you have any product-related questions, comments, input, or otherwise, the Product Manager is the primary person you should talk to, if creating an issue does not suffice.
Creating an issue includes, but is not limited to, features, bugs, and other changes that need to be prioritized, changed, discussed, or need more attention. Product Managers will reach out to stakeholders when making or communicating any decision. The pressure of balancing priorities while ensuring we build excellent software is on the product managers and they need all the input they can get to achieve this. Paid features fall under their respective PMs, not under one PM in particular. For instance, Service Desk falls under the Monitor PM.
If a customer has a feature request that doesn't already exist, refer to the process to create an issue in the gitlab-org issue tracker and choose the Feature Proposal template, following the instructions and providing as much information as possible. Once you've created the issue, make sure to add the appropriate labels for the product stage and/or group (e.g ~"devops::plan") if known and add a comment tagging the appropriate Product Manager. If an issue already exists, make a comment on the issue with their information and use case.
Whenever you're sharing feedback on an issue (e.g. "Customer X wants this"), please make sure to do the following:
If a customer expresses interest by simply mentioning an issue number or e.g. "an integration with X", that is not sufficient information. Before creating or commenting on an issue, make sure to ask them:
The Product Manager is responsible for figuring all of this out, but being one step ahead of them will speed things up.
If a customer is a member of our Product Customer Advisory Board, the CSM should add two labels: ~CAB Takeaway and ~CAB Takeaway Qx FY20xx to the issue.
It is highly recommended to use the feedback template below to make this easier.
You can copy/paste this to make sure you don't miss anything or create a comment template for reusability:
<!-- Select the appropriate subscription and product text below and remove the others (note: do not add them as labels)>
<!-- Click on ~customer priority:: below to select an appropriate label 1 through 10 with 10 being the highest>
The following ~customer is interested in this capability
- Subscription: ~"GitLab Ultimate" OR ~"GitLab Premium" OR ~"GitLab Free"
- Product: ~"self-managed" OR ~SaaS
- Link to request:
- Priority: ~customer priority::
- Why interested:
- Problem they are trying to solve:
- Current solution for this problem:
- Impact to the customer of not having this:
- Questions:
- PM to mention:
- CSM to mention:
The ~customer priority::* labels are inputs for the prioritization model powering the customer issue prioritization framework dashboards:
These dashboards represent the relative importance of a given issue to the specific customer. 1 is the lowest priority and 10 is the highest. These can be updated at any point in time and will be reflected in the model within 24 hours. You can find more context about priority labels on the customer issues prioritization framework handbook page.
A customer with more than 1000 users mentioned they are interested in this feature to be able to do their sprint planning more effectively. The problem they are trying to solve is that with the current implementation, they can't X and need to do so because Y. They are using software X to do this today, but would be able to move to GitLab if we would do this.
@productmanager this issue doesn't have a milestone right now, are we planning to address this in the near term?
salesforce.com/blabla
Customers that are assigned a Customer Success Manager typically have a collaboration project on GitLab.com, which is used to share information, document customer details, and track issues in a place that both the GitLab team and the customer's team can access.
Generally, CSMs maintain a main issue and/or enable the CS-Tool - TAM issue tracker, which lists out all feature requests the customer is interested in with links to the public GitLab issue.
When a customer expresses interest in a feature, the CSM should capture that in the public GitLab issue, as well as add it as an entry in the main feature tracking issue of the customer's collaboration project.
The feature tracking issue should be maintained regularly by updating priority (elaborated on below) and milestones as the single source of truth on customer product needs. It can also be used for reviewing metrics of previously delivered feature requests.
If there is a lot of discussion with the customer about a specific feature request, create an issue on the customer collaboration project about it and list that issue as a related issue on the main GitLab issue. This is another signal of the main product issue of customer interest and also allows discussion with the customer and internal GitLab team members about their needs and concerns.
If you have followed the process of creating/commenting on issues and have not gotten traction, confirm that all of the necessary information is included in the issue. Follow up with the Product Manager again in the issue and in the product stage Slack channel (linking to the issue) to get additional attention and team member involvement.
If a customer has identified an issue that is high priority for them, such as a work-stoppage bug or a feature required for the customer to meet a deadline, follow the expected steps for logging and tracking customer feature requests above by adding the customer's interest in a GitLab issue and including it in the collaboration project issue. In addition, reach out to the Product Manager who is responsible for the corresponding group and discuss it with them directly. A general idea of high priority is that the customer needs a particular feature as soon as possible.
Critical Priority Requests are extremely rare, but, when they occur, they are agreed upon by both Product and Engineering, with the CSM facilitating the request. If a customer is unable to continue using GitLab without a specific feature, the CSM should begin the triaging the account, follow the process to indicate customer interest in the issue, then set up regular check-ins with the Product and Engineering teams to assess the status of the feature, expectations, and potential secondary plans. For the product & engineering process, please refer to the details of a critical customer merge request.
The following part of this UX design article sums it up well:
Listening to the right customers at the right time is a great first start, but you also need to make sure you are interpreting their feedback/requests correctly. The reason for that is generally customers ask for something to be better, not different — they interpret their problems through existing solutions. A customer is unlikely to tell you what new product to create (that’s your company’s job!) but they will tell you what problem that product needs to solve.
To do this you need to get to the underlying why behind the feature request — what is the basic problem to be solved, and then think about how to solve that problem in a fundamentally better (e.g., 10x faster, easier, cheaper) way.
This concept is best described by the (most likely misattributed) quote by the founder of the Ford Motor Company, Henry Ford: "If I had asked people what they wanted, they would have said faster horses.”
When the customer asks for a faster horse, you should then ask why. You would invariably hear things like: I’d like to shorten my commute from home to work I’d like to be able to sell my widgets to more cities I’d like to win the Kentucky Derby Now that you understand the basic problem to be solved (of which there are many solutions including a faster horse), its your job to think of a fundamentally better way to solve it — e.g., what does a 10x faster horse look like? And one potential solution to that is obviously a car.
If you hear a feature request from a customer, and they do not have a CSM assigned to their account, you should follow the normal procedure: create an issue and label it correctly. Let's say the customer requests an enhancement to Issues. You know by reading above that you'll have to label this with Discussion and you can mention or reach out to the Plan PM to expedite this if warranted.
A salesperson for an organization asking for a paid-tier feature request shall work with the product manager to arrange conversations to further explore the feature request and desired outcome. The process will be:
In the event that a paid customer is willing to pay for us to develop a specific feature, we should still respond as above. It's great that they're willing to pay for it: that means they really need it. However, we will not make a custom version of GitLab; even gitlab.com is running on GitLab Ultimate, and we move faster that way by minimizing technical complexity to determine features to follow after, it’s a trade-off to make. This doesn’t mean that "no" is always going to stay "no." We keep an open mind to improvements.
If you need support with a specific customer and your Customer Success Manager is unable to configure what is being requested or you are being asked to provide very specific guidelines for use of GitLab, we suggest creating an issue using the Product Support Request, and following the steps suggested in the issue.
To remain focused on customer results and efficiency, we recommend setting a due date on the issue in 5 business days and assigning the issue to the Product Leader of the section for triage.
Same as before, make sure an issue is made and make your case with the PM that this is becoming a problem and needs to be fixed. The PM will make sure that this is fixed or resolved in some other way.
Everything in GitLab should be fast and creating files falls under the repository, so you create an issue and make the PM aware of it by mentioning it.
The PM in turn will investigate whether this is a general problem or one specific to GitLab.com, in collaboration with infrastructure and others, and schedule any necessary changes for an upcoming release.
The Product team maintains a Sisense dashboard to aggregate issues and customer interest in those issues. Information is automatically gathered from GitLab issues by scanning for Salesforce customer account links. A separate dashboard Customer Requested Issues (CSM) is maintained for Sales and CS to make the dashboard easily filterable by the Account Owner or CSM for example.
The Sisense page automation will detect when Salesforce links are added and use the customer's Salesforce data, such as Total Account Value and seat licenses, to add them to the page. This also maintains a customer's privacy on public issues, since Salesforce links are only accessible to GitLab employees with proper credentials.
If your customer would like to report a bug, refer to the example of how to express the customer's interest in an issue and use the Bug template, following the instructions and the same steps as above.
You can refer to the following steps if a medium priority bug has become stale on the Product Management triage board. Another potentially helpful view is the triage report label.
Follow the same steps as for logging and tracking bugs as with feature requests, but be sure that steps to reproduce and workarounds are included whenever possible.
It is essential for the Product team and the CSM team to have a close working relationship, so that the business has a pulse on customer interests, feedback, and sentiment.
If you are on the Product team and seeking feedback from customers, you should consult with the Customer Success Management organization, as CSMs have direct access and regular communication with customers across all regions, tiers, use cases, and industries.
To request a meeting with a customer, open an issue in the CSM project and use the Product Engagement issue template, filling out the appropriate fields. If you have a specific customer in mind that you'd like feedback from, please share the customer name in the issue and tag the CSM assigned if you know who it is (you can find this information in Salesforce if you have access; otherwise, someone else will check for you).
The CSM team gets notified via Slack whenever a new issue is opened, and they will respond in the issue with specific customers when they are available. If you don't receive a response within a week (allowing the CSM to review with their customers), feel free to ping the [@timtams](https://gitlab.com/timtams) group in the issue.
One of the responsibilities of CSMs is collaborating with the Product team to help prioritize features by indicating demand from customers and relaying customers' use cases and experiences.
Following the process described below will ensure that customer interest in features is shared with Product properly, so that Product can take appropriate action. Through following the documented process, we are able to increase our efficiences, decrease back-and-forth communication, build a better product, and get answers and resolutions to customers faster.
It can be very helpful for both Product and customers to be on a call together to discuss feedback, roadmaps, etc.
It is best practice to ask for a PM to join your call through the slack channel for their group or category. Direct messages are problematic because it is hard to loop in other PMs if the right person for the call is not included in the DM, and it limits visibility into topics that may be discussed. If you are unsure about the right group to reach out to, you can ask in the general #product channel.
When including a member of the Product team on the call it is important that they have as much information and context as possible in advance. In order for the call to be successful it is important that you collect and share as much context as possible from all attendees in advance.
Also make sure you have a detailed agenda set at least 24 hours before the call that is shared with both the customer and the Product team.
Take the following steps to ensure an efficient and productive meeting:
In advance to the product call, have a conversation with the customer about expectations and their background.
Ask the following questions as applicable:
Once you have the context from the customer, share it with Product as soon as possible, so they have the appropriate background going into the call.
Ideally, provide them as much of the following details as possible:
CSMs regularly hold Executive Business Reviews with their customers and often request involvement from Product Managers. When a CSM is looking for Product involvement, they will reach out to the PM (in their group Slack channel) with the date, time, and desired topic.
The CSM will involve the PM in preparation for the EBR, working with them to ensure expectations of content, timing, and desired outcomes are fully established.
EBRs are usually quite long (60-90 minutes) and the product presentation is only a small portion (15-20 minutes) of the overall EBR, so the PM is welcome to only join when they will be speaking. Of course, if they want to join and/or participate in the full call, that is definitely welcome, as customers often share product feedback and requests throughout an EBR.
Throughout the customer lifecycle, customer-facing teams (Support, Account Executives, CSMs, Solutions Architects, Professional Services, Renewals Managers, etc.) may need the assistance of a Product Manager. This can include a detailed discussion of our direction, and how to address specific use cases, or gaps in functionality, within an organization.
To ensure these requests can be quickly triaged, easily scheduled, and later tracked, there is a standardized request process based on issues.
Product support requests are tracked in the Product team project. To create a request:
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.
When a support request is opened, labels will automatically be assigned to categorize the request.
Three fields are particularly important when triaging requests:
urgent requests should be treated with a high priorityAll Product Managers should ensure they are set up to receive label notifications for their respective stages: