Product feature review planner

What it does

Share the feature goals, results and user feedback. Compare facts with hopes. Get a decision brief for the person who owns the choice.

What goes in and out

You give it

• The original feature goals, observed outcomes, customer impact, costs and known measurement limits.
• Document (optional)
• The product spec (optional)

You get

• An outcome review, assumption updates and a decision brief with accountable owners and follow-up.

How the task works

• Separate claims and observations. Label expectations, measured outcomes, uncertainty and inference before comparing results.
• Assess feature health. Review adoption, technical, operational and strategic evidence without collapsing it to one score.
• Prepare the lifecycle decision. Explain alternatives and human authority; if retirement is chosen, plan migration, support and learning closure.

Full instructions

• Gather three things first: your feature goals and targets, your usage and outcome numbers with any known gaps, and your user feedback with dates.
• If one is missing, say so. Your AI will mark it as missing and will not guess. Add what you can find, or note it as a gap.
• Add the skill to your AI tool, or paste its text into a chat. No code or web access is needed.
• Paste your three inputs and ask your AI to work in four stages, in this order. First the outcome review, from your goals and numbers. Then the assumption updates, from your early assumptions and the feedback. Then the feature health record, from usage, cost and support load. Last the decision brief. The skill folder has a template for each stage in templates/.
• Check the facts and gaps first. Then let the person who owns the choice make the decision.
• The skill points to follow-up skills for customer success and incident learning that are not yet available. Do those by hand. If you retire the feature, the product owner and support lead write the customer notice and the export or migration steps. Send any incident found to your on-call lead for a normal incident review.

Full instruction file

Product Lifecycle Learning

Close the loop from launch to learning. This skill compares what was intended against what actually happened, maintains an evidence-backed assumption ledger, assesses feature health, and makes disciplined continue/improve/harvest/pivot/pause/retire decisions — including full retirement lifecycles. It produces a durable retained learning record that feeds back into roadmap, analytics, adoption, experimentation, and future specifications.

If the feature has a written spec or requirements document, use it as the source of what was expected.

Before you start

Use the material below to do this job. If facts or tool access are missing, explain what you can finish and what must wait.

What you need (use your own material or the linked skill):

• Your question (yours): the decision or problem, and what a good outcome looks like.
• Your results (yours): an export of your numbers for set dates, from the tool that holds them: an ad account, your store, analytics or your product.
• Your notes (yours): what to keep, change or drop.

Makes it better (optional):

• A document (yours): a finished document, such as a Word file, a PDF or a page of notes.
• The product spec (yours): what to build and how to tell it's done: a requirements doc or user stories.

How to start:

1. Look first. Use what they've already attached, pasted or put in their about-me note. In a coding assistant with file access, look in the project too for these by name.
2. Check what's missing. Look for your question, your results, your notes. They can attach files, paste the details, or share a file path your assistant can read. Ask only for missing facts that change the result. If they ask you to start with what they have, complete the parts you can and mark the gaps.
3. Do the job. Follow the skill below with the facts and tools you have. Mark each gap with MISSING: where it belongs and never invent a fact to fill it.

Loading Guide

Load only the reference or template relevant to the task. Do not load every file at once.

Core Methodology

The Launch-to-Learning Loop

LAUNCH → [OBSERVE] → [COMPARE] → [IDENTIFY GAPS] → [UPDATE ASSUMPTIONS] → [ASSESS HEALTH] → [DECIDE] → [CAPTURE LEARNING] → (feed back)
              |            |              |                 |                    |               |               |
         Collect      Expected vs.    Gap analysis     Assumption         Feature health    Continue /      Retained
         outcome      observed        with confidence  ledger update      dimensions        Improve /       learning
         data         outcomes        intervals                                              Harvest /       record
                                                                                            Pivot /
                                                                                            Pause /
                                                                                            Retire

The loop starts after launch (the feature or capability is live and generating data) and ends with a durable learning artifact that feeds the next cycle of roadmap, analytics, adoption, experimentation, and specification work.

Stage-by-Stage

Epistemic Discipline

Every claim in lifecycle-learning output is classified into exactly one of four categories. These are not conflated; a comparison is not an observation, and an inference is not a fact.

Full taxonomy and field guide in references/epistemic-discipline.md.

Lifecycle Decisions

Six outcomes are available after assessment. The choice requires human judgment informed by evidence; no numeric threshold or automated rule replaces context and accountability.

Retirement Lifecycle

When the decision is Retire, a structured retirement lifecycle covers the full path from deprecation announcement through internal cleanup. Full detail in references/retirement-lifecycle.md.

Retained Learning Record

Every lifecycle-learning cycle produces a durable retained learning record — not a transient meeting summary. The record captures:

• What the feature or capability was intended to achieve (expected outcomes)
• What actually happened (observed outcomes, with confidence)
• What was uncertain and why
• What assumptions were updated and how
• What decision was made (continue/improve/harvest/pivot/pause/retire) and who made it
• Why that decision was reached, with evidence
• What should inform future decisions — reusable patterns, anti-patterns, assumptions to test next time
• Where the learning was routed (roadmap, analytics, adoption, experimentation, specifications)

This record is the durable learning artifact. It is the evidence that the launch-to-learning loop actually closed.

When Not to Use

This skill does not own:

• Incident postmortems, root-cause analysis, or operational incident review — these belong to incident-learning (not yet landed) and ../site-reliability-engineering/SKILL.md (source reference: ../site-reliability-engineering/SKILL.md). Lifecycle-learning consumes incident signals as input but does not produce postmortems.
• Analytics instrumentation, metric dashboard design, tracking-plan creation, or event taxonomy — these belong to ../product-analytics-and-measurement/SKILL.md (source reference: ../product-analytics-and-measurement/SKILL.md). Lifecycle-learning consumes analytics data as input but does not own measurement infrastructure.
• Customer-success account management, renewal decisions, or health scoring — these belong to conditional-customer-success (not yet landed). Lifecycle-learning routes retirement communication plans and customer-treatment strategies there.
• Roadmap prioritization or portfolio allocation — these belong to ../product-roadmapping-and-portfolio/SKILL.md (source reference: ../product-roadmapping-and-portfolio/SKILL.md). Lifecycle-learning feeds evidence into roadmap decisions but does not make them.
• Arbitrary or automated retirement thresholds — this skill never applies rules like "retire if DAU < 100" or "kill if NPS < 30" without context about the product, market, user base, and alternatives. Retirement decisions require human judgment and named accountability.

Routing and Feedback

Inputs (consumed by lifecycle-learning)

Outputs (produced by lifecycle-learning, routed to)

At least five feedback destinations must be updated per cycle: roadmap, analytics, adoption, experimentation, and specifications. Additional routing to customer-success and incident-learning is conditional on the decision.

File Map

Related Skills

• ../product-analytics-and-measurement/SKILL.md (source reference: ../product-analytics-and-measurement/SKILL.md) — Owns instrumentation and metric definition. Lifecycle-learning consumes analytics outputs.
• ../product-adoption/SKILL.md (source reference: ../product-adoption/SKILL.md) — Owns adoption diagnostics and strategy. Lifecycle-learning consumes adoption evidence.
• ../product-experimentation/SKILL.md (source reference: ../product-experimentation/SKILL.md) — Owns experiment design and readout. Lifecycle-learning consumes experiment results.
• ../product-roadmapping-and-portfolio/SKILL.md (source reference: ../product-roadmapping-and-portfolio/SKILL.md) — Owns roadmap and portfolio decisions. Lifecycle-learning feeds evidence.
• ../spec-driven-development/SKILL.md (source reference: ../spec-driven-development/SKILL.md) — Owns specifications and acceptance criteria. Lifecycle-learning feeds spec improvements.
• ../site-reliability-engineering/SKILL.md (source reference: ../site-reliability-engineering/SKILL.md) — Owns operational reliability. Lifecycle-learning consumes incident signals.
• conditional-customer-success — Consumer for retirement communication plans, customer treatment during sunset, migration support coordination. Prose reference; skill not yet landed.
• incident-learning — Destination for incident-driven learning signals. Prose reference; skill not yet landed.

After this

When you've handed it back, suggest what they could do next in one short question. It's a suggestion: if they're done, that's fine. Offer these, and say they can type their own:

• Test the idea with real people with the Idea evidence reviewer. It takes the lessons and audit report and plan. If they pick one and that skill is added here, carry straight on with what you just made. If not, give the link and say what to bring.