Skip to content
Snippets Groups Projects
Commit 14f88a89 authored by Kamil Niechajewicz's avatar Kamil Niechajewicz :palm_tree:
Browse files

Moved Growth engineering back to Development and updated links

parent f5e233c3
No related branches found
No related tags found
1 merge request!7276Moved Growth engineering back to Development and updated links
Showing
with 27 additions and 24 deletions
...@@ -148,6 +148,7 @@ ...@@ -148,6 +148,7 @@
/content/handbook/engineering/development/fulfillment/fulfillment-platform.md @jameslopez @ofernandez2 /content/handbook/engineering/development/fulfillment/fulfillment-platform.md @jameslopez @ofernandez2
/content/handbook/engineering/development/fulfillment/provision.md @isandin @courtmeddaugh /content/handbook/engineering/development/fulfillment/provision.md @isandin @courtmeddaugh
/content/handbook/engineering/development/fulfillment/utilization/ @csouthard @alex_martin /content/handbook/engineering/development/fulfillment/utilization/ @csouthard @alex_martin
/content/handbook/engineering/development/growth/ @kniechajewicz
/content/handbook/engineering/development/ops/ @sgoldstein @cheryl.li @nicolewilliams @crystalpoole /content/handbook/engineering/development/ops/ @sgoldstein @cheryl.li @nicolewilliams @crystalpoole
/content/handbook/engineering/development/ops/deploy/ @nmezzopera /content/handbook/engineering/development/ops/deploy/ @nmezzopera
/content/handbook/engineering/development/ops/monitor/observability.md @nicholasklick @mappelman /content/handbook/engineering/development/ops/monitor/observability.md @nicholasklick @mappelman
...@@ -365,7 +366,6 @@ ...@@ -365,7 +366,6 @@
/content/handbook/marketing/emergency-response.md @akramer @rkohnke @amy.waller /content/handbook/marketing/emergency-response.md @akramer @rkohnke @amy.waller
/content/handbook/marketing/events/ @akramer /content/handbook/marketing/events/ @akramer
/content/handbook/marketing/growth/ @akramer @gdoud /content/handbook/marketing/growth/ @akramer @gdoud
/content/handbook/marketing/growth/engineering/ @kniechajewicz
/content/handbook/marketing/inbound-marketing/ @akramer /content/handbook/marketing/inbound-marketing/ @akramer
/content/handbook/marketing/inbound-marketing/search-marketing/ @ncregan @hsmith-watson @akramer /content/handbook/marketing/inbound-marketing/search-marketing/ @ncregan @hsmith-watson @akramer
/content/handbook/marketing/inbound-marketing/search-marketing/analytics.md @akramer /content/handbook/marketing/inbound-marketing/search-marketing/analytics.md @akramer
......
...@@ -16,7 +16,7 @@ as well our own [areas of responsibility](/handbook/marketing/growth/#product-ow ...@@ -16,7 +16,7 @@ as well our own [areas of responsibility](/handbook/marketing/growth/#product-ow
## Direction ## Direction
We work on the issues prioritized by our product teams including running [experiments](/handbook/marketing/growth/engineering/experimentation/) on GitLab.com. We work on the issues prioritized by our product teams including running [experiments](/handbook/engineering/development/growth/experimentation/) on GitLab.com.
More information on priorities can be found on the [Growth direction](/handbook/marketing/growth/) page. More information on priorities can be found on the [Growth direction](/handbook/marketing/growth/) page.
Growth stage teams have Fullstack Engineers. Growth stage teams have Fullstack Engineers.
...@@ -33,7 +33,7 @@ Some useful links to see how and what we are working on include: ...@@ -33,7 +33,7 @@ Some useful links to see how and what we are working on include:
- [acquisition](acquisition/) group - [acquisition](acquisition/) group
- [activation](activation/) group - [activation](activation/) group
Growth teams contribute to a GitLab [experimentation](/handbook/marketing/growth/engineering/experimentation/) gem to make it easier to run experiments and make data driven product decisions on GitLab.com. Growth teams contribute to a GitLab [experimentation](/handbook/engineering/development/growth/experimentation/) gem to make it easier to run experiments and make data driven product decisions on GitLab.com.
## Roadmap ## Roadmap
......
...@@ -75,6 +75,6 @@ for work in the [build phase](/handbook/product-development-flow/#build-track) o ...@@ -75,6 +75,6 @@ for work in the [build phase](/handbook/product-development-flow/#build-track) o
## Common Links ## Common Links
- [Growth Stage](/handbook/marketing/growth/engineering/) - [Growth Stage](/handbook/engineering/development/growth/)
- [Acquisition issues](https://gitlab.com/gitlab-org/growth/product/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aacquisition) - [Acquisition issues](https://gitlab.com/gitlab-org/growth/product/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aacquisition)
- `#g_acquisition` in [Slack](https://gitlab.slack.com/archives/g_acquisition) (GitLab internal) - `#g_acquisition` in [Slack](https://gitlab.slack.com/archives/g_acquisition) (GitLab internal)
...@@ -71,6 +71,6 @@ We use the Activation development [workflow board](https://gitlab.com/groups/git ...@@ -71,6 +71,6 @@ We use the Activation development [workflow board](https://gitlab.com/groups/git
## Common Links ## Common Links
- [Growth Stage](/handbook/marketing/growth/engineering/) - [Growth Stage](/handbook/engineering/development/growth/)
- [Activation issues](https://gitlab.com/gitlab-org/growth/product/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aactivation) - [Activation issues](https://gitlab.com/gitlab-org/growth/product/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aactivation)
- `#g_activation` in [Slack](https://gitlab.slack.com/archives/g_activation) (GitLab internal) - `#g_activation` in [Slack](https://gitlab.slack.com/archives/g_activation) (GitLab internal)
...@@ -60,7 +60,7 @@ There are additional rollout plan processes to keep yourself aware of: ...@@ -60,7 +60,7 @@ There are additional rollout plan processes to keep yourself aware of:
* [Rolling out a low-risk feature flag](/handbook/product-development-flow/feature-flag-lifecycle/#rollout) * [Rolling out a low-risk feature flag](/handbook/product-development-flow/feature-flag-lifecycle/#rollout)
* [Rolling out a high-risk feature flag](/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process) * [Rolling out a high-risk feature flag](/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process)
* [Running an experiment](/handbook/marketing/growth/engineering/experimentation/#experiment-rollout-issue) * [Running an experiment](/handbook/engineering/development/growth/experimentation/#experiment-rollout-issue)
#### Rollout plan templates #### Rollout plan templates
......
...@@ -53,7 +53,7 @@ You are encouraged to work as closely as needed with our [stable counterparts](/ ...@@ -53,7 +53,7 @@ You are encouraged to work as closely as needed with our [stable counterparts](/
Other teams that we might collaborate with include but are not limited to: Other teams that we might collaborate with include but are not limited to:
- [Govern:Authentication and Authorization](/handbook/engineering/development/sec/govern/authentication-and-authorization/) - [Govern:Authentication and Authorization](/handbook/engineering/development/sec/govern/authentication-and-authorization/)
- [Growth:Acquisition and Activation](/handbook/marketing/growth/engineering/) - [Growth:Acquisition and Activation](/handbook/engineering/development/growth/)
- [Fulfillment:Fulfillment Platform](/handbook/engineering/development/fulfillment/fulfillment-platform/#team-members) - [Fulfillment:Fulfillment Platform](/handbook/engineering/development/fulfillment/fulfillment-platform/#team-members)
Here are some examples of when to engage with your counterpart: Here are some examples of when to engage with your counterpart:
......
...@@ -18,7 +18,7 @@ gathered in Utrecht to bond but also work on finalising auto-deployment process. ...@@ -18,7 +18,7 @@ gathered in Utrecht to bond but also work on finalising auto-deployment process.
the proposal for Fast boot, and the proposal for Fast boot, and
[the Delivery Fast boot epic](https://gitlab.com/groups/gitlab-org/release/-/epics/17) [the Delivery Fast boot epic](https://gitlab.com/groups/gitlab-org/release/-/epics/17)
contains issues and links to recordings created during the Fast Boot. contains issues and links to recordings created during the Fast Boot.
* The third Fast Boot took place in Vancouver in September 2019. It included 18 people from Product, Engineering, UX and Data from the Acquisition, Conversion, Expansion and Retention teams. [The planning issue](https://gitlab.com/gitlab-org/growth/product/issues/1) contains the proposal for Fast Boot, and outcomes are available in the [Growth Fast Boot Page](/handbook/marketing/growth/engineering/fast-boot/). * The third Fast Boot took place in Vancouver in September 2019. It included 18 people from Product, Engineering, UX and Data from the Acquisition, Conversion, Expansion and Retention teams. [The planning issue](https://gitlab.com/gitlab-org/growth/product/issues/1) contains the proposal for Fast Boot, and outcomes are available in the [Growth Fast Boot Page](/handbook/engineering/development/growth/fast-boot/).
## Why should you have a Fast Boot? ## Why should you have a Fast Boot?
......
...@@ -7,7 +7,7 @@ canonical_path: "/handbook/marketing/growth/" ...@@ -7,7 +7,7 @@ canonical_path: "/handbook/marketing/growth/"
The GitLab Growth section is dedicated to making it easier for teams to find value and increased efficiency within the GitLab platform. We work across stages within the product experience to make the product as easy as possible to adopt and use. The GitLab Growth section is dedicated to making it easier for teams to find value and increased efficiency within the GitLab platform. We work across stages within the product experience to make the product as easy as possible to adopt and use.
The Growth section lives within Marketing & Strategy to ensure we're aligned in our go-to-market strategy and we're as efficient as possible in finding the right prospects, convincing them to become product users, and assisting in converting them into paying customers. Since the work within the section occurs within the product experience our engineering and user experience counterparts are within the [Development division](/handbook/engineering/development/). This approach ensures that we have proper alignment on our priorities from a go-to-market and business perspective while ensuring our [development team](/handbook/marketing/growth/engineering/) is set up for success to operate within the development division. The Growth section lives within Marketing & Strategy to ensure we're aligned in our go-to-market strategy and we're as efficient as possible in finding the right prospects, convincing them to become product users, and assisting in converting them into paying customers. Since the work within the section occurs within the product experience our engineering and user experience counterparts are within the [Development division](/handbook/engineering/development/). This approach ensures that we have proper alignment on our priorities from a go-to-market and business perspective while ensuring our [development team](/handbook/engineering/development/growth/) is set up for success to operate within the development division.
## Growth Section's Principles ## Growth Section's Principles
...@@ -71,7 +71,7 @@ The Growth section owns the following areas of the product experience. ...@@ -71,7 +71,7 @@ The Growth section owns the following areas of the product experience.
## Engineering ## Engineering
[Growth engineering](engineering/) handbook pages. [Growth engineering](/handbook/engineering/development/growth/) handbook pages.
## Growth Coffee & Learn Sessions ## Growth Coffee & Learn Sessions
...@@ -110,5 +110,5 @@ Congratulations! :tada: From now on all your PTO events will be automatically sy ...@@ -110,5 +110,5 @@ Congratulations! :tada: From now on all your PTO events will be automatically sy
### Helpful Links ### Helpful Links
* [Engineering Growth Section](/handbook/marketing/growth/engineering/) * [Engineering Growth Section](/handbook/engineering/development/growth/)
* [Growth Product Handbook](/handbook/product/growth/) * [Growth Product Handbook](/handbook/product/growth/)
...@@ -165,7 +165,7 @@ To start the Design phase, the Product Designer or Product Manager applies the ` ...@@ -165,7 +165,7 @@ To start the Design phase, the Product Designer or Product Manager applies the `
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Proposed solution(s) identified and documented**: The Product Designer works with the Product Manager and Engineering team to explore solutions and identifies the approach(es) that strike the best balance of user experience, customer value, business value, and development cost. | The Product Designer optionally apply by `workflow::ready for design` label to the issue, signaling the design backlog of next issues to be done is prioritized. <br/> <br/> **Diverge**: explore multiple different approaches as a team. Example activities: <br/>- [Think Big](/handbook/product/ux/thinkbig/) session. <br/>Internal interviews (be sure to [document findings in Dovetail](/handbook/product/ux/dovetail/)). <br/> - Creating [user flows](https://careerfoundry.com/en/blog/ux-design/what-are-user-flows/). <br/><br/> **Converge**: identify a small set of options to validate. Example activities:<br/> - [Think Small](/handbook/product/ux/thinkbig/#think-small) session with the team.<br/> - Design reviews with team<br/> - Low fidelity design ideas. <br/> - Update issue/epic description with proposed solution. Add Figma design file link or attach design to [GitLab's Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) to communicate the solution idea. Read to understand [what tool to use](/handbook/product/ux/product-designer/#deliver). <br/> - Validate approach with help from stakeholders. Run user validation using any of the [proposed methods](/handbook/product/ux/ux-research/solution-validation-and-methods/) and [document your findings in Dovetail](/handbook/product/ux/dovetail/) and appropriate GitLab issue. <br/> - Draw inspiration from competitive and adjacent offerings. | Product Designer | |<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Proposed solution(s) identified and documented**: The Product Designer works with the Product Manager and Engineering team to explore solutions and identifies the approach(es) that strike the best balance of user experience, customer value, business value, and development cost. | The Product Designer optionally apply by `workflow::ready for design` label to the issue, signaling the design backlog of next issues to be done is prioritized. <br/> <br/> **Diverge**: explore multiple different approaches as a team. Example activities: <br/>- [Think Big](/handbook/product/ux/thinkbig/) session. <br/>Internal interviews (be sure to [document findings in Dovetail](/handbook/product/ux/dovetail/)). <br/> - Creating [user flows](https://careerfoundry.com/en/blog/ux-design/what-are-user-flows/). <br/><br/> **Converge**: identify a small set of options to validate. Example activities:<br/> - [Think Small](/handbook/product/ux/thinkbig/#think-small) session with the team.<br/> - Design reviews with team<br/> - Low fidelity design ideas. <br/> - Update issue/epic description with proposed solution. Add Figma design file link or attach design to [GitLab's Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) to communicate the solution idea. Read to understand [what tool to use](/handbook/product/ux/product-designer/#deliver). <br/> - Validate approach with help from stakeholders. Run user validation using any of the [proposed methods](/handbook/product/ux/ux-research/solution-validation-and-methods/) and [document your findings in Dovetail](/handbook/product/ux/dovetail/) and appropriate GitLab issue. <br/> - Draw inspiration from competitive and adjacent offerings. | Product Designer |
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Shared understanding in the team of the proposed solution**: The Product Designer leads the broader team through a review of the proposed solution(s). | - Review the proposed solution as a team so that everyone has a chance to contribute, ask questions, raise concerns, and suggest alternatives. <br/>- Review the proposed solution with leadership. | Product Designer | |<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Shared understanding in the team of the proposed solution**: The Product Designer leads the broader team through a review of the proposed solution(s). | - Review the proposed solution as a team so that everyone has a chance to contribute, ask questions, raise concerns, and suggest alternatives. <br/>- Review the proposed solution with leadership. | Product Designer |
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Confidence in the technical feasibility**: It's important that Engineering understands the technical feasibility of the solution(s) to avoid rework or significant changes when we start the build phase. | - Discuss the technical implications with Engineering to ensure that what is being proposed is possible within the desired timeframe. When sharing design work, use both Figma's collaboration tools and GitLab's design management features. Read to understand [what tool to use](/handbook/product/ux/product-designer/#deliver). <br/>- Engage engineering peers early and often through Slack messages, pings on issues or by scheduling sessions to discuss the proposal.<br>- If the solution is large and complex, consider scheduling a [spike](/handbook/product/product-processes/#spikes) to mitigate risks and uncover the optimal iteration path. | Product Designer | |<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Confidence in the technical feasibility**: It's important that Engineering understands the technical feasibility of the solution(s) to avoid rework or significant changes when we start the build phase. | - Discuss the technical implications with Engineering to ensure that what is being proposed is possible within the desired timeframe. When sharing design work, use both Figma's collaboration tools and GitLab's design management features. Read to understand [what tool to use](/handbook/product/ux/product-designer/#deliver). <br/>- Engage engineering peers early and often through Slack messages, pings on issues or by scheduling sessions to discuss the proposal.<br>- If the solution is large and complex, consider scheduling a [spike](/handbook/product/product-processes/#spikes) to mitigate risks and uncover the optimal iteration path. | Product Designer |
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Updated issues/epic descriptions**: The Product Manager and Product Designer ensure issues and epics are up-to-date. | - Ensure issues and epics are up-to-date, so we can continue our work efficiently and asynchronously. <br/>- [Experiment definition](/handbook/marketing/growth/engineering/#experiment-definition-standards). | Product Manager | |<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Updated issues/epic descriptions**: The Product Manager and Product Designer ensure issues and epics are up-to-date. | - Ensure issues and epics are up-to-date, so we can continue our work efficiently and asynchronously. <br/>- [Experiment definition](/handbook/engineering/development/growth/#experiment-definition-standards). | Product Manager |
|Continue Dogfooding process | - If applicable to their feature, the Product Manager continues the Dogfooding process by deciding whether to [build the feature in GitLab or keep outside](/handbook/product/product-processes/#dogfooding-process) the product. | Product Manager | |Continue Dogfooding process | - If applicable to their feature, the Product Manager continues the Dogfooding process by deciding whether to [build the feature in GitLab or keep outside](/handbook/product/product-processes/#dogfooding-process) the product. | Product Manager |
### Validation phase 4: Solution Validation ### Validation phase 4: Solution Validation
...@@ -331,7 +331,7 @@ When the change becomes available in production and any needed verification is c ...@@ -331,7 +331,7 @@ When the change becomes available in production and any needed verification is c
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Stakeholders of a feature will know it's available in production** | - After the feature is deployed to production and any needed verification in production is completed, the development team will close the issue and add the `workflow::complete` label. <br/>- Product Manager may follow up with individual [stakeholders](/handbook/product/product-processes/#what-is-a-stakeholder) to let them know the feature is available. | Development | |<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Stakeholders of a feature will know it's available in production** | - After the feature is deployed to production and any needed verification in production is completed, the development team will close the issue and add the `workflow::complete` label. <br/>- Product Manager may follow up with individual [stakeholders](/handbook/product/product-processes/#what-is-a-stakeholder) to let them know the feature is available. | Development |
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Customers will be informed about major changes**: When appropriate for a change, a release post item will be written and merged by the Product Manager. | - Product Manager follows the instructions in the [template](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/.gitlab/merge_request_templates/Release-Post.md), which will then cause it to appear on the [GitLab.com releases page](https://about.gitlab.com/releases/gitlab-com/) and be part of the release post. | Product Manager | |<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Customers will be informed about major changes**: When appropriate for a change, a release post item will be written and merged by the Product Manager. | - Product Manager follows the instructions in the [template](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/.gitlab/merge_request_templates/Release-Post.md), which will then cause it to appear on the [GitLab.com releases page](https://about.gitlab.com/releases/gitlab-com/) and be part of the release post. | Product Manager |
|Continue Dogfooding process | - If the PM wants to Dogfood the feature and it's ready for internal consumption, the Product Manager [promotes it internally](/handbook/product/product-processes/#dogfooding-process). | Product Manager | |Continue Dogfooding process | - If the PM wants to Dogfood the feature and it's ready for internal consumption, the Product Manager [promotes it internally](/handbook/product/product-processes/#dogfooding-process). | Product Manager |
| Experiment results and follow-up issue is created | For experiments, create a [follow-up issue](/handbook/marketing/growth/engineering/#experiment-tracking-issue) that will be where results of the test and next-steps are tracked. | Product Manager | | Experiment results and follow-up issue is created | For experiments, create a [follow-up issue](/handbook/engineering/development/growth/#experiment-tracking-issue) that will be where results of the test and next-steps are tracked. | Product Manager |
### Build phase 4: Improve ### Build phase 4: Improve
......
...@@ -96,7 +96,7 @@ Since the Growth section is among the first groups to launch product experiments ...@@ -96,7 +96,7 @@ Since the Growth section is among the first groups to launch product experiments
- [Experiment guide for Product managers](https://gitlab.com/gitlab-org/growth/experimentation/-/issues/14) - [Experiment guide for Product managers](https://gitlab.com/gitlab-org/growth/experimentation/-/issues/14)
- [Experiment ideation Process](https://gitlab.com/gitlab-org/growth/experiment-design-repo/-/issues/1) - [Experiment ideation Process](https://gitlab.com/gitlab-org/growth/experiment-design-repo/-/issues/1)
- [Engineering guide for how to run experiment](https://docs.gitlab.com/ee/development/experiment_guide/) - [Engineering guide for how to run experiment](https://docs.gitlab.com/ee/development/experiment_guide/)
- [Growth Engieering Handbook page on running experiments](/handbook/marketing/growth/engineering/experimentation/) - [Growth Engieering Handbook page on running experiments](/handbook/engineering/development/growth/experimentation/)
- [A way for GitLab team members to view currently active experiments on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/262725) - [A way for GitLab team members to view currently active experiments on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/262725)
## How Growth collaborates with other groups ## How Growth collaborates with other groups
...@@ -136,12 +136,12 @@ Every milestone will have more work than we can commit to. Product designers kno ...@@ -136,12 +136,12 @@ Every milestone will have more work than we can commit to. Product designers kno
#### How UX Works #### How UX Works
We follow the [Product Designer workflows](/handbook/product/ux/product-designer/) and [UX Researcher workflows](/handbook/product/ux/ux-research/) described in the [Product Design section](/handbook/product/ux/) of the handbook. As Growth designers, we relentlessly measure the impact of our design changes following the [experimentation workflow](/handbook/marketing/growth/engineering/experimentation/). In addition: We follow the [Product Designer workflows](/handbook/product/ux/product-designer/) and [UX Researcher workflows](/handbook/product/ux/ux-research/) described in the [Product Design section](/handbook/product/ux/) of the handbook. As Growth designers, we relentlessly measure the impact of our design changes following the [experimentation workflow](/handbook/engineering/development/growth/experimentation/). In addition:
- we have issue boards so we can see what everyone is up to. Refer to issue boards in our planning issues. For example, this is the [template for Acquisition Planning issues](https://gitlab.com/gitlab-org/growth/team-tasks/-/blob/master/.gitlab/issue_templates/growth_acquisition_planning_template.md). - we have issue boards so we can see what everyone is up to. Refer to issue boards in our planning issues. For example, this is the [template for Acquisition Planning issues](https://gitlab.com/gitlab-org/growth/team-tasks/-/blob/master/.gitlab/issue_templates/growth_acquisition_planning_template.md).
- we **label** our issues with `UX`, `devops::growth` and `group::`. - we **label** our issues with `UX`, `devops::growth` and `group::`.
- we will label experiments with `UX problem validation` and `UX solution validation` according to the [UX Research Workflow](/handbook/product/ux/#ux-labels) definitions to indicate the type of learning the experiment achieves. The purpose of these labels is to track [this UX KPI](/handbook/product/ux/performance-indicators/#ux-research-velocity) related to research velocity. - we will label experiments with `UX problem validation` and `UX solution validation` according to the [UX Research Workflow](/handbook/product/ux/#ux-labels) definitions to indicate the type of learning the experiment achieves. The purpose of these labels is to track [this UX KPI](/handbook/product/ux/performance-indicators/#ux-research-velocity) related to research velocity.
- we use the [workflow labels](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=workflow%3A%3A) for regular issues and [experiment workflow labels](/handbook/marketing/growth/engineering/#experiment-workflow-labels) for experiment issues. - we use the [workflow labels](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=workflow%3A%3A) for regular issues and [experiment workflow labels](/handbook/engineering/development/growth/#experiment-workflow-labels) for experiment issues.
- we use **milestones** to aid in planning and prioritizing the four growth groups of Acquisition, Conversion, Expansion and Retention. - we use **milestones** to aid in planning and prioritizing the four growth groups of Acquisition, Conversion, Expansion and Retention.
- PMs provide an [ICE score for experiments](https://docs.google.com/spreadsheets/d/1yvLW0qM0FpvcBzvtnyFrH6O5kAlV1TEFn0TB8KM-Y1s/edit#gid=0) and by using [priority labels](https://docs.gitlab.com/ee/development/labels/index.html#priority-labels) for other issues. - PMs provide an [ICE score for experiments](https://docs.google.com/spreadsheets/d/1yvLW0qM0FpvcBzvtnyFrH6O5kAlV1TEFn0TB8KM-Y1s/edit#gid=0) and by using [priority labels](https://docs.gitlab.com/ee/development/labels/index.html#priority-labels) for other issues.
- The Product Designer applies the milestone in which they plan to deliver the work (1-2 milestones in advance, or backlog for items that are several months out. For example, if an issue is not doable for a designer in the current milestone, they can add the next milestone to the issue, which will communicate to the PM when the work will be delivered. - The Product Designer applies the milestone in which they plan to deliver the work (1-2 milestones in advance, or backlog for items that are several months out. For example, if an issue is not doable for a designer in the current milestone, they can add the next milestone to the issue, which will communicate to the PM when the work will be delivered.
...@@ -241,6 +241,6 @@ In alignment with GitLab's [RADCIE](/handbook/people-group/directly-responsible- ...@@ -241,6 +241,6 @@ In alignment with GitLab's [RADCIE](/handbook/people-group/directly-responsible-
| Post-Experiment Analysis | Data Team | | Post-Experiment Analysis | Data Team |
| Post-Experiment Decision | Growth Product/Stage Product/Engineering | | Post-Experiment Decision | Growth Product/Stage Product/Engineering |
| Maintenance | Stage Product/Engineering | | Maintenance | Stage Product/Engineering |
| Alert creation | Growth Product/Engineering : [How to create a Sisense SQL alert](/handbook/marketing/growth/engineering/sisense_alert.html) | | Alert creation | Growth Product/Engineering : [How to create a Sisense SQL alert](/handbook/engineering/development/growth/sisense_alert.html) |
It is in the Growth teams purview to run any experiment in any area of the application. Growth's ability to experiment in this manner is designed to further learning potential for the larger GitLab team and support business priorities. When an experiment impacts the area of another product owner/team, Growth informs them following the collaboration model above. Product owners/teams are encouraged to raise concerns and provide further context. Ultimately, Growth determines whether the experiment is deemed a success using data and input from relevant teams. The product owner/team is made aware of the result and next steps. It is in the Growth teams purview to run any experiment in any area of the application. Growth's ability to experiment in this manner is designed to further learning potential for the larger GitLab team and support business priorities. When an experiment impacts the area of another product owner/team, Growth informs them following the collaboration model above. Product owners/teams are encouraged to raise concerns and provide further context. Ultimately, Growth determines whether the experiment is deemed a success using data and input from relevant teams. The product owner/team is made aware of the result and next steps.
...@@ -634,7 +634,7 @@ Growth owns the free and trial registration and new user onboarding experiences. ...@@ -634,7 +634,7 @@ Growth owns the free and trial registration and new user onboarding experiences.
**Key handbook pages** **Key handbook pages**
[Overall Growth Section Handbook page for Engineering](/handbook/marketing/growth/engineering/) [Overall Growth Section Handbook page for Engineering](/handbook/engineering/development/growth/)
[Growth Direction Page](/handbook/marketing/growth/) [Growth Direction Page](/handbook/marketing/growth/)
...@@ -644,6 +644,6 @@ Growth owns the free and trial registration and new user onboarding experiences. ...@@ -644,6 +644,6 @@ Growth owns the free and trial registration and new user onboarding experiences.
**Team members** **Team members**
[All team members section of engineering page](/handbook/marketing/growth/engineering/#all-team-members) [All team members section of engineering page](/handbook/engineering/development/growth/#all-team-members)
</details> </details>
...@@ -6,7 +6,7 @@ title: Experimentation Design & Analysis ...@@ -6,7 +6,7 @@ title: Experimentation Design & Analysis
At GitLab, we have a unique approach to experimentation that is built in-house by our incredible development team. The reason we use this approach is to uphold our commitment to our users and customers to protect their privacy. This custom approach leads to some challenges that are not experienced with more commonly used 3rd party experimentation tools. Due to this reality, experimentation at GitLab must be approached with a high level of intentionality and forethought. The purpose of this handbook page is to create some guidelines around experimentation to avoid common errors and to define best practices. At GitLab, we have a unique approach to experimentation that is built in-house by our incredible development team. The reason we use this approach is to uphold our commitment to our users and customers to protect their privacy. This custom approach leads to some challenges that are not experienced with more commonly used 3rd party experimentation tools. Due to this reality, experimentation at GitLab must be approached with a high level of intentionality and forethought. The purpose of this handbook page is to create some guidelines around experimentation to avoid common errors and to define best practices.
In order to increase our [velocity](/handbook/marketing/growth/engineering/#experiment-cadence) In order to increase our [velocity](/handbook/engineering/development/growth/#experiment-cadence)
while maintaining our ability to learn from experiments, the GitLab Growth stage (including the while maintaining our ability to learn from experiments, the GitLab Growth stage (including the
Product Analysis group) is adopting a new framework for designing and analyzing experiments. This Product Analysis group) is adopting a new framework for designing and analyzing experiments. This
framework is adapted from the work of data scientist [Danielle Nelson](https://www.linkedin.com/in/daniellevnelson/). framework is adapted from the work of data scientist [Danielle Nelson](https://www.linkedin.com/in/daniellevnelson/).
...@@ -325,7 +325,7 @@ You can find additional experimentation resources throughout the handbook and Gi ...@@ -325,7 +325,7 @@ You can find additional experimentation resources throughout the handbook and Gi
Here are a few pages to check out: Here are a few pages to check out:
- [How Growth launches experiments](/handbook/product/growth/#how-growth-launches-experiments) - [How Growth launches experiments](/handbook/product/growth/#how-growth-launches-experiments)
- [Growth Engineering Guide to running experiments](/handbook/marketing/growth/engineering/experimentation/) - [Growth Engineering Guide to running experiments](/handbook/engineering/development/growth/experimentation/)
- [GitLab Experiment Guide](https://docs.gitlab.com/ee/development/experiment_guide/) - [GitLab Experiment Guide](https://docs.gitlab.com/ee/development/experiment_guide/)
- [Experimentation Best Practices](/handbook/business-technology/data-team/experimentation-best-practices/) - [Experimentation Best Practices](/handbook/business-technology/data-team/experimentation-best-practices/)
......
...@@ -99,7 +99,7 @@ Managers should add approved growth and development programs to the [department ...@@ -99,7 +99,7 @@ Managers should add approved growth and development programs to the [department
### Handbook ### Handbook
- [Minimum Viable Experiment](/handbook/marketing/growth/engineering/experimentation/#minimum-viable-experiment-mve) - [Minimum Viable Experiment](/handbook/engineering/development/growth/experimentation/#minimum-viable-experiment-mve)
- [How Growth launches experiments](/handbook/product/growth/#how-growth-launches-experiments) - [How Growth launches experiments](/handbook/product/growth/#how-growth-launches-experiments)
- [Growth Experiments Knowledge Base](/handbook/marketing/growth/) - [Growth Experiments Knowledge Base](/handbook/marketing/growth/)
......
...@@ -107,7 +107,7 @@ Below is a list of our cross-functional partners and high-level description of h ...@@ -107,7 +107,7 @@ Below is a list of our cross-functional partners and high-level description of h
| Fulfillment | [Analytics Instrumentation](/handbook/product/analytics-instrumentation-guide/) | The Self-Service Team works with the product intelligence team in cases where our product data set is incomplete (i.e. instrumentation gaps, accessibility, accuracy) when the Self-Service Team team is attempting to answer product questions related to self-service. | | Fulfillment | [Analytics Instrumentation](/handbook/product/analytics-instrumentation-guide/) | The Self-Service Team works with the product intelligence team in cases where our product data set is incomplete (i.e. instrumentation gaps, accessibility, accuracy) when the Self-Service Team team is attempting to answer product questions related to self-service. |
| Fulfillment | License, Purchase, and Utilization | | | Fulfillment | License, Purchase, and Utilization | |
| Growth | [Product Analysis](/handbook/product/product-analysis/#working-with-us) | Our teams have similar functions as it relates to product analytics (e.g. experiment analysis, product KPI tracking, ad hoc product analyses); however the lens through which we ask questions (product v. self-service) and our stakeholders (PMs v. Self-Service Team/sales) differ. <br> <br> We share knowledge, best practices and output of our analyses across our two teams. | | Growth | [Product Analysis](/handbook/product/product-analysis/#working-with-us) | Our teams have similar functions as it relates to product analytics (e.g. experiment analysis, product KPI tracking, ad hoc product analyses); however the lens through which we ask questions (product v. self-service) and our stakeholders (PMs v. Self-Service Team/sales) differ. <br> <br> We share knowledge, best practices and output of our analyses across our two teams. |
| Growth | [Conversion](/handbook/marketing/growth/engineering/) | We partner on experiments related to trial/free to paid self-service conversion. Example: define product qualified lead strategy (PQL) to understand how we can maximize for nARR while emphasizing efficiency through self-service. | | Growth | [Conversion](/handbook/engineering/development/growth/) | We partner on experiments related to trial/free to paid self-service conversion. Example: define product qualified lead strategy (PQL) to understand how we can maximize for nARR while emphasizing efficiency through self-service. |
| [Data](/handbook/business-technology/data-team/) | [GTM Data Fusion & R&D Data Fusion](/handbook/business-technology/data-team/#data-fusion-teams) | Self-Service Team is a ['spoke' and works closely with the core data team 'hub'](/handbook/business-technology/data-team/#how-data-teams-work-together). Self-Service Team digests the aggregated data tables created and maintained by the core data team. Self-Service Team provides input and creates issues for the core team when we have gaps in our data needed for decision making. In the case that analyses become important and repeatable, Self-Service Team works with the core data team to create long term solutions.<br> <br> Self-Service Team partners with the GTM Data Fusion Team on special projects that impact sales and marketing teams as it relates to self-service (e.g. surfacing product insights to sales teams, PTB). | | [Data](/handbook/business-technology/data-team/) | [GTM Data Fusion & R&D Data Fusion](/handbook/business-technology/data-team/#data-fusion-teams) | Self-Service Team is a ['spoke' and works closely with the core data team 'hub'](/handbook/business-technology/data-team/#how-data-teams-work-together). Self-Service Team digests the aggregated data tables created and maintained by the core data team. Self-Service Team provides input and creates issues for the core team when we have gaps in our data needed for decision making. In the case that analyses become important and repeatable, Self-Service Team works with the core data team to create long term solutions.<br> <br> Self-Service Team partners with the GTM Data Fusion Team on special projects that impact sales and marketing teams as it relates to self-service (e.g. surfacing product insights to sales teams, PTB). |
| [Marketing](/handbook/marketing/) | | | | [Marketing](/handbook/marketing/) | | |
| [Sales](/handbook/sales/) | | | | [Sales](/handbook/sales/) | | |
......
...@@ -60,7 +60,7 @@ The Intermediate Fullstack Engineer is a [grade](/handbook/total-rewards/compens ...@@ -60,7 +60,7 @@ The Intermediate Fullstack Engineer is a [grade](/handbook/total-rewards/compens
### Growth ### Growth
The [Growth sub-department](/handbook/marketing/growth/engineering/) analyzes the entire customer journey from the acquisition of a customer, to the flow across multiple GitLab features, and even reactivation of lost users. They work in small groups with a product manager, product designer, and a data analyst to scale GitLab usage by connecting users to the existing value that GitLab already delivers. The [Growth sub-department](/handbook/engineering/development/growth/) analyzes the entire customer journey from the acquisition of a customer, to the flow across multiple GitLab features, and even reactivation of lost users. They work in small groups with a product manager, product designer, and a data analyst to scale GitLab usage by connecting users to the existing value that GitLab already delivers.
#### Growth Requirements #### Growth Requirements
......
...@@ -76,5 +76,8 @@ ...@@ -76,5 +76,8 @@
/handbook/customer-success/csm/segment/cse/webinar-calendar/ https://university.gitlab.com/pages/gitlab-user-webinars 301 /handbook/customer-success/csm/segment/cse/webinar-calendar/ https://university.gitlab.com/pages/gitlab-user-webinars 301
/handbook/customer-success/csm/segment/scale/webinar-calendar/ https://university.gitlab.com/pages/gitlab-user-webinars 301 /handbook/customer-success/csm/segment/scale/webinar-calendar/ https://university.gitlab.com/pages/gitlab-user-webinars 301
# Growth section move from Marketing to Engineering - remove 2024-12-01
/handbook/marketing/growth/engineering/* /handbook/engineering/development/growth/:splat 301
# Handbook doesn't use .html style page locations so repoint these # Handbook doesn't use .html style page locations so repoint these
/*.html /:splat/ 301 /*.html /:splat/ 301
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment