The Pilot-First Playbook

Contents

What you'll work through

Not a build order guide. A proof playbook: how to earn budget and trust by shipping on work that already has a deadline and a sponsor.

1. 01 Start here 2
2. 02 The Make System Use System trap 3
3. 03 Hitch to moving work 4
4. 04 Pilot Scorecard worksheet 5
5. 05 Five pilot types 6
6. 06 The Measuring Spoon Cycle 7
7. 07 Connected npm vs copy-paste 8
8. 08 Three concurrent pilots 9
9. 09 Hot Potato beats handoff 10
10. 10 Flow week / Systems week 11
11. 11 The store, not the catalog 12
12. 12 Pilot planning worksheet 13
13. 13 Prove it, then pitch 14
14. 14 What to do next 15

01 · Start here

Proof before the pitch deck

You do not need permission to start. You need a funded flow, three weeks, and something shipped that a product lead will defend in a steering meeting.

This playbook is for design and engineering leaders at product companies (roughly 20, 200 people) who:

• Keep losing the budget conversation to "we'll hire a design systems team later"
• Have a Figma library or Storybook that nobody imports into production
• Are sitting on a rebrand, replatform, or merger that leadership already funded

If you need readiness gates, build order, adoption rituals, and governance models, read my Survive Handoff playbook first. That guide answers what to build and in what order.

This guide answers a different question: how do you prove the system on real product work before anyone funds a dedicated team?

I led Aurora at Nord/NordVPN (dozens of teams, millions of users). Every time we scaled, proof on a live product beat a prettier roadmap.

02 · The Make System Use System trap

"Build it and they will come" is a fantasy

The default corporate playbook fails in the same order every time. You have probably seen it.

1. Pitch leadership with ROI slides and competitor screenshots
2. Win budget for an abstract "foundation" nobody ships against
3. Launch a comprehensive library in a big reveal
4. Mandate adoption while squads are underwater on feature work
5. Ask those same squads to contribute back while understaffed
6. Watch usage flatline within two quarters

Call it the Make System Use System fantasy: if we just make a really good system, people will use it. Duh!

It ignores three realities:

• Least effort wins. Under deadline pressure, teams reach for what they already know. Your library is unfamiliar until it ships something they needed yesterday.
• Abstract bloat. Palettes and primitives built for hypothetical futures do not survive contact with one real checkout flow.
• Zero slack. Adoption and contribution are two behavior changes. Most squads cannot absorb both at once.

03 · Hitch to moving work

Board the train that's already leaving

A pilot without product pressure is a side project. Side projects do not survive the next reorg.

Look for inflection-point work that already has budget, a sponsor, and a deadline:

• Rebrand or visual refresh landing in Q3
• Replatform or migration (monolith to micro-frontends, legacy stack swap)
• M&A integration forcing two UIs to look like one company
• New market launch with a greenfield surface
• Compliance push (accessibility, localization) with executive air cover

Your ask to the product lead is not "help me build a design system." It is: "Let us standardize this flow so your team ships faster and your launch date holds."

Reframe the conversation around schedule risk, not consistency theater. Velocity-measured teams fund what protects their roadmap.

DACH replatform waves are ideal Raiders hosts: funded engineering motion, visible UI drift, and leadership already paying for the refactor.

04 · Pilot Scorecard worksheet

Turn politics into a ranked backlog

Eight factors, scored 0, 10 each. Highest total goes first. Run this live with PM and engineering in the room.

Disagreement on scores is data. A 3 on receptiveness tells you to pick a different host or change the pilot type.

I ship a blank scorecard in every audit readout. It is the bridge from diagnostic to funded pilot.

05 · Five pilot types

Match the pilot to the political terrain

Not every host squad wants a design system embedded in their sprint. Pick the type that fits the work and the room.

06 · The Measuring Spoon Cycle

Make product, then extract, then reuse forever

The system is not the textbook. It is the margin notes from real builds.

Think of a well-worn measuring spoon in a kitchen: forged from daily use, shaped by what you actually cook. Your design system should grow the same way.

1. Make product. Ship the pilot flow on the host team's deadline. Use whatever components exist. Note every snowflake.
2. Extract. Pull reusable pieces into the system package. Document what you learned in production, not in a vacuum.
3. Reuse. Import those pieces into the next pilot. Measure whether the second host ships faster.
4. Repeat. Each cycle hardens the canon. The library stops being theoretical.

Apply the three-times rule before you systematize a snowflake: if three squads need the same pattern, promote it. If one team needed it once, leave it local.

07 · Connected npm vs copy-paste

Bootstrap is a download. Your system should be a package.

How product teams consume your system predicts whether pilots stick or drift within a quarter.

Audit question I ask on every diagnostic: "How do squads consume your system today?" Copy-paste is a red flag. Connected consumption is a green flag.

Pilots fail quietly when extraction stops at Figma. The proof point leadership remembers is merged code in a product repo, importing a package version they can point to in a release note.

• Publish from day one, even if the package only exports three components
• Semantic versioning from v0.1.0: signal that change is managed
• Pair Figma Code Connect or Storybook with the same version tag

At Nord scale, connected distribution was the difference between a library people admired and a library people shipped.

08 · Three concurrent pilots

One pilot's components rarely fit the second channel

Multichannel orgs that run pilots sequentially often wait 18 months to learn the web components do not fit mobile or marketing.

If you ship across web app, marketing site, and mobile (or admin + customer-facing), plan three concurrent pilots with a small dedicated system team (even 2, 3 people):

• Pilot A: Core product flow (often Raiders on a replatform)
• Pilot B: Marketing or docs surface (often Perimeter or Facelift)
• Pilot C: Secondary product or internal tool (Surrogate if partnership is weak)

Run the same Pilot Scorecard for each channel. Expect different winners. That is the point.

Sequential single pilots are fine for single-surface startups. For 20, 200 person product companies with multiple UIs, parallel pilots are cheaper than a false start.

Minimum viable design system after pilot one: three components teams can import Monday morning. Not a catalog. A wedge.

09 · Hot Potato beats handoff

Pass work in hours, not weeks

Pilots die in the gap between "design approved" and "engineering started." Hot Potato closes that gap.

The workflow is simple: designer and engineer work in the same session (virtual counts). The engineer drives implementation early. Work passes back and forth like a hot potato, same day.

1. Designer explores inside code-friendly constraints (real tokens, real breakpoints)
2. Engineer stubs the component in the product repo while pixels are still cheap to move
3. Designer refines in Figma or directly in Storybook against the stub
4. Engineer surfaces system gaps (missing variant, unclear token) before the PR is "done"
5. Ship to the host squad's branch before the standup ends

This is the studio wedge in one ritual: design intent survives handoff because handoff barely exists.

Still running waterfall comps? Pair this with my Design × Development Collaboration guide.

10 · Flow week / Systems week

You cannot ship product and harden the system at full throttle simultaneously

Alternate weeks. Product delivery, then extraction. WordPress teams figured this out years ago; it still works.

Without protected Systems weeks, extraction gets sacrificed every sprint. The library stays a side project.

• Put "Systems week" in the retainer contract or team charter: billable, protected, reported
• End each Systems week with a short extraction report: what landed in the package, what version shipped
• Alternate even when it feels slow. Flow without Systems creates debt. Systems without Flow creates shelfware.

11 · The store, not the catalog

Sell the Millennium Falcon kit, not loose bricks

Nobody walks into a Lego store asking for a 2×4 brick in #C91A09. They walk in for a kit they can build this weekend.

Most reference sites are parts warehouses: 47 button variants, alphabetized. Pilots need a store: assembled products teams can ship from.

Structure your docs around what squads actually build:

• Recipes: "Billing settings page" with components nested inside
• Templates: Starter frames for onboarding, empty states, error flows
• Flows: End-to-end patterns with copy, states, and accessibility notes

Components live inside those products, not at the top level. A PM browsing your site should recognize their roadmap, not a design textbook.

12 · Pilot planning worksheet

Plan the first 3, 4 weeks

Fill this before you embed. One row per week. Share it with the host PM so scope stays honest.

Need a day-by-day build plan after the pilot proves out? See my 100-Day Playbook.

13 · Prove it, then pitch

Bring shipped code to the steering committee

The second funding conversation should open with a merged PR, not a Figma link.

What leadership needs to see after pilot one:

• A production flow importing your package at a pinned version
• One metric moved (even 15% faster build time on the host flow counts)
• A ranked Pilot Scorecard showing where pilot two and three will land
• A Flow/Systems week rhythm the host squad will defend

What to ask for next:

1. Two more concurrent pilots (if multichannel)
2. A named system owner (even 0.5 FTE to start)
3. Protected Systems weeks on the roadmap
4. Budget for connected tooling (CI, visual regression, docs hosting)

Run the 40-Point Audit before pilot two if you need an objective health baseline. Reds become the extraction backlog.

14 · What to do next

Want help running your first pilot?

I help DACH and EU product teams prove design systems on funded work, then scale what ships.

16+ years · Nord/NordVPN design systems (dozens of teams, millions of users on Aurora) · React/TypeScript · 1st place, Into Design Systems AI Hackathon 2026