When the stage becomes relevant
Evolve can become relevant when:
- user needs, behavior, expectations, or contexts change materially;
- product outcomes plateau or decline despite stable operation;
- repeated support or operational problems reveal a structural limitation;
- technology, data, architecture, cost, security, privacy, accessibility, or vendor conditions threaten sustainability;
- strategy, policy, regulation, funding, market conditions, or organizational structure changes;
- a product must serve a new audience, channel, geography, or use case;
- portfolio governance identifies duplication, consolidation, or competing investment;
- a legacy capability requires modernization;
- a product has accumulated disconnected enhancements without a coherent future direction;
- a replacement, partnership, acquisition, or platform creates a different product path;
- continued investment must be compared with reduction, repositioning, consolidation, or retirement.
Evolution should be triggered by evidence and decision need, not by a calendar requirement to produce a new roadmap.
Questions and decisionsRead section
Continuing need and value
- Which user and business needs continue, change, emerge, or disappear?
- Does the product still address a meaningful business problem?
- Which outcomes and groups receive benefit, and where has performance changed?
- What would happen if the organization maintained, reduced, repositioned, combined, replaced, or retired the product?
- Does continued investment remain justified compared with other opportunities?
Evidence and causes
- What do product health, behavior, research, support, cost, risk, and outcome evidence show together?
- Which observed problems are operational and which require a change in direction?
- What assumptions about users, value, technology, or sustainability require renewed discovery?
- Are external changes temporary, uncertain, or durable enough to influence the product?
Direction and boundaries
- Should the product improve within its current purpose, expand, narrow, modernize, consolidate, reposition, or prepare for retirement?
- Which users, outcomes, capabilities, channels, data, workflows, or products belong within the changed boundary?
- Which existing capabilities should continue, change, migrate, combine, or stop?
- How does the evolved product fit the wider portfolio and user journey?
Investment and feasibility
- Which benefits, costs, risks, dependencies, skills, vendors, architecture, and operating changes affect the options?
- Can the organization support the transition and the resulting product sustainably?
- Which technical debt or platform limits must be addressed rather than carried forward?
- What evidence would justify increasing, maintaining, reducing, or ending investment?
Transition and learning
- Which earlier lifecycle decisions must be revisited?
- How can the organization test the changed direction before broad commitment?
- Which users, data, integrations, operations, and obligations would be affected?
- How will the organization protect current users while introducing change?
- Which conditions indicate that evolution should proceed or give way to retirement?
Activities and evidenceRead section
Useful evolution work may include:
- reviewing product-health, adoption, support, outcome, cost, risk, accessibility, security, privacy, and technical evidence;
- conducting renewed discovery with current, former, excluded, and potential users;
- evaluating changed strategy, policy, regulation, market, technology, vendor, data, and portfolio conditions;
- comparing improvement, expansion, modernization, consolidation, repositioning, reduction, replacement, and retirement options;
- revising product purpose, audiences, outcomes, boundaries, principles, requirements, ownership, and measures;
- assessing architecture, data, integrations, technical debt, operating model, skills, capacity, and transition feasibility;
- prototyping and testing changed experiences or business models;
- evaluating effects on existing users, workflows, channels, support, contracts, records, and obligations;
- defining transition, migration, coexistence, rollback, and communication needs;
- reprioritizing roadmap and backlog around the updated direction;
- testing the riskiest assumptions before material commitment;
- recording the investment decision, evidence, tradeoffs, rejected options, and review conditions.
Evolution can contain renewed Discover, Define, Design, Develop, Validate, Launch, and Adopt work. Those stages remain distinct because each serves a different decision within the changed direction.
Typical outputsRead section
Useful Evolve-stage outputs may include:
- an evolution rationale and evidence summary;
- an updated product purpose, audience, outcome, boundary, or value logic;
- comparative options and investment decisions;
- revised product strategy, roadmap, requirements, measures, and decision rights;
- an improvement, expansion, modernization, consolidation, reduction, or repositioning plan;
- technical, data, operational, organizational, vendor, and portfolio implications;
- transition, migration, coexistence, support, communication, and rollback conditions;
- tested assumptions and evidence limitations;
- updated risks, obligations, dependencies, and ownership;
- a decision to proceed, narrow, combine, pause, reduce investment, return to discovery, or retire.
The output should explain why change is justified and how the new direction differs. A refreshed feature list does not establish product evolution.
Contributing responsibilitiesRead section
Product and portfolio leadership
Product management connects evidence to continuing need, outcomes, direction, investment, and transition. Product ownership connects the changed direction to backlog and delivery decisions. Portfolio governance compares products, opportunities, dependencies, capacity, and investment without replacing product-level evidence.
Users, research, experience, and accessibility
Current, former, excluded, and potential users provide evidence about changing needs and consequences. Research, experience, content, service-design, and accessibility specialists help redefine the experience and protect groups affected by change.
Engineering, architecture, data, and operations
Specialists assess modernization, integration, data, security, reliability, maintainability, migration, technical debt, cost, and operational feasibility. Their evidence should influence the direction before investment becomes fixed.
Business, finance, change, and obligation specialists
Business leaders, finance, procurement, vendors, change, communications, support, legal, compliance, privacy, security, and risk contributors evaluate strategy, economics, contracts, transition, obligations, and organizational readiness.
The accountable decision-maker integrates these contributions while preserving specialist accountability.
Cross-lifecycle considerationsRead section
- Operate supplies the evidence that may trigger evolution.
- Opportunity and Discover can re-evaluate the need and changed context.
- Define and Design establish the changed direction and experience.
- Develop and Validate create and evaluate new capability.
- Launch and Adopt manage introduction and behavior change.
- Retire becomes appropriate when no responsible evolution option justifies continued operation.
Evolution may occur several times. Each cycle should preserve learning and avoid treating prior investment as evidence that future investment remains justified.
Common mistakesRead section
Treating every enhancement as evolution
Routine corrections and minor improvements can remain within operation. Evolution involves a deliberate change to direction, boundary, capability, architecture, audience, or investment.
Allowing the backlog to determine the future
Accumulated requests reflect partial perspectives. Reassess needs, outcomes, evidence, strategy, risk, and portfolio context before setting direction.
Modernizing technology without reassessing the product
Replacing a platform can preserve an outdated experience, boundary, or value assumption. Evaluate what should continue before rebuilding it.
Expanding because the capability exists
Technical feasibility does not establish need, benefit, organizational readiness, or responsible use.
Ignoring current users during transformation
Existing users, records, workflows, integrations, and support needs remain product responsibilities throughout change.
Using evolution to avoid retirement
Additional features or modernization do not restore relevance automatically. Compare credible evolution options with responsible retirement.
Treating prior investment as future justification
Decisions should consider future benefit, cost, risk, and alternatives rather than protecting sunk cost.
Decision signals
Proceed with an evolved direction
Proceed when evidence supports a continuing or changed need, the proposed direction offers credible benefit, the organization can sustain the change, material risks and obligations are understood, and continued investment compares responsibly with alternatives.
Test or narrow the direction
Use focused discovery, prototypes, limited development, or phased introduction when material assumptions can be resolved before broader commitment.
Return to an earlier decision context
Return to Discover for changed needs, Define for direction and boundaries, Design for experience, Develop for capability, Validate for evidence, or Launch and Adopt for introduction and use.
Combine, reposition, reduce, or pause
Combine with another product when needs and ownership overlap. Reposition when a different audience or outcome offers credible relevance. Reduce scope or investment when a smaller product remains justified. Pause when a dependency or uncertainty prevents responsible choice.
Advance to Retire
Retire when the need no longer exists, another product can meet it, sustainability is unacceptable, obligations or risks cannot be managed responsibly, or continued value does not justify operation and change.
Applied-example continuation
Operating evidence supports the status product’s value for current request types and shows continuing demand for broader coverage. A platform modernization initiative could provide more reliable status data, while research identifies a need for clearer exception handling and selective proactive updates.
The organization evaluates expansion, modernization, and maintaining the current scope. It rejects a broad mobile rebuild because channel-specific duplication does not address the data and ownership constraints. The evolved direction expands trustworthy status across additional request types, modernizes the shared status source, and adds channel options only where users demonstrate benefit.
The roadmap prioritizes the status data model, ownership, migration, exception behavior, and reusable account and notification capabilities. Expansion remains phased and requires renewed design, development, validation, launch, and adoption decisions. Continued investment depends on data reliability, user benefit, operational capacity, and reduced support burden.
Source notesRead section
- GOV.UK Service Manual — How the live phase works. Supports continuing research, evidence-led improvement, cross-channel effects, roadmap decisions, sustainable operation, and retirement when continued use is not justified.
- U.S. Digital Services Playbook. Supports iterative change, real-user evidence, accountable product ownership, data-driven decisions, and attention to the complete experience.
- NIST Special Publication 800-160 Volume 1. Supports lifecycle change, maintenance, risk-informed engineering, evolving stakeholder needs, and responsible transition.