Product adoption enablement

# Product adoption enablement

## Goal

Design the smallest truthful enablement system that helps eligible users discover, understand, try, complete, and repeat an accepted product workflow until they reach the intended outcome.

Exposure is not adoption. A click is not comprehension. Feature use is not value, and a support-assisted success is not self-serve adoption unless the labor is named.

This is planning and operating design for an existing product. Do not change product code, alter production configuration, launch an experiment, publish documentation, send messages, contact users, create accounts, or manipulate telemetry.

Complete the analysis autonomously. Do not stop to ask clarifying questions. When the accepted product cannot complete the promised workflow, choose `REVISIT PRODUCT`. When adoption or authorization evidence is missing, preserve it as `UNKNOWN` and narrow or hold the plan.

## Inputs

Locate and read:

* all applicable `AGENTS.md` files
* the approved product contract, opportunity, outcome, and acceptance criteria
* `docs/product/acceptance-verification.md`, `docs/product/acceptance-verification.yaml`, and `docs/product/acceptance-verification-changelog.md`
* the accepted implementation and release candidate, plus any verified release record when one already exists
* any existing rollout plan, actual rollout observations, incidents, deviations, and current availability rules
* current onboarding, navigation, empty states, help, accessibility, and in-product guidance
* approved event definitions and instrumentation documentation
* authorized product-usage extracts, support records, usability research, and customer feedback already present in the workspace
* implementation, training, support, and founder-labor records
* current ICP, positioning, pricing, sales commitments, onboarding, retention, and product-feedback artifacts in `docs/gtm/`
* applicable consent, communication, accessibility, contractual, privacy, retention, deletion, and data-processing requirements
* any existing `docs/product/adoption-enablement.md`, `docs/product/adoption-enablement.yaml`, and `docs/product/adoption-enablement-changelog.md`

Use only authorized existing evidence. Do not query live accounts, add tracking, scrape user behavior, reuse support content for marketing, or assume a rollout stage occurred because it was planned.

Proceed only from `ACCEPT` or `ACCEPT WITH LIMITS`, inheriting the exact accepted boundary. An inherited `HOLD` or `REJECT` forces `HOLD` or `REVISIT PRODUCT`; enablement cannot cure an unaccepted product increment.

If a verified release record is absent, you may prepare a pre-release enablement plan, but label all availability and behavior claims `ASSUMED` or `UNKNOWN`, set `status: planned`, and do not report adoption.

## Evidence standard

Label every material claim with exactly one shared product-evidence label:

* `OBSERVED`: directly supported by an identified, authorized source
* `DERIVED`: calculated or logically produced from identified `OBSERVED` inputs, with the method shown
* `ASSUMED`: a planning premise that has not been observed and could change the decision
* `UNKNOWN`: absent, inaccessible, immature, conflicting, or not safely inferable

For every rate, show raw counts, numerator, denominator, eligibility rule, window, cohort maturity, exclusions, and data limitations. An absence of tickets is not proof of comprehension. A low-use feature may be undiscoverable, irrelevant, unavailable, or poorly measured.

Do not infer user intent from a single event. Do not turn an interview quote, sales request, or planned message into observed adoption.

## Step 1: Define the adoption ladder

Start with the product outcome and define each distinct state:

* eligible: the accepted release candidate is appropriate for the user or account; availability remains planned until rollout is observed
* exposed: the user had a real opportunity to encounter it
* aware: there is authorized evidence the user recognized the capability
* attempted: the user began the intended workflow
* completed: the user completed the product action as defined
* valued: the intended user or business outcome occurred or was credibly measured
* repeated: the workflow recurred at its natural cadence when recurrence is part of the job

For every state specify the unit, event or evidence, denominator, natural time window, and known ambiguity. Do not collapse login, click, completion, and value into one activation event.

If the product is episodic, define adoption at the job’s actual cadence. Quiet periods without a job trigger are not automatically abandonment.

## Step 2: Identify eligible cohorts and exclusions

Describe who should be enabled using the approved product contract and accepted release boundary or current availability—not a broader market aspiration.

For each cohort record:

* user job, role, account context, and triggering situation
* prerequisite permissions, data, integration, or workflow state
* current release stage and evidence that the cohort is eligible
* expected adoption cadence
* known accessibility, language, device, or operational needs
* explicit exclusions and why exposure would be irrelevant or unsafe
* sample maturity and whether the cohort is large enough to analyze without exposing individuals

Do not target, personalize, or compare enablement using protected or sensitive attributes unless the use is documented as lawful, necessary, consented where required, and human-reviewed. Prefer job and workflow state over identity traits.

## Step 3: Map the actual path to value

Trace the shortest current path from an eligible user’s trigger to the intended outcome. Use the accepted implementation or verified released product, not the roadmap.

For each step record:

* user intent and required input
* product behavior and expected feedback
* owner when human assistance is required
* observable completion signal
* known failure and abandonment evidence
* accessibility and comprehension risk
* time, effort, and context switching
* support, services, or founder labor
* evidence label

Separate product friction from missing prerequisites, organizational approval, enablement gaps, and a job that does not matter. If value requires undocumented or unscalable human work, make that labor visible.

## Step 4: Design enablement interventions

Choose the fewest interventions that address an identified step. Options may include in-product context, onboarding, examples, help content, training, support playbooks, lifecycle communication, or a GTM handoff, but do not include an intervention merely because the channel exists.

For each proposed intervention specify:

* stable ID and the adoption state it is meant to change
* evidence-backed friction or an explicit `ASSUMED` hypothesis
* eligible audience and exclusion rule
* trigger and timing tied to the user’s job
* single next action
* current-product claim and source
* owner and required human approval
* frequency cap, dismissal, accessibility, and opt-out behavior
* measure, guardrail, observation window, and kill condition
* support capacity and ongoing maintenance cost

Draft language may be included, but mark it `DRAFT — NOT SENT OR PUBLISHED`. It must not imply universal availability, guaranteed outcomes, customer endorsement, or roadmap commitments.

Do not use forced actions, disguised ads, guilt, artificial urgency, obstructive defaults, or repeated prompts that trade user trust for clicks. Enablement should help a user complete a job, not inflate a feature metric.

## Step 5: Pre-register the adoption measurement

Define how a later analysis can distinguish:

* eligible but not exposed
* exposed but unaware
* aware but not attempted
* attempted but not completed
* completed but not valued
* valued once but not repeated
* assisted versus unassisted completion

For each transition state the source, identity resolution method, denominator, window, maturity rule, and data-quality limitation. Use an existing event only when its semantics are documented. If the event is missing or ambiguous, mark it `UNKNOWN` and specify the smallest future instrumentation requirement without implementing it.

Pre-register primary adoption behavior, intended outcome, guardrails, support burden, and possible confounders. Do not optimize a proxy without measuring whether it connects to value.

## Step 6: Check data rights and communication authority

For every source and proposed intervention, document:

* authorized purpose and provenance
* consent or other lawful basis where relevant
* contractual and data-processing restrictions
* permitted audience and channel
* data minimization, access, retention, deletion, and residency requirements
* whether support, research, or usage data may legally and ethically be reused for this decision
* whether a human legal, privacy, security, accessibility, or customer owner must approve it

Do not copy personal data, message content, secrets, or sensitive traits into the artifacts. Aggregate or de-identify where possible. Small cohorts that could identify a person must be suppressed or reported qualitatively. A repository artifact is not permission to contact anyone.

## Step 7: Align product and Full-cycle GTM

Create a handoff table covering:

* in-product guidance owned by product
* help and support material owned by the authorized operator
* onboarding and implementation changes proposed to Full-cycle GTM
* positioning or sales language that remains permitted
* claims GTM must stop or qualify after the release
* feedback signals GTM should return without promising a feature

The product path and GTM promise must describe the same current behavior. If enablement requires selling a future capability, return `REVISIT PRODUCT` or remove the promise.

## Step 8: Desk-test the system

Verify:

1. Adoption is a path to an outcome, not a click target.
2. Eligibility is supported by actual availability or clearly marked as planned.
3. Every intervention addresses named evidence or a falsifiable assumption.
4. The plan uses the current product and exposes all human labor.
5. Measurement separates exposure, attempt, completion, value, and recurrence.
6. Privacy, accessibility, consent, communication, and frequency controls are explicit.
7. No message was sent, no product surface changed, and no telemetry was added.
8. Full-cycle GTM receives only approved current-product claims.

## Decision

Choose exactly one:

* `ENABLE`: the complete enablement plan is ready for authorized human implementation and execution
* `ENABLE NARROWLY`: only the named cohort, path, or intervention is supportable
* `HOLD`: acceptance evidence, authorization, instrumentation, or operating capacity is insufficient
* `REVISIT PRODUCT`: the accepted workflow, value path, reliability, or product contract must change before enablement can solve the problem

This decision authorizes nothing by itself.

Lead with:

“As of [date], the adoption path for [accepted release candidate or verified released workflow] moves eligible [cohort] from [trigger] to [intended outcome] through [N] observed or assumed steps; the primary blocker is [blocker or unknown], decision [ENABLE / ENABLE NARROWLY / HOLD / REVISIT PRODUCT]. No user was contacted and no production change was made.”

## Required artifacts

### 1. `docs/product/adoption-enablement.md`

Lead statement, evidence standard, adoption ladder, cohorts, current path to value, intervention plan, measurement registration, data-rights review, product/GTM ownership, desk test, decision, and handoff.

### 2. `docs/product/adoption-enablement.yaml`

Include `version`, `status`, `as_of`, `decision`, `release_id`, `product_contract_id`, `outcome`, `adoption_states`, `cohorts`, `exclusions`, `path_to_value`, `frictions`, `interventions`, `measures`, `guardrails`, `capacity`, `data_rights`, `human_approvals`, `gtm_handoff`, `assumptions`, `unknowns`, and `sources`.

Use `null` for unknown values with an explanation. Use `status: planned` until authorized execution evidence exists.

### 3. `docs/product/adoption-enablement-changelog.md`

Append only. Record timestamp, version, changed definitions or interventions, evidence added, decision, and reason. Do not rewrite a past cohort definition to improve a later rate.

## Closed-loop handoff

Hand the plan to the named product, support, accessibility, privacy, and communication owners for human approval and execution. Before exposure, pass the planned artifacts to Product release readiness; `ENABLE` or `ENABLE NARROWLY` does not override that release gate. Require later observed records of what was actually released, shown, sent, or delivered before treating an intervention as active.

When a cohort has reached the pre-registered maturity window, pass authorized rollout and adoption evidence—not the plan—to Product outcome measurement. Pass recurring objections, comprehension gaps, support load, and claim corrections to Full-cycle GTM’s onboarding, retention, collateral, and product-feedback artifacts.

If the decision is `REVISIT PRODUCT`, return the failed value-path step to product prioritization and delivery. The resulting release must re-enter adoption enablement and rollout planning. Outcome measurement goes directly to the product cycle decision when supported, through friction diagnosis when mixed or unsupported, and stops when too early.

## Boundaries

* Do not change code, flags, configuration, telemetry, documentation, or production data.
* Do not publish, send messages, contact users, or create accounts.
* Do not invent releases, eligibility, users, behavior, support volume, adoption rates, outcomes, or endorsements.
* Do not repurpose support, research, or customer data without documented authority.
* Do not expose personal data or report identifying small cohorts.
* Do not use dark patterns or optimize clicks at the expense of value or trust.
* Do not make GTM promises the current product cannot honor.
* Preserve uncertainty and human decision authority.

## Done when

* Eligibility, the adoption ladder, the current path to value, and exclusions are explicit.
* Every material claim uses `OBSERVED`, `DERIVED`, `ASSUMED`, or `UNKNOWN`.
* Each intervention has evidence, an owner, approval, measurement, guardrail, and kill condition.
* Privacy, legal, accessibility, data-reuse, and communication limits are documented.
* The Markdown, YAML, and append-only changelog agree.
* The decision uses one allowed value and the handoff closes the loop to outcome measurement, the next product cycle, and Full-cycle GTM.