Product Development Life Cycle:
From Discovery to Sunset

A product development life cycle carries an identified customer problem through discovery, delivery, launch, live operation, and eventual retirement. The phases name where work happens; evidence gates govern the few transitions where the organization buys materially more risk through added investment, wider customer exposure, or a new residual obligation. Without that distinction, the lifecycle is only a stage list.

The Product Development and Management Association describes new product development as work spanning strategy, concept generation, product and marketing planning, evaluation, and commercialization. Its process definition emphasizes disciplined, repeatable tasks that convert early ideas into products or services that can be sold.

The definition reaches beyond engineering delivery: cross-functional product work repeatedly moves early ideas through evaluation and commercialization.

An evidence gate makes the investment logic visible inside that process. The team does the learning work within a phase; at the gate, an accountable group examines what was learned and decides what exposure, capacity, or obligation—if any—to authorize next. The Stage-Gate model formalizes the distinction: stages produce information, while gates examine deliverables and criteria before a Go, Kill, Hold, or Recycle decision.

Stage-Gate locates cross-functional work and learning inside stages, then reserves gates for reviewing deliverables against criteria and deciding whether to commit further resources.

There is no universal product development life cycle formula. PDLC is a process framework, not a calculated metric. A discovery gate might use problem frequency and research quality; a release gate might use task success, defect evidence, security findings, and rollback readiness. Those measures have different meanings and units. Compressing them into one score may be a local prioritization aid, but it is not a standard PDLC equation.

There is no accepted number of phases or standard total duration either. Stage-Gate publishes six stages from Discovery through Launch. The GOV.UK Service Manual uses five service phases—discovery, alpha, beta, live, and retirement. Atlassian presents seven development stages ending in commercialization and also states that development has no set duration. The variation is useful: phase labels are a local design choice; the decisions and evidence cannot be omitted merely by renaming the workflow.

Product development, product life, PLM, and SDLC are different scopes#

Product development life cycle (PDLC) often means the internal path from an idea through research, design, testing, and launch. Product life cycle (PLC) usually describes what happens in the market after introduction: growth, maturity, and decline. Shopify’s side-by-side explanation uses that narrower boundary.

Product lifecycle management (PLM) is an operating discipline for coordinating product information, people, and decisions across a wider span, including maintenance and end of life. Atlassian’s PLM overview extends from concept and development through optimization and retirement.

This article deliberately uses a full operating span from discovery to sunset. That choice prevents launch from becoming an organizational cliff: the same product decision system that authorizes customer exposure must also judge live value and manage withdrawal responsibly.

Software development life cycle (SDLC) has a narrower engineering focus. IBM defines SDLC as the interdependent phases used to build, deliver, and maintain software. It may cover planning, design, coding, testing, deployment, and maintenance in sequential or iterative arrangements. PDLC asks whether the product investment still deserves to exist and grow; SDLC governs how software is engineered and operated. A product gate cannot waive security, quality, release, or incident controls, and an engineering release cannot prove that the product solves a valuable problem.

For a B2B SaaS team, PDLC can serve as the product-investment layer across the full product life while SDLC remains the engineering-delivery layer inside it. Product Development and Management Association and Shopify indicate that the two share evidence at delivery and live gates but answer different decisions, as Atlassian also explains.

A stage tells the team what to learn. A gate decides how much risk to buy next.

Map six changes in investment and exposure#

The following six-phase model is a practical synthesis, not a claim that every company needs these exact names. Read it as a route map: each row names the decision, minimum packet, and legitimate dispositions for one change in commitment. A phase ends when the team can make that decision, not when a calendar box expires.

The shared skeleton does not imply equal proof standards. Discovery can authorize a bounded learning effort on incomplete evidence. A broad launch creates customer expectations, support load, data obligations, and dependencies, so it needs stronger receipts. Sunset also deserves a real gate because withdrawal can impose work and risk on customers long after new development has stopped. The sections that follow focus on those changing failure conditions and the remedy at each transition.

Fix the decision contract before gathering the packet#

A Gate Card is the reusable deliverable in this model. Write it before the phase begins, while the requested commitment, proof standard, and possible outcomes can still be fixed without knowing the result:

Gate and decision:
Decision owner:
Next investment or exposure being requested:

Claims that must be true:
Evidence required for each claim:
Decision criteria and non-negotiable constraints:
Known limitations, missing evidence, and expiry date:

Outcome: continue / revise / hold / stop
Decision rationale and dissent:
Owner and due date for conditions or follow-up:

The card prevents a team from deciding what counts only after seeing the result. It is not a demand for certainty; it defines what uncertainty the organization is willing to carry into the next investment state. A reversible prototype can proceed with a clearly labeled assumption. A customer-facing launch cannot treat an unowned migration risk as a footnote.

Use four labels to preserve the status of every item inside the packet:

• Observed: behavior or conditions already recorded in a traceable source, such as product events, support cases, interviews, contracts, or operational logs.
• Tested: a claim challenged with a prototype, experiment, technical spike, usability session, or controlled release, with the method and limitations retained.
• Inferred: a conclusion drawn from observed or tested inputs, with the reasoning stated so another reviewer can challenge it.
• Assumed: something material that remains unknown. It may be acceptable for the next bounded step, but it cannot be presented as evidence.

This vocabulary keeps a polished slide from giving every statement the same epistemic weight. It also makes a conditional decision precise: “continue only if this assumption is tested before broader exposure” is operational; “looks promising” is not.

Gate 1 — Discovery: earn a bounded learning budget#

The specific failure to prevent at discovery is solution commitment before the problem boundary is defensible. GOV.UK’s discovery guidance asks teams to understand users and their context, constraints, alternatives, and measures of success before building. It explicitly treats a stop decision as a valid result.

In the GOV.UK model, discovery ends with a decision about whether to move forward. The evidence includes the user problem, wider context, constraints, alternative ways to meet the need, cost effectiveness, and an approach to measuring success.

For a B2B SaaS product, make six discovery questions reviewable:

1. Affected actor and job: who encounters the problem, in what workflow, and what they are trying to accomplish.
2. Observed problem: what behavior, support evidence, research, loss, delay, or workaround shows the problem exists.
3. Current alternative: how the actor solves or avoids the problem now, including doing nothing.
4. Business relevance: why solving this problem advances an explicit product or company objective.
5. Constraints and harms: data, legal, security, integration, accessibility, operational, or channel conditions that could make a proposed intervention unacceptable.
6. Next learning plan: the riskiest unresolved claim, the smallest useful way to test it, and the success measure the team will refine.

The output is not a detailed backlog. It is a defensible problem boundary and, when warranted, permission to run the next learning step. If the evidence says the need is weak, already served, outside strategy, or blocked by a hard constraint, stop. That is resource allocation working as intended.

Gate 2 — Validation: attack the claims most likely to break#

Validation turns a problem worth pursuing into a proposed product approach by attacking the claims that could make the investment fail. Prototypes, workflow simulations, technical spikes, pricing or packaging research, service-design tests, and direct evaluation with intended users are possible methods. The required artifact is not “an MVP” by default; it is a set of claim-specific receipts.

The GOV.UK alpha guidance recommends prototypes that are only complex enough to test risky assumptions, not production-quality code. Its exit decision asks whether an approach can meet user needs, remain cost effective, and be delivered with available people and resources.

Alpha can end by moving forward, repeating discovery or alpha, or stopping. A substantial prototype is useful because it supports the decision; completing a prototype is not itself proof that beta investment is justified.

Use the validation packet to connect each claim class to an appropriate receipt and to reject evidence that cannot settle it:

The remedy for an open claim is not permanent proof. Bound the next commitment, label what remains assumed, and set the condition that will test it.

Gate 3 — Delivery: earn controlled customer exposure#

Delivery is where the selected approach becomes a real product increment. Its characteristic error is to treat merged or deployed code as sufficient evidence for customer exposure. The work still belongs inside an appropriate SDLC, with its own architecture, testing, security, deployment, and operational controls. The product gate reads those receipts alongside customer and business readiness; it does not repeat the engineering review.

The GOV.UK beta model begins with controlled access, gathers performance data against previously defined measures, and expands only after the team can support learning and operation at greater scale.

Controlled beta exposure is used to learn from real users while limiting risk. Wider access follows evidence about user outcomes, operational capacity, security, support, accessibility, and the ability to run the service at scale.

For a SaaS release, the remedy is an inspectable exposure packet:

• the intended user, critical task, and acceptance conditions are unchanged or deliberately revised;
• product behavior has been tested at the level appropriate to its risk;
• instrumentation can distinguish exposure, use, success, failure, and important guardrails;
• known defects and limitations have owners and a clear exposure decision;
• support and customer-facing teams know what is changing and how to escalate problems;
• deployment, rollback, data migration, permissions, and dependency risks have accountable technical sign-off; and
• the release cohort, monitoring period, expansion rule, and stop condition are written.

Passing this gate means “safe and useful enough to learn from a bounded cohort.” It does not mean product success has been demonstrated.

Gate 4 — Launch: test the launch system in limited release#

A technical release and a product launch are separate commitments. The first makes functionality available under controlled conditions. The second widens discoverability, customer expectation, contractual exposure, enablement work, and support load. This gate exists to keep a working feature from being mistaken for a working launch system.

Use the limited release to test the launch system as well as the feature. Can the intended customer understand the value and reach the product? Can onboarding get them to the critical task? Do sales, success, support, and operations describe the same scope? Does telemetry reveal failures quickly enough to limit harm? Can the organization support the product at the proposed exposure?

The launch packet therefore contains actual limited-release evidence, not only a completed campaign plan. It also retains the baseline and success definition chosen earlier. Otherwise the team can always reinterpret whatever happens after launch as encouraging.

An allowed outcome is limit: keep serving the current cohort while repairing a known weakness. Another is roll back. If every gate can only say yes, it is a status meeting wearing a governance label.

Gate 5 — Live: compare continuing value with the full burden#

Launch moves the product into a longer learning period, not a permanent default. GOV.UK defines live operation as sustainable support plus continued research, measurement, testing, quality assurance, and improvement. The live gate’s distinct job is to compare that continuing value with the whole burden of keeping the product.

A live product still requires operating capacity, performance measures, user research, testing, and improvement. Retirement becomes relevant when the underlying need disappears or continued operation is no longer cost effective.

Use both a recurring lifecycle review and event-driven triggers. The cadence depends on product risk and change rate; there is no universal PDLC duration or review interval. Review sooner when customer behavior shifts, a critical dependency changes, operating risk rises, a strategic assumption breaks, or a replacement changes the value of continued investment.

The live gate compares a product’s outcomes with its full burden:

• customer value and the evidence that the product still solves the intended problem;
• adoption, successful use, retention, and the distribution of value among relevant segments;
• reliability, security, privacy, accessibility, and other guardrails;
• support, infrastructure, maintenance, integration, and enablement load;
• strategic fit and the opportunity cost of keeping scarce capacity committed; and
• accumulated obligations such as contracts, stored data, APIs, documentation, or downstream workflows.

The result may be to invest, maintain, reshape, or prepare a sunset. New improvements can loop through their own discovery and validation gates while the parent product remains live. Gates therefore do not make the lifecycle waterfall: they mark changes in investment and exposure while learning within and across phases remains iterative. Stage-Gate itself allows parallel cross-functional activity, and product-development stages can repeat when evidence challenges the current approach.

Gate 6 — Sunset: prove the transition safe#

A sunset proposal starts with the case for withdrawal. The completion decision is different: it concerns customers and residual obligations. The GOV.UK retirement guidance begins by asking how the underlying user need will be met. It also covers communication, API consumers, transition paths, traffic, and protection or transfer of user information.

Retirement affects more than the product interface. A responsible plan accounts for the continuing user need, replacement services, direct users, API consumers, transition timing, routes to the replacement, and ongoing protection of retained or transferred information.

For a B2B SaaS product or feature, require these transition artifacts before approving execution:

1. Decision basis: the evidence for retirement, alternatives considered, and the accountable decision owner.
2. Impact map: affected customers, roles, contracts, entitlements, integrations, APIs, exports, automations, documentation, and internal operations.
3. Need and transition plan: whether the need disappeared, moves to a replacement, or will no longer be served—and how customers complete their work afterward.
4. Communication plan: audiences, channels, ownership, feedback path, and enough lead time for each dependency to adapt. The appropriate notice depends on contracts, product risk, and customer workflow; there is no universal period.
5. Data plan: export, migration, retention, deletion, access, and security decisions reviewed under applicable contractual and legal obligations.
6. Technical removal plan: sequencing, redirects or compatibility behavior, monitoring, rollback boundaries, dependency cleanup, and support coverage.
7. Closure receipts: proof that agreed communications, migrations, removals, and data actions occurred, plus ownership for anything that must remain.

The first sunset gate authorizes the transition work. A later completion gate verifies that the product can actually be withdrawn. Separating those decisions prevents an internal end date from being mistaken for customer-safe closure.

Worked example: trace one claim through six decisions#

Suppose a B2B SaaS team is considering a guided setup flow for new workspace administrators. This is an unnamed workflow example, not a report of real results. It shows what the team would need to collect; it does not invent what the evidence says.

Use the example as a lineage audit. Its thread is the changing claim: every decision can be traced back to the original problem, show how the evidence changed, and explain why the next exposure is proportionate.

Scale ceremony, authority, and records to the risk#

The six decisions do not justify six equally heavy meetings. Scale the gate to the next commitment:

• A reversible internal experiment may need an asynchronous Gate Card and one accountable approver.
• A controlled customer test needs explicit consent or exposure rules, measurement, support, and a stop path appropriate to the context.
• A broad launch, sensitive-data change, contractual dependency, or product sunset needs cross-functional receipts and clear decision authority.

Keep non-negotiable constraints separate from trade-offs. A weighted score can hide a critical security, legal, or customer-harm condition inside a strong average. Review veto conditions directly; use judgment across the remaining evidence, and record that judgment.

Maintain a decision ledger with the Gate Card, evidence links, outcome, rationale, conditions, dissent, owner, and expiry date. When evidence changes, open a new decision rather than editing the old rationale into a cleaner story. Over time, the ledger shows which assumptions repeatedly survive, which gates approve work without usable receipts, and where stop decisions arrive too late.

Finally, review the gate system itself. A gate that never changes a decision may be redundant, badly timed, or deprived of real alternatives. A gate that stops everything may be using proof standards mismatched to reversible learning. The objective is not maximum documentation. It is a clear relationship between evidence, uncertainty, and the next commitment.

Final trigger test: did the cost of error change?#

Not every handoff merits a gate. Use one where the next step changes the cost of error, then test whether completed activity actually changed the evidence. Interviews alone do not pass discovery. A prototype alone does not pass validation. Merged code alone does not pass delivery. A campaign date alone does not pass launch. Live does not continue by inertia, and a roadmap label of “end of life” does not complete sunset.

Put evidence gates at the few points where the next commitment changes the cost of being wrong. Preserve the limits of the evidence and keep revise, hold, and stop available as real outcomes. That is enough structure to make the lifecycle accountable without pretending product development follows one universal set of boxes.

Frequently asked questions#