Product development lifecycle (PDLC)

This describes a generic product lifecycle — from validating that a problem is worth solving, through delivery (via Software development lifecycle (SDLC) phases A–F), to post-launch growth and eventual sunset. It defines which product artifacts to produce at each stage and who is accountable.

How PDLC relates to SDLC: SDLC answers "are we building the product right?" — phases, DoD, CI/CD, ceremonies. PDLC answers "are we building the right product?" — problem validation, strategy, go-to-market, outcome measurement. SDLC sits inside PDLC as the Build & Release engine. See PDLC ↔ SDLC bridge for the full mapping, diagrams, and worked example.

Discipline bridges: Cross-cutting disciplines each have a bridge mapping their practices to PDLC P1–P6 and SDLC A–F — see BRIDGES.md for the full index, or jump to a specific discipline: BA · PM · Testing · Architecture · DevOps · Big Data · Data Science.

Approaches depth (Dual-Track, Stage-Gate, Lean Startup, Design Thinking, …): see PDLC approach guides (blueprint) — full guides with external links and adoption notes.

Path examples below use a common docs/product/ layout; adjust names if your tree differs.

1. Roles

Product lifecycle work involves different accountabilities than delivery. These roles can overlap with SDLC roles (one person may hold both), but the concerns are distinct.

Product Trio: The PM + Designer + Tech Lead form the product trio — a cross-functional unit that co-owns discovery decisions. This maps to the Demand & value archetype in Roles, archetypes & methodology titles, extended to include design and feasibility perspectives.

SDLC handoff: When work enters SDLC Phase A (Discover / prioritize), the PM becomes (or hands off to) the Owner in Software development lifecycle (SDLC) §1. The Implementer role in SDLC maps to delivery engineering, not product discovery.

2. Phases & product obligations

Phase overview

Continuous discovery: In mature teams, P1–P2 run in parallel with SDLC delivery (Dual-Track Agile — see https://forgesdlc.com/pdlc-approaches-dual-track-agile.html). The sequential diagram shows logical dependency; real cadence overlaps.

Phase P1 — Discover problem

Goal: Validate that a real, meaningful problem exists for a specific audience before investing in solutions.

Activities: User interviews, market research, competitive analysis, data mining (usage analytics, support tickets, churn analysis), persona refinement, problem framing.

Artifacts (typical)

Exit: The team has evidence (not just intuition) that a meaningful, underserved problem exists for a defined audience. Stakeholders agree the problem is worth exploring solutions for.

Approaches that help here: Design Thinking (Empathize + Define), Opportunity Solution Trees, Lean Startup (problem interviews).

Phase P2 — Validate solution

Goal: Generate and test solution ideas to find one that addresses the validated problem — before committing engineering capacity.

Activities: Ideation workshops, rapid prototyping, usability testing, feasibility spikes, concept testing, fake-door tests, concierge MVPs, Wizard-of-Oz experiments.

Artifacts (typical)

Exit: At least one solution concept has evidence of desirability (users want it), viability (business case exists), feasibility (team can build it), and usability (users can use it). The team is ready to commit strategy and resources.

Approaches that help here: Design Thinking (Ideate + Prototype + Test), Lean Startup (Build-Measure-Learn), Stage-Gate (Gate 2: business case).

Phase P3 — Strategize

Goal: Commit organizational resources — budget, people, timeline — to the validated solution. Define success metrics and go-to-market approach.

Activities: Product vision writing, OKR/goal setting, roadmap creation, success metric definition, pricing/positioning analysis, go-to-market planning, stakeholder alignment, resource allocation.

Artifacts (typical)

Exit: Initiative is funded, staffed, and prioritized. Success metrics are defined. The product trio is ready to hand validated intent into SDLC Phase A (Discover / prioritize).

Handoff to SDLC: At this point, the validated problem, solution concept, personas, success metrics, and high-level scope cross into Software development lifecycle (SDLC) Phase A — where they become backlog items, WBS entries, and story specifications. See PDLC ↔ SDLC bridge §4 for the artifact handoff table.

SDLC Phases A–F — Build & Release

Goal: Turn validated product intent into shippable software — with quality, traceability, and governance.

This is the domain of SDLC blueprint. PDLC does not redefine these phases:

During SDLC: The product trio stays engaged through ceremonies (C1 Align, C4 Inspect) — they do not disappear until launch. In Dual-Track teams, discovery for the next initiative (P1–P2) runs in parallel with current delivery.

Phase P4 — Launch

Goal: Make the product (or feature) available to the target market and activate go-to-market.

Activities: Beta program management, GA rollout, marketing activation, sales enablement, support team training, documentation publishing, announcement comms.

Artifacts (typical)

Exit: Product is available to the intended audience. Monitoring is active. Support can handle inquiries.

Phase P5 — Grow

Goal: Drive adoption, measure outcomes, and iterate based on real-world usage data.

Activities: Analytics review, A/B testing, funnel optimization, retention analysis, feature iteration, user feedback synthesis, expansion plays (new segments, upsell), NPS/CSAT surveys.

Artifacts (typical)

Exit: Product health targets are met (adoption, retention, revenue within acceptable range), or the team makes a strategic decision — pivot (back to P1 with new evidence), invest (more P5 iteration), or harvest (transition to P6).

Feedback loop: Insights from P5 are the primary input to continuous discovery (P1). In Dual-Track teams, this loop runs continuously. See https://forgesdlc.com/pdlc-approaches-dual-track-agile.html.

Phase P6 — Mature / Sunset

Goal: Manage the product through maturity (stable, profitable, declining investment) and eventual retirement when the product no longer justifies maintenance.

Activities: Lifecycle stage assessment, maintenance-mode optimization, harvest/invest/divest decisions, sunset planning, customer migration, EOL communications, resource reallocation.

Artifacts (typical)

Exit: Product is retired (removed from market, support ended, data handled per policy) or repositioned (back to P1 with a new problem framing that extends the product's life).

3. Definition of Done (product initiative)

A product initiative is done when:

1. The target outcome (P3 success metrics) is either achieved, explicitly accepted at current levels, or the initiative is pivoted/cancelled with documented reasoning.
2. The experiment log captures validation evidence from P1–P2 and iteration evidence from P5.
3. The product vision and metrics dashboard reflect the current state.
4. SDLC delivery obligations are met per Software development lifecycle (SDLC) §3 (story DoD) and §4 (epic DoD).
5. If sunset: migration, communications, and data handling are complete per the sunset plan.

4. Stage gates (decision points)

Between PDLC phases, explicit go/kill/pivot decisions prevent wasted investment. These complement (do not replace) SDLC phase exits.

Use Stage-gate review — [Initiative Name] to document gate decisions.

See https://forgesdlc.com/pdlc-approaches-stage-gate.html for the full Stage-Gate framework.

5. Metrics framework

PDLC uses outcome metrics (did users/business benefit?) alongside SDLC's output metrics (did we ship correctly?).

SDLC metrics (velocity, defect rate, DORA, CI pass rate) remain in Software development lifecycle (SDLC) §7 and are complementary. See PDLC ↔ SDLC bridge §5 for the full comparison.

6. Review cadence (suggested)

Keep product-specific context in docs/product/ (or equivalent), not in this file.