LLenny's Podcast
← All frameworks
InnovationMatt MacInnis (Rippling)

The Pickle: Iterated Product Quality List

A lightweight, memorably-named ship checklist you grow one line at a time from every miss.

Difficulty
Moderate
Time to result
~months to results
Steps
4
Confidence
92%

A ship-gate quality mechanism plus a culture-change technique. The 'Pickle' (Product Quality List / PQL) is a lightweight checklist of the standards a product must meet at ship, run as a 'factory inspection' before a product 'rolls off the assembly line.' You iterate it by adding one line every time something slips through. The deliberately odd name is the second half of the framework: to change culture you create a vessel for meaning and fill it.

Origin

MacInnis built the Pickle while fixing Rippling's 'locally optimized, globally incoherent' product org. The name is a pun on PQL (product quality list) → 'pickle.' A live example: Parker Conrad installed a new feedback app and hit a blank screen because a feature flag was left on, so MacInnis added a Pickle line capping products at one feature flag at ship.

Core principles

  • 01Everything must be done in its time and order — establish basic ship standards (test coverage, quality checklist) before chasing higher-order metrics like adoption.
  • 02Keep the checklist lightweight: it states standards in the simplest way, and not every line applies to every product.
  • 03Iterate the list in response to everything you learn; each escaped defect becomes a new line.
  • 04To make change stick in a large org, coin an idiosyncratic 'vessel for meaning' and fill it with your definition.
  • 05It lowers the system's beta with only a modicum of cost to alpha.

How to run it

  1. 1

    Create the vessel

    Name the standard something angular and idiosyncratic (Pickle, not 'quality checklist') so new joiners know it's unique to you and it enters daily team vocabulary.

    Pro tip A slightly silly, memeable name (dancing-pickle Slack emoji) increases adoption, not decreases it.

  2. 2

    Fill it with lightweight standards

    Write the simplest possible articulation of what 'product quality' means at ship. Make it comprehensive but non-heavy; mark that lines are selectively applicable.

    Watch out Don't skip steps: measuring adoption metrics before basic test coverage exists is 'absolute insanity.'

  3. 3

    Run it as a factory inspection

    Before a product ships, inspect it against the list. Require a recorded Loom of every major flow; the leader personally reviews flows and gives feedback in a public channel.

    Pro tip Public review lets other teams see how the process played out and learn from it.

  4. 4

    Add a line for every escape

    When a defect slips past, give direct feedback AND ask 'how did the inspection miss this?' Then add a new checklist line so the system that builds the system improves.

    Pro tip Set aspirational standards even if not fully achievable (e.g. 'one feature flag governing the whole product at ship').

    Watch out Feature flags are 'shims' — engineers add them temporarily and forget; unmanaged, they silently break shipped products.

In the wild

The blank-screen feature flag

Parker Conrad, Rippling's sole payroll admin who dog-foods every new app, installed a new feedback product and landed on an empty screen because a feature flag was never disabled.

MacInnis added a Pickle line: one feature flag max governing the entire product at ship.

Common mistakes

Chasing adoption metrics before foundations

Pointing at high-triangle failures (bad adoption tracking) while basic test coverage and a ship checklist don't exist skips all the steps in between.

Heavy, generic process

A bloated or blandly-named checklist neither embeds in culture nor stays lightweight; it suppresses alpha without becoming zeitgeist.

Is it for you?

Best for

Product/eng leaders scaling quality across a large R&D org (Rippling has ~1,300 in R&D) who need a repeatable, evolving ship gate.

Not ideal for

Tiny early teams where a shared ship standard is overhead and pre-PMF exploration matters more than quality gates.

From the transcript

we have a product quality list. And the product quality list is lightweight in the sense that it just articulates in the simplest ways the…

30:00

you got to create an entity, a vessel for meaning, and then you got to fill that vessel with your meaning.

29:00

I added a line to the [ __ ] pickle that said you are allowed to have one feature flag that governs your entire product…

From the episode

10 contrarian leadership truths every leader needs to hear

Matt MacInnis (Rippling)