fleet/handbook/product

Product design

Contributors in Fleet's product department prioritize and define the changes we make to the product.

Changes begin as ideas or code that can be contributed by anyone.

You can read what's coming in the next 3-6 weeks in Fleet's ⚗️ Drafting board.

Making changes to the product

Fleet's product designers are responsible for prioritizing and shaping changes to the Fleet product, from the outside-in, reviewing and collecting feedback from users, would-be users, and future users, prioritizing changes, designing the changes, and delivering these changes to the engineering team.

The scope of product design at Fleet is any change that involves changes to functionality or usage, including the UI, REST API, command line, and webhooks.

Learn more about Fleet's philosophy and process for making interface changes to the product, or why we use a wireframe-first approach.

Wireframing

At Fleet, like GitLab and other organizations, every change to the product's UI gets wireframed first.

• Take the top user story that is assigned to you in the "Prioritized" column of the drafting board.

• Create a new file inside the Fleet product Figma project. See Working with Figma below for more details.

• Use dev notes (component available in our library) to highlight important information to engineers and other teammates.

• Draft changes to the Fleet product that solve the problem specified in the story. Constantly place yourself in the shoes of a user while drafting changes. Place these drafts in the appropriate Figma file in Fleet product project.

• Be intentional about changes to design components (e.g. button border-radius or modal width) because these are expensive. They'll require code changes and QA in multiple parts of the product. Propose changes to a design component as part of an already-prioritized user story instead of making a new request in 🎁🗣 Feature Fest.

• While drafting, reach out to sales, customer success, and marketing for a business perspective.

• While drafting, engage engineering to gain insight into technical costs and feasibility.

Working with Figma

Create a new file

When starting a new draft:

• Create a new file inside the Fleet product project by duplicating "[TEMPLATE] Starter file" (pinned to the top of the project).
• Right-click on the duplicated file, select "Share", and ensure anyone with the link can view the file.
• Rename each Figma file to include the number and name of the corresponding issue on the drafting board. (e.g. # 11766 Instructions for Autopilot enrollment).
• The starter file includes 3 predefined pages: Cover, Ready, and Scratchpad.
  • Cover. This page has a component with issue number, issue name, and status fields. There are 3 statuses: Work in progress, Approved, and Released (the main source of truth is still the drafting board).
  • Ready. Use this page to communicate designs reviews and development.
  • Scratchpad. Use this page for work in progress and design that might be useful in the future.

Keep projects/files clean and up-to-date

• Once your designs are reviewed and approved, change the status on the cover page of the relevant Figma file and move the issue to the "Settled" column.
• After each release (every 3 weeks) make sure you change the status on the cover page of the relevant Figma files that you worked on during the sprint to "Released".

Questions and missing information

1. Take a screenshot of the area in Figma
2. Start a thread in the #help-product-design Slack channel and paste in the screenshot

Note: Figma does have a commenting system, but it is not easy to search for outstanding concerns and is therefore not preferred.

For external contributors: please consider opening an issue with reference screenshots if you have a Figma related question you need to resolve.

Scheduling design reviews

• Prepare your draft in the user story issue.
• Prepare the agenda for your design review meeting, which should be an empty document other than the proposed changes you will present.
• Review the draft with the CEO at one of the daily design review meetings, or schedule an ad-hoc design review if you need to move faster. (Efficient access to design reviews on-demand is a priority for Fleet's CEO. Emphasizing design helps us live our empathy value.)
• When introducing a story, clarify which review "mode" the CEO should operate in:
  • Final review mode — you are 70% sure the design is 100% done.
  • Feedback mode — you know the design is not ready for final review, but would like to get early feedback. Before bringing something in feedback mode consider whether the CEO will be best for giving feedback or if it would be better suited for someone else (engineer or PM).
• During the review meeting, take detailed notes of any feedback on the draft.
• Address the feedback by modifying your draft.
• Rinse and repeat at subsequent sessions until there is no more feedback.

As drafting occurs, inevitably, the requirements will change. The main description of the issue should be the single source of truth for the problem to be solved and the required outcome. The product manager is responsible for keeping the main description of the issue up-to-date. Comments and other items can and should be kept in the issue for historical record-keeping.

Settled

Once the draft has been approved, it moves to the "Settled" column on the drafting board.

Before assigning an engineering manager to estimate a user story, the product designer ensures the product section of the user story checklist is complete.

Once a bug has gone through design and is considered "Settled", the designer removes the :product label and moves the issue to the 'Sprint backlog' column on the "Bugs" board and assigns the group engineering manager.

Learn https://fleetdm.com/handbook/company/development-groups#making-changes

Expedited drafting

Expedited drafting is the revision of drafted changes currently being developed by the engineering team. Expedited drafting aims to quickly adapt to unknown edge cases and changing specifications while ensuring that Fleet meets our brand and quality guidelines.

You'll know it's time for expedited drafting when:

• The team discovers that a drafted user story is missing crucial information that prevents contributors from continuing the development task.
• A user story is taking more effort than was originally estimated, and Product Manager wants to find ways to cut aspects of planned functionality in order to still ship the improvement in the currently scheduled release.

What happens during expedited drafting?

1. Everyone on the product and engineering teams know that a drafted change was brought back to drafting and prioritized.
2. Drafts are updated to cover edge cases or reduce functionality.
3. UI changes are approved, and the UI changes are brought back to the engineering team to continue the development task.

Outside contributions

Anyone can contribute at Fleet, from inside or outside the company. Since contributors from the wider community don't receive a paycheck from Fleet, they work on whatever they want.

Many open source contributions that start as a small, seemingly innocuous pull request come with lots of additional unplanned work down the road: unforseen side effects, documentation, testing, potential breaking changes, database migrations, and more.

Thus, to ensure consistency, completeness, and secure development practices, no matter where a contribution comes from, Fleet will still follow the standard process for prioritizing and drafting a feature when it comes from the community.

Prioritizing improvements

Product Managers prioritize all potential product improvements worked on by Fleeties. Anyone (Fleeties, customers, and community members) are invited to suggest improvements. See the intake section for more information on how Fleet's product team intakes new feature requests.

Prioritizing bugs

Bugs are always prioritized. (Fleet takes quality and stability very seriously.) Bugs should be prioritized in the following order:

1. Quality: product does what it's supposed to (what is documented).
2. Common-sense user criticality: If no one can load any page, that's obviously important.
3. Age of bugs: Long-open bugs are open wounds bleeding quality out of the product. They must be closed quickly.
4. Customer criticality: How important it is to a customer use case.

If a bug is unreleased or critical, it is addressed in the current sprint. Otherwise, it may be prioritized and estimated for the next sprint. If a bug requires drafting to determine the expected functionality, the bug should undergo expedited drafting.

If a bug is not addressed within six weeks, it is sent to the product team for triage. Each sprint, the Head of Product Design reviews these bugs. Bugs are categorized as follows:

• Schedule: the bug should be prioritized in the next sprint if there's engineering capacity for it.
• De-prioritized: the issue will be closed and the necessary subsequent steps will be initiated. This might include updating documentation and informing the community.

The Head of Product Design meets with the Director of Product Development to discuss and finalize the outcomes for the churned bugs.

After aligning with the Director of Product Development on the outcomes, The Head of Product Design will clean up churned bugs. Below are the steps for each category:

• Schedule: Remove the :product label, move the bug ticket to the 'Sprint backlog' column on the bug board, and assign it to the appropriate group's Engineering Manager so that it can be prioritized into the sprint backlog.
• De-prioritized: The Head of Product Design should close the issue and, as the DRI, ensure all follow-up actions are finalized.

Writing user stories

Product Managers write user stories in the drafting board. The drafting board is shared by every product group.

Drafting user stories

Product Designers draft user stories that have been prioritized by PMs. If the estimated user stories for a product group exceed that group's capacity, all new design work for that group is paused, and the designer will contribute in other ways (documentation & handbook work, Figma maintenance, QA, etc.) until the PM deprioritizes estimated stories to make room, or until the next sprint begins. (If the designer has existing work-in-progress, they will continue to review and iterate on those designs and see the stories through to estimation.)

If an issue's title or user story summary ("as a…I want to…so that") does not match the intended change being discussed, the designer will move the issue to the "Needs clarity" column of the drafting board and assign the group product manager. The group product manager will revisit ASAP and edit the issue title and user story summary, then reassign the designer and move the issue back to the "Prioritized" column.

Estimating user stories

Engineering Managers estimate user stories. They are responsible for delivering planned work in the current sprint (0-3 weeks) while quickly getting user stories estimated for the next sprint (3-6 weeks). Only work that is slated to be released into the hands of users within ≤six weeks will be estimated. Estimation is run by each group's Engineering Manager and occurs on the drafting board.

Sprints

Sprints align with Fleet's 3-week release cycle.

On the first day of each release, all estimated issues are moved into the relevant section of the new "Release" board, which has a kanban view per group.

Sprints are managed in Zenhub. To plan capacity for a sprint, create a "Sprint" issue, replace the fake constants with real numbers, and attach the appropriate labels for your product group.

Sprint numbering

Sprints are numbered according to the release version. For example, for the sprint ending on June 30th, 2023, on which date we expect to release Fleet v4.34, the sprint is called the 4.34 sprint.

Product design conventions

MDM behind-the-frame

Behind every MDM wireframe at Fleet, there are 3 foundational design principles:

• Use-case first. Taking advantage of top-level features vs. per-platform options allows us to take advantage of similarities and avoid having two different ways to configure the same thing. Start off cross-platform for every option, setting, and feature. If we prove it's impossible, then work backward making it platform-specific.

• Bridge the Mac and Windows gap. Implement enough help text, links, guides, gifs, etc that a reasonably persistent human being can figure it out just by trying to use the UI. Even if that means we have fewer features or slightly lower granularity (we can iterate and add more granularity later), Make it easy enough to understand. Whether they're experienced Mac admins people or career Windows folks (even if someone has never used a Windows tool) they should "get it".

• Control the noise. Bring the needs surface level, tuck away things you don't need by default (when possible, given time). For example, hide Windows controls if there are no Windows devices (based on number of Windows hosts).

Wireframes

• Showing these principles and ideas, to help remember the pros and cons and conceptualize the above visually.

  • Figma: ⚗️ Fleet product project

We have certain design conventions that we include in Fleet. We will document more of these over time.

Figma component library

Use the 🧩 "Design System (current)" Figma library as a source of truth for components. Components in the product (Storybook) should match the style of components defined in the Figma library. If the frontend component is inconsistent with one in the Figma library, treat that as a bug.

Table empty states

Use ---, with color $ui-fleet-black-50 as the default UI for empty columns.

Form behavior

Pressing the return or enter key with an open form will cause the form to be submitted.

Internal links

For text links that navigates the user to a different page within the Fleet UI, use the $core-blue color and xs-bold styling. You'll also want to make sure to use the underline style for when the user hovers over these links.

External links

For a link that navigates the user to an external site (e.g., fleetdm.com/docs), use the $core-blue color and xs-bold styling for the link's text. Also, place the link-out icon to the right of the link's text.

Tooltips

All tooltips change the cursor to a question mark on hover. All tooltips have a solid background color.

There are two types of tooltips. The two types of tooltips have some unique styles:

1. Tooltips for text (column headers, input titles, inline text) appear when hovering over any text with a dashed underline. These tooltips use left-aligned text.

2. Tooltips for buttons, bubbles, table row elements, and other non-text elements appear when hovering over the element. These tooltips use center-aligned text. These tooltips include a centered arrow.

Bold text

For copy in the Fleet UI and Fleet documentation, use bold text when referencing UI elements such as buttons, links, column names, form field names, page names, and section names. For an example, check out the bold text in the docs here.

This way, if a user is scanning instructions, the bold text tells them what UI element they should look for.

In the docs, if a UI element is part of a section title (already bold) use double quotes. For an example, see this section title here.

Copy in parentheses (additional information)

When writing copy, consider whether additional information is necessary before adding it as a new sentence or in parentheses. If the information is needed, use parentheses with an incomplete sentence to keep the copy shorter.

Writing the time

When writing the time in the UI using "am" and "pm" abbreviations, write them without space between time and abbreviation, with no punctuation, and use lowercase letters (e.g. Working hours are 8am to 5pm).

Writing error messages

When writing error messages in the UI or CLI, follow these rules:

• If the solution to the error isn't obvious, write a message with the error followed by the solution. For example, "No hosts targeted. Make sure you provide a valid hostname, UUID, osquery host ID, or node key."
• If the solution is obvious when additional info is provided, write a message with the error followed by additional info. For example, "You don’t have permission to run the script. Only users with the maintainer role and above can run scripts."

Fleetctl commands with --hosts or --host flag

When designing CLI experience for commands that target hosts (e.g. fleetctl query or fleetctl mdm run-command when including the --hosts or --host flag), if a non-existing host is specified, use a single error message such as: Error: No hosts targeted. Make sure you provide a valid hostname, UUID, osquery host ID, or node key.

When writing copy for CLI help pages use the following descriptions:

$ fleetctl <command with --hosts/--host flag> -h

OPTIONS
--hosts     Hosts specified by hostname, uuid, osquery_host_id or node_key that you want to target.     
--host      Host specified by hostname, uuid, osquery_host_id or node_key that you want to target.     

Release

This section outlines the communication between the product, marketing, and customer success teams prior to a release of Fleet.

These measures exist to keep all contributors (including other departments besides engineering and product) up to date with improvements and changes to the Fleet product. This helps folks plan and communicate with customers and users more effectively.

Ranking features

After the kickoff of a product sprint, the marketing and product teams decide which improvements are most important to highlight in this release, whether that's through social media "drumbeat" tweets, collaboration with partners, or emphasized content blocks within the release blog post.

When an improvement gets scheduled for release, the Head of Product sets its "echelon" to determine the emphasis the company will place on it. This leveling is based on the improvement's desirability and timeliness, and will affect marketing effort for the feature.

• Echelon 1: A major product feature announcement. The most important release types, these require a specific and custom marketing package. Usually including an individual blog post, a demo video and potentially a press release or official product marketing launch. There is a maximum of one echelon 1 product announcement per release sprint.
• Echelon 2: A highlighted feature in the release notes. This product feature will be highlighted at the top of the Sprint Release blog post. Depending on the feature specifics this will include: a 1-2 paragraph write-up of the feature, a demo video (if applicable) and a link to the docs. Ideally there would be no more than three echelon 2 features in a release post, otherwise the top features will be crowded.
• Echelon 3: A notable feature to mention in the changelog. Most product improvements fit into this echelon. This includes 1-2 sentences in the changelog and release blog post.

Blog post

Before each release, the Head of Product creates a "Release" issue, which includes a list of all improvements included in the upcoming release. Each improvement links to the relevant bug or user story issue on GitHub so it is easy to read the related discussion and history.

The product team is responsible for providing the marketing team with the necessary information for writing the release blog post. Every three weeks after the sprint is kicked off, the product team meets with the relevant marketing team members to go over the features for that sprint and recommend items to highlight as echelon 2 features and provide relevant context for other features to help marketing decide which features to highlight.

Feature flags

At Fleet, features are placed behind feature flags if the changes could affect Fleet's availability of existing functionalities.

The following highlights should be considered when deciding if we should leverage feature flags:

• The feature flag must be disabled by default.
• The feature flag will not be permanent. This means that the Directly Responsible Individual (DRI) who decides a feature flag should be introduced is also responsible for creating an issue to track the feature's progress towards removing the feature flag and including the feature in a stable release.
• The feature flag will not be advertised. For example, advertising in the documentation on fleetdm.com/docs, release notes, release blog posts, and Twitter.

Fleet's feature flag guidelines is borrowed from GitLab's "When to use feature flags" section of their handbook. Check out GitLab's "Feature flags only when needed" video for an explanation of the costs of introducing feature flags.

Beta features

At Fleet, features are advertised as "beta" if there are concerns that the feature may not work as intended in certain Fleet deployments. For example, these concerns could be related to the feature's performance in Fleet deployments with hundreds of thousands of hosts.

The following highlights should be considered when deciding if we promote a feature as "beta:"

• The feature will not be advertised as "beta" permanently. This means that the Directly Responsible Individual (DRI) who decides a feature is advertised as "beta" is also responsible for creating an issue that explains why the feature is advertised as "beta" and tracking the feature's progress towards advertising the feature as "stable."
• The feature will be advertised as "beta" in the documentation on fleetdm.com/docs, release notes, release blog posts, and Twitter.

Breaking changes

For product changes that cause breaking API or configuration changes or major impact for users (or even just the 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 (private Google doc).

Intake

• Making a request
• How feature requests are evaluated
• After the feature is accepted
• Why this way?

To stay in-sync with our customers' needs, Fleet accepts feature requests from customers and community members on a sprint-by-sprint basis in the regular 🎁🗣 Feature Fest meeting. Anyone in the company is invited to submit requests or simply listen in on the 🎁🗣 Feature Fest meeting. Folks from the wider community can also request an invite.

Making a request

To make a feature request or advocate for a feature request from a customer or community member, create an issue and attend the next scheduled 🎁🗣 Feature Fest meeting.

Requests are weighed from top to bottom while prioritizing attendee requests. This means that if the individual that added a feature request is not in attendance, the feature request will be discussed towards the end of the call if there's time.

To be acceptable for consideration, a request must:

• Have a clear proposed change
• Have a well-articulated underlying user need
• Specify the requestor (either internal stakeholder or customer or community user)

To help the product team, other pieces of information can be optionally included:

• How would they solve the problem without any changes if pressed?
• How does this change fit into the requester's overall usage of Fleet?
• What other potential changes to the product have you considered?

To ensure your request appears on the "Feature Fest" board:

• Add the ~feature fest label to your issue
• Add the relevant customer label (if applicable)

To maximize your chances of having a feature accepted, requesters can visit the 🗣 Product office hours meeting to get feedback on requests prior to being accepted.

How feature requests are evaluated

Digestion of these new product ideas (requests) happens at the 🎁🗣 Feature Fest meeting.

At the 🎁🗣 Feature Fest meeting, the DRI (Head of Product) weighs all requests on the board. When the team weighs a request, it is immediately prioritized or put to the side.

• A request is prioritized when the DRI decides it is a priority. When this happens, the team sets the request to be estimated within five business days.
• A request is put to the side when the business perceives competing priorities as more pressing in the immediate moment.

If a feature is not prioritized during a 🎁🗣 Feature Fest meeting, it only means the feature has been rejected at that time. Requestors will be notified by the Head of Product, and they can resubmit their request at a future meeting.

Requests are weighed by:

• The completeness of the request (see making a request)
• How urgent the need is for the customer
• How much impact the request will have. This may be a wide impact across many customers and/or high impact on one
• How well the request fits within Fleet's product vision and roadmap
• Whether the feature seems like it can be designed, estimated, and developed in 6 weeks, given its individual complexity and when combined with other work already accepted

Customer feature requests

The product team's goal is to prioritize 16 customer feature requests at Feature Fest, then take them from settled to shipped. The customer success team is responsible for providing the Head of Product a live count during the Feature Fest meeting. Product Operations is responsible for monitoring this KPI and raising alarms throughout the design and engineering sprints.

Customer stories should be estimated at 1-3 points each to count as 1 request. If a feature request spans across multiple customers, it will be counted as the number of customers involved.

After the feature is accepted

After the 🎁🗣 Feature Fest meeting, Product Operations will clear the Feature Fest board as follows: Prioritized features: Remove feature fest label, add :product label, and assign the group Product Manager. Put to the side features: Remove feature fest label and close the issue.

Group Product Managers will then develop user stories for the prioritized features.

The product team's commitment to the requester is that a prioritized feature will be delivered within 6 weeks or the requester will be notified within 1 business day of the decision to de-prioritize the feature.

Potential reasons for why a feature may be de-prioritized include:

• The work was not designed in time. Since Fleet's engineering sprints are 3 weeks each, this means that a prioritized feature has 3 weeks to be designed, approved, and estimated in order to make it to the engineering sprint. At the prioritization meeting, the perceived design complexity of proposed features will inevitably be different from the actual complexity.
  • This may be because other higher-priority design work took longer than expected or the work itself was more complex than expected
• The was designed but was not selected for the sprint. When a new sprint starts, it is populated with bugs, features, and technical tasks. Depending on the size and quantity of non-feature work, certain features may not be selected for the sprint.

Just as when a feature request is not accepted in the 🎁🗣 Feature Fest meeting, whenever a feature is de-prioritized after it has been accepted, it only means that the feature has been de-prioritized at this time. It is up to the requester to bring the request back again at another 🎁🗣 Feature Fest meeting.

Why this way?

Most requests are not prioritized. The goal is to narrow our focus and avoid creating an overflowing, aspirational backlog where good ideas inevitably go to die. Instead, at Fleet we manage a small "frontlog" of changes we intend to ship. Responsibility for keeping backlogs then belong to the stakeholder who is closest to the customer.

Misc.

• All 🎁🗣 Feature Fest meetings are recorded and uploaded to Gong.
• 🎁🗣 Feature Fest is located on the "Office hours" calendar.

Usage statistics

In order to understand the usage of the Fleet product, we collect statistics from installations where this functionality is enabled.

Fleeties can view these statistics in the Google spreadsheet Fleet usage available in Google Drive.

Some of the data is forwarded to Datadog and is available to Fleeties.

Maintenance

Fleet's product offerings depend on the capabilities of other platforms. This requires the ongoing attention of the product and engineering teams to ensure that we are up-to-date with new capabilities and that our existing capabilities continue to function. The first step to staying up-to-date with Fleet's partners is to know when the partner platform changes.

Every week, a member of the product team (as determined in the rituals section) looks up whether there is:

1. a new major or minor version of macOS
2. a new major or minor version of CIS Benchmarks Windows 10 Enterprise
3. a new major or minor version of CIS Benchmarks macOS 13 Ventura
4. a release of CIS Benchmarks for macOS 14 Sonoma
5. a new major or minor version of ChromeOS

The DRI should record the latest versions in the maintenance tracker and then notify the #help-product-design Slack channel with an update, noting the current versions and highlighting any changes.

Restart Algolia manually

At least once every hour, an Algolia crawler reindexes the Fleet website's content. If an error occurs while the website is being indexed, Algolia will block our crawler and respond to requests with this message: "This action cannot be executed on a blocked crawler".

When this happens, you'll need to manually start the crawler in the Algolia crawler dashboard to unblock it. You can do this by logging into the crawler dashboard using the login saved in 1password and clicking the "Restart crawling" button on our crawler's "overview" page](https://crawler.algolia.com/admin/crawlers/497dd4fd-f8dd-4ffb-85c9-2a56b7fafe98/overview).

No further action is needed if the crawler successfully reindexes the Fleet website. If another error occurs while the crawler is running, take a screenshot of the error and add it to the GitHub issue created for the alert and @mention eashaw for help.

New CIS benchmarks

When we create new CIS benchmarks, also submit the new CIS benchmark set to CIS for certification.

Rituals

Directly Responsible Individuals (DRI) engage in the ritual(s) below at the frequency specified.

Ritual	Frequency	Description	DRI
Design sprint review (#g-endpoint-ops)	Sprintly (Wednesday)	After the last estimation session, the Head of Product reviews the board with each group PM and designer and de-prioritizes all design issues that were not estimated. The Head of Product also collects all items that are product-driven and puts them in the 🎁🗣 Feature fest meeting agenda to consider for continuing work. The number of de-prioritized issues should be recorded in the KPI spreadsheet.	Noah Talerman
Design sprint review (#g-mdm)	Sprintly (Thursday)	After the last estimation session, the Head of Product Design reviews the board with each group PM and designer and de-prioritizes all design issues that were not estimated. The group PM collects all items that were de-prioritized and, if desired, puts them in the 🎁🗣 Feature fest meeting agenda to consider for continuing work. The number of de-prioritized issues should be recorded in the KPI spreadsheet.	Noah Talerman
🎁 Feature fest prep	Sprintly (Thursday)	The Head of Product Design reviews the agenda and pre-comments on items in order to be well-prepared for the discussion.	Noah Talerman
🎁🗣 Feature fest	Sprintly (Thursday)	We make a decision regarding which customer and community feature requests can be committed to in the next six weeks. We create issues for any requests that don't already have one.	Noah Talerman
🎁 Feature fest cleanup	Sprintly (Thursday)	Clean up the agenda in anticipation of the next meeting	Noah Talerman
Design sprint kickoff (#g-endpoint-ops)	Sprintly (Thursday)	the Head of Product Design introduces and determines the order of the newly prioritized list of work with each group PM	Noah Talerman
Design sprint kickoff (#g-mdm)	Sprintly (Thursday)	the Head of Product Design introduces and determines the order of the newly prioritized list of work with each group PM	Noah Talerman
🗣 Product office hours	Weekly (Tuesday)	Ask questions to the product team	Noah Talerman
Sprint kickoff review	Sprintly (Monday)	After each sprint kickoff, the Head of Product Design reviews the Estimated column with each group EM and de-prioritizes the features that were not included in the sprint and prepares recommended highlights for the release notes. The number of de-prioritized issues should be recorded in the KPI spreadsheet.	Noah Talerman
🦢🗣 Design review (#g-mdm)	Daily	Review designs from the MDM team	Marko Lisica
🦢🗣 Design review (#g-endpoint-ops)	Daily	Review designs from the Endpoint ops team	Rachael Shaw
Product development process review	Sprintly	CEO, Director of Product Development, and Head of Product get together to review boards and process to make sure everything still makes sense	Noah Talerman
Maintenance	Weekly (Friday)	Head of Product Design checks the latest versions of relevant platforms, updates the maintenance tracker, and notifies the #help-product-design Slack channel.	Noah Talerman
Quality check	Daily	Every day, Head of Product design will review the "Settled" column on the drafting board to ensure all product action items are complete.	Noah Talerman
Product confirm and celebrate	Weekly (Wednesday)	The Head of Product meets with the designers and product managers to discuss completed user stories. They also verify all updates to documentation, communications, guides, and the pricing and transparency pages, ensuring everything is set for the next steps.	Noah Talerman
Pre-sprint prioritization	Sprintly (Monday)	The Head of Product Design and each group's EM meet before each sprint to align on priorities and discuss what stories weren't completed in the previous sprint. Head of Product Design records number of stories that weren't completed in the "Stories dropped" product KPI.	Noah Talerman
Bug round-up	Mid-sprint	Head of Product Design will compile a list of churned bugs, including issue numbers, specifics, and age. They will also notify the Customer Success team of any churned bugs that have customer tags	Noah Talerman
Churned bug review	Mid-sprint	The Head of Product Design meets with the Head of Product Development to examine churned bugs and categorize them as either schedule, needs prioritization, or de-prioritize.	Churned bug clean-up
Stand-up (#g-website)	Daily (Monday - Thursday)	The website product team meets to discuss completed tasks, upcoming work, and address any questions.	Mike Thomas
Prioritization session (#g-website)	Sprintly	The website product team meets to prioritize tasks for the upcoming sprint.	Mike Thomas
Design review (#g-website)	Daily (Monday - Thursday)	Review designs from the website team.	Mike Thomas
PMMs R Us	Weekly (Sunday)	The CEO meets with the Head of Design to discuss product marketing strategies.	Mike Thomas

Slack channels

This group maintains the following Slack channels:

Slack channel	DRI
#help-product-design	Noah Talerman
#g-mdm	Noah Talerman
#g-endpoint-ops	Noah Talerman