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.
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 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.
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
You can copy/paste this to make sure you don't miss anything:
<!-- Click on ~customer priority:: to select an appropriate label -->
- 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:
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.
Please note these dashboards are still being piloted. For more context on the pilot, including model overview, status, and quickstart info/video and issues for pilot participation, visit customer issues prioritization framework.