Handbook: Product groups: Air guitar (#13970)

# 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 (docs/Using
Fleet/manage-access.md)
- [ ] 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)).
This commit is contained in:
Jin Yi 2023-09-15 14:29:29 -07:00 committed by GitHub
parent e2aa0b28c7
commit 58be6fdacc
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -205,20 +205,8 @@ The product designer prepares proposed changes in the form of wireframes for thi
#### Air guitar
Air guitar is an optional, conceptual exercise that can sometimes happen before (or in lieu of) the formal design review stage, focusing on rapid iteration and exploration without immediate plans for engineering implementation. It's like strumming an imaginary guitar — full of movements and rhythm but without strings attached.
The goal of the air guitar process is to explore the shape of an idea, feature, or customer request quickly, without affecting the engineering pipeline. This enables the team to:
1. Validate or invalidate assumptions.
2. Refine the scope and nature of the user story.
3. Explore multiple avenues with low stakes.
4. Quickly gather feedback for future planning.
The air guitar process is particularly useful when:
1. The team receives an interesting customer request that may not yet align with immediate development priorities.
2. The team wishes to explore a new idea or feature without committing engineering effort.
3. The product group needs to validate whether a user story is worth scheduling for formal development.
1. Air guitar issues are always intended to be designed right away.
2. If they can't be, the requestor is notified via at-mention in the issue. (That person is either the CSM or AE.) These comments (like every github comment) should at-mention the intended recipient. GitHub comments without at-mentions do not notify anyone.
##### Initiate an air guitar session