GitLab Package: JTBD

Overview

The goal of this issue will be to create and iterate on the Jobs to be Done and their corresponding job stories for the package stage. Our goal is to utilize the jobs theory to better understand our buyers' and users' needs.

As part of the product development workflow, we will select prioritized job stories for problem and solution validation. We will then move the validated solutions to the build track, and launch the feature. Each quarter, we will select key JTBD and job stories for user experience testing.

Goals

  • Utilize JTBD and job stories to:
    • Understand our users' motivations
    • Validate identified use cases and solutions
    • Continuously test and iterate features to ensure we are meeting our customers' and users' needs.
  • Create a transparent view for our stakeholders into the current and future state of the product.

Challenges

  • Most customers do not purchase GitLab solely for the Package stage. So, there will be assumptions in the JTBD that from the buyer's perspective, the motivations for 'buying' Package are the same.
  • There may be many job stories that need to be validated. We will need a good way of deciding which to bring into the validation track.

JTBD

I purchased GitLab, so that I can consolidate the entire DevOps lifecycle in a single application.

I as a Buyer, when I am evaluating GitLab's Package Registry, I want to ensure that enough of our use cases are covered, so I can stop paying for and maintaining other package management solutions.

  • I need to understand when I can stop paying for my package management tools.
  • I need to understand what has to be true for me to use GitLab's package registry and cancel the other service.
  • I need to understand how GitLab's product compares to what my team is currently using.
  • I need GitLab to support all of my organization's package managers, so I can fully migrate to GitLab.

I as a Systems Administrator, when my organization has decided to use GitLab's, need an easy way to migrate to their Package Registry, so that I can tell my boss that the migration has been completed successfully.

  • I need to understand how migration from the other solution to GitLab works.
  • I need one team to migrate from their existing package management solution to GitLab and tell me how it went.
  • I need to understand the status of the migration and maybe how long it is taking.
  • I need all of my development teams to migrate to GitLab.
  • I need to know when the migration is complete, so that I can cancel the other service.

I as a Developer, when I have been asked to use GitLab's Package Registry, need the ability to easily understand which features exist and how to use them, so that I can understand if it's possible to migrate off of my existing workflows.

  • I need a quick an easy way to create and publish my first package.
  • I need an easy way to test building works with pipelines.
  • I need authentication to work, every time.
  • I need to understand how to troubleshoot problems when something goes wrong.
  • I need access to help when I am first getting started.
  • If I can't migrate because of a lack of features, I need to be able to show my boss what's missing and when it will be done.

I need the GitLab Package Registry to work reliably, so I don't have to think about something else.

I as a Developer, now that I am using the GitLab Package Registry as part of my production code, need the ability to reliably build packages, so that I can deploy my code in a timely manner.

  • I need to be able to deploy packages using the command line or my pipelines.
  • I need to know when a package was built successfully.

I as a Developer, need the ability to confirm that I am using the correct version of a package, so that I can ensure my code is correct.

  • I need the ability to verify it was built with the correct branch/version.
  • I need to check the version number.
  • I need the ability to understand the difference between versions.
  • I need to know when the version was created and last updated.
  • I need a way of marking a package as validated or approved, so I can easily find it next time.

I as a Developer, need the ability to troubleshoot why a package was not built correctly, so that I can quickly get back to coding.

  • I need to see a list of common issues, so I can understand if it's my fault or not.
  • I need clear, easy to find error messages.
  • I need to understand what code/pipeline is responsible for a given package.
  • I need to understand any additional external dependencies.
  • I need a way of documenting what changes I made to a given package, so I can ensure I don't forget.
  • I need a way of documenting issues, so that I can work on low priority issues later.

I need to make sure that my organization is working efficiently and safely

I as a Development Lead, need visibility into how my team is working, so that I can ensure they are working efficiently and not blocked.

  • I need to understand which packages are being used and by which projects.
  • I really need to ensure no one is using the incorrect version of a package.
  • I need to understand if there are any critical issues or vulnerabilities with a given package.
  • I need to see my org's most commonly used packages, so I can find them easily and share them across teams.

I as a System Administrator, need to maintain a tidy environment, so that I can reduce errors and risk.

  • I need the ability to create shared 'golden packages' that are approved for use by all teams.
  • I need to know which packages are not being used and have the option to delete them.
  • I need the ability to apply policies to expire/retain old packages.

I as a Systems Administrator, need the ability to understand if any security violations are being introduced into my organization's code, so that I can remediate them before they cause any problems.

I want a cheaper DevOps solution.

I as a Systems Administrator, need the ability to understand how much GitLab's Package Registry is costing me, so that I can set reasonable budget expectations

  • I need to know how much storage I am using.
  • I need to limit the amount of users created, and ensure they are all real people.

I as a Systems Administrator, need the ability to reduce storage costs for the Gitlab Package Registry, so that I can come in under budget.

  • I need the ability to set project/group/instance quotas.
  • I need the ability to create/execute policies for enforcing those quotas.
  • I need to know when a project or user has exceeded their quotas.
  • I need to understand my costs relate to my budget.

I use GitLab because I want to support the open source project.

I as a Community Member, want an easy way to discover Package issues that are good candidates for community contribution, so that I can understand the best way to contribute.

  • I need documentation for common changes, like documentation or user interface.
  • I need documentation and best practices for making bigger changes, such as adding a new package manager format.
  • I need to understand the best way to interact/ask questions of the GitLab Package team.
  • I want to feel like my contribution is valuable and useful.
Edited by Tim Rizzi