--- name: product-lifecycle-progress-map description: Create and update a Product Lifecycle Progress Map for stakeholder and executive communication, linking lifecycle progress to evidence, ownership, risks and next decisions. Use for living project overviews and lifecycle status reporting, including requests loosely called a project charter; distinguish formal project authorization when needed. --- # Product Lifecycle Progress Map Skill revision: 1.11 (public edition) Help stakeholders see where the initiative stands, what it has produced, what has been decided and what comes next. The Product Experience Blueprint (PEB), or another designated product intent document, captures evolving product intent; this map summarizes progress and links supporting records rather than duplicating exhaustive requirements. ## Workflow 1. Identify audience, reporting date, outcome, scope and sources. Accept multiple initiating documents; preserve provenance and approval status. Do not expand unfamiliar acronyms by guesswork. 2. Extract dated activities, findings, artifacts, decisions, approvals and dependencies. Flag conflicting claims. Separate reported evidence from records actually inspected. 3. Read [the maintained template](references/map-template.md) before creating a full map. Default to the numbered phases 0–6 shown there. Adapt to an established lifecycle; numbering supports reference and reading order, not mandatory sequential gates. Phases can overlap, repeat or be omitted with rationale. 4. Assess phase status using the rules below. Keep project health, document acceptance, artifact maturity and phase completion distinct. 5. Create the concise executive view first, with linked supporting detail. Prioritize decisions that change scope, investment, delivery or user outcomes. Use [the illustrative example](references/maintenance-example.md) only as a structural aid; its authored scenario is not evidence for another project. 6. For updates, read the existing document, reconcile affected current-state statements throughout it, preserve unrelated team edits and retain dated history. Check that the map, roles, risks, measures and decision register agree. ## Status and ownership - **Not started:** The plan, team or source explicitly establishes that work has not begun, including future phases confirmed not yet reached. Missing evidence, no release decision or no measured outcome alone does not establish non-start. - **In progress:** Relevant work is underway. **In review:** Defined outputs are awaiting review or acceptance. **Blocked:** A dependency prevents the relevant work from advancing; mention what is blocked if other work continues. - **Done:** The agreed phase scope and expected outputs for the current increment are confirmed complete by the team or supported by clear completion evidence. A formal gate is not required unless the project requires one. Qualify scope when useful, such as “Done — prototype increment”; later learning can reopen work. Producing a document or resolving one decision alone does not establish phase completion. Preserve “reported done; confirmation pending” when the source itself is qualified. - **Unknown:** Available evidence does not establish status. **Not applicable:** The phase does not apply, with a brief reason when needed. Use these labels consistently; do not suppress supported Done or Not started statuses merely because formal gate criteria are absent. - Functional roles do not automatically establish accountability for entire phases, decisions or risks. Keep confirmed responsibilities in Team and roles. Add an optional **Phase lead** row only when explicitly assigned responsibilities are useful to the audience; otherwise omit it. Name known action owners beside next steps without implying phase accountability. - Retain known people and responsibilities through updates unless evidence changes them. For example, a clarification that production needs a later approval does not erase the sponsor's established approval role. If the authority for a specific new decision is uncertain, state that uncertainty precisely. ## Executive presentation Use the template's five default rows: **Status; What happens; Artifacts & evidence; Key decisions; Next step**. “What happens” explains the phase purpose in a short phrase. Artifacts & evidence identifies important outputs and their maturity (Planned, Draft, Reviewed or Accepted), not an exhaustive inventory. Key decisions distinguishes **Decided:** from **Open:**; proposals are not approvals. Next step gives one consequential action, review or milestone, with owner and date when known. Keep detailed unresolved issues in Risks and dependencies or Decisions needed, and dated updates in Status log; do not add a redundant Latest row. Use **Discover (as-is)** for understanding current work and **Define (to-be)** for agreeing the problem, desired outcomes, future experience, scope and requirements. Definition is more than drawing a future workflow. Verification/QA, user/workflow validation, data validation and inquiry continue across the lifecycle rather than living only at the end. Label the phase map **Project at a glance**. Keep the opening to compact metadata, outcome, current position, the primary next decision, the map and roughly three grouped top risks. Put provenance and acceptance history in Status log. Aim for about 120–180 opening words outside metadata and the map; prioritize clarity over a rigid word limit. Use short cell phrases and linked depth. Aim for one brief phrase per cell, selecting the important output or decision rather than an inventory. Move review caveats, approval history and secondary dependencies into the corresponding supporting sections. Keep future phases sparse. Avoid repeating the authorization boundary or shared unknowns across columns. For material missing information use **Not confirmed** (or Unknown for status); use **None recorded** where no output or decision is documented. Prefer **Not applicable** over unexplained dashes. Do not add a default legend or glossary of ordinary statuses; explain an unusual symbol only if it is actually used and ambiguous. Put scoped completion qualifiers directly beside Done or once in the current-position summary. Do not leave ambiguous blanks in a delivered map. For visual output use accessible horizontal phase cards with distinct headings and sensible reflow; for Markdown use a phase-column table. Preserve readable type. For a full stakeholder deliverable, also generate a standalone HTML presentation companion from the saved Markdown when file/script tools are available, unless the user requests Markdown only. Use the bundled [renderer](scripts/render_progress_map.py): `python3 scripts/render_progress_map.py --output ` (resolve the script relative to this skill). It converts the map's existing five rows into numbered phase cards, stacks cards on narrow screens and retains every supporting section. Do not reauthor a separate partial mockup or add facts in the HTML. On updates regenerate the companion from the revised Markdown. Respect requested alternative formats; if the renderer cannot be run, provide the Markdown and state that the companion was not generated. Inspect normal and narrow layouts when rendering is available; a scrollable detail table is preferable to clipped text or tiny type. Native Markdown preview behavior belongs to the client; HTML styling does not change that preview. Do not claim visual review when only source text was inspected. Keep document status to a short label; acceptance provenance and repeated qualifications belong in Status log, with only consequential uncertainty retained in the opening. For explicitly fictional source dates, explain their relationship to the edit date once in provenance; do not repeatedly frame the simulation as an unresolved chronology problem. The public HTML companion uses neutral, self-contained presentation styles and text-labeled status chips. Adapt styling to a supplied design-system profile when requested; no employer branding or proprietary tokens are bundled. [HTML design guidance](references/html-design-guidance.md) explains the presentation choices. Color must not imply project health or approval, and scoped or unconfirmed completion qualifiers must remain visible. ## Evidence and living-document delivery For a complete overview include all eight template sections. Quick reviews can remain in chat. Save full deliverables as a clearly named Markdown file in the requested location or current workspace, with a short summary and file link. Respect alternative formats. If file tools are unavailable, provide a downloadable artifact where supported or explain the limitation and supply copyable Markdown. Never claim a save without confirmation. Include initiative/ID, independent map version, revision date, status-as-of source date, maintainer, document status and related Product Experience Blueprint (PEB) version/link. Spell out Product Experience Blueprint on first mention in the delivered document; PEB is sufficient afterward. If the project supplies a different product intent document, name and link that document instead. Start at **v0.1 Draft**; substantive draft revisions advance to v0.2, v0.3. Explicit team acceptance of the reporting overview advances the initial accepted version to **v1.0 Confirmed for sharing**, then substantive updates to v1.1 and so on. Cosmetic edits need no bump. Map versions do not change the PEB or plugin version. Sharing acceptance is not phase sign-off, production authorization or permission to distribute externally. Update the same filename. Record substantive history newest first, retaining source dates separately from revision dates and marking undated evidence. Use the actual edit date for Last updated independently of the source reporting date, even when a simulated source date is later than the edit date; otherwise mark it Not confirmed. For missing scheduling information use “Timing not confirmed”; use “Not scheduled” only when the source explicitly establishes that no schedule exists. Apply this distinction throughout supporting risks, headings, next actions and history as well as the executive map; avoid calling an undated planned review “unscheduled” without that evidence. Do not substitute a source reporting date or assume when an update was incorporated. Preserve resolved contradictions as history while removing stale current claims. Reconcile prospective wording when events occur (for example, “will propose” becomes “proposed” where supported). Keep future milestones out of historical events. Use Needed by only for agreed deadlines and Resolved on only for an explicitly supplied decision event date. A report dated November 2 saying a decision was approved does not establish that approval occurred on November 2: record the report date in provenance and leave the resolution date Not confirmed. For a resolved decision with no agreed deadline, Needed by remains Not confirmed or Not applicable; do not put resolution information there. On update, insert the newest dated history first rather than appending below older entries. Missing baselines or targets limit assessment of measured impact; missing agreed dates limit schedule assessment. They do not prevent reporting evidence-supported phase progress, completed artifacts or decisions. State the specific measurement or schedule gap rather than declaring all progress or success unknowable. Qualify missing deadlines by their subject: an unknown evaluation date does not mean no deadlines exist when a data-access decision has an agreed due date. Do not invent research, policies, metrics, targets, dates, owners or approvals. Planned tests are not findings; proposed targets are not commitments. Retain metric source, period, population and uncertainty. Distinguish implementation QA, user/workflow validation and data validation. Show separate workstream progress when differing UI, agent, report, integration or operational maturity matters; do not average away dependencies. Release considerations include people, support, permissions, monitoring and recovery as relevant. Accuracy alone does not authorize autonomy: expose human review, consequences, escalation and authority when relevant. ## Final review and foundations Check that a reader can locate current progress and the next decision quickly; supported completed work is visible; plans and findings remain separate; the current map agrees with the supporting sections; and ownership and authority are not inferred. Recommend proportionate completion criteria only where needed, clearly labeled as recommendations rather than imposed governance. This synthesis draws on [Design Council's Double Diamond](https://www.designcouncil.org.uk/resources/the-double-diamond/), [Agile principles](https://agilemanifesto.org/principles.html), and [NASA product realization](https://www.nasa.gov/reference/5-0-product-realization/). Apply inquiry, iteration, verification, validation and transition distinctions proportionately; do not describe this map as a NASA standard or approved company process.