Product

  1. You are here:
  2. Team Handbook
  3. Product

The document below talks about how we do product at GitLab, not about what. For the what, see Product Direction.

Communication

On this page

Who to talk to for what

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 more attention, be prioritized, changed, or discussed.

Product managers will reach out to stakeholders in making or communicating any decision. The weight of balancing priorities and ensuring we build excellent software is on the product manager and they will need all the input they can to achieve this.

See below who to contact for what in detail. In short it is:

Enterprise edition features fall under their respective PM, not under one PM in particular. For instance, Service Desk falls under Victor, because it's part of our Issues.

Mike Bartlett

Reach out for anything that falls under the following things.

Platform

GitLab.com

For example, if a customer would like us to support a particular extension to LDAP or wants to have a particular importer, contact Mike.

For anything related to GitLab.com, Mike is also the first responder. If you want to know more about the rollout of particular features on GitLab.com or how our plans work, talk to Mike.

customers.gitlab.com

Our subscription manager.

license.gitlab.com

Our license creator and manager.

Victor Wu

Discussion

For anything that falls under:

version.gitlab.com

Salesforce

This means that if a customer would like to see burndown charts, which relates to issues, you should speak to Victor.

Mark Pundsack

I2P Demo

Anything related to the Idea to Production demo itself is Mark's responsibility, but not all features in the idea-to-production scope.

Joshua Lambert

Prometheus

Anything related to monitoring inside of GitLab, falls under Josh's responsibility. If a customer wants to monitor particular data or see this improved, speak to Joshua.

Prometheus shipped with GitLab 8.16. The Prometheus Team is tasked with:

Delvering out-of-the-box monitoring and alerting features for applications, including GitLab Improving Prometheus open source project to support that goal Helping other groups, such as infrastructure and UI/UX, instrument and gather data

Build

Build is all about how we ship GitLab and make sure everyone can easily install, update and maintain GitLab. This includes:

GitLab stack. This includes (but is not limited to): gems with native extensions,

Stan Hu

Geo

Fabio Busatto

CI/CD

Fabio handles anything related to CI and CD within GitLab. If a customer would like to see build artifacts improved, speak to Fabio.

Job

about.gitlab.com

Job

Technical Writing

The Technical Writing team is responsible for:

We are there to assist developers in their documentation writing process by providing copy editing and reviewing services and are not responsible for writing the first draft of documentation for new or updated features.

We will maintain and improve the overall health of documentation e.g. by creating topic index pages, improving organization and creating tutorials.

We manage our documentation tasks for CE and EE on the following issues boards which track labels beginning with docs-:

Job van der Voort - High level and process

Contact Job for any questions about the strategy of product or process within product.

How to work as/with product

At GitLab, the PM leads their specialization. That is, the Platform PM decides what is being worked on by the platform team in which release and makes sure this furthers our goals. This includes bugs, features, architectural changes.

The PM can't be expected to parse every single bug, issue that comes by, so they will 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 resources 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 scoping, design and decisions on 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 best equipped to make this prioritization, keeping in mind all goals of GitLab.

Example: A customer has a feature request

If you hear a feature request from a customer, you should follow the normal procedure: you create an issue, label it correctly. Let's say the customer requests an enhancement to Issues. You know by reading above that you'll have label this with Discussion and you can mention or reach out to Victor to expedite this if warranted.

Salesperson for organizations asking for Enterprise Edition feature request, shall work with product manager to arrange conversation to further explore feature request and desired outcome. The process will be:

Example: Many support requests come in about a bug with CI

Same as before, make sure an issue is made and make your case with Mark on that this is becoming a problem and needs to be fixed. Mark will make sure that this is fixed or resolved in some other way.

Example: I think create new files is slow

Everything in GitLab should be fast and creating files falls under the repository, so you create an issue and make Mike aware of it by mentioning it.

Mike 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.

Communication

Goals of Product

Everyone at GitLab is involved with the product. It's the reason why we are working together.

With every release of GitLab, we want to achieve each of the following goals.

  1. Improve GitLab's existing tools.
  2. Achieve our vision of a complete toolset.
  3. Make our product more interesting for our customers through Products and EE exclusive features.

Scope of responsibilities

The product team is responsible for iteration on most of GitLab's products and projects:

This includes the entire stack and all its facets. The product team needs to prioritize and weigh bugs, features, regressions, performance, but also architectural changes and other changes required for ensuring GitLab is excellent.

Product at GitLab

GitLab is designed and developed in a unique way.

The direction for the GitLab product is spelled out on the Direction page. This document provides lessons and heuristics on how to design changes and new features. Our iterative process is demonstrated in a blog post.

Much of our product philosophies are inspired by Ruby on Rails doctrine of 'Rails is omakase'. I highly suggest reading these.

TL;DR

  1. Minimally Viable Change: Work in iterations by implementing only the minimally viable change.
  2. Convention over Configuration: Avoid configuration and make it work out of the box.
  3. Be Ambitious: do things no one else is doing.
  4. Do not mess with Flow: frictionless from idea to production. Avoid adding clicks.

Product Core Values

The Minimally Viable Change

Reduce every change proposal to its very minimally viable form. This allows us to ship almost anything within a single release, get immediate feedback and avoid deep investments in ideas that might not work. Other advantages:

Virtually every feature must be maintained forever. (The standard of sunsetting a feature is very high.) Creating a new feature means that you incur the technical, design, and product costs of maintenance and compatibility forever. 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.

Despite its minimal form, the change

Convention over Configuration

Prefer choices that are well thought out, based on current best practices. Avoid unnecessary configuration.

For example, when considering adding a checkbox or two radio boxes, think really hard what users really want. Most of the time, you'll find you really only need one solution, so remove the option. When two possible choices really are necessary, the best or most common one should be default, and the other one should be possible. If the non-default choices are significantly less common, then consider taking them out of the main workflow for making decisions such as putting them behind an Advanced configuration tab.

Every configuration in GitLab multiplies its complexity, which means the application is harder to use, harder to develop, and less friendly to its users.

Making features configurable is easy and lazy. It's a natural reaction to propose a big change to be configurable, as you worry it'll negatively affect certain users. However, by making a feature configurable, you've now created two problems.

Work on solutions that work for everyone, that replace all previous solutions.

Sometimes configuration is inevitable or preferable. GitLab should work perfectly right out of the box for most users. Your configuration can't make that experience worse and should always get out of the way of the user.

Encouraging behavior

Convention also implies that we're encouraging our customers to do things in a certain way. A very concrete example of this is the ability to disable pipelines.We believe that our integrated solution will give a superior user experience and we're motivated to encourage behavior. For this reason, adding a configuration to be able to disable this permanently (be that in template or instance-wide), is something that should be avoided.

Encourage favorable behaviors by limiting configuration.

Default to ON

In addition to encouraging behavior by limiting the ability to toggle features, when introducing new features default to turning things ON if they are configurable at all.

Deciding on configurations

Avoiding configurations is not always possible. When we do have to make this choice, the second order of preference is to configure something in the GitLab interface. Only as a last resort should a configuration appear in file (gitlab.rb or gitlab.yml).

Configuration in file

There are two major configuration files available in GitLab. It should be avoided to add new configurations to either.

When you have to add new configuration, make sure that the features and services are on by default. Only add a configuration line to either of this configuration files if the feature or service cannot be fully disabled from the admin UI.

Convention over configuration is also listed in the CONTRIBUTING file in GitLab's repositories.

Be Ambitious

Many crazy, over-ambitious ideas just sound like they are impossible because no one else is doing them.

Because we have amazing engineers and a culture of shipping a minimally viable change, we are able to do a lot more 'impossible' things than other people.

That's why we're shipping merge conflict resolution, why we shipped built-in CI before anyone else did it, why we built a better static pages solution, and why we're able to compete.

Simplicity

Doing something simple in GitLab should be simple and require no human cpu-cycles to do so. Things that are simple now, should be simple in two and ten years.

This sounds obvious, but messing with Flow is easily done. In most cases, flow is disrupted by adding another action, another click.

For instance: You want users to be made aware of the rules of a project. Your proposal is a little popup that shows the rules before they create an issue. This means that every time that someone creates an issue they need to click once before resuming their normal action. This is unacceptable. A better solution is to add a link to the issue that points the user to this.

It's very hard to maintain flow with a lot of configurations and options. In cases where you want to enforce certain behaviour, the most obvious step is to add another step or action. This can be avoided by making the action work in parallel (like a link in the issue), encouraging rather than enforcing certain behaviours.

We don't want users to be able to construct workflows that break GitLab or make it work in unpredictable ways.

Banners

There are several banners in GitLab, often used to highlight new features or a particular action we want a user to do. These very quickly become annoying, therefore:

  1. Never show a banner again after dismissing it. Dismissals should be saved in the database.
  2. In case of feature highlighting: Empty states should be used over banners whenever possible, because they are actionable and only applicable before usage.
  3. Never use banners to replace good UI or onboarding experiences: if a feature is not being seen or used, it's unlikely to be due to the lack of a banner.

Prioritization

As this document and the direction page will show you, there are a million things we want to do, so how do we prioritize between them and schedule anything in particular? Roughly speaking, we balance the following priorities:

  1. Security fixes
  2. Data-loss fixes
  3. Regression fixes (things that worked before)
  4. Performance fixes
  5. Technical debt fixes
  6. Other fixes
  7. New features

Any new feature will have to meet the following requirements:

  1. It is technically viable
  2. 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)
  3. It is orthogonal to other features (prevent overlap with current and future features)
  4. Are the requirements are clear?
  5. 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.

New features are prioritized on a couple of dimensions:

Every release of GitLab has to be better than the last. This means that bugs, regressions, security issues and necessary performance and architecture changes always take up the capacity they require to ensure GitLab remains stable, secure and fast.

We hope to realize our vision, while make sure we're building things our customers want. In practice this means we aim to ship one or more features that preferably fit within our vision, but also solve problems our customers have. These features bring the product forward, and build value for the largest group of people possible. E.g. issue relationships is a highly requested feature and one that fits neatly within our vision. Everyone will benefit from this.

In practice, it is not always possible to only ship things that strictly fall within our vision. Other changes are prioritized and scheduled based on demand. An example would be a specific form of authentication that is only used in particular organizations. This is not a big win to all our customers, but if it's not too much work can be very big win to a subset of customers. Demand can also come from internally, such as things that'll help achieve goals within the team or specifically drive business goals, such as particular EE features.

We take all priorities in account when planning and schedule larger initiatives across the teams (such as: we're integrating CI: everyone has to contribute to this in some way), but most changes are scheduled on team-level (make issues faster; add a new way to schedule pipelines).

Example

To make it concrete with an example, the CI/CD team might ask:

Milestones

We schedule an issue by assigning it a milestone; for more on this see Planning a Future Release.

Naming features

Naming new features or renaming existing features is notoriously hard and sensitive to many opinions.

Factors in picking a name

Process

Renaming

The bar for renaming existing features is extremely high, especially for long-time features with a lot of usage. Some valid but not exclusive reasons are:

Performance

Fast applications are better applications. Everything from the core user experience, to building integrations and using the API is better if every query is quick, every page loads fast. When you're building new features, performance has to be top of mind.

We must strive to make every single page fast. That means it's not acceptable that new pages add to performance debt. When they ship, they should be fast.

You must account for cases where someone has thousands of objects or just a single.

Of course, you must prioritize improvements according to the impact. Pages that are often visited should be prioritized over pages that have rarely any visitors. However, as page load time approaches 5 seconds or above, they are no longer useable and should be fixed at the earliest opportunity.

For a detailed in-depth performance overview, see the engineering performance page.

Alpha, Beta, GA

Occasionally we want to test large, complex features without having the confidence that we'll be able to scale, support and maintain them as they are. In this case we have the option to release them as Alpha or Beta.

In general, we should avoid releasing Alpha and Beta versions of features. A minimally viable change should be viable and therefore not need a pre-release. That said, if it comes to be that we have no valid alternative, below the definitions of each stage.

It's never acceptable to make changes that can damage existing production data available to our users.

Alpha

Beta

Generally Available (GA)

Deprecating features

Deprecating features (changes) follows a particular pattern. Use the language Discouraged (maintained), Deprecated (not maintained) or Removed to specify the state of a feature that is going to be or is removed.

Features that are discouraged, deprecated or removed should be:

  1. Labelled accordingly in the documentation
  2. Labelled accordingly in the application

Features that are Deprecated or Removed should be removed from marketing pages.

Discouraged (maintained)

Deprecated (no longer maintained)

Removed

How to work as a PM

If you follow the guidelines above, you won't be writing long, detailed specs for a part of the product for the next year. So how should you be spending your time?

Invest the majority of your time in understanding the problem deeply (say 70%). Then spend 10% of your time writing the spec for only the first iteration and handling comments, while the remaining 20% you work on promoting it.

A problem you understand well will 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 on 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 need to set the bar for engineering; 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. 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 without your direct intervention. It's your job to make sure something is decided and planned, not to come up with every idea or change.

Dogfood everything

The best way to understand the pain of the users is to go through what we ask them to do while setting up or using GitLab. As a PM, you should go through every feature, at the minimum the ones you are responsible for. All of them. That includes features that are not in GitLab's UI directly but require server configuration. If you, as a PM, can't understand the documentation or struggle to install something, who else would even bother to do it? Going through this is not only beneficial to understand what the pain points are, it will also tell you what you can enhance, from a better flow to a better documentation.

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 to add a new UI 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 if you can.

Product Workflow

Almost everything that we do is documented in an issue.

How to submit a new issue

  1. If you have time, the first thing you should do is search both CE and EE projects if a similar issue already exists. We shouldn't create duplicates if we can avoid them.
  2. Identify if the issue is about GitLab Community Edition (CE) or GitLab Enterprise Edition (EE), although this can easily be changed later.
  3. You should clearly state what the current pain point is, what we are trying to solve, what the benefits will be, what it should do, how to accomplish that and the next steps.
  4. The issue's body should be written in a clear way, without ambiguity.
  5. If the body of the issue contains too many paragraphs, it can surely be rewritten to be shorter.
  6. Do not use acronyms or abbreviations. Everyone should be able to jump on the issue and participate without needing a glossary.
  7. Choose which labels are relevant to the issue. If you are unsure about what certain labels are for, head up to the Labels page (CE or EE) and read the descriptions. The Engineering handbook provides good hints on how to choose the right label.
  8. 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
  9. Mention the different stakeholders in the body of your issue. In most product related issues, we usually mention the product manager, the design lead (if needed), and the frontend and backend leads as appropriate. Some teams have experts or liaisons that can be mentioned instead of the leads. Mentioning the people in the body 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).

Wireframes

When relevant, you can include a wireframe in your issues in order to illustrate your point. You don't need to include wireframes per se - our UX/design team can help us on that matter. Simply ping them if you need their help. We like Balsamiq for its simplicity and its sketch-y approach. If you don't have inspiration, you can also paste screenshots of similar features in other products.

What is a Meta issue?

Meta is a label assigned to issues that contain a large list of todos. If you are familiar with the Agile methodology, it's similar to an epic. At GitLab we have a short release cycle: the 22nd of every month. In some cases we won't be able to tackle all the tasks of a meta issue in a single release - this is why we centralize all the things that we need to do in a meta issue, then break it down to issues small enough that they will fit into one release. Most of the time, meta issues generate lots of comments and passionate discussions. As a consequence, they always lead to something great.

Meta issues themselves generally should not be assigned to a milestone as the actual work is expressed in sub-issues. Sometimes, if you want the meta issue to show up in our direction page with a given release, you may want add a milestone, but only if you know for sure that all sub-issues will be completed by that milestone. Don't assign a milestone for when you're going to start the meta issue.

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 in multiple issues.

Meta/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 to make sure we stick to our values of the minimally viable change.

The above means that feature issues should be closed after a first iteration whenever possible. We'll know more in the future and this keeps remaining issues short and actionable.

In addition, it's almost never a bad idea to throw away an original plan and start fresh. Try to do this more often than you're comfortable. Close the issue and create a new one.

Which issue should you be working on?

When you don't have specific tasks assigned, you should work on issues that are labeled Product work, in both EE and CE projects. These are issues that need our attention the most.

Feature assurance

Before a new features is shipped, the PM should test it out to make sure it effectively solves the original problem. This is not about quality assurance (QA); developers are responsible for the quality of their code. This is about feature assurance (FA). Feature assurance is necessary because sometimes there are misunderstandings between the original issue proposal and the final implementation, sometimes proposals that seem like they would solve the problem actually don't, and sometimes solutions just don't feel as good when 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 convenient 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 you can so any new issues can be addressed before final release. Also, take the FA cycle into account when scheduling new milestone work.

Managing Upcoming Releases

Refer to the 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

Product Managers assign milestones to issues to indicate when an issue is likely to be scheduled and worked on. As we consider farther out milestones, the certainty of the scope of their assigned issues and their implementation timelines are 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. If the plan changes, the milestone should be updated as soon as possible to reflect that changed plan.

Approximately, closer-to-current-time milestones are assigned to issues that are higher priority. The times also reflect an approximate product roadmap, with further out milestones reflecting increasing uncertainty.

The milestones are:

These assigned milestones should be used as a signal for GitLab stakeholders and collaborators (especially UX and Engineering) to help them with their own respective workflows.

In addition we have a Backlog milestone. Product Managers assign this milestone to issues that they think make sense in the product, but don't have yet a clear timeline of when it should be worked on. Again, a milestone of an issue can be changed at any moment, including the Backlog milestone.

We make sure to do this ahead of starting to work on a release. Capacity is discussed between the PMs and the engineering leads.

For a detailed timeline, see the product development timeline.

Content of an MVP

We only ship in a Minimally Viable Product mode. Here are some guidelines about it:

When to create or close an issue

You should create an issue if:

You should consider not creating an issue when:

Close issues that are either:

  1. duplicated elsewhere.
  2. no longer relevant due to other reasons.
  3. 'not the next iteration': an iteration on a proposed feature that is unlikely to ship in the next few months.

When closing an issue, leave a comment with why you're closing the issue and link to anything of relevance (the other duplicate, the original feature that this is an iteration on).

The 'not the next iteration' is the most important one to resolve. It is very easy to create a big plan with meta issues and lots of 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 listen for the feedback. As a product manager you think about the bigger picture when making a proposal to improve the product. The important thing is to not write this down is a bunch of issues. Think of a plan but only record the first step. This we we can preserve the efficiency of our value of iteration. Closing issues whenever possible is an important part of your job and helps to keep a good overview of what is next. Consider using the following template to close the issue:

Closing this because XXX is something we should do first. If that feature is done we can learn from having that being used. If we learn that this is still relevant we can then reopen it. See https://about.gitlab.com/handbook/product/#when-to-create-or-close-an-issue for more detail about this policy.

Competition Channel

When someone posts information in the #competition channel that warrants creating an issue and/or a change in features.yml, follow this procedure:

Where should you look when you need help?

Shipping

Internal and external evangelization

Before shipping a new or updated feature, you are responsible for its evangelization, both internally and externally. When something is released, the following teams need to be aware of it as they will all need to do something about it:

You can promote your work in several ways:

GitLab University

To promote a major new feature internally, you can ask to host a GitLab University, a company wide demo session. This is a great opportunity to make sure every one is on the same page.

Major feature rollout

Major features deserve proper attention from product and marketing. With a proper rollout, we'll have ample marketing opportunities and receive more feedback ahead, during and after the release.

Here is the ideal rollout schedule. For each step, there is the indication about who is responsible for it.

  1. Feature is drafted in an issue (PM)
  2. Feature is planned in an upcoming release (PM)
  3. A feature proposal blog post is made (PM or Dev), where we'll describe
    • What we are planning on doing,
    • How you'll be able to buy it: CE or any EE Editions,
    • Link to the issue,
    • When it'll be available, if possible,
    • Anything else that is interesting to share in order to fuel the discussion.
  4. Feature is implemented, documentation is written (Dev).
  5. Feature should appear on the website (Marketing)
    • For very significant features: Feature page on the website is made and pushed, with the mention "Available from X.X"
    • For other features: Feature should be listed on some page (/comparison, Enterprise page, /features page).
  6. Feature is launched with the release (Marketing)
    • "Available from X.X" is removed
    • Documentation and other resources are linked
    • Pricing page is updated if needed
  7. Feature is highlighted in a blog post (Marketing)
    • This post is linked from the feature page on the website (if applicable)

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. Worst, if you reject an idea too harshly, you might discourage other people to contribute, which is something we want to avoid.

However, as the number of issues and merge requests grow more and more, we should be diligent about rejecting features we are sure will not do. It's better for everyone: for the product team so we don't maintain a huge backlog of things we will not 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:

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.

Responsibilities and Expectations

As a PM you're expected to:

Customer meetings

It's important to get direct feedback from our customers on things we've built, are building or should be building.

As a PM you should have regular meetings with customers that are using the things you've been working on and with customers that are not - in order to get an idea of why they're not switching to our solution.

Set up a meeting

To setup a customer meeting, identify what you're interested in discovering 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 a customer.

There is no formal internal process to schedule a customer meeting, if that need arises, we can formulate one.

During and after

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 tell more about our products.

After the meeting, make sure all your notes and feedback lands in issues.

Marketing materials

As a PM you're responsible for making sure changes you've shipped are well represented throughout GitLab's documentation and marketing materials. This means that on release, features.yml is updated, documentation is merged and deployed, and any existing content is updated where necessary.

It's not acceptable to do this after the release. GitLab is very complex and features and functions are easily missed, even those that provide significant value to customers (e.g. the many ways you can authenticate with GitLab).

You can recruit the help of the marketing and technical writing team if needed, but it's highly recommend to do small updates yourself. This takes less time and overhead than communicating what needs to be done to someone else.

Enterprise Edition Tiers

There are two EE tiers: Starter and Premium. In the future we'll introduce Ultimate.

EE Starter features are more relevant for organizations that have more than 100 potential users.

EE Premium features are more relevant for organizations that have more than 750 potential users.

EE Ultimate features are more relevant for organizations that have more than 5000 potential users.

Deciding on whether something should be a Premium feature or just a EE-only feature can be tough. In doubt, make it a Premium feature, that's a reversible option, whereas the alternative is not.

Talking about EE only decisions

When talking about why a certain change is limited to Enterprise Edition in public, mention the stewardship paragraph in the about page directly and link to it.

EES and EEP requirements

All EES and EEP features should:

Designing features for Enterprise Editions

To make it possible to ship a feature for Enterprise Edition, ideally the code is completely separate. I.e. the frontend and backend of the feature only exist in the gitlab-ee project. However, this is not always possible.

In cases where it's preferable to have the backend code live in the gitlab-ce repository, it's acceptable to only ship the frontend for the feature in EE. In practice this makes the feature EE-only.

GitLab.com

GitLab.com runs GitLab Enterprise Edition.

To keep our code easy to maintain and to make sure everyone reaps the benefits of all our efforts, we will not separate GitLab.com codebase from EE.

To avoid complexity, GitLab.com subscriptions and GitLab EE tiers have a 1:1 match. No exceptions to this rule are acceptable.

Because we are not able to give admin access and do not yet have full feature parity between a self-hosted instance and GitLab.com, we avoid saying that there is a one on one match between subscriptions levels and tiers in marketing materials. This has been the cause of confusion in the past for customers.

Restriction of closed source Javascript

In addition, to meet the ethical criteria of GNU, all our javascript code on GitLab.com has to be free as in freedom. This is why we moved to Piwik, over Google Analytics. Read more about this on GNU's website.

Private tools and dashboards for monitoring and KPI tracking

EE usage: dev.gitlab.org account

Grafana: Google gitlab.com account

Kibana: dev.gitlab.org account

LogTrail: dev.gitlab.org account

Piwik: GitLab 1Password account

S3stat: GitLab 1Password account

Sentry: dev.gitlab.org account

Writing about features

As PM we need to constantly write about the features we ship: in a blog post, internally to promote something, in emails sent to customers.

While we want every PM to have his unique voice and style, there are some guidelines that one should take into account when writing about features. Let's highlight them with a concrete example, Preventing Secrets in your repositories, that we've shipped in 8.12.

It's a bad idea to commit secrets (such as keys and certificates) to your repositories: they'll be cloned to the machines of anyone that has access to the repository, only one of which has to be insecure for the information to be compromised. Yet it happens quite easily. You write git commit -am 'quickfix' && git push and suddenly you've committed files that were meant to stay local!

GitLab now has a new push rule that will prevent commits with secrets from entering the repository.

Just check the checkbox and GitLab will prevent common unsafe files such as .pem and .key from being committed.

Writing release blog posts

For every monthly release, there is a blog post announcing features. The blog post should contain anything exciting or disruptive. All new features should appear in the blog post. We want to help people understand exciting features (which are often new), and increase adoption. Disruptive features may change workflows or even introduce unavoidable inconveniences. We want to anticipate questions and avoid confusion by communicating these changes through the blog post. Smaller tweaks and bug fixes don't necessarily need to be mentioned, but if interesting, can be included at the bottom of the post.

This page is generated from a public file on GitLab.com — merge requests with improvements are very welcome. Creative Commons License