AI Opportunity Scoping Canvas

AI Opportunity Scoping Canvas

Use this concise canvas to rapidly evaluate whether an AI idea is worth prototyping, what risks to watch for, and what next steps will be required to test and scale it. The canvas helps teams focus scarce engineering, data, and product resources on opportunities that are realistic, valuable, and safe.

How to use

1. Gather a small cross-functional team (product, data, engineering, domain expert, ethics/privacy lead).
2. Work through each canvas section and capture a short, specific answer.
3. Score the opportunity using the scoring guidance below and compute a weighted score.
4. Use the score plus qualitative safety/ethics flags to decide whether to prototype, refine, or drop the idea.

Canvas sections (with prompts)

1. User need & hypothesis
   Who is the user or process? What problem are we solving? What is the hypothesis about how AI will help? Keep it to one clear sentence.
2. Value metric
   What specific metric will show value if the AI works? (e.g., % fewer manual reviews, minutes saved per case, revenue uplift per user, defect reduction rate).
3. Expected uplift (estimate)
   Roughly how much improvement do we expect versus current baseline? Provide a numeric range or percent when possible and a short justification.
4. Data availability & quality
   What data is needed? Where does it live? Volume, labeling needs, privacy concerns, biases, freshness, and known quality issues.
5. Model approach options
   Candidate technical approaches (rules, classical ML, supervised deep learning, embeddings+retrieval, LLMs, hybrid). Note feasibility and known unknowns.
6. Compute & infrastructure requirements
   On-prem vs cloud, expected inference cost per request, batch vs real-time, data pipeline needs, monitoring and retraining cadence.
7. Integration points
   Where will the model output be consumed? Which systems/users must change? What UX or workflow decisions are needed?
8. Safety & ethics flags
   Potential harms, fairness risks, regulatory issues, PII/exposure, explainability needs, misuse scenarios, and mitigation ideas.
9. Measurement plan
   Experiment design, evaluation metrics, acceptance criteria for a minimum viable proof of concept (PoC), and data collection plan.
10. Cost estimate
    Ballpark engineering, data labeling, infrastructure, and operational costs for PoC and for initial scale (month 1 and annualized).
11. Go / No-go criteria
    Explicit pass/fail thresholds combining value, data readiness, safety mitigations, and cost—used to decide whether to prototype.

Scoring guidance (quick decision tool)

Score the following dimensions 1 (weak) to 5 (strong). Optionally apply weights to reflect your priorities.

• Value potential (how big a business / user impact) — 1–5
• Data readiness (available, labeled, trustworthy) — 1–5
• Technical feasibility (clear approach, low unknowns) — 1–5
• Integration effort (low friction to adopt) — 1–5
• Safety & compliance readiness (risks manageable) — 1–5

Example weights: Value 30%, Data 25%, Feasibility 20%, Integration 15%, Safety 10%. Compute a weighted average score. Use thresholds such as:

• >=4.0: Strong candidate — prototype with a focused PoC.
• 3.0–3.9: Promising — refine scope, de-risk data and safety before prototyping.
• <3.0: Low priority — iterate on hypothesis or deprioritize.

Short worked example

Context: Customer support team wants faster triage of incoming tickets.

• User need & hypothesis: Reduce agent triage time by automatically classifying and routing tickets so agents see higher-priority work sooner.
• Value metric: Triage time per ticket (minutes) and % tickets routed correctly.
• Expected uplift: 30–40% reduction in triage time; 10% faster SLAs.
• Data: 200k historic tickets with categories, but labels are noisy — requires 5k relabeled examples for initial model.
• Model approach: Fine-tune a text classification model or use embeddings+nearest-neighbor for initial PoC.
• Compute: Low, can run in near-real-time on cloud inference; estimated $500–1,000/month at pilot scale.
• Integration: Output inserted into ticketing system UI via a simple API; small UX change required.
• Safety flags: Misclassification could misroute urgent tickets — need confidence thresholds and human-in-the-loop fallback.
• Measurement plan: A/B test on 10% traffic for 4 weeks; primary metric triage time, secondary metric routing accuracy and SLA breaches.
• Costs: Labeling $4k, engineering 2 sprint effort, infra $1k/mo.
• Decision: Weighted score 4.1 -> prototype with explicit human-in-loop guardrails.

Go/no-go checklist (quick)

• Is the value metric measurable in the PoC timeframe?
• Is a minimally useful dataset available or feasible to produce quickly?
• Can safety risks be mitigated for the pilot (fallback, monitor, human review)?
• Are integration points reachable within the planned effort?
• Does the ROI look plausible given estimated cost and expected uplift?

Recommended artifacts after scoping

• One-page scoping summary (canvas filled in).
• Scoring worksheet and computed weighted score.
• PoC plan: success criteria, timeline (4–8 weeks typical), roles, minimal data needs, and monitoring requirements.
• Safety & compliance brief listing mitigations and approvals needed.

Practical tips

• Start with the smallest test that would prove the hypothesis: prioritise low-cost data collection and quick instrumentation.
• Prefer hybrid approaches (rules + model or model + human review) during early pilots to reduce risk.
• Capture failure modes and deploy simple monitoring during PoC so you can learn quickly.
• Document assumptions clearly — many projects fail because hidden assumptions about data or integration are wrong.

When to revisit this canvas

Re-score after initial data collection or once a small prototype produces real metrics. Use the canvas as a living artifact through discovery, prototype, and early-scale phases.