Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Product Development Lifecycle (PDLC)

Purpose

The Product Development Lifecycle (PDLC) defines how product work moves from idea to outcome at CXT.

This page is the single authoritative definition of:

  • Lifecycle stages

  • Stage purpose

  • Entry and exit criteria

  • Required artifacts

All other product documentation (playbooks, templates, meetings) must align to and reference this page.
No other document may redefine stages or lifecycle flow.

Core Principles

  • We optimize for customer outcomes and learning speed, not artifact completion.

  • Not all work follows the same path; the process should fit the work.

  • Discovery and delivery often run in parallel, not sequentially.

  • Artifacts exist to support decisions, not to satisfy process.

PDLC Stages

1. Capture & Triage

Purpose

Funnel all signals into one place and do a quick sanity check to ensure we are solving a real, clearly understood problem before investing in discovery or delivery.

Entry Criteria

  • Signal from customer, support, sales, operations, or strategy (research)

  • Clear product owner identified

Exit Criteria

  • Problem is clearly articulated

  • Target user or customer segment identified

  • Why the problem matters is understood

Required Artifact

  • Productboard Feature

Optional Artifacts

  • Supporting evidence links

  • Related insights in Productboard or Dovetail

  • Initial hypotheses or assumptions

AI Assist

Run /signal-triage in product-os. Claude evaluates the signal against all three exit criteria, searches Jira for existing coverage, and produces a Productboard-ready summary with a triage recommendation.

2. Discovery

Purpose

Reduce uncertainty by validating the problem, understanding users, and exploring viable solution directions.

Entry Criteria

  • Approved problem statement

  • Capacity available to explore the problem

Exit Criteria

  • Problem validity is confirmed or disproven

  • One or more viable solution directions identified

  • Key risks, assumptions, and unknowns documented

Required Artifact

  • Discovery Brief

Optional Artifacts

  • Research notes or summaries

  • Concept sketches or prototypes

  • Opportunity sizing or impact estimates

Note: Discovery is not a one-time gate.
It may continue in parallel with delivery as new information emerges.

AI Assist

Run /discovery-brief in product-os. Claude guides you through a structured brief, scores it using the Discovery Diagnostic Quality Score (DDQS) (0–10; ≥6 required to advance), and can publish the finished brief directly to Confluence.

3. Specification

Purpose

Translate discovery into a buildable, testable, and well-scoped plan.

Entry Criteria

  • Discovery direction agreed

  • Engineering actively engaged

Exit Criteria

  • Solution is feasible and understood

  • Scope and trade-offs are explicit

  • Success metrics are defined

Required Artifact

  • Product Requirements Document (PRD or 'Spec')

  • Jira Epic (pushed via PB integration)

Optional Artifacts

  • UX prototypes or flows

  • Technical design notes

  • Experiment or rollout plans

AI Assist

Run /prd-generator in product-os. Claude generates a CXT-format PRD (13 sections matching the Confluence PRD Example), then creates the Jira Epic via the Productboard–Jira integration. Run /multi-review before stakeholder review to catch gaps.

4. Delivery

Purpose

Build, test, and release value to customers in a reliable, incremental way.

Entry Criteria

  • Design and scope aligned

  • Delivery capacity committed

Exit Criteria

  • Functionality shipped to users

  • Release communicated appropriately

  • Instrumentation in place to measure outcomes

Required Artifacts

  • Jira epics and stories

  • Release notes or release communication

Optional Artifacts

  • Feature flags

  • Phased rollout plans

  • Operational runbooks

AI Assist

Run /release-package-assembler in product-os. Claude determines the correct release tier (Patch / Minor / Major), generates the tier-specific checklist, drafts release notes and a KB article outline, and produces a communication plan from T-5 days through T+90.

5. Outcome Review

Purpose

Assess whether the work delivered the intended outcome and decide what to do next.

Entry Criteria

  • Feature, change, or improvement released

Exit Criteria

  • Outcome evaluated against expectations

  • Learnings captured

  • Clear next action chosen (iterate, expand, stop, or revisit discovery)

Required Artifact

  • 14 / 30 / 60 / 90 Day Outcome Review

Optional Artifacts

  • Follow-up discovery items

  • Roadmap updates

  • Additional experiments

AI Assist

Run /outcome-review in product-os. Claude pulls Pendo engagement data for both CXT Software and CXT Driver apps and pre-populates the T+14/30/60/90 review, tracking PLOAR (Post-Launch Outcome Achievement Rate) against the success metrics defined in the PRD.

AI-Assisted Execution (product-os)

CXT product managers use product-os, an AI PM assistant built on Claude, to execute PDLC stages faster and more consistently. product-os has direct access to Confluence, Jira, and Pendo—so it works with your real product data, not a blank canvas.

PDLC Stage → Skill Map

 

PDLC Stage

 

product-os Skill

 

What It Does

 

  1. Capture & Triage

/signal-triage

Evaluates signal against exit criteria; Productboard-ready output

  1. Discovery

/discovery-brief

Structured brief with DDQS scoring; publishes to Confluence

  1. Specification

/prd-generator

CXT 13-section PRD + Jira Epic creation

  1. Delivery

/release-package-assembler

Tier checklist, comms plan, Go/No-Go summary

  1. Outcome Review

/outcome-review

T+14/30/60/90 review with Pendo data
 

Additional skills: /weekly-metrics (Pendo analytics), /product-brain-builder (loads context from Confluence + Jira), /backlog-prioritizer, /roadmap-builder, and 70+ more.

Getting Started

  1. Ask your Product Lead for access to the product-os repository.

  2. Follow the setup instructions in the product-os README.

  3. Run /welcome to initialize your workspace with CXT product context.

  4. From there, every PDLC stage has a corresponding skill—start with /signal-triage the next time a new idea lands in your inbox.

Important: product-os assists with structure, research, and artifact generation. PMs are responsible for reviewing and approving all outputs before sharing with stakeholders or engineering.

Classes of Work and Lifecycle Flexibility

Not all work goes through every stage.

Examples:

  • Bugs, regressions, and escalations may compress or bypass stages.

  • Fixed-date or regulatory work (i.e. SOC2, Prop A, GDPR) may prioritize speed over exploration.

  • Discovery-heavy product bets may spend significant time upfront.

Teams should apply the PDLC proportionally, based on the nature of the work.

Relationship to Other Documents

  • How We Work
    Describes product culture, collaboration norms, and decision-making principles.
    It does not define lifecycle stages.

  • Detailed Playbooks by Stage
    Provide tactical guidance on how to execute each stage well.
    They do not redefine stage purpose or requirements.

  • Templates
    Support specific PDLC artifacts like Requirements Documents or Outcome Reviews.

Governance

  • This page is owned by Product Leadership.

  • Changes to stage definitions or requirements must be intentional and explicit.

  • All product documentation must align to this PDLC.

Final Note

The PDLC exists to enable good decisions and fast learning, not to create ceremony.

If the process is not helping us deliver better outcomes for customers, it should be revisited.