AI Opportunity Assessment Template: Evaluate AI Use Cases Before You Build

Why AI Opportunities Fail Before Development Starts

A McKinsey survey of AI initiatives found that over 60% of projects that failed to reach production were killed by pre-development factors: unclear ROI, data readiness problems, risk concerns raised late, or a total cost of ownership that exceeded the business case only after engineering had already started. The pattern is consistent: teams move to development before the opportunity is stress-tested, and the problems surface at demo time or at the six-month review.

Feature prioritization frameworks (RICE, ICE, value vs. effort) are not designed for this problem. They help you sequence work inside an approved roadmap. An opportunity assessment happens earlier: it answers the question of whether to pursue the AI use case at all, and whether the conditions for success actually exist.

When to run an AI opportunity assessment

Run this before any new AI initiative enters your roadmap. That includes net-new AI features, upgrades from rule-based to ML-based systems, integrations with external AI APIs, and internal AI tooling proposals from engineering. The template takes 2 to 4 hours to complete with input from your engineering lead and a data owner. That investment eliminates the 6-to-12-week development cycles that end in a killed project.

The Five Scoring Dimensions

The assessment scores the AI opportunity across five dimensions. Each dimension gets a score of 1 to 5, with scoring criteria defined below. A total score below 15 out of 25 is a red flag. Below 10 is a stop signal. But the total score is less important than the profile: a single dimension scoring 1 can kill an otherwise strong opportunity.

1. Business value

Does solving this problem create measurable business impact? Is the impact material enough to justify the investment?

5Direct, measurable impact on a top-3 company metric (revenue, retention, cost). Size is significant (>$500K ARR equivalent or >10% improvement in key metric).

3Clear impact on a secondary metric. Connection to top-line goal is 2-3 steps removed. Size is moderate.

1Impact is indirect, qualitative, or speculative. No clear metric. Value is 'better user experience' without a causal chain to business results.

2. Data readiness

Is the data required to build, train, and operate this AI feature available, accessible, and of sufficient quality?

5Training data exists, is labeled, is accessible to the team, and volume exceeds minimum requirements. Data pipeline is operational or easily buildable. No privacy or access blockers.

3Data partially exists. Some labeling effort needed, or data is accessible but requires transformation. Privacy review needed but likely clear.

1Data does not exist, requires collection from scratch, is locked behind regulatory or legal barriers, or volume is insufficient for the use case.

3. Technical feasibility

Is the problem well-suited to current AI capabilities? Is the solution path clear to the engineering team?

5Problem type is a known AI strength (classification, summarization, generation, code completion). Accuracy requirements are achievable with current models. Clear build-or-API decision. Engineering team has prior experience with this class of problem.

3Problem is solvable but requires R&D effort or novel approach. Solution path is directionally clear but involves meaningful uncertainty.

1Problem requires capabilities beyond current AI state-of-the-art, or engineering team has no adjacent experience. Solution path is unclear.

4. Risk profile

What is the failure mode if the AI is wrong, and are those failures acceptable?

5Failure mode is low stakes (wrong recommendation, not wrong action). Human is in the loop before any consequence. Regulatory environment is clear.

3Failure mode has moderate consequence. Mitigation strategy exists. Regulatory requirements are understood, some compliance work needed.

1Failure mode is high stakes (medical, legal, financial, safety). No human review layer. Regulatory landscape is unclear or unfavorable.

5. Total cost of ownership

Does the full cost of building, operating, and maintaining this AI feature justify the expected return over 12 to 24 months?

5Development cost is low to moderate. Inference costs at projected usage are well within budget. Maintenance requirements are predictable. Payback period is under 6 months.

3Development cost is moderate. Inference costs require monitoring. Payback period is 6 to 18 months. Some ongoing model maintenance expected.

1Development cost is high. Inference costs are uncertain or scale poorly with usage. No clear payback window. Ongoing retraining or fine-tuning costs are unplanned.

The Full Template (Fill-In Format)

Copy this template into a shared doc. Complete it with your engineering lead (for dimensions 3 and 5) and your data owner or analyst (for dimension 2). Budget 90 minutes for the first pass and 30 minutes for a second review after gathering input.

AI Opportunity Assessment

Opportunity overview

Opportunity name:
Date:
PM owner:
Engineering lead:
Data owner:
Problem statement (1-2 sentences: who is affected, what they cannot do today, why it matters):
Proposed AI approach (1-2 sentences):

Dimension 1: Business value

Primary business metric affected:
Current baseline value of that metric:
Expected improvement (% or absolute):
Confidence in that estimate (low / medium / high) and why:
Secondary metrics affected:
Connection to top-3 company goals (be explicit about the causal chain):
Score (1-5):

Dimension 2: Data readiness

Data required (type, volume, labels needed):
Data currently available (yes / partial / no):
Data access blockers (privacy, legal, ownership):
Data quality assessment (clean / needs work / unknown):
Estimated labeling effort if needed:
Score (1-5):

Dimension 3: Technical feasibility

Problem type (classification / generation / retrieval / other):
Build vs. use API decision and rationale:
Accuracy requirement for acceptable user experience:
Engineering estimate of achievability with current models:
Known technical risks:
Score (1-5):

Dimension 4: Risk profile

What happens when the AI is wrong? (describe the most likely failure mode):
Who is affected by that failure and how severely?
Is there a human review layer before the failure has consequences?
Regulatory or compliance requirements for this use case:
Reputational risk if failure becomes public:
Score (1-5):

Dimension 5: Total cost of ownership

Estimated development cost (time and dollars):
Estimated inference cost per 1,000 user actions at target volume:
Ongoing maintenance requirements (retraining, monitoring, labeling):
Estimated payback period:
Score (1-5):

Scoring summary

Business value: __ / 5
Data readiness: __ / 5
Technical feasibility: __ / 5
Risk profile: __ / 5
Total cost of ownership: __ / 5
Total score: __ / 25
Recommendation (proceed / proceed with conditions / pause / kill):
Conditions if any:

Use This Template in the AI PM Masterclass

The AI PM Masterclass walks through real opportunity assessments case by case, taught by a Salesforce Sr. Director PM who has evaluated hundreds of AI use cases in enterprise product teams.

How to Score and Present Your Assessment

The score profile matters more than the total. A 22/25 with a dimension-5 score of 1 is not a 22/25 in any practical sense: the cost structure alone can kill the project at launch. Read the profile, not just the total.

Strong proceed signal

Total score 20 or above AND no single dimension below 3. Business value and data readiness are both 4 or 5. Move to scoping.

Proceed with conditions

Total score 15 to 19 OR one dimension at 2 with others strong. Name the conditions explicitly: 'We proceed when data labeling is complete' or 'We proceed when legal review clears dimension 4.'

Pause and reinvestigate

Total score 10 to 14 OR two dimensions at 2. Fundamental questions unanswered. Return in 30 days with better data on the weak dimensions, not a revised score.

Kill

Total score below 10 OR any single dimension at 1. The underlying conditions for success do not exist. Document the reasoning and move resources to better opportunities.

When presenting to leadership, lead with the recommendation and the two or three most important scoring factors. Do not walk through every dimension sequentially. That buries the lead. Structure it as: here is what we assessed, here is the recommendation, here are the three factors that drove it, here are the conditions if any.

Five Common Pitfalls That Sink AI Opportunity Assessments

These are the patterns that consistently come up when AI initiatives get sent back from review or cancelled mid-development.

Inflating business value with vague qualitative claims

Phrases like 'improves user experience' or 'increases efficiency' are not scoreable. Every AI opportunity assessment needs a specific metric, a current baseline, and a credible improvement estimate. If you cannot name the metric, the business value score is 1.

Confusing data existence with data readiness

The data exists somewhere is not the same as the data is ready to use. Volume, quality, labeling, and access rights are all separate questions. Teams score this too high and hit data readiness walls two months into development.

Assuming low risk because the failure mode is not obvious

The failure mode for an AI recommendation system is not always the bad recommendation. It is also the user who follows the bad recommendation without questioning it, the downstream liability, and the trust destroyed when users discover the pattern. Think through second-order failure modes.

Treating inference costs as one-time development costs

Development is a sunk cost. Inference is a recurring cost that scales with usage. Teams build accurate cost models for development and then discover that serving 100,000 daily queries at $0.003 per query is $109,500 per month. Run the unit economics at target usage volume before scoring dimension 5.

Completing the assessment solo without engineering and data input

Dimensions 3 and 5 cannot be scored accurately without an engineering perspective. Dimension 2 cannot be scored without a data owner. An assessment completed by a PM alone is a speculation document, not an assessment. The process requires cross-functional input by design.

Making the Assessment Part of Your Process

The assessment is most valuable when it is a standing gate, not a one-off exercise. The best AI product teams run it on every new AI initiative as a matter of process, with the outputs stored in a shared doc that gets referenced at the quarterly planning review.

Building an institutional knowledge base

After six months of running assessments, you have a portfolio of evaluated opportunities: some proceeded, some were killed, some are paused. That portfolio tells you which dimensions your team consistently underestimates (usually data readiness and TCO), which types of AI use cases consistently score high in your context, and which stakeholders add the most accurate input to each dimension. This institutional knowledge makes future assessments faster and more accurate. Build the habit before you need the database.