How They Do ItBETA

COMPANY PLAYBOOK

Fleet

Fleet uses independent verification for quality, continuous planning for product flow and written transition criteria for sales opportunities.
Operating system
  1. Work intake
  2. continuous board flow
  3. independent QA evidence
  4. release; sales opportunity
  5. written exit criteria.

System principles

  • Separate the maker from the verifier.
  • Separate planning from the release batch.
  • Tie stage transitions to observable conditions.

Tensions and trade-offs

  • Independent QA reduces defects but depends on another person’s availability.
  • Written control points create visibility but can add friction to smaller work.

PRACTICES

How Fleet builds its operating system

01
Quality

Independently test changes on QA Day

The maker does not QA their own change; two independent tests are required. The tester records steps in the issue and moves the work toward release readiness or back for rework.

How it works
The QA owner joins the issue; small failures become separate bugs, larger ones return work to In progress and notify the product group.
Why it is used
Makes test evidence independent from the change author and traceable.
Trade-off
Two separate tests and retesting can lengthen delivery.
Best fit
Product teams with capacity for independent pre-release verification.
Open original source
02
Production flow

Plan continuous flow from right to left

Product groups use continuous intake-to-release flow rather than sprint batches; weekly planning examines the board backwards from Ready for release and triages Inbox.

How it works
The planning rhythm is separate from the three-week release boundary; completed work enters the release queue.
Why it is used
Makes near-done work and bottlenecks visible before starting more.
Trade-off
Continuous flow depends on intake prioritization and board discipline.
Best fit
Product groups with continuous intake and regular releases.
Open original source
03
Decision making

Advance sales opportunities through written exit criteria

The sales handbook ties discovery and scope stages to a recorded use case, budget, dated next step and success criteria approved in writing by the prospect.

How it works
Stage conditions include probabilities and time windows; a demo alone does not qualify as completed discovery.
Why it is used
Replaces assumed sales progress with customer-confirmed context.
Trade-off
CRM fields and written prospect confirmation add work and waiting to the sales cycle.
Best fit
B2B sales teams with multi-stage technical discovery.
Open original source
04
AI-assisted work

AI is expected, accountability stays human: read every line

Fleet expects engineers to use Claude Code in their daily workflow. In return, no AI-generated work (code, blog posts, handbook edits, customer emails) ships until both author and reviewer have read and understood it line by line; multiline product changes are run locally and the PR is opened from the person’s own GitHub account, not a bot.

How it works
AI output is treated as “cognitive debt”: the author pays it before opening the PR, the reviewer before approving. AI review tools (Copilot, CodeRabbit, Qodo, BugBunny) supplement human review but do not take over accountability.
Why it is used
When writing code gets cheap, the value of review is the guarantee that a human read and understood every line, not the findings; attributing the commit to a person keeps ownership.
Trade-off
Reading every line gives back part of the speed AI adds; the source defines no audit or metric showing the rule is followed.
Best fit
Software teams making AI use expected or widespread while keeping quality accountability with individuals.
Open original source
05
Product

Feature Fest: no backlog, only work that fits the next three-week release

Fleet accepts product requests continuously but keeps no feature backlog: a story is prioritized only if it can ship in the upcoming three-week release. Requests are decided at the Feature Fest meeting; a request not prioritized is treated as rejected for now and can be resubmitted. A request must meet at least one of four criteria: a small UX improvement, a company or product maturity goal, a “core” feature, or a “context” feature that one customer considers mission critical.

How it works
The feature-prioritization DRI weighs requests at Feature Fest, and the Head of Product Design triages new ones daily. Core features rank above context features; a context feature can jump ahead only if it is a customer promise or a P0–P2 customer request. The requester is told the decision; prioritized work is delivered or the requester hears about de-prioritization within one business day. Urgent requests can go straight to the Head of Product Design.
Why it is used
To avoid the false promises and staleness of a long backlog, and to give every request a quick, clear yes or “not now”.
Trade-off
The burden of resubmitting a rejected request falls on the requester, and work that does not fit three weeks has to be split to get in. Single-customer features only advance through the exception rule. The page shows no visible date and no measured outcome.
Best fit
Small product organizations with a short, fixed release cycle and a single named decision owner.
Open original source

Primary sources

Fleet product groups — continuous flowCompany-published operating handbook
Source details
Company publication: YesAccessed: 2026-09-23Visible update: 2026-09-22 (repository path commit; not page update)Licence: Site footer says CC BY-SA 4.0; repository LICENSE describes docs/ as CC BY-SA 4.0 and other paths as MIT. Handbook path license is unresolved; only original factual paraphrases and links are used.Archive: Public handbook page with a stable route; eligible for an external web snapshot (no snapshot is claimed).
Fleet releases — QA DayCompany-published operating handbook
Source details
Company publication: YesAccessed: 2026-09-23Visible update: 2026-09-07 (repository path commit; not page update)Licence: Site footer says CC BY-SA 4.0; repository LICENSE describes docs/ as CC BY-SA 4.0 and other paths as MIT. Handbook path license is unresolved; only original factual paraphrases and links are used.Archive: Public handbook page with a stable route; eligible for an external web snapshot (no snapshot is claimed).
Fleet sales — opportunity stagesCompany-published operating handbook
Source details
Company publication: YesAccessed: 2026-09-23Visible update: 2026-04-01 (repository path commit; not page update)Licence: Site footer says CC BY-SA 4.0; repository LICENSE describes docs/ as CC BY-SA 4.0 and other paths as MIT. Handbook path license is unresolved; only original factual paraphrases and links are used.Archive: Public handbook page with a stable route; eligible for an external web snapshot (no snapshot is claimed).
Fleet communications — you own the outputCompany-published operating handbook
Source details
Company publication: YesAccessed: 2026-09-27Visible update: 2026-09-03 (sitemap lastmod; not page update)Licence: Site footer says CC BY-SA 4.0; repository LICENSE describes docs/ as CC BY-SA 4.0 and other paths as MIT. Handbook path license is unresolved; only original factual paraphrases and links are used.Archive: Public handbook page with a stable route; eligible for an external web snapshot (no snapshot is claimed).
Fleet — why read every line of AI-generated workCompany-published operating handbook
Source details
Company publication: YesAccessed: 2026-09-27Visible update: 2026-09-16 (sitemap lastmod; not page update)Licence: Site footer says CC BY-SA 4.0; repository LICENSE describes docs/ as CC BY-SA 4.0 and other paths as MIT. Handbook path license is unresolved; only original factual paraphrases and links are used.Archive: Public handbook page with a stable route; eligible for an external web snapshot (no snapshot is claimed).
Fleet engineering — AI coding toolsCompany-published operating handbook
Source details
Company publication: YesAccessed: 2026-09-27Visible update: 2026-09-22 (sitemap lastmod; not page update)Licence: Site footer says CC BY-SA 4.0; repository LICENSE describes docs/ as CC BY-SA 4.0 and other paths as MIT. Handbook path license is unresolved; only original factual paraphrases and links are used.Archive: Public handbook page with a stable route; eligible for an external web snapshot (no snapshot is claimed).
Fleet Handbook: Product groups (Feature Fest)Company handbook page
Source details
Company publication: YesAccessed: 2026-10-15Visible update: Not displayed (no visible update date on the page)Licence: No reuse licence displayed for this page; treat page prose as copyrighted/all rights reserved.Archive: Public HTML URL; eligible for an external web snapshot (no snapshot is claimed).