OmniSmithConnect with us

OmniSmith Learning CenterGuides

OmniSmith Learning Center

Digital Product Lifecycle Stage 01

Opportunity

Determine whether a potential need or business problem deserves attention.
Direct answer

The Opportunity stage gives an organization a disciplined way to recognize and evaluate a potential need or business problem before making material investment or committing to a preferred solution. The central question is not, “Should we build this idea?” It is, “Do we have sufficient reason to give this situation structured attention, and what should happen next?”

When the stage becomes relevant

Opportunity can become relevant when:

  • users describe an unmet need or recurring difficulty;
  • business or operational performance reveals a persistent problem;
  • an existing digital product underperforms, creates avoidable effort, or no longer supports current needs;
  • strategy, policy, regulation, security, privacy, accessibility, or risk conditions change;
  • a new market, partnership, data source, or organizational capability creates a possible opening;
  • a new technology appears capable of supporting a valuable use case;
  • support patterns, operational incidents, or product analytics reveal a recurring concern;
  • an organization may need to replace, consolidate, reposition, or retire an existing product;
  • portfolio governance identifies an investment question requiring further attention;
  • several disconnected requests may reflect one larger business problem.

A proposed feature, solution, vendor, or technology can trigger the conversation, but it should not define the opportunity before the underlying need and relevance receive attention.

Questions and decisionsRead section

Central decision and possible outcomes

The Opportunity-stage decision determines what level and direction of attention the situation should receive.

Possible outcomes include:

  • advance to Discover because the signal appears credible and material uncertainty requires investigation;
  • route the need to an existing product or another lifecycle stage when the problem and decision context are already sufficiently understood;
  • combine the opportunity with related work that addresses the same underlying problem or affected group;
  • reframe the opportunity because the available evidence points to a different need;
  • pause with a defined trigger, evidence need, owner, or review date;
  • stop because the need lacks sufficient relevance, evidence, impact, ownership, or strategic justification;
  • take a non-product action when policy, process, training, operations, or another response better addresses the situation.

Stopping, pausing, combining, or redirecting work can represent responsible product management. Opportunity should protect the organization from investing in a solution merely because someone proposed it.

Questions that guide the Opportunity decision

The signal

  • What happened or changed to bring this situation to attention?
  • Which observations represent evidence, and which statements remain assumptions or interpretations?
  • Does the signal appear isolated, recurring, growing, or time-sensitive?
  • How reliable and current is the available evidence?

People and context

  • Who experiences the need, difficulty, risk, or possible benefit?
  • In what workflow, environment, or broader experience does the situation occur?
  • Which groups may be affected differently or may face greater barriers?
  • Who else depends on the current product, process, data, or service?

Business relevance

  • What business problem or organizational outcome gives the opportunity relevance?
  • Why might the situation deserve attention now?
  • What may happen if the organization does nothing?
  • Does the opportunity connect to strategy, obligations, risk reduction, service quality, revenue, cost, efficiency, trust, or another meaningful outcome?

Existing responses

  • Does an existing product, capability, process, or initiative already address part of the need?
  • Could the situation represent an operational issue, an adoption problem, a product-evolution need, or a portfolio decision rather than a new product opportunity?
  • Are similar opportunities already being considered elsewhere in the organization?

Uncertainty and responsibility

  • What remains unknown, disputed, or weakly supported?
  • Which uncertainty most affects the decision to investigate further?
  • What constraints, dependencies, risks, or obligations already deserve attention?
  • Who owns the decision about what happens next?
  • What is the smallest responsible next action that can improve the decision?
Activities and evidenceRead section

Opportunity-stage work should remain proportionate to the decision. Useful activities may include:

  • capturing the original signal and its source;
  • speaking with the people who raised or experience the concern;
  • reviewing existing user feedback, support records, operational data, product analytics, financial information, audit findings, or market evidence;
  • describing the current condition and the likely consequence of no action;
  • identifying the affected users, stakeholders, workflows, products, and organizational areas;
  • connecting the situation to strategy, outcomes, obligations, or material risks;
  • checking for existing products, initiatives, requests, or portfolio items that overlap;
  • separating observed facts from assumptions, interpretations, and preferences;
  • identifying initial constraints, dependencies, and specialist concerns;
  • documenting the questions that further investigation should answer;
  • making and recording the next decision.

Evidence may be qualitative or quantitative. A small amount of credible evidence can justify discovery when uncertainty remains high. A large volume of weak or repetitive opinion does not automatically justify investment.

Opportunity-stage work should generally avoid extensive solution design, detailed requirements, vendor selection, delivery estimation, or a complete business case. Those activities can narrow the discussion prematurely or create the appearance of certainty before the organization understands the problem.

Typical outputsRead section

The Opportunity stage should leave behind enough information to make the next decision understandable and revisitable. Depending on the context, useful outputs may include:

  • a concise opportunity statement;
  • the source and summary of the initial evidence;
  • the affected people, workflows, products, or organizational areas;
  • the business relevance and possible outcomes;
  • the current-state or no-action consequence;
  • known assumptions, uncertainties, constraints, dependencies, and material risks;
  • known overlap with existing products, initiatives, or portfolio items;
  • the decision and its rationale;
  • the person accountable for the next decision;
  • the next action, review trigger, or reason for stopping.

The output can be a short record rather than a formal document. The level of detail should reflect the materiality, uncertainty, risk, and reversibility of the decision.

A practical opportunity-statement pattern

An opportunity statement can provide a neutral starting point:

For [affected people or context], [observed need or business problem] is contributing to [evidence or consequence], creating a reason to determine [what requires further investigation or decision].

The statement should describe the situation without embedding a preferred feature, vendor, channel, or technical solution.

Contributing responsibilitiesRead section

No universal team owns every Opportunity-stage activity. Participation should reflect the situation and the evidence required.

Product leadership

Product management can connect the signal to users, business relevance, outcomes, existing product direction, uncertainty, and the next decision. When an existing product is involved, product ownership can contribute backlog, delivery, acceptance, and operational context. Neither responsibility replaces specialist judgment.

Business and operational leadership

Business sponsors, operational leaders, service owners, and subject-matter experts can explain the current condition, affected workflows, strategic relevance, consequences, and decision urgency.

Users, research, design, and accessibility

Users and frontline stakeholders provide direct evidence about needs and barriers. Research, design, service-design, and accessibility specialists can help interpret early signals and identify whose experience requires further investigation.

Data, finance, and performance

Analytics, finance, and performance specialists can clarify baselines, trends, costs, benefits, measurement limitations, and whether the available information supports the claimed relevance.

Engineering, architecture, operations, and support

Engineering, architecture, operations, and support specialists can identify existing capabilities, technical dependencies, operational patterns, feasibility concerns, reliability issues, and constraints. Opportunity does not require them to design or estimate a solution before the need receives sufficient attention.

Risk and obligation specialists

Security, privacy, legal, compliance, procurement, data-governance, safety, and other specialists can surface obligations or risks that influence whether, when, or how the opportunity should proceed.

The accountable decision-maker should integrate these contributions while leaving specialist accountabilities intact.

Cross-lifecycle considerationsRead section

Opportunity does not occur only before a new product. Signals can emerge anywhere in the Digital Product Lifecycle:

  • Discover may reveal that the original opportunity needs to be reframed or combined with another.
  • Validate may expose a different business problem than the product was intended to solve.
  • Adopt may reveal barriers that create a new opportunity for the existing product or surrounding experience.
  • Operate may produce support, performance, reliability, cost, or risk evidence requiring renewed attention.
  • Evolve may identify a broader opportunity that exceeds the current product direction.
  • Retire may reveal an unmet need that a replacement, consolidation, or transition must address.
  • Portfolio governance may create, combine, defer, or stop opportunities based on competing investments and organizational capacity.

A new technology does not become a product opportunity merely because it exists. The technology becomes relevant when evidence connects it to a meaningful need, business problem, outcome, or obligation.

Common mistakesRead section

Starting with the solution

“Build a mobile application” or “add artificial intelligence” describes a preferred response, not the opportunity. Return to the observed need, affected people, business relevance, and evidence.

Treating the loudest request as the most important signal

Volume, authority, urgency, and repetition can influence attention, but they do not establish impact by themselves. Compare the request with broader evidence and affected groups.

Requiring discovery-level certainty before authorizing discovery

Opportunity should not prove the complete problem. It should determine whether the evidence and uncertainty justify further investigation.

Treating strategic alignment as sufficient evidence

A strategy statement can explain relevance, but it does not confirm that the need exists, that the proposed outcome matters, or that a particular solution should proceed.

Ignoring the current-state alternative

The organization should understand what may happen if it does nothing, continues the current approach, or uses an existing product. Otherwise, the opportunity can appear more compelling than the evidence supports.

Assuming every opportunity requires a new product

The appropriate response may involve an existing product, an operational change, a policy decision, learning and enablement, process improvement, vendor management, or no action.

Approving a project too early

Moving an opportunity into funded delivery before understanding the problem can turn later research into justification for a decision that has already been made.

Treating pause or stop as failure

A decision not to invest can preserve capacity for more consequential needs. Record the rationale so new evidence can prompt reconsideration when appropriate.

Decision signals

Advance to Discover

Advancing to Discover may be appropriate when:

  • a credible signal connects to a potential need or business problem;
  • the people or context affected can be identified well enough to guide investigation;
  • the possible impact or obligation appears relevant enough to justify attention;
  • material questions remain unanswered;
  • further evidence could meaningfully change a product decision;
  • someone accepts responsibility for the next decision and the investigation has a clear purpose.

This decision authorizes learning. It does not approve a preferred solution, development effort, or full investment.

Route to existing product work or another stage

Routing elsewhere may be appropriate when the evidence already connects the need to an active product and the next decision belongs more clearly to Define, Design, Develop, Validate, Adopt, Operate, Evolve, or Retire. The lifecycle stage should match the decision purpose rather than force repeated work.

Combine or reframe

Combining or reframing may be appropriate when several requests reflect the same underlying business problem, the initially affected group was too narrow, or the evidence points to a different need than the one first described.

Pause

Pausing may be appropriate when the signal appears credible but timing, ownership, capacity, evidence access, a dependency, or an external decision prevents responsible progress. A useful pause records what must change and who will reconsider the opportunity.

Stop

Stopping may be appropriate when evidence does not support a meaningful need, the situation is already adequately addressed, the opportunity does not merit additional attention, no responsible owner exists, another action better addresses the problem, or foreseeable costs and risks outweigh the reason to continue.

Applied-example continuation

Initial signal

A growing organization receives increasing customer contacts asking for the status of active service requests. Support teams report repeated calls, customers describe uncertainty, and employees maintain separate spreadsheets to track escalations. A leader proposes building a mobile application with push notifications.

Opportunity-stage reframing

The proposed mobile application becomes an input, not the definition of the opportunity. The organization reframes the situation:

For customers managing active service requests, limited status visibility is contributing to repeated support contacts, avoidable uncertainty, and additional operational effort, creating a reason to determine whether the current digital experience should change.

Evidence considered

The initial review examines contact reasons, wait times, request volumes, status-related complaints, existing account-portal usage, manual tracking practices, affected customer groups, accessibility concerns, and current platform capabilities. The review also identifies important assumptions: customers may want proactive updates, but the preferred channel and the underlying causes remain unclear.

Decision

The available evidence supports additional attention. The organization advances to Discover with specific questions about customer needs, the end-to-end request journey, the reliability of status data, operational ownership, channel preferences, accessibility, privacy, and the outcomes that should improve.

The decision does not approve a mobile application. It authorizes investigation into the business problem and the most responsible product direction.

Related learning

Move to an adjacent stage or use a reference to clarify a connected concept.

Next stageDiscoverFoundational guideDigital Product LifecycleDictionary termOutcomeDictionary termDigital product
Source notesRead section
  1. GOV.UK Service Manual — How the discovery phase works. Supports beginning with an understood problem, users, constraints, and evidence before committing to building a service.
  2. U.S. Digital Services Playbook. Supports beginning with the needs of real people, documenting qualitative and quantitative evidence, addressing the whole experience, assigning accountable leadership, and using data to drive decisions.
  3. The Green Book 2026 — HM Treasury. Supports establishing rationale, objectives, the consequence of continuing the current state, broad options, risks, uncertainty, and transparent reasons for progressing or rejecting an option. This manuscript adapts those general appraisal principles without treating the public-sector framework as a required product method.
  4. NIST Special Publication 800-160 Volume 1. Supports addressing stakeholder needs, concerns, requirements, and risk early and throughout the system lifecycle. The Opportunity profile uses this principle to surface specialist considerations without transferring specialist accountability to product leadership.