Product cycle decision

# Product cycle decision

## Goal

Close the current product-development loop by deciding what the evidence supports next: expand the released capability, iterate on it, maintain it at its current scope, recommend rollback, plan retirement, or restart discovery.

Shipping is not completion. Adoption is not automatically value. A supported outcome is not automatic permission to scale, and a disappointing result is not automatic permission to build more.

This is decision synthesis for an existing product and codebase. Do not change the roadmap, create external tickets, modify code, deploy, change flags, roll back, retire a feature, migrate data, alter contracts, publish, message users, or contact anyone.

Complete the decision autonomously. Do not stop to ask clarifying questions. When evidence is incomplete, choose the option that preserves current safety and reversibility, expose the unknown, and set a bounded review condition. Do not invent traction, outcomes, demand, cost, or strategic value to force momentum.

## Inputs

Locate and read:

* all applicable `AGENTS.md` files
* the originating discovery evidence, opportunity decision, product contract, prioritization record, and accepted scope
* implementation, acceptance, test, architecture, accessibility, security, privacy, and release evidence
* rollout plan plus `docs/product/rollout-observation.*`, including verified execution, incidents, exposure, deviations, pauses, and rollback records
* adoption-enablement plan and observed intervention evidence
* outcome-measurement analysis, data-authority ledger, cohort maturity, comparison, guardrails, and causal limits
* friction diagnosis, competing hypotheses, severe risks, and bounded response when diagnosis was required; otherwise the direct `OUTCOME SUPPORTED` handoff
* current product architecture, dependencies, operational burden, technical debt, and reversibility constraints
* authorized revenue, billing, cost-to-serve, support, implementation, infrastructure, and founder-labor evidence already in the workspace
* current ICP, market, positioning, pricing, pipeline, onboarding, retention, product feedback, and metrics in `docs/gtm/`
* product strategy, company identity, durable assets, constraints, capacity, and opportunity cost documented in the repository
* contractual, notice, accessibility, security, privacy, retention, deletion, export, portability, and end-of-service obligations
* any existing `docs/product/cycle-decision.md`, `docs/product/cycle-decision.yaml`, and `docs/product/cycle-decision-changelog.md`

Use only authorized existing evidence. A planned rollout is not exposure, a draft intervention is not enablement, a roadmap item is not product capability, and a sales request is not customer outcome.

If upstream artifacts conflict, preserve the conflict. Do not resolve it by selecting the most favorable version.

The inherited outcome decision gates entry. `OUTCOME SUPPORTED` may enter this prompt directly. `MIXED` or `NOT SUPPORTED` requires a current Product friction diagnosis with exactly one of `FIX`, `RESHAPE`, `ENABLE`, `HOLD`, or `ROLL BACK`; do not bypass diagnosis. `TOO EARLY` stops the series until its maturity condition is met. The only exception is separately `OBSERVED` active severe risk with a current `ROLL BACK` friction decision, in which case this prompt may consider rollback only. A missing or conflicting outcome decision cannot enter the cycle decision.

## 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 decision premise that has not been observed and could change the choice
* `UNKNOWN`: absent, inaccessible, immature, conflicting, unauthorized for this use, or not safely inferable

For every quantitative claim, show definition, raw counts, numerator, denominator, window, cohort maturity, calculation, source, exclusions, and limitations. Do not average across incompatible cohorts or report an immature absence of churn as retention.

Weight observed user outcome and guardrail evidence above request volume, stakeholder enthusiasm, feature usage, and sunk implementation cost. Sunk cost is context, not a reason to continue.

## Step 1: Freeze the decision record

State:

* decision date and evidence cutoff
* release and product-contract IDs
* original user, job, trigger, problem, and promised outcome
* original exclusions and non-goals
* registered success, guardrail, cost, and kill criteria
* actual authorized scope and exposure
* current outcome-measurement decision and the friction-diagnosis decision when its branch was required
* current reversibility and contractual commitments

Do not edit the original criteria after seeing results. Any new criterion is explicitly exploratory and cannot retroactively make the cycle a success.

## Step 2: Audit evidence continuity

Trace every material claim from discovery through the released result:

```text
problem evidence → product contract → delivered behavior → actual exposure
→ adoption path → mature outcome → supported outcome → cycle choice
                                  ↘ mixed or unsupported → friction diagnosis → cycle choice
```

Record broken links, including:

* a different cohort received the release
* delivered behavior differs from the contract
* enablement changed the mechanism or promise
* exposure or identity cannot be reconstructed
* outcome definitions moved
* cohorts are immature or selected after results
* GTM sold a broader job than the product delivered
* support or founder labor created the outcome outside the product
* a pricing, campaign, policy, or concurrent release confounds the result

A broken evidence chain limits the decision. Do not treat narrative coherence as proof.

## Step 3: Build the governing scorecard

Evaluate the current increment across:

* user or customer outcome against the registered threshold
* adoption at the product’s natural cadence
* reliability, performance, accessibility, safety, security, privacy, and data integrity
* support, implementation, operational, and founder labor
* infrastructure and cost-to-serve effects
* retention, renewal, or expansion only when the cohort is mature
* effect on the existing core workflow and other users
* current ICP and positioning fit
* architecture, maintainability, dependency, and reversibility burden
* durable inheritance: reusable technology, data rights, knowledge, trust, distribution, or operating capability
* opportunity cost relative to other evidenced work

For each dimension show the registered rule, observation, evidence label, limitation, and implication. Missing economics remain `UNKNOWN`; do not fill them with SaaS benchmarks. Durable inheritance must name an asset that actually exists and may legally be reused.

## Step 4: Test all six options

Evaluate every option before choosing one.

### `EXPAND`

Requires mature evidence that the capability produces the intended outcome for the current cohort without unacceptable guardrail, support, cost, trust, or legal burden. Name the adjacent eligible population or volume, why continuity is expected, added capacity required, and the gate that would stop expansion.

Do not use a successful narrow cohort as proof that every segment will behave the same.

### `ITERATE`

Requires evidence that the job and outcome remain worth serving, while a bounded implementation, shape, or enablement change can plausibly address a diagnosed friction. State the smallest next product contract and the evidence that would kill it.

Do not translate an undiagnosed weak result into a backlog.

### `MAINTAIN`

Use when the current scope creates sufficient value and is safe and supportable, but expansion or another change lacks evidence or has lower priority. Define maintenance obligations, observability, review cadence, and what would reopen the decision.

Do not use `MAINTAIN` to bypass a `TOO EARLY` stop. Preserve already authorized exposure under the prior rollout decision until the registered maturity condition, outside this cycle decision.

### `ROLL BACK`

Requires observed active harm, material regression, breached stop condition, or unacceptable risk where the approved containment or rollback path is preferable to current exposure. Separate code reversal, data remediation, contract response, and user support.

This prompt can recommend rollback; only an authorized human may execute it.

### `RETIRE`

Requires evidence that the capability’s ongoing value does not justify its cost, risk, complexity, support burden, or strategic distraction, and that removal is preferable to maintenance. Identify dependencies, affected users, data export or deletion, accessibility, contracts, notice, migration, support, and reversibility obligations.

Retirement is a planned product change, not silent abandonment.

### `RESTART DISCOVERY`

Use when the underlying problem, segment, trigger, urgency, or promised outcome is unsupported or materially different from what was built. Preserve what was learned, explicitly reject unsupported premises, and return to real problem evidence before another implementation cycle.

Do not rename iteration as discovery to avoid acknowledging a failed premise.

For all six options record evidence for, evidence against, prerequisites, risk, reversibility, opportunity cost, and why it won or lost.

## Step 5: Check portfolio and GTM continuity

Determine whether the proposed option preserves continuity of:

* customer and user job
* current product and architecture
* legally reusable data and learned evidence
* distribution, trust, and support relationships
* team capability and operating system
* company identity and long-term product direction

Then specify what Full-cycle GTM must change now:

* allowed positioning and proof claims
* audience or ICP limits
* pricing or packaging implications that require separate analysis
* sales commitments to stop, qualify, or preserve
* onboarding, support, retention, and product-feedback updates
* current availability language

Do not let GTM keep selling a behavior slated for rollback or retirement. Do not let a commercial request silently override product safety, outcome, or scope evidence.

## Step 6: Write the human decision and action envelope

The decision record must include:

* exactly one primary decision
* decision owner and required approvers
* effective date only if a human has approved one; otherwise `null`
* scope, exclusions, and constraints
* actions proposed, in sequence, for authorized owners
* actions explicitly not authorized
* next review trigger, date, or maturity condition
* measures and stop conditions for the next cycle
* communications, support, legal, privacy, accessibility, security, and data obligations

For `ROLL BACK` or `RETIRE`, require a separate human-approved impact and transition plan before execution. Include affected workflows, dependencies, required notices, contractual review, data export or deletion, migration, support, and recovery. Do not draft public claims from private customer evidence.

For `EXPAND` or `ITERATE`, route the proposed scope back through prioritization, shaping, acceptance, delivery, rollout, and outcome measurement. This decision does not skip the next cycle’s gates.

## Step 7: Desk-test the decision

Verify:

1. Original success and kill criteria did not move after results.
2. The evidence chain from problem to outcome is intact or its breaks limit the decision.
3. Outcome, adoption, guardrails, cost, labor, architecture, and GTM fit are all visible.
4. Every option was tested and explicitly rejected or selected.
5. Immature cohorts, sunk cost, enthusiasm, and request volume did not become proof.
6. Rollback and retirement obligations are treated as human-approved product work.
7. Privacy and legal authority covers every reused source and proposed downstream use.
8. The selected option has an owner, boundaries, review condition, and next-cycle handoff.
9. No roadmap, code, production, customer, or external-system action occurred.

## Decision

Choose exactly one:

* `EXPAND`
* `ITERATE`
* `MAINTAIN`
* `ROLL BACK`
* `RETIRE`
* `RESTART DISCOVERY`

Lead with:

“As of [evidence cutoff], product cycle [identifier] produced [outcome result or unknown] for [mature cohort or none], with [guardrail and burden summary]. The evidence supports [EXPAND / ITERATE / MAINTAIN / ROLL BACK / RETIRE / RESTART DISCOVERY] because [decisive evidence], while [strongest rejected option] lost because [reason]. No product, production, roadmap, or customer action was taken by this analysis.”

## Required artifacts

### 1. `docs/product/cycle-decision.md`

Lead statement, frozen decision record, evidence-continuity audit, scorecard, six-option comparison, selected and rejected options, portfolio and GTM continuity, human action envelope, desk test, and closed-loop handoff.

### 2. `docs/product/cycle-decision.yaml`

Include `version`, `status`, `as_of`, `evidence_cutoff`, `decision`, `decision_owner`, `required_approvals`, `effective_date`, `release_id`, `product_contract_id`, `original_criteria`, `actual_scope`, `evidence_continuity`, `scorecard`, `options`, `selected_reason`, `rejected_options`, `action_envelope`, `next_review`, `next_cycle`, `gtm_handoff`, `privacy_and_legal`, `assumptions`, `unknowns`, and `sources`.

Use `null` for unknown or unapproved fields with an explanation. `status: recommended` until authorized humans record approval; never mark an external action complete from a plan.

### 3. `docs/product/cycle-decision-changelog.md`

Append only. Record timestamp, version, evidence cutoff, evidence added, option comparison changes, decision, approval status, and reason. Later reversals add a new decision; they do not overwrite the historical record.

## Closed-loop handoff

Create the next product-cycle packet according to the selected decision:

* `EXPAND`: return the next eligible scope to product prioritization and a new product contract; retain the current evidence ceiling and expansion stop gate
* `ITERATE`: return the bounded friction and acceptance evidence to shaping, prioritization, and delivery
* `MAINTAIN`: preserve current scope, maintenance owner, observability, and a dated or maturity-based review trigger
* `ROLL BACK`: refer the recommendation to authorized incident and release owners; after human action, remeasure harm, restoration, and remaining obligations
* `RETIRE`: refer a reversible transition proposal to product, legal, privacy, support, and GTM owners; measure completion and user impact after authorized execution
* `RESTART DISCOVERY`: return rejected premises, observed behavior, and unanswered questions to discovery without carrying the failed solution as a requirement

Every implemented change re-enters delivery verification, adoption enablement, rollout planning, rollout observation, and outcome measurement. A supported outcome then enters this cycle decision directly; a mixed or unsupported outcome enters through friction diagnosis first.

Send Full-cycle GTM an evidence-bounded write-back: current availability, supported outcome claims, unsupported claims, ICP implications, onboarding and support changes, retention consequences, product-feedback disposition, and any offer or messaging that must stop. GTM returns new market, sales, onboarding, retention, and support evidence to the next product cycle without promising a roadmap result.

The cycle is closed only when both product and GTM use the same current-product truth and the next decision preserves the historical evidence trail.

## Boundaries

* Do not change the roadmap, create external tickets, modify code, deploy, change flags, roll back, retire, migrate, publish, message, or contact anyone.
* Do not invent deployments, users, cohorts, telemetry, adoption, outcomes, demand, costs, retention, customer evidence, approvals, or strategic assets.
* Do not reuse customer, support, research, or personal data outside its authorized purpose.
* Do not expose personal information, sensitive traits, secrets, or identifying small cohorts.
* Do not count immature cohorts as success, failure, or retention.
* Do not let sunk cost or stakeholder preference outrank outcome and guardrail evidence.
* Do not skip human legal, privacy, security, accessibility, support, or contractual review.
* Preserve uncertainty, reversibility, and human decision authority.

## Done when

* The original decision criteria, actual release scope, evidence continuity, and governing scorecard are explicit.
* Every material claim uses `OBSERVED`, `DERIVED`, `ASSUMED`, or `UNKNOWN`.
* All six options were tested with evidence for, against, prerequisites, risk, and reversibility.
* Exactly one allowed decision is selected and the strongest alternative is explicitly rejected.
* Human owners, approvals, action limits, legal and privacy obligations, and the next review are named.
* The Markdown, YAML, and append-only changelog agree.
* The handoff starts the appropriate next product cycle and writes the current truth back to Full-cycle GTM.