Customer 0

What is Customer 0?

Customer 0 means that internal team members act as first customers for new features. It is our model of collaboration throughout the development and launch of new features to validate their usability and value before broad release. It includes requirements delivery, validation of intended functionality and mockups, and alpha/beta testing.

Every feature we are building that targets an audience that can be represented by a group of GitLab team members and that matches their needs, must be shipped to a level of quality that we would want to use ourselves.

For that to have the highest possible business impact, we need to ensure that the way we work is either the same as how our customers use our product, or that we need to help our customers benefit from the way we work. The solutions we build for ourselves should also be incorporated into our product, and ideally not require extra work from the customer.

Due to the fact that we already have workarounds in place for our teams to circumvent shortcomings in our product, teams also will have to critically evaluate whether Customer 0 feedback or requests might be consequences of these teams using existing workarounds, or us not following DevSecOps best practices.Teams have to ensure that new features can be used without relying on existing or creating new workarounds.

Existing workarounds can also be a great signal for unmet needs from Customer 0. If we build extra tooling or processes around our product, that investment of time and effort is a strong indicator that teams have an unmet need that our platform does not deliver on yet.

Customer 0 & dogfooding

There is a lot of overlap between Customer 0 and dogfooding. In both models, feedback from team members about value, usefulness and usability of features we are actively building should inform our product, design and engineering choices.

The main difference is what moment of the product development flow a feature is in: While the Customer 0 model is relevant for the ideation, development and launch of new features, dogfooding takes over once these features are part of our product.

What it means to be a “Customer 0”

Obligations

• All product features must solve an internal use-case/demand first unless it meets a unique strategic advantage and is done in partnership with a particular customer/market vertical.
• All team members should act as Customer 0 and use the product with the intent of ensuring that it aids in doing their job efficiently and meets the quality bar that our customers can easily gain value.
• Customer 0 must surface unmet user needs and propose feature requests based on hands-on use and experience before the initial launch. This should include details of the use case, need, and expected functionality.
• If Customer 0 anticipates having to use/create a workaround due to shortcomings of the product once it’s launched, there is an open issue that they regularly monitor and will plan to migrate to internal functionality when resolved.

Process

• Customer 0 requests will be triaged by the stage group teams owning that part of the experience.
• Customer 0 works directly with these teams to help validate the prevalence and severity of those unmet needs.

Awareness

• In line with our Product Principles, Customer 0 recognises that we are not a replacement of actual customers, nor can we fully represent the diversity of customer experiences. However, our internal use cases are a helpful informant and early indicator of value.

Resources

The Secure stage and Product Security team have been piloting the Customer 0 approach together. As part of that effort, they created 4 templates for Product Managers and Product Designers to request Customer 0 feedback.