Product

As everything at GitLab, this document is forever in draft. Merge requests are very welcome. Infographics from xkcd.

Table of contents

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.

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.

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:

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.

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.

Do not mess with Flow

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.

Alignment

Balancing our great ambition with our dedication to customer success is tough. Add in a growing number of dedicated teams focusing on areas of the product, and it becomes challenging to make sure everything we work on is truly the right thing to work on, right now. To help with that, it's good to keep a few things in mind. To ask a few questions to keep us all aligned.

At a high level, you can think of aligning along these dimensions (not necessarily in priority order):

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

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

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 (EE) 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. 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.
  5. 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
  6. Mention the different stakeholders in the body of your issue. In most product related issues, we usually mention the product team members, either the frontend or the backend lead and sometimes the cofounders, as what we do impact the product most of the time. 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. Meta issues generate most of the time lots of comments and passionate discussions. As a consequence, they always lead to something great.

Note: smaller tasks that are part of a meta issue are sometimes also labeled meta. That's because they are part of a meta topic, and thus get the meta label.

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

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.

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:

Continuous Integration (CI)/Continuous Deployment and Delivery (CD)

For more insights into our vision on Continuous Integration and Continuous Deployment & Delivery, see the CI/CD page.

EE only and Products

Products are large additions to GitLab that we sell separate to GitLab Enterprise Edition customers.

EE only features are exclusive to GitLab Enterprise Edition, but don't require any additional purchases besides GitLab EE.

EE only or Product?

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

Also consider:

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.

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.

Links