fleet/handbook/product

Product

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.

Product design

The product team is responsible for product design tasks like drafting changes to the Fleet product, reviewing and collecting feedback from engineering, sales, customer success, and marketing counterparts, and delivering these changes to the engineering team.

Learn more about Fleet's philosophy and process for making iterative 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 issue that is assigned to you in the "Prioritized" column of the drafting board.

• Create a page in the Fleet EE (scratchpad, dev-ready) Figma file and combine your issue's number and title to name the Figma page.

• Draft changes to the Fleet product that solve the problem specified in the issue. Constantly place yourself in the shoes of a user while drafting changes. Place these drafts in the appropriate Figma page in Fleet EE (scratchpad, dev-ready).

• 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.

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.)
• 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.

Estimating

Once the draft has been approved:

• move it to the "Designed" column in the drafting board
• make sure that the issue is updated with the latest information on the work to be done, such as link to the correct page in the Fleet EE (scratchpad) Figma and most recent requirements.

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

Emergency drafting

TODO: extrapolate this content to

Emergency drafting is the revision of drafted changes currently being developed by the engineering team. Emergency 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 emergency 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 emergency 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, it is still important to ensure consistency, completeness, and secure development practices, no matter where a contribution comes from:

• Prior to merging any change, small or large, that would change the expected behavior of the product, prioritized by the appropriate product group's Product Manager and drafted by the group's Product Designer prior to merging.
• All changes to the user interface should be wireframed first by the appropriate Product Designer.

Prioritizing improvements

Product Managers prioritize all potential product improvements worked on by contributors inside the company.

Bugs are always prioritized. (Fleet takes quality and stability very seriously.)

Anyone can suggest improvements.

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.

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 (aka "iterations") 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

Sprint 1 began at the beginning of January 2023. Sprint 4 began in late March 2023. And so forth.

Leftovers

Improvements are prioritized prior to estimation. But sometimes, estimations will affect the calculus of what to include in an upcoming release. Improvements that do not not "fit" into the capacity of the next scheduled release are left at the very top of the "Estimated" column of the drafting board. The Product Manager always either includes these "leftovers" in the next release (3-6 weeks) or deprioritizes and closes them.

Product design conventions

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

TODO: Link to style guide here instead, and deduplicate all of this content (or as much as possible).

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.

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).

Intake

You can quickly suggest a product idea by adding a bullet to the bottom of "Product feature requests".

Digestion of these new product ideas (requests) happens at the 🗣 Product Feature Requests meeting. This recurring meeting is located on the "Office hours" calendar.

At the 🗣 Product Feature Requests meeting, the product team weighs all requests in the agenda. When the team weighs a request, it is immediately prioritized or put to the side. The DRI for this decision is the Head of Product.

• A request is prioritized when the business decides it is an immediate 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.

Why this way?

• At Fleet, we use quarterly metrics to align the organization with measurable goals. These goals fill up a large portion, but not all, of planning (drafting, wireframing, spec'ing, etc.) and engineering capacity. This means there is always some capacity to prioritize requests advocated for by customers, Fleet team members, and members of the wider Fleet community.
• The 🗣 Product Feature Requests meeting is a recurring ritual to make sure that the team weighs all requests.
• At Fleet, we tell the requestor whether their request is prioritized or put to the side within one business day from when the team weighs the request.
• Fleet always prioritizes bugs.

Making a request

To make a request or advocate for a request from a customer or community member, Fleet asks all members of the organization to add their name and a description of the request to the list in the 🗣 Product Feature Requests Google doc. Then attend the next scheduled 🗣 Product Feature Requests meeting.

All members of the Fleet organization are required to attend the 🗣 Product Feature Requests meeting. Requests will be 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.

All 🗣 Product Feature Requests meetings are recorded and uploaded to Gong.

PFR cleanup

Each week the DRI for the 🗣 Product Feature Requests meeting resets the document to blank by doing the following:

1. Create issues for accepted items
2. Notify absent requesters of decisions
3. Move that week's feature requests to the backup journal document

Usage statistics

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

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

Rituals

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

Ritual	Frequency	Description	DRI
🗣 Product feature requests	Weekly (Tuesdays)	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.	Mo Zhu
🗣️ Product feature requests prep and cleanup	Weekly (Tuesdays)	Every week a backup doc is created to accompany the 🗣️ Product Feature Requests event	Mo Zhu
🗣 Product office hours	Weekly (Thursdays)	Ask questions to the product team	Mo Zhu
Sprint release notes kick-off meeting	Triweekly (Wednesday)	Communicate high-value features from the current sprint to prepare release blog post and drumbeat social posts, etc in the leadup to release at the end of each sprint. Marketing is responsible for getting what they need to publish and promote the release, including a great release post. Product is responsible for helping marketing understand what is coming early enough that there is time to prepare.
⚗️✨🗣 Design review (MDM)	Daily	Review designs from the MDM team	Noah Talerman
⚗️✨🗣 Design review (CX)	Daily	Review designs from the CX team	Zay Hanlon
⚗️✅🎉Product confirm and celebrate	Weekly	Product teams gets together to review work completed	Mo Zhu
⚗️ Sprint release notes kickoff	Tri-weekly	Product provides recommended features to highlight for the current sprint to enable the Marketing team to start writing release notes	Mo Zhu

Slack channels

This group maintains the following Slack channels:

Slack channel	DRI
#help-product	Mo Zhu
#g-mdm	Noah Talerman
#g-cx	Zay Hanlon