{
  "schema_version": 1,
  "skill_name": "product-lifecycle",
  "evals": [
    {
      "id": "new-product-complete-lifecycle",
      "prompt": "We have an idea for a new product: a privacy-first personal finance dashboard that aggregates bank accounts, credit cards, and investments into a single view. The founders have strong opinions but haven't talked to any potential users yet. Take this through the full product lifecycle — discovery through lifecycle review — and produce the evidence at each phase.",
      "expected_output": "Scenario: a new product idea traversing the full lifecycle across multiple phases with phase handoffs. Phase 1 (discovery) loads product-discovery, produces a problem statement and stakeholder map, and classifies the product as consumer. Phase 2 (strategy) loads product-strategy, produces a strategic assessment and portfolio recommendation. Phase 3 (roadmap) loads product-roadmapping-and-portfolio, produces an outcome roadmap entry and bet record. Phase 4 (UX) loads product-design-and-ux, produces information architecture and interface contracts. Phase 5 (experimentation) loads product-experimentation, produces an experiment brief — for a consumer finance product this may be a concierge test or prototype rather than an A/B test. Phase 6 (delivery handoff) loads implementation-planning, production-readiness, and release-engineering, producing an implementation plan, readiness verdict, and release plan. Phase 7 (adoption) loads product-adoption, producing an adoption plan with consumer-specific onboarding and activation paths. Phase 8 (success) loads product-analytics-and-measurement — note that customer-success routing is skipped because this is a consumer product, with the skip recorded in the evidence ledger. Phase 9 (lifecycle review) loads product-lifecycle-learning, producing an outcome review, assumption ledger update, and a lifecycle decision. The lifecycle evidence ledger carries evidence across all nine phases. The trajectory terminates in a launch decision for the new product, recorded as an evidence-ledger entry built from the Phase 6 readiness verdict and release plan, and the post-launch lifecycle review is the ledger's terminal entry. The routing decision in Phase 8 explicitly records the skip of conditional-customer-success with reason 'product type: consumer — customer-success routing not applicable.' Claims are scoped to the harness, model, fixtures, and revision under test.",
      "assertions": [
        "All nine lifecycle phases are addressed with named specialist skills loaded per phase",
        "Phase 8 explicitly records the skip of conditional-customer-success with the reason citing consumer product type",
        "The lifecycle evidence ledger is referenced as the cross-phase handoff artifact",
        "Phase 1 classifies the product type (consumer) and this classification is carried in the ledger",
        "Phase 5 selects a method appropriate to a new consumer product (not defaulting to A/B)",
        "Phase 6 produces a production-readiness verdict and release plan",
        "The trajectory terminates in a launch decision recorded as a lifecycle evidence-ledger entry",
        "Phase 9 produces a lifecycle decision with rationale"
      ]
    },
    {
      "id": "ambiguous-stakeholder-request",
      "prompt": "Our CEO sent a one-line Slack message: 'We should add AI features to the platform.' There's no scope, no user problem, no success criteria, and three different VPs have different interpretations of what this means (one thinks chatbots, one thinks recommendations, one thinks internal tooling). Figure out what to do with this request.",
      "expected_output": "Scenario: an ambiguous stakeholder request that requires discovery before any commitment. Phase 1 (discovery) loads product-discovery and identifies that the request has no articulated user problem. The discovery phase engages stakeholders to surface the underlying needs behind each VP's interpretation. The discovery log records conflicting interpretations and surfaces assumptions. The escalation path may trigger: if the problem cannot be articulated in user terms after discovery engagement, the lifecycle stops at Phase 1 with the escalation reason 'problem cannot be articulated in user terms after stakeholder engagement.' The evidence ledger records what was learned — the three interpretations, the underlying needs surfaced, and why no single problem statement emerged. Alternatively, if discovery converges on a coherent problem, the lifecycle proceeds through strategy and portfolio choice. In either case, the ambiguous request is NOT routed directly to delivery — discovery is mandatory before any commitment.",
      "assertions": [
        "Phase 1 (discovery) is loaded and produces a discovery log with stakeholder interpretations",
        "The response does not skip directly to delivery or implementation",
        "If the lifecycle stops, the escalation reason is recorded in the evidence ledger",
        "If the lifecycle proceeds, a problem statement exists that a stakeholder recognizes",
        "The handling distinguishes between 'ask for clarification' and 'proceed with what we know'",
        "No specialist beyond product-discovery is loaded until discovery has a problem statement"
      ]
    },
    {
      "id": "failed-experiment-stop-path",
      "prompt": "Our hypothesis was that adding a 'trending topics' sidebar to the news reader would increase daily active usage by 15%. We ran a 4-week A/B test with 50,000 users per variant. The result: the sidebar had no statistically significant effect on DAU (p=0.42), and qualitative feedback showed users found it distracting. The experiment disproved the hypothesis. Decide what to do next.",
      "expected_output": "Scenario: a failed experiment that requires a stop/pivot decision. Phase 5 (experimentation) loads product-experimentation and produces an experiment readout. The readout records the hypothesis, method (A/B test), observed results (no significant effect, p=0.42), and the decision: stop — hypothesis disproved. The assumptions register is updated to record that 'trending topics increases engagement' is false for this user population. The lifecycle evidence ledger records the experiment evidence. Phase 9 (lifecycle review) loads product-lifecycle-learning and captures retained learning: the assumption that social-proof content increases engagement was disproved; this feeds back into the roadmap and future experiment design. The lifecycle may terminate at Phase 5 with a stopped outcome, or proceed through Phase 9 for formal learning capture. The key behavior: a disproved hypothesis is a legitimate and valuable lifecycle outcome, not a failure to be hidden or re-tested.",
      "assertions": [
        "The experiment readout records the hypothesis, method, observed results, and stop decision",
        "The assumptions register is updated to record the disproved hypothesis",
        "The lifecycle evidence ledger records the experiment evidence",
        "Phase 9 captures retained learning from the failed experiment",
        "The response does NOT suggest re-running the same experiment or tweaking the variant",
        "The stop decision is treated as a legitimate outcome, not a failure"
      ]
    },
    {
      "id": "non-adoption-outcome",
      "prompt": "We launched an internal tool for expense reporting six months ago. Despite mandatory training and executive sponsorship, only 12% of employees use it (target was 70% within 3 months). Most people still email receipts to finance. The product team wants to know whether to invest more in adoption or accept that this tool isn't working.",
      "expected_output": "Scenario: a non-adoption outcome that requires diagnosis and a decision. Phase 7 (adoption) loads product-adoption and diagnoses the adoption failure. The adoption diagnostic examines onboarding (was training effective?), activation (did users see value in first use?), time-to-value (how long to complete an expense report vs. emailing?), and structural barriers (is the tool solving a real problem for employees or just for finance?). Note: this is an internal tool — customer-success routing is not loaded. Phase 8 (success) loads product-analytics-and-measurement and measures outcomes against the 70% adoption target. Phase 9 (lifecycle review) loads product-lifecycle-learning and produces a lifecycle decision — likely retire or pivot, with a deprecation plan if retiring. The evidence ledger records the adoption diagnostic, the outcome measurement, and the lifecycle decision. The response may conclude that the tool was solving finance's problem, not employees' problem — a structural mismatch that more adoption investment won't fix.",
      "assertions": [
        "Phase 7 loads product-adoption and produces an adoption diagnostic",
        "The diagnostic examines onboarding, activation, time-to-value, and structural barriers",
        "Internal-tool context is recognized (no customer-success routing)",
        "Phase 8 measures outcomes against the adoption target",
        "Phase 9 produces a lifecycle decision (retire or pivot) with rationale",
        "The evidence ledger carries the adoption evidence across phases",
        "The response does NOT default to 'invest more in adoption' without diagnosis"
      ]
    },
    {
      "id": "justified-retirement-decision",
      "prompt": "Our legacy on-premises monitoring product has been in harvest mode for two years. Revenue has declined 40% year-over-year, the remaining 12 enterprise customers have active migration plans to our cloud product, and the engineering team supporting it costs more than the revenue it generates. The last customer is scheduled to migrate in Q3. Make the retirement decision and plan the sunset.",
      "expected_output": "Scenario: a justified retirement decision — a STOP path where work halts with evidence and escalation. Phase 8 (success) loads product-analytics-and-measurement and confirms the outcome: revenue decline, customer migration progress, cost/revenue ratio. Phase 9 (lifecycle review) loads product-lifecycle-learning and produces an outcome review comparing expected (harvest → retire) vs. observed (declining revenue, migrating customers, negative margin). The lifecycle decision is 'retire' with a sunset plan that includes: deprecation communication to remaining customers with migration timeline, internal cleanup (decommissioning schedule, team transition plan), and retained learning (what made the cloud product a successful replacement, lessons for future on-prem→cloud migrations). The evidence ledger records the retirement decision, the sunset plan, and the retained learning. The lifecycle terminates in a stopped/escalated path — the product is being retired, which is the correct and justified outcome. The STOP is not a failure; it is a disciplined closeout of a product that has reached end-of-life.",
      "assertions": [
        "Phase 9 produces a 'retire' lifecycle decision with evidence-based rationale",
        "A sunset plan exists with deprecation communication, migration path, and internal cleanup",
        "The lifecycle evidence ledger records the retirement decision and sunset plan",
        "Retained learning is captured for future cycles",
        "The retirement is treated as a justified and disciplined outcome, not a failure",
        "The STOP path is explicit — work halts after retirement planning, not after re-investment",
        "Customer treatment during sunset is addressed (migration path, communication timeline)"
      ]
    },
    {
      "id": "cross-phase-evidence-handoff",
      "prompt": "A B2B SaaS product team completed discovery and strategy for a new integration marketplace. Discovery validated strong demand from enterprise customers. Strategy positioned it as a platform differentiator. Now the roadmap phase needs to sequence it, UX needs to design the marketplace experience, and delivery needs a plan. Walk through phases 3-6 with explicit evidence handoffs between phases.",
      "expected_output": "Scenario: cross-phase navigation with explicit evidence handoffs. Phase 3 (roadmap) loads product-roadmapping-and-portfolio, reads the discovery log and strategic assessment from the evidence ledger (written by phases 1-2), and produces an outcome roadmap entry and bet record — writing these to the ledger. Phase 4 (UX) loads product-design-and-ux, reads the roadmap entry and bet record from the ledger, and produces information architecture and interface contracts. Phase 5 (experimentation) loads product-experimentation, reads the UX contracts, and designs an experiment — for a B2B marketplace this might be a concierge test with 3-5 design partners rather than an A/B test. Phase 6 (delivery handoff) loads implementation-planning, production-readiness, and release-engineering, reading the experiment readout and UX contracts from the ledger, producing an implementation plan, readiness verdict, and release plan. At each phase transition, the ledger is the mechanism for handoff — the next phase reads what the prior phase wrote. No phase re-derives evidence that already exists in the ledger. The B2B SaaS context means conditional-customer-success would be loaded in Phase 8 (not in this trajectory, but noted in the ledger).",
      "assertions": [
        "Each phase reads prior-phase evidence from the lifecycle evidence ledger",
        "Phase 3 reads discovery log and strategic assessment from Phases 1-2",
        "Phase 4 reads roadmap entry and bet record from Phase 3",
        "Phase 5 reads UX contracts from Phase 4",
        "Phase 6 reads experiment readout and UX contracts from Phases 4-5",
        "No phase re-derives evidence that already exists in the ledger",
        "The evidence ledger is explicitly referenced as the cross-phase handoff mechanism"
      ]
    }
  ]
}

# Capability Map — product-lifecycle bundle

This map indexes product management capabilities to their owning specialist
skills. When a user needs a specific capability, load the owning skill directly
rather than traversing the full lifecycle. The lifecycle bundle provides
cross-phase routing; this map provides point lookup.

## Capability → Owning skill

| Capability area | Owning skill |
|---|---|
| Stakeholder discovery, user research, requirements elicitation | [product-discovery](../../product-discovery/SKILL.md) |
| Product vision, strategy, competitive positioning | [product-strategy](../../product-strategy/SKILL.md) |
| Strategic frameworks (Five Forces, Blue Ocean, Ansoff) | [strategy-frameworks](../../strategy-frameworks/SKILL.md) |
| Market sizing (TAM/SAM/SOM), product-market fit | [product-strategy](../../product-strategy/SKILL.md) |
| Outcome roadmaps, Now/Next/Later views | [product-roadmapping-and-portfolio](../../product-roadmapping-and-portfolio/SKILL.md) |
| Strategic bets, portfolio management, continue/pause/kill | [product-roadmapping-and-portfolio](../../product-roadmapping-and-portfolio/SKILL.md) |
| Prioritization frameworks (RICE, MoSCoW, Kano, OST) | [product-methodology](../../product-methodology/SKILL.md) |
| Information architecture, task flows, interaction design | [product-design-and-ux](../../product-design-and-ux/SKILL.md) |
| Experiment design, method selection, guardrails | [product-experimentation](../../product-experimentation/SKILL.md) |
| Statistical design, causal inference, A/B analysis | [data-scientist](../../data-scientist/SKILL.md) |
| Specification, acceptance criteria, phase gates | [spec-driven-development](../../spec-driven-development/SKILL.md) |
| Work breakdown, dependency mapping, rollout planning | [implementation-planning](../../implementation-planning/SKILL.md) |
| Release process, progressive delivery, versioning | [release-engineering](../../release-engineering/SKILL.md) |
| Production readiness, launch evidence, go/no-go | [production-readiness](../../production-readiness/SKILL.md) |
| Onboarding, activation, feature discovery, sustained use | [product-adoption](../../product-adoption/SKILL.md) |
| Metric trees, tracking plans, outcome measurement | [product-analytics-and-measurement](../../product-analytics-and-measurement/SKILL.md) |
| Customer success, account health, renewals (conditional) | [conditional-customer-success](../../conditional-customer-success/SKILL.md) |
| Outcome review, assumption updates, retirement decisions | [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) |
| Decision rights, governance cadences, evidence standards | [product-operations-and-governance](../../product-operations-and-governance/SKILL.md) |
| Financial modeling, unit economics, pricing | [financial-modeling](../../financial-modeling/SKILL.md) |
| Go-to-market strategy, positioning, acquisition | [go-to-market](../../go-to-market/SKILL.md) |
| Privacy requirements, data lifecycle, retention | [privacy-engineering](../../privacy-engineering/SKILL.md) |
| Security requirements, threat modeling, secure design | [secure-software-engineering](../../secure-software-engineering/SKILL.md) |
| Legal analysis, regulatory landscape, IP strategy | [legal-strategy](../../legal-strategy/SKILL.md) |
| Data pipelines, ETL, schema design | [data-engineering](../../data-engineering/SKILL.md) |
| Production resilience, recovery, game days | [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) |
| Capacity planning, cost engineering, SLO-cost tradeoffs | [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) |
| Migration planning, expand/contract, cutover | [migration-engineering](../../migration-engineering/SKILL.md) |
| Incident learning, post-incident improvement | [incident-learning](../../incident-learning/SKILL.md) |
| Site reliability, SLOs, alerting, incident response | [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) |
| Platform engineering, infrastructure, CI/CD | [platform-engineering](../../platform-engineering/SKILL.md) |
| QA strategy, test planning, quality gates | [qa-methodology](../../qa-methodology/SKILL.md) |
| Verification methodology, evidence trails | [verification-methodology](../../verification-methodology/SKILL.md) |
| Software delivery lifecycle (SDLC) | [neckbeard](../../neckbeard/SKILL.md) |

## Cross-cutting concerns

These capabilities span multiple phases and are loaded on trigger, not by phase:

| Cross-cutting concern | Owning skill | When loaded |
|---|---|---|
| Product governance, decision rights, cadences | [product-operations-and-governance](../../product-operations-and-governance/SKILL.md) | When setting up or changing governance; at phase boundaries where a decision needs formal authority |
| Prioritization (RICE, MoSCoW, Kano, OST) | [product-methodology](../../product-methodology/SKILL.md) | When a phase produces alternatives that need ranking |
| Privacy and data protection | [privacy-engineering](../../privacy-engineering/SKILL.md) | When any phase handles PII, consent, retention, or data flows |
| Security | [secure-software-engineering](../../secure-software-engineering/SKILL.md) | When any phase touches trust boundaries, auth, or sensitive data |
| Evidence standards and verification | [verification-methodology](../../verification-methodology/SKILL.md) | At every phase gate where evidence is required |

# Bounded Discovery Brief — product-lifecycle bundle

## Bundle boundary

The `product-lifecycle` bundle is a thin orchestration umbrella that composes
existing product skills across nine lifecycle phases — from discovery through
post-launch learning. It provides **cross-skill routing and evidence handoff**.
It is NOT another product methodology and does NOT duplicate any specialist's
step-by-step method.

The bundle answers a specific gap: the catalog has strong individual product
skills (discovery, strategy, UX, experimentation, analytics, adoption,
methodology, GTM, financial modeling, operations/governance, lifecycle
learning) but no composition layer that routes a product through a coherent
lifecycle with phase-entry evidence, handoff artifacts, and stop/escalation
rules. A user who wants to evaluate a new product idea end-to-end currently
must manually chain skills. This bundle provides that routing.

## Comparison with existing bundles

### neckbeard

neckbeard is an SDLC delivery operating model — it routes a **code change**
through framing, discovery, design, implementation, review, verification,
delivery, and learning. It owns the cross-stage contracts for software delivery
(change contract, evidence ledger, stop rules) and composes specialist
engineering skills. The product-lifecycle bundle is complementary: it routes a
**product** through its lifecycle phases (discovery, strategy, roadmap, UX,
experimentation, delivery handoff, adoption, success, lifecycle review) and
composes specialist product skills. The delivery-handoff phase of the product
lifecycle explicitly hands off to production skills — production-readiness,
release-engineering, and the neckbeard change-request journey for the
implementation and delivery of product decisions. The two bundles intersect at
the delivery-handoff boundary but own different domains.

### workflow-architect

workflow-architect is a meta-skill that discovers a **person's** workflow
through conversation or observation and generates a tailored skills bundle. It
is an interrogation/observation tool, not a product management operating model.
The product-lifecycle bundle does not discover or generate workflows; it
provides a fixed, opinionated lifecycle routing table for product work. A user
might run workflow-architect to discover their own product workflow and then
use the product-lifecycle bundle as a reference for building it.

### tailscale

tailscale is a domain-specific infrastructure bundle for self-hosted
Tailscale/Headscale VPN. It has no product management content and no lifecycle
routing. No overlap with product-lifecycle. Mentioned here only for comparison
completeness.

### research-and-vault

research-and-vault is a thin orchestrator for a repeatable research-to-notes
pipeline: gather sources, extract atomic claims, create durable notes. It
composes web-research and note-taking capabilities. While the
product-lifecycle bundle's discovery phase may consume research outputs,
research-and-vault is a content-capture pipeline, not a product management
lifecycle. No overlap. Mentioned here for comparison completeness.

## Adjacent product skills surveyed

The following specialist skills exist in the catalog and are composed (never
duplicated) by the product-lifecycle bundle:

| Skill | Role in lifecycle |
|---|---|
| `product-discovery` | Phase 1 — stakeholder discovery, requirements, acceptance criteria |
| `product-strategy` | Phase 2 — vision, strategy, competitive positioning, market sizing |
| `product-roadmapping-and-portfolio` | Phase 3 — outcome roadmaps, strategic bets, portfolio views |
| `product-design-and-ux` | Phase 4 — information architecture, task flows, interface contracts |
| `product-experimentation` | Phase 5 — experiment design, method selection, guardrails, readouts |
| `implementation-planning` | Phase 6 — work breakdown, dependency mapping, rollout strategy |
| `spec-driven-development` | Phase 6 — formal specification, phase gates, implementation pipeline |
| `release-engineering` | Phase 6 — release process, progressive delivery, readiness gates |
| `production-readiness` | Phase 6 — risk-scaled launch evidence, go/no-go/defer/exception |
| `product-adoption` | Phase 7 — onboarding, activation, behavior change, sustained use |
| `product-analytics-and-measurement` | Phase 8 — metric trees, tracking plans, outcome measurement |
| `conditional-customer-success` | Phase 8 — success plans, health evidence, renewal signals (conditional) |
| `product-lifecycle-learning` | Phase 9 — outcome review, assumption updates, continue/retire decisions |
| `product-operations-and-governance` | Cross-cutting — decision rights, cadences, evidence standards |
| `product-methodology` | Cross-cutting — RICE, MoSCoW, prioritization frameworks |
| `go-to-market` | Phase 7/8 — positioning, acquisition strategy, growth modeling |
| `financial-modeling` | Phase 2/8 — unit economics, pricing, business model analysis |
| `data-scientist` | Phase 5/8 — statistical design, causal inference, experiment analysis |

Additional skills that may be routed to contextually: `site-reliability-engineering`,
`platform-engineering`, `secure-software-engineering`, `qa-methodology`,
`verification-methodology`, `strategy-frameworks`, `legal-strategy`,
`data-engineering`, `security-audit-methodology`.

## What this bundle does NOT own

- **Product discovery methodology.** Routes to `product-discovery`.
- **Product strategy frameworks.** Routes to `product-strategy` and `strategy-frameworks`.
- **UX design process.** Routes to `product-design-and-ux`.
- **Experimentation statistics and method.** Routes to `product-experimentation` and `data-scientist`.
- **Release engineering, CI/CD, deployment.** Routes to `release-engineering` and `production-readiness`.
- **Analytics instrumentation and pipelines.** Routes to `product-analytics-and-measurement` and `data-engineering`.
- **Customer success account management.** Routes to `conditional-customer-success` (conditional on product type).
- **Software delivery lifecycle.** Routes to `neckbeard` and `implementation-planning`.
- **Financial modeling and pricing.** Routes to `financial-modeling`.
- **GTM strategy and execution.** Routes to `go-to-market`.
- **Privacy, security, legal compliance.** Routes to `privacy-engineering`, `secure-software-engineering`, `legal-strategy`.
- **A universal B2B SaaS product model.** The bundle does not assume B2B SaaS. Customer-success routing is
  CONDITIONAL; internal tools, public-service products, transactional products, and consumer products proceed
  without it. Phase contracts use product-type-agnostic language.

## Design decisions

1. **Thin umbrella with real routing links.** Every phase routes to a named specialist skill via a
   relative markdown link. The umbrella SKILL.md never restates a specialist's step-by-step method.
2. **Evidence ledger as cross-phase handoff.** Each phase writes to a lifecycle evidence ledger; the
   next phase reads it. This is the artifact that makes the bundle composable — it is the handoff
   contract between phases.
3. **Stop/escalation at every phase.** Every phase has explicit escalation behavior. The bundle
   supports stopped paths (e.g., discovery shows no viable problem, experimentation disproves the
   hypothesis, adoption fails to meet thresholds) as legitimate outcomes.
4. **Conditional customer-success routing.** The bundle explicitly gates customer-success routing on
   product type. Products without accounts, renewals, QBRs, or customer-success teams proceed without
   loading `conditional-customer-success`.
5. **Capability map.** A separate reference (`capability-map.md`) maps capability areas to owning
   skills so users can discover which skill to load for a specific need without traversing the full
   lifecycle table.

# Lifecycle Phases — product-lifecycle bundle

Each of the nine lifecycle phases defines: entry evidence (what must exist before
the phase starts), output artifacts (what the phase produces), escalation behavior
(when to stop and escalate), and completion criteria (how to know the phase is
done). Phases are sequential; a phase may be skipped only when its entry evidence
is already satisfied by prior work, and every skip must be recorded in the
lifecycle evidence ledger with a reason.

## Lifecycle evidence ledger

Every phase writes to a shared **lifecycle evidence ledger** — a durable record
that carries evidence, decisions, assumptions, and handoff artifacts across
phases. The ledger is the cross-phase contract: phase N+1 reads what phase N
wrote and does not re-derive it.

### Ledger fields

| Field | Written by | Read by |
|---|---|---|
| Product identity (name, type, context) | Phase 1 | All phases |
| Problem statement and evidence | Phase 1 | Phases 2–9 |
| Stakeholder map and discovery log | Phase 1 | Phases 2–4 |
| Strategy and positioning decisions | Phase 2 | Phases 3–9 |
| Portfolio allocation and bet record | Phase 3 | Phases 4–9 |
| UX contracts and design decisions | Phase 4 | Phases 5–6 |
| Experiment briefs and readouts | Phase 5 | Phases 3, 6–9 |
| Delivery plan, spec, readiness verdict | Phase 6 | Phases 7–9 |
| Adoption plan and rollout evidence | Phase 7 | Phases 8–9 |
| Outcome metrics and success evidence | Phase 8 | Phase 9 |
| Lifecycle review and retained learning | Phase 9 | Future cycles (new phase 1) |
| Phase skip records (any phase) | Skipping phase | All subsequent phases |
| Escalation and stop records (any phase) | Stopping phase | Terminal (ledger closed) |

### Ledger conventions

- Every entry is dated and attributed to the phase that wrote it.
- Assumptions are labeled as such and separated from observed evidence.
- Gaps ("not yet verified," "unknown," "deferred to phase N") are recorded explicitly.
- The ledger is append-only within a lifecycle run. A phase never deletes or alters a prior phase's entries.
- A stopped/escalated lifecycle preserves the ledger as evidence of what was learned.

---

## Phase 1 — Discovery

**What happens:** Understand the problem space, identify stakeholders, gather
evidence about user needs, and decide whether the problem is worth solving.

**Entry evidence:**
- A product idea, market signal, stakeholder request, or strategic initiative.
- Sufficient context to identify who to talk to and what to investigate.

**Output artifacts:**
- Problem statement with supporting evidence (not just opinion).
- Stakeholder map identifying who has relevant knowledge or authority.
- Discovery log: interviews conducted, observations, assumptions surfaced.
- Initial product type classification (B2B subscription, transactional, public-service, consumer, internal tool).
- Decision: proceed to strategy, escalate (no viable problem), or pause (more discovery needed).

**Escalation behavior:**
- Stop and escalate when: the problem cannot be articulated in user terms; no
  stakeholder can describe a real, current need; discovery reveals the problem
  is already adequately solved; or the problem is outside the organization's
  remit or authority.
- Record the escalation reason and evidence in the ledger. The lifecycle may
  terminate here (closed — no viable problem).

**Completion criteria:**
- A problem statement exists that a stakeholder would recognize as their own.
- The product type is classified and recorded.
- A proceed/pause/stop decision is recorded with rationale.

**Primary specialist:** [product-discovery](../../product-discovery/SKILL.md)

---

## Phase 2 — Strategy and portfolio choice

**What happens:** Evaluate the discovered problem against organizational strategy,
competitive landscape, market opportunity, and existing portfolio commitments.
Decide whether and how to invest.

**Entry evidence:**
- Problem statement and discovery log from Phase 1.
- Organizational strategy context (mission, vision, current strategic bets).
- Market context (size, competition, trends).

**Output artifacts:**
- Strategic assessment: fit with organizational strategy, competitive positioning.
- Market sizing (TAM/SAM/SOM) and opportunity assessment.
- Portfolio recommendation: new strategic bet, enhancement to existing bet, or no-go.
- Investment thesis and resource estimate (order-of-magnitude).
- Decision: proceed to roadmap, escalate (no strategic fit), or defer (not now).

**Escalation behavior:**
- Stop and escalate when: the opportunity conflicts with organizational strategy
  and the conflict is material; market evidence contradicts the investment thesis;
  resource constraints make investment infeasible; or strategic direction is
  ambiguous and requires executive resolution.
- Record the escalation reason and evidence in the ledger.

**Completion criteria:**
- A strategic assessment exists with explicit fit/no-fit reasoning.
- The portfolio decision (new bet / enhancement / no-go / defer) is recorded.
- Resource estimate is recorded (even if rough).

**Primary specialists:** [product-strategy](../../product-strategy/SKILL.md),
[strategy-frameworks](../../strategy-frameworks/SKILL.md) (for framework-guided analysis)

**Supporting:** [financial-modeling](../../financial-modeling/SKILL.md) (for unit economics and sizing)

---

## Phase 3 — Roadmap

**What happens:** Sequence the investment as an outcome-based roadmap entry.
Define what success looks like, map dependencies, and set confidence levels.

**Entry evidence:**
- Strategic assessment and portfolio decision from Phase 2.
- Resource estimate and investment thesis.

**Output artifacts:**
- Outcome roadmap entry: desired outcome, leading indicators, target timeframe.
- Now/Next/Later placement with rationale.
- Strategic bet record: hypothesis, confidence level, continue/pause/kill criteria.
- Dependency map (other teams, platforms, external factors).
- Capacity allocation decision.
- Decision: proceed to UX and requirements.

**Escalation behavior:**
- Stop and escalate when: dependencies cannot be resolved; capacity is
  unavailable and cannot be negotiated; confidence is below the organization's
  threshold for investment and cannot be raised with further discovery; or the
  bet conflicts with a higher-priority bet that cannot be deprioritized.
- Record the escalation reason in the ledger.

**Completion criteria:**
- The roadmap entry exists in the organization's roadmap view.
- Strategic bet record is complete with confidence level and kill criteria.
- Dependencies are mapped and acknowledged by owners.

**Primary specialist:** [product-roadmapping-and-portfolio](../../product-roadmapping-and-portfolio/SKILL.md)

**Supporting:** [product-methodology](../../product-methodology/SKILL.md) (for prioritization frameworks if ranking against other bets)

---

## Phase 4 — UX and requirements

**What happens:** Translate the roadmap entry into concrete user-facing behavior,
information architecture, interaction design, and verifiable requirements.

**Entry evidence:**
- Roadmap entry and strategic bet record from Phase 3.
- Discovery log from Phase 1 (user context, needs, pain points).

**Output artifacts:**
- Information architecture and task flows.
- Interface contracts (screens, states, recovery paths).
- User-facing behavior specification.
- Acceptance criteria derived from user needs.
- Decision: proceed to experimentation (if validation needed) or directly to delivery handoff.

**Escalation behavior:**
- Stop and escalate when: UX work reveals the problem is fundamentally different
  from what discovery suggested; user research contradicts the roadmap hypothesis;
  the required behavior cannot be specified testably; or accessibility, privacy,
  or security constraints cannot be satisfied within the proposed scope.
- Record the escalation reason in the ledger.

**Completion criteria:**
- Information architecture and key task flows are documented.
- Interface contracts exist for all user-facing surfaces.
- Acceptance criteria are testable and traceable to user needs.

**Primary specialist:** [product-design-and-ux](../../product-design-and-ux/SKILL.md)

**Supporting:** [spec-driven-development](../../spec-driven-development/SKILL.md) (for formal specification)

---

## Phase 5 — Experimentation

**What happens:** Test the riskiest assumptions before committing to full
delivery. Select the right experimental method, define guardrails, run the
experiment, and produce a readout that updates the decision record.

**Entry evidence:**
- UX contracts and acceptance criteria from Phase 4 (or roadmap entry if UX was lightweight).
- Assumptions register: what must be true for this to succeed.
- Risk assessment: which assumptions are riskiest or least validated.

**Output artifacts:**
- Experiment brief: hypothesis, method, guardrails, decision rule, stopping condition.
- Experiment readout: observed results, confidence, decision.
- Updated assumptions register.
- Decision: proceed to delivery (hypothesis supported), pivot (hypothesis partially supported), or stop (hypothesis disproved).

**Escalation behavior:**
- Stop and escalate when: the experiment cannot be designed ethically; the
  required method is infeasible (e.g., sample size too small, no control group
  possible); the experiment reveals a safety, privacy, or security risk; or the
  experiment disproves the core hypothesis and no pivot is viable.
- A disproved hypothesis is a legitimate stop — record the evidence and close the lifecycle.
- Record the escalation reason and experiment evidence in the ledger.

**Completion criteria:**
- An experiment brief exists with explicit hypothesis, method, and decision rule.
- An experiment readout exists with observed results.
- A proceed/pivot/stop decision is recorded with evidence.

**Primary specialist:** [product-experimentation](../../product-experimentation/SKILL.md)

**Supporting:** [data-scientist](../../data-scientist/SKILL.md) (for statistical design and analysis)

---

## Phase 6 — Delivery handoff

**What happens:** Hand off the verified product decision to delivery. This phase
bridges product management and production engineering. It produces the
implementation plan, specification, and production-readiness evidence — routing
to engineering and production skills rather than doing the work itself.

**Entry evidence:**
- Proceed decision from Phase 5 (or Phase 4 if experimentation was skipped).
- UX contracts and acceptance criteria from Phase 4.
- Updated assumptions register.

**Output artifacts:**
- Implementation plan: work breakdown, dependency map, rollout strategy.
- Formal specification (SPEC.md) with acceptance criteria.
- Production-readiness evidence packet: risk classification, evidence checklist, launch decision.
- Release plan: versioning, progressive delivery strategy, rollback plan.
- Decision: proceed to adoption (delivery complete and launched).

**Escalation behavior:**
- Stop and escalate when: the implementation plan reveals an infeasible
  dependency; production-readiness review returns No-go or blocked Exception;
  security, privacy, or compliance review blocks launch; or the release plan
  cannot satisfy the organization's change-governance requirements.
- Record the escalation reason and readiness verdict in the ledger.

**Completion criteria:**
- An implementation plan exists and is accepted by the delivery team.
- A production-readiness verdict (Go/No-go/Defer/Exception) is recorded with evidence.
- The release plan is documented and reviewed.

**Primary specialists:**
- [implementation-planning](../../implementation-planning/SKILL.md) — work breakdown, dependencies, rollout
- [spec-driven-development](../../spec-driven-development/SKILL.md) — formal specification and phase gates
- [production-readiness](../../production-readiness/SKILL.md) — risk-scaled launch evidence and go/no-go
- [release-engineering](../../release-engineering/SKILL.md) — release process, progressive delivery, versioning

**Supporting:**
- [neckbeard](../../neckbeard/SKILL.md) — change-request journey for the implementation itself
- [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) — reliability and SLOs
- [platform-engineering](../../platform-engineering/SKILL.md) — infrastructure and CI/CD
- [secure-software-engineering](../../secure-software-engineering/SKILL.md) — security requirements and review
- [qa-methodology](../../qa-methodology/SKILL.md) — test strategy and quality gates
- [verification-methodology](../../verification-methodology/SKILL.md) — verification evidence

Note: The `production-excellence` bundle may also serve as a handoff target when
available — it composes production-readiness, migration-engineering,
resilience-and-recovery, capacity-and-cost-engineering, and incident-learning
under a single umbrella. When that bundle is installed, route to it; when it is
not, route to the individual production skills listed above.

---

## Phase 7 — Adoption

**What happens:** Drive user adoption after launch. Design onboarding, measure
activation, support behavior change, and monitor sustained use.

**Entry evidence:**
- Launch decision (Go) and release evidence from Phase 6.
- Target user segments and their needs from Phase 1.
- Success metrics from Phase 3 (roadmap outcomes).

**Output artifacts:**
- Adoption plan: onboarding design, activation path, time-to-value target.
- Segmentation and rollout record: who gets what, when.
- Activation and adoption metrics baseline.
- Behavior change and education strategy.
- Decision: adoption on track / needs intervention / pivot to re-launch.

**Escalation behavior:**
- Stop and escalate when: adoption metrics are materially below threshold after
  the intervention window; user feedback reveals a fundamental product-market
  mismatch; the adoption problem is structural (e.g., organizational resistance
  to an internal tool) and cannot be solved by product changes alone.
- A non-adoption outcome is a legitimate lifecycle result — record the evidence
  and feed into the lifecycle review (Phase 9).
- Record the escalation reason and adoption evidence in the ledger.

**Completion criteria:**
- Adoption plan is documented and executed.
- Activation, adoption, and retention baselines are measured.
- A proceed/intervene/pivot/stop decision is recorded with evidence.

**Primary specialist:** [product-adoption](../../product-adoption/SKILL.md)

**Supporting:** [go-to-market](../../go-to-market/SKILL.md) (for acquisition and positioning strategies)

---

## Phase 8 — Success

**What happens:** Measure outcomes against the success criteria defined in the
roadmap phase. Determine whether the product investment achieved its intended
results.

**Entry evidence:**
- Adoption evidence and metrics from Phase 7.
- Success criteria and leading indicators from Phase 3 (roadmap).
- Experiment readouts from Phase 5.

**Output artifacts:**
- Outcome measurement: metric tree with actuals vs. targets.
- Product analytics dashboard or report.
- Decision: success confirmed / mixed results / did not meet expectations.

**Note on customer-success routing:**
- `conditional-customer-success` is loaded ONLY for B2B subscription products
  with accounts, renewals, QBRs, and customer-success teams.
- For internal tools, public-service products, transactional products, and
  consumer products, skip customer-success routing and record the skip in the
  ledger with reason: "product type <type> — customer-success routing not applicable."

**Escalation behavior:**
- Stop and escalate when: outcomes are materially below expectations and the
  root cause is unknown after analysis; the measurement infrastructure is
  insufficient to evaluate success and cannot be remediated; or success evidence
  contradicts the original assumptions in a way that invalidates the investment
  thesis.
- Record the escalation reason and outcome evidence in the ledger.

**Completion criteria:**
- Outcome metrics are measured against success criteria.
- A success/mixed/not-met assessment is recorded with evidence.
- The ledger is complete and ready for lifecycle review.

**Primary specialist:** [product-analytics-and-measurement](../../product-analytics-and-measurement/SKILL.md)

**Conditional specialist:** [conditional-customer-success](../../conditional-customer-success/SKILL.md) (B2B subscription only)

**Supporting:** [financial-modeling](../../financial-modeling/SKILL.md) (for business outcome analysis)

---

## Phase 9 — Lifecycle review

**What happens:** Close the loop. Compare expected vs. observed outcomes, update
the assumption ledger, make a disciplined continue/improve/harvest/pivot/pause/retire
decision, and capture retained learning for future cycles.

**Entry evidence:**
- Outcome measurement and success assessment from Phase 8.
- Full lifecycle evidence ledger (all prior phases).
- Original assumptions register from Phase 2/5.

**Output artifacts:**
- Outcome review: expected vs. observed, epistemic categories (expected/observed/uncertain/inferred).
- Assumption ledger update: which assumptions held, which did not, what was learned.
- Feature health assessment across multiple dimensions.
- Lifecycle decision: continue, improve, harvest, pivot, pause, or retire.
- If retiring: deprecation communication, migration path, customer treatment plan, internal cleanup.
- Retained learning record: reusable insights fed back to roadmap, analytics, adoption, experimentation, and specifications.

**Escalation behavior:**
- Stop and escalate when: the retirement decision has material customer,
  revenue, or legal implications beyond the product team's authority; the
  retained learning contradicts a foundational organizational assumption that
  requires executive attention; or the lifecycle reveals a systemic pattern
  (e.g., third consecutive failed experiment in the same area) that suggests a
  strategy or governance issue.
- A justified retirement decision is a legitimate and valuable lifecycle outcome — record the
  evidence and retained learning, and close the lifecycle.

**Completion criteria:**
- An outcome review comparing expected vs. observed is recorded.
- A lifecycle decision (continue/improve/harvest/pivot/pause/retire) is recorded with rationale.
- Retained learning is captured in a durable, reusable format.
- The lifecycle evidence ledger is complete and closed.

**Primary specialist:** [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md)

**Supporting:** [product-operations-and-governance](../../product-operations-and-governance/SKILL.md) (for governance review and escalation)

---

## Phase skip rules

A phase may be skipped when its entry evidence is already satisfied by prior
work or the phase is not applicable to the product type. Every skip must be
recorded in the lifecycle evidence ledger with:

- The phase skipped.
- The reason (citing which entry evidence was pre-satisfied or why the phase is not applicable).
- The date and the authority for the skip.

| Phase | Skip criteria |
|---|---|
| 2 — Strategy and portfolio choice | The product is a minor enhancement to an existing bet and strategic alignment is already documented. |
| 3 — Roadmap | The work is a small, pre-prioritized task with no portfolio impact. |
| 4 — UX and requirements | The change has no user-facing behavior (backend-only, infrastructure). |
| 5 — Experimentation | The assumptions are already validated (e.g., a regulatory mandate leaves no choice). |
| 7 — Adoption | The product has no user-facing adoption surface (e.g., a backend data pipeline). |
| 8 — Customer-success routing | The product type is not B2B subscription (see Phase 8 conditional routing note). |

Phases 1 (Discovery), 6 (Delivery handoff), and 9 (Lifecycle review) may not be
skipped — they are the minimum viable lifecycle.