From d696c91dbaf02aeb8fe746cd18b5991e3237d253 Mon Sep 17 00:00:00 2001 From: Mike McNeil Date: Thu, 16 Mar 2023 18:06:08 -0500 Subject: [PATCH] "Significant product changes" (#10539) # Checklist for submitter If some of the following don't apply, delete the relevant line. - [ ] Changes file added for user-visible changes in `changes/` or `orbit/changes/`. See [Changes files](https://fleetdm.com/docs/contributing/committing-changes#changes-files) for more information. - [ ] Documented any API changes (docs/Using-Fleet/REST-API.md or docs/Contributing/API-for-contributors.md) - [ ] Documented any permissions changes - [ ] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [ ] Added support on fleet's osquery simulator `cmd/osquery-perf` for new osquery data ingestion features. - [ ] Added/updated tests - [ ] Manual QA for all new/changed functionality - For Orbit and Fleet Desktop changes: - [ ] Manual QA must be performed in the three main OSs, macOS, Windows and Linux. - [ ] Auto-update manual QA, from released version of component to new version (see [tools/tuf/test](../tools/tuf/test/README.md)). --- handbook/product/README.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/handbook/product/README.md b/handbook/product/README.md index 2c4fe2894e..a190491bb1 100644 --- a/handbook/product/README.md +++ b/handbook/product/README.md @@ -319,6 +319,19 @@ The following highlights should be considered when deciding if we should leverag Fleet's feature flag guidelines is borrowed from GitLab's ["When to use feature flags" section](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) of their handbook. Check out [GitLab's "Feature flags only when needed" video](https://www.youtube.com/watch?v=DQaGqyolOd8) for an explanation of the costs of introducing feature flags. +## Significant changes + +For product changes that cause major impact for users, or even just create impression of major impact, the company plans migration thoughtfully. That means the product department and E-group: + +1. **Written:** Write a migration guide, even if that's just a Google Doc +2. **Tested:** Test out the migration ourselves, first-hand, as an engineer. +3. **Gamed out:** We pretend we are one or two key customers and try it out as a role play. +4. **Adapt:** If it becomes clear that the plan is insufficient, then fix it. +5. **Communicate:** Develop a plan for how to proactively communicate the change to customers. + +That all happens prior to work getting prioritized for the change. + + ## Competition We track competitors' capabilities and adjacent (or commonly integrated) products in Google doc [Competition](https://docs.google.com/document/d/1Bqdui6oQthdv5XtD5l7EZVB-duNRcqVRg7NVA4lCXeI/edit) (private).