Opportunity Discovery

Guide · Enterprise AI Solution EngineeringPage 2 of 18Overview → Discovery

Executive summary

Discovery turns “how can we use generative AI?” into a clear problem: which business issue is worth solving, what blocks it today, and what outcomes matter. Collect context, map stakeholders and workflows, and leave with artefacts—not workshop theatre.

When to use this page

• Use when the problem is still ambiguous or technology-led.
• Use before architecture, model choice or vendor selection.
• Skip ahead to Business case if discovery artefacts already exist and only prioritisation remains.

Executive view

Fund discovery that produces a problem statement, success measures and a prioritised next decision—not a demo.

Decision required: Is the opportunity clear enough to enter structured prioritisation?

Technical view

Map current-state process, data readiness and control-function constraints before naming patterns or platforms.

Capture assumption and constraint logs; missing process maps and metrics are discovery findings.

Owners

Owner · AI Solution Engineer / discovery lead

Contributors · Business owner, end users, architecture, data, security, legal, compliance, finance, change

Why discovery matters

Many failed AI projects begin with a technology-first question:

How can we use generative AI?

A better question is:

Which business problem is important enough to solve, and what is preventing the organisation from solving it today?

Discovery is the process of understanding business context, existing workflow, user needs, operational pain points, strategic priorities, data availability, technical constraints, risk tolerance and expected outcomes.

Discovery inputs

Before a workshop, collect:

• Business strategy documents
• Process maps
• Organisational structure
• Existing technology architecture
• Application inventory
• Data landscape
• Policies and risk registers
• Service-level agreements
• Customer feedback
• Operational metrics
• Previous transformation initiatives

If these artefacts do not exist, note the gap. Missing process maps and metrics are themselves discovery findings.

Stakeholder mapping

Identify stakeholders across six groups.

Group	Role in discovery
Executive sponsors	Strategic direction and funding (CEO, CIO, CTO, CDO, CAIO, BU leader)
Business owners	Own the process and business outcome
End users	Real workflow, exceptions and operational frustrations
Technical stakeholders	Architecture, cloud, data, AI, platform, integration, SRE
Control functions	Cybersecurity, privacy, legal, compliance, risk, audit, model risk
Commercial and operational	Finance, procurement, vendor management, service management, change, L&D

Discovery workshop structure

Part 1: Business context

Strategic priorities, market pressure, customer expectations, regulatory obligations, current transformation programmes.

Part 2: Current-state process

Map inputs, activities, systems, decisions, roles, outputs, exceptions and escalations.

Part 3: Pain points

Delays, rework, manual effort, inconsistency, knowledge gaps, compliance failures, poor customer experience, high operating cost.

Part 4: Desired future state

Define what success would look like in the language of outcomes, not tools.

Part 5: Constraints

Budget, deadlines, legacy systems, data limitations, security rules, regulatory restrictions, organisational readiness.

Part 6: Candidate AI opportunities

Generate potential interventions without prematurely choosing a technology.

Decision required

Do not leave discovery until a problem statement exists without naming a model, vendor or product—and a prioritised next decision is explicit.

Discovery question bank

Business

• What outcome matters most?
• How is the problem measured today?
• What is the cost of doing nothing?
• Why is this important now?
• Which strategic priority does it support?
• Who owns the outcome?

Workflow

• What triggers the process?
• Which steps are manual?
• Which decisions require judgement?
• Where do exceptions occur?
• What causes delays?
• Which systems are involved?
• How does work move between teams?

Users

• Who will use the solution?
• What decisions will it support?
• What level of explanation is required?
• How much autonomy is acceptable?
• What would cause users to reject the solution?

Data

• What data is required?
• Who owns it?
• Is it accurate, sensitive, and legally usable?
• Where is it stored and how frequently does it change?

Risk

• What could go wrong?
• What is the impact of an incorrect answer?
• Is human approval required?
• Are regulated decisions involved?
• Must the organisation explain the outcome?

Discovery outputs

At the end of discovery, produce:

• Problem statement
• Current-state process
• Future-state vision
• Stakeholder map
• Use-case inventory
• Assumption log
• Constraint log
• Data-readiness assessment
• Initial risk register
• Success measures
• Recommended next steps

Output

Problem statement, current-state process, stakeholder map, use-case inventory, assumption and constraint logs, data-readiness assessment, initial risk register, success measures and recommended next steps.

Case study: financial-services assistant

Discovery finding. Advisors and contact-centre agents average several minutes searching SharePoint, product PDFs, policy wikis and CRM notes for each complex query. Answers vary by tenure. Compliance has flagged inconsistent product explanations.

Problem statement draft. Reduce time-to-accurate answer for product and policy queries while keeping every response grounded in approved, versioned knowledge and within the user’s access rights.

Not yet decided. Model vendor, agent framework, or vector database. Those come after workflow, data readiness and risk classification.

Common failure modes

• Workshop theatre without artefacts
• Interviewing only executives and skipping end users
• Capturing ideas as “AI chatbot” instead of pain and outcomes
• Ignoring control-function constraints until late review
• Ending discovery without a prioritised next decision

Solution Engineer checklist

Solution Engineer checklist

• Pre-read pack assembled or gaps logged
• Six stakeholder groups represented or explicitly deferred
• Current-state process mapped with exceptions
• Pain points linked to measurable outcomes
• Use-case inventory separated from technology choices
• Assumption and constraint logs started

Practical exercise

Shadow one user for a single painful task. Record trigger, systems touched, decisions made, time spent searching, and what “good” would look like. Convert the notes into a one-page problem statement.

Key takeaways

• Start from the business problem and blockers, not generative AI.
• Cover six stakeholder groups—including control functions and end users.
• End discovery with artefacts and an explicit next decision.
• Keep technology choices out of the problem statement.

What to do next

1. Continue with Business case and prioritisation.
2. Keep VALUE quality gate open when scoring discovery artefacts.
3. Use 8D Framework Define / Discover stages for stage gates.