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 of 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.
If you hear a feature request from a customer, 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 for improvements.
If you need support with a specific customer and your Technical account 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.
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. Otherwise, read this section on how to create an issue.
This 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 Plan PM, because it's part of our Issues.
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. 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.
You can use this feedback template to make this easier.
A customer with more than 1000 users mentioned they are interested in this feature to be able to do their sprint planning more effectively. 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
You can copy/paste this to make sure you don't miss anything:
- Link to request:
- Priority: ~customer priority::
- Why interested:
- Current solution for this problem:
- Impact to the customer of not having this:
- Questions:
- PM to mention:
The ~customer priority::* labels are inputs for the prioritization model powering the user requested issues dashboard, and 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.
