Product Development Life Cycle: Add Evidence Gates from Discovery to Sunset

A product development life cycle is the repeatable, cross-functional process that turns an identified customer problem into a product, then governs its launch, live operation, and eventual retirement. The useful version does more than name phases. It places an evidence gate between meaningful increases in investment or customer exposure, forcing an explicit decision to continue, revise, hold, or stop before the next commitment is made.

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.

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.

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.

Use six investment states, not a ceremonial stage list#

The following six-phase model is a practical synthesis, not a claim that every company needs these exact names. Each phase ends when the team can make its named decision, not when a calendar box expires.

The gates should become stricter as exposure and reversibility change. 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.

Write the Gate Card before producing the evidence#

A gate becomes vulnerable to storytelling when the team decides what counts only after seeing the result. Before the phase begins, write a small Gate Card:

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 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 evidence labels 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 prevents 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: fund a problem, not a preselected feature#

Discovery should determine whether a problem merits more investigation before the team commits to a solution. 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.

For a B2B SaaS product, the discovery packet should make six things 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 discovery gate does not need a detailed backlog. It needs a defensible problem boundary and 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: prove the riskiest parts before authorizing delivery#

Validation turns a problem worth pursuing into a proposed product approach. The work may include prototypes, workflow simulations, technical spikes, pricing or packaging research, service-design tests, and direct evaluation with intended users. The artifact is not “an MVP” by default; it is evidence about the claims that could make the investment fail.

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.

Ask for a validation packet that connects claims to receipts:

Do not require every claim to be proven permanently. Require enough evidence for the next bounded commitment, label what remains assumed, and set the condition that will test it.

Gate 3: separate “built” from “ready for controlled exposure”#

Delivery is where the selected approach becomes a real product increment. That work belongs inside an appropriate SDLC, with its own architecture, testing, security, deployment, and operational controls. The product gate reviews their 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.

For a SaaS release, make these receipts inspectable before customer exposure:

• 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.

Gate 4: launch only after the limited release answers launch questions#

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.

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 should contain actual limited-release evidence, not only a completed campaign plan. It should also retain 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: make live value an active decision#

Launch moves the product into a longer learning period. GOV.UK defines live operation as sustainable support plus continued research, measurement, testing, quality assurance, and improvement. That is a stronger model than treating live as a permanent default.

Set 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. Trigger a 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: require evidence that sunset is safe, not merely economical#

A sunset proposal starts with the case for withdrawal, but the completion gate is about 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.

For a B2B SaaS product or feature, require these 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.

An illustrative SaaS workflow: carry one claim through every gate#

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.

The important thread is not the feature. It is the claim lineage. Every gate can trace the current decision back to the original problem, show how the evidence changed, and explain why the next exposure is proportionate.

Keep evidence gates lighter than the risk they control#

Evidence governance fails when every backlog item receives the same ceremony. 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.

Use a gate whenever the next step changes the cost of being wrong#

The product development life cycle earns its place when it prevents activity from masquerading as progress. Discovery does not pass because interviews were completed. Validation does not pass because a prototype exists. Delivery does not pass because code merged. Launch does not pass because a campaign date arrived. Live does not continue by inertia, and sunset does not complete because the roadmap says “end of life.”