Exposure Plans

Exposure Plans

An Exposure Plan turns a feature spec's hypothesis into an ordered set of reveal levels. Each level adds a visible layer of the product and tests one belief. It answers: what becomes visible, in what order, to whom, under what belief.

Core mental model

• Build ≠ Reveal. The Exposure Plan controls what becomes visible, independent of how the code lands. Default mechanism: build whole, flip layers on with feature flags. Incremental development (no flags, ship each layer as built) is a lighter alternative only when every level exposes to the entire deployment population AND the coding agent maintains context across iterations. The plan suggests a mechanism; engineering owns the final call.
• Each level accumulates. Level 2 includes everything in Level 1. You never remove something that was revealed; you add.
• Each level tests one belief. One clear falsifiable claim per level, written from the user/business perspective, never technical.
• The set of beliefs validated across levels = the spec's hypothesis resolved.
• Audience characterization, not traffic percentages. Describe who is exposed by behavior or role ("active users with 3+ sessions in the last 2 weeks"), never by technical cohort ("10% of traffic").

Terminology (strict)

• Bet / belief / assumption — level-scoped claims. Reserve "hypothesis" for the spec-level hypothesis being resolved.
• Value = desirability + utility: will users want this, use it, get something real from it?
• Viability = will this work for the business (economics, operations, support, legal)?
• Level = one accumulative reveal step that tests one belief.
• Validation = the success criterion for a level: what evidence says "advance", what says "stop".

Language

Write the plan in the same language as the spec. If Spanish spec → entire output in professional neutral Spanish (no voseo: "divide", not "dividí"), including section titles and level names.

Workflow

Step 1 — Locate or confirm the hypothesis

Use the spec's ## Bet / ## Hypothesis sections verbatim if present. If absent, derive an implicit hypothesis in one sentence from the Overview + Success Criteria, show it to the user, and ask them to confirm or correct it before continuing. If proceeding without confirmation, prepend the plan with: > ⚠ Derived hypothesis — confirm before validating. (in the spec's language).

Step 2 — Decompose the hypothesis into sequenced beliefs

Quality bar for a belief:

• Active-voice claim: "Users understand…", "Customers act on…".
• Falsifiable — describable evidence could make the team say "no, this didn't hold".
• User/business framing — not "the system detects patterns correctly" but "users find the detected patterns actionable enough to change what they do next".
• Load-bearing — if belief N fails, belief N+1 is uninterpretable or irrelevant. Order accordingly.

Step 3 — Decide how many levels

• Single-capability feature: 1 level may be enough.
• Typical feature: 2–4 levels.
• Large feature with loosely-coupled modules: up to 5.
• Never exceed 5. If 6+ feel necessary, the feature is too big — say so in open questions and suggest splitting the spec.

Each level must add something user-visible. Not internal polish, not pipeline work.

Step 4 — Write each level

• Level name — what's revealed, from the user's lens. Short.
• What is revealed — concrete list of what's visible, including what is deliberately still dark.
• Belief — the one falsifiable claim this level tests.
• Audience — who is exposed, by behavior or role.
• Duration — typically 1–3 weeks.
• Validation — Advance if: evidence the belief held. Stop if: evidence it didn't.

Keep each level dense and short — grasped in under 30 seconds, no sub-sections.

Step 5 — Reveal mechanism

If the user expressed a preference (flags or incremental), adopt it — binding, don't argue, don't switch silently — but honestly note fit in 2–3 lines (e.g., "incremental was chosen, but Level 2 targets a behavioral sub-cohort which incremental can't deliver").

Otherwise recommend one: feature flags by default; incremental only when no level needs sub-cohort targeting AND the coding agent maintains context across iterations. Name the driver explicitly.

Step 6 — Close

• Parallel validations — viability risks (operational cost at scale, regulatory exposure, partner dynamics) and precondition risks needing non-product investigation alongside the reveal. One or two sentences each.
• Open questions for the product team — what the plan can't resolve alone: audience recruitment constraints, internal team capacity, existing data that could reduce early risk.

Output

Markdown, saved to product/exposure-plans/{YYYY-MM-DD-HHMM}-{spec-slug}.md (timestamp = creation date; revise in place without renaming). No preamble, no closing fluff — the document IS the response.

Anti-patterns

• Levels as audience cohorts. A level is a product layer turning on, not a different group being exposed.
• Technical rollout plans. Recommending the mechanism is in scope; naming flag platforms, canary infra, or deployment rings is not.
• Viability beliefs as levels — they go in Parallel validations.
• More than one belief per level.
• Vague validations. "See how it goes" is not a validation; validations have a concrete threshold and an advance/stop decision.
• Treating the spec's claims as facts. "Users will return weekly" is a belief to test, not a given.
• Mixed languages.