When the stage becomes relevant
Operate becomes relevant when:
- users, employees, partners, or other products depend on an active capability;
- the organization must monitor availability, reliability, performance, data, security, privacy, accessibility, and support;
- incidents, defects, requests, costs, and product-health signals require prioritization;
- product outcomes and user behavior require continuing interpretation;
- vendors, integrations, infrastructure, or data sources require oversight;
- legal, regulatory, contractual, retention, audit, or governance obligations continue;
- ownership becomes unclear after a project or delivery team changes;
- a mature product accumulates technical debt, workarounds, or disconnected enhancements;
- changing conditions may require evolution or retirement;
- a replacement and legacy product must operate together during transition.
Operation begins as soon as people or systems rely on the product, even when availability remains limited.
Questions and decisionsRead section
Product health and user effect
- Is the product available, reliable, responsive, accurate, accessible, and supportable at the required level?
- Which failures or degraded conditions affect users most?
- Are important journeys and outcomes improving, stable, or declining?
- Which groups experience different performance, access, or support?
- What does the product communicate when it cannot perform normally?
Support and incidents
- What are users asking for help with, and what do repeated contacts reveal?
- Which incidents, defects, and problems require immediate response versus longer-term change?
- Are ownership, escalation, communication, recovery, and post-incident learning clear?
- Do workarounds protect users without becoming an invisible permanent process?
Measurement and outcomes
- Which product-health, behavior, support, cost, risk, and outcome measures inform decisions?
- Are the data complete, timely, comparable, and correctly interpreted?
- Which measures have become targets without preserving their original purpose?
- What qualitative evidence explains observed patterns?
- Does the product continue creating sufficient benefit to justify operation and investment?
Governance and obligations
- Who owns product direction, operational service, data, incidents, risk, vendors, and change decisions?
- Are security, privacy, legal, compliance, accessibility, financial, contractual, and retention responsibilities being met?
- Which accepted risks or exceptions require review or expiration?
- How are competing maintenance, support, risk, and improvement needs prioritized?
Sustainability and future direction
- What do technical debt, architecture, vendor conditions, skills, cost, capacity, and dependencies imply for sustainability?
- Which issues should be corrected through operation and which require Evolve?
- Does new evidence require renewed Discover, Define, Design, Develop, Validate, or Adopt work?
- Should investment increase, remain stable, decrease, or move toward retirement?
Activities and evidenceRead section
Useful operating work may include:
- monitoring availability, reliability, performance, capacity, integrations, data freshness, security, privacy, accessibility, and critical journeys;
- supporting users and analyzing contact reasons, complaints, requests, and workarounds;
- detecting, triaging, communicating, resolving, and learning from incidents and problems;
- maintaining product content, data, configurations, dependencies, certificates, access, and vendor relationships;
- reviewing product behavior, adoption, outcome, cost, risk, and support evidence;
- conducting continuing user research and accessibility evaluation;
- testing changes across relevant devices, channels, integrations, and operational conditions;
- maintaining continuity, recovery, backup, rollback, and incident procedures;
- managing vulnerabilities, patches, technical debt, quality, and lifecycle obligations;
- reviewing service levels, accepted risks, exceptions, contracts, privacy conditions, retention, and compliance evidence;
- governing backlog, maintenance, operational improvement, and product decisions;
- identifying signals that require a more substantial product evolution or retirement decision;
- preserving decision records, ownership, operational knowledge, and product history.
Operational work should combine rapid response with longer-term learning. Repeated urgent work can signal a structural product, process, staffing, or technical problem.
Typical outputsRead section
Useful Operate-stage outputs may include:
- a product-health and outcome view;
- monitoring, alerting, analytics, and feedback evidence;
- incident, problem, recovery, and post-incident records;
- support patterns, knowledge, service levels, and escalation decisions;
- maintenance, vulnerability, accessibility, privacy, data, compliance, and risk records;
- technical-debt, dependency, vendor, cost, and capacity evidence;
- product and operational governance decisions;
- prioritized corrective work and operational improvements;
- updated ownership, decision rights, continuity, and support arrangements;
- recommendations for renewed discovery, definition, design, development, validation, adoption work, evolution, or retirement.
Operational reporting should support decisions. A dashboard without thresholds, context, ownership, or action can create visibility without control.
Contributing responsibilitiesRead section
Operations, reliability, engineering, and support
Operations, reliability, platform, engineering, and support specialists maintain technical service, respond to incidents, manage recovery, and provide evidence about recurring problems and sustainability.
Product management and product ownership
Product management connects operating evidence to users, outcomes, investment, product direction, governance, and future choices. Product ownership connects defects, maintenance, support, technical debt, and product changes to an ordered backlog and day-to-day tradeoffs.
Data, analytics, research, experience, and accessibility
Data and analytics specialists maintain measurement quality and interpret patterns. Research, experience, content, and accessibility specialists explain user behavior, barriers, comprehension, and cross-channel effects that monitoring alone cannot show.
Security, privacy, quality, legal, and compliance
Specialists maintain controls, assurance, testing, vulnerability response, consent, retention, audit, accessibility, regulatory, and risk responsibilities as conditions change.
Business and operational leaders maintain workflows, policy, staffing, capacity, vendor, and financial ownership. Portfolio governance connects product evidence to competing investments and continuation decisions.
Cross-lifecycle considerationsRead section
- Launch and Adopt establish rollout, ownership, support, measures, and early behavior patterns.
- Discover through Validate provide the evidence and decisions that operation must preserve and test in real use.
- Evolve uses operating evidence to decide how direction and investment should change.
- Retire begins when continued operation is no longer justified and withdrawal responsibilities require coordinated action.
Operate can trigger any earlier stage. A reliability issue may require Develop; repeated confusion may require Design; declining outcomes may require Discover and Define; a material fix may require Validate and relaunch.
Common mistakesRead section
Treating uptime as product success
Availability matters, but it does not show usability, accessibility, adoption, outcomes, trust, cost, or continued relevance.
Moving product ownership away after launch
Technical operation cannot replace continuing product direction, prioritization, measurement, adoption, investment, and retirement decisions.
Allowing requests to become the roadmap
Support contacts and stakeholder requests provide evidence. They should be interpreted against users, outcomes, patterns, risk, and product direction.
Normalizing repeated workarounds
Manual effort can protect users temporarily while hiding a structural problem. Track its cost, risk, and effect and make an explicit longer-term decision.
Separating incidents from product learning
Incident resolution restores service. Product learning asks what the event reveals about experience, design, architecture, ownership, support, or priorities.
Monitoring without decision thresholds
Measures need context, owners, and actions. More dashboards do not resolve ambiguous responsibility.
Deferring accessibility and privacy maintenance
Product changes, content, dependencies, user needs, and regulations can make earlier evidence outdated. These responsibilities continue in operation.
Decision signals
Continue normal operation
Continue when product health, support, obligations, outcomes, cost, and risk remain within understood conditions and accountable owners can address expected variation.
Correct through operational work
Use focused maintenance or support changes when the problem is understood, the response fits the current product direction, and evidence can confirm the correction.
Revisit an earlier stage
Return to Discover for an unclear need or cause, Define for direction or ownership, Design for experience, Develop for implementation, Validate for material evidence, Launch for rollout, or Adopt for persistent behavior barriers.
Advance to Evolve
Evolve when evidence supports a deliberate change to product direction, audience, value, capabilities, architecture, operating model, or level of investment.
Limit, pause, or retire
Limit use when a product condition affects a defined audience or capability. Pause availability when continuing use creates unacceptable risk. Move toward Retire when the need has changed, a replacement exists, sustainability is unacceptable, or continued value does not justify operation.
Applied-example continuation
The status product now supports a stable group of request types. Operations monitors data freshness, account access, notification delivery, exceptions, support contacts, accessibility concerns, security events, operating cost, and customer behavior.
Support evidence shows that the improved exception state reduces confusion, but one upstream system continues missing expected updates. The organization adds monitoring and an operational escalation rather than displaying unreliable status. Product analytics and research show sustained use and fewer avoidable contacts for supported requests.
Over time, customers ask for status on additional request types, and operations reports that manual escalation remains expensive outside the supported scope. A platform modernization initiative creates a possible path to more reliable data. The product remains healthy, but the combined evidence supports an Evolve decision about broader coverage, clearer exceptions, and additional channel options.
Source notesRead section
- GOV.UK Service Manual — How the live phase works. Supports sustainable operation, continuing user research, measurement, accessibility, quality, security, support, and improvement.
- U.S. Digital Services Playbook. Supports accountable ownership, data-driven decisions, automated testing, security and privacy, and ongoing attention to user needs.
- NIST Special Publication 800-160 Volume 1. Supports lifecycle operation, maintenance, risk management, monitoring, and multidisciplinary system responsibility.