Day 2
Day 2 — Problem Framing for AI
Mode: Daily Learning Mode
Level: Foundation to interview-ready
Theme: How strong AI PMs identify the right problems and reject weak
ones
1. Concept Overview
Simple explanation
Problem framing for AI means defining the problem in a way that makes it clear:
• what user pain exists
• where in the workflow it happens
• why it matters
• whether AI is actually the right solution
• how success will be measured
Most weak AI products fail before they are built, because the team framed
the problem poorly.
What weak problem framing looks like
• “Let’s build an AI chatbot for claims”
• “We should use GenAI for patient operations”
• “Can we add AI to underwriting?”
These are solution-first statements, not product problem statements.
What strong problem framing looks like
• “Claims adjusters spend too much time reading long claim files and
manually writing case summaries, causing delays and inconsistent
handoffs.”
• “Care coordinators struggle to identify overdue care actions from
fragmented patient records, reducing care gap closure rates.”
• “Fraud analysts waste time stitching together transaction history,
case notes, and alerts before making a decision.”
These are stronger because they define:
• user
• pain
• workflow step
• operational cost
• opportunity for improvement
AI-native PM leadership view
A strong AI PM frames the problem in a way that answers six core questions:
1. Who is the user?
2. What exact job are they trying to do?
3. What makes the workflow painful today?
4. Why is AI potentially better than alternatives?
5. What are the risks of using AI here?
6. What does success look like operationally and
commercially?
This is important because AI is expensive, probabilistic, and risky in
enterprise environments.
So framing is not just discovery work. It is risk reduction and strategic
clarity.
2. When AI Should / Should Not Be Used
When AI is a good fit during problem framing
AI is a good candidate when:
• the user pain involves unstructured content
• the work is repetitive but cognitively heavy
• the workflow requires summarization, extraction, classification,
prioritization, or recommendations
• the manual process is slow or inconsistent
• user productivity or decision quality can improve meaningfully
• a small error rate is manageable through review or controls
When AI is not the right first answer
AI is usually not the right primary mechanism when:
• the workflow is purely deterministic
• the business logic is fully known and stable
• exactness is mandatory every time
• the decision is high-risk and not reviewable
• the pain point is actually caused by bad workflow design, not lack of
intelligence
• there is no usable data or context available
AI vs rules vs software automation vs hybrid during framing
A strong PM does not just ask whether a problem is suitable for AI.
They ask which part of the workflow deserves which mechanism.
Example
Prior authorization workflow
• extracting key facts from clinical notes → AI/LLM
• checking required payer fields → rules/software
• routing incomplete requests → workflow automation
• drafting rationale summary → AI
• final submission → human + deterministic validation
Day 2 key lesson
The question is not:
“Can AI solve this?”
The better question is:
“Which part of this problem, if any, should be solved with AI, and why?”
3. Healthcare Example
Example: Prior Authorization Automation
Weak framing
“Build AI for prior authorization.”
This is weak because prior authorization contains many subproblems:
• reading records
• extracting facts
• understanding payer requirements
• completing forms
• drafting narratives
• checking eligibility
• routing exceptions
• submission workflow
• audit trail
Not all of these should use AI.
Strong framing
“Prior auth coordinators spend 15–25 minutes per request manually reviewing
clinical notes, extracting relevant diagnosis/treatment history, and drafting
payer-specific medical necessity narratives. This causes delays, inconsistent
quality, and lower staff productivity. We want to reduce prep time per request
by 40% while maintaining submission quality and reviewability.”
Why this framing is strong
It identifies:
• user: prior auth coordinator
• task: review and prepare requests
• current pain: time-heavy manual prep
• business pain: delays, low productivity, inconsistency
• target outcome: 40% time reduction with quality retained
AI fit analysis
Good AI candidates:
• summarize notes
• extract diagnoses, treatments, history
• draft medical necessity narrative
• identify missing supporting documentation
Better solved by rules/software:
• payer field validation
• format checks
• workflow status updates
• routing and escalation
• deadline reminders
PM lesson
In Healthcare, problem framing must separate language-heavy assistance
from deterministic policy execution.
4. BFSI Example
Example: Fraud Investigation Copilot
Weak framing
“Use AI to detect fraud better.”
This is too broad. Fraud is a huge domain:
• real-time prevention
• post-event investigation
• anomaly scoring
• case review
• SAR documentation
• customer outreach
• chargeback disputes
Strong framing
“Fraud analysts spend too much time manually reviewing alert context across
transaction history, device signals, prior case notes, and customer activity
before deciding whether to escalate or close a case. We want to reduce
average investigation time per alert while improving summary consistency and
preserving human-controlled final decision-making.”
Why this framing is strong
It defines:
• user: fraud analyst
• workflow: alert review
• pain: fragmented information and review burden
• business outcome: lower investigation time
• control constraint: human remains decision-maker
AI fit analysis
Good AI candidates:
• summarize case evidence
• cluster related signals
• generate analyst-ready narratives
• suggest next-best actions
Better solved by ML/rules:
• anomaly detection
• alert scoring
• threshold-based triggers
• block/hold criteria
PM lesson
In BFSI, framing often improves when you choose a specific persona +
workflow moment, not the entire domain.
5. AI Product Strategy Lens
A. Problem selection
A strong AI PM asks:
• Is this pain frequent?
• Is this pain meaningful enough to solve?
• Is it expensive in time, money, or risk?
• Is the pain caused by information overload, ambiguity, or judgment
burden?
• Would solving this create strategic advantage?
B. User pain point definition
Great problem framing is very operational.
Use this pattern:
User + workflow + pain + consequence + target improvement
Example:
“Claims adjusters reviewing multi-document claims packages spend too much
time reading and summarizing evidence manually, causing slower resolution
and inconsistent case handling. We want to reduce summary preparation time
by 50% without increasing error risk.”
C. Business case
A problem is stronger when it maps to one or more business outcomes:
• lower operating cost
• faster turnaround time
• increased case throughput
• lower denial rates
• improved first-contact resolution
• better quality consistency
• higher user retention or lower burnout
• better customer experience
D. Success metrics
A strong framed problem usually leads naturally to metrics.
Examples:
• time saved per workflow
• acceptance rate of AI draft
• edit rate
• case throughput
• accuracy or quality score
• denial reduction
• review burden
• analyst productivity
• user satisfaction
E. Adoption and ROI thinking
Even if AI works technically, the use case may still be weak if:
• users do not trust it
• it changes workflow too much
• review overhead cancels the value
• risk controls make it too slow
• cost of inference exceeds savings
Day 2 strategy principle
A well-framed AI problem must be:
• important
• specific
• measurable
• feasible
• governable
• adoptable
6. System / Execution Lens
Problem framing must shape system design
Framing affects:
• what data is needed
• whether AI is needed at all
• where in the workflow AI is invoked
• what model type fits
• whether retrieval is required
• what guardrails are necessary
• whether human review is mandatory
Example 1: Patient support assistant
If you frame the problem as:
“Patients ask repetitive post-visit questions and support teams are overloaded,”
then likely needs include:
• approved knowledge base
• safe response policies
• RAG
• escalation to human support
• intent-level restrictions
Example 2: Underwriting assistant
If you frame the problem as:
“Underwriters spend too much time reviewing long applicant documents and
preparing case summaries,”
then likely needs include:
• document ingestion
• extraction pipeline
• domain-grounded summarization
• evidence linking
• underwriter review
• audit logs
Why this matters
Poor framing leads to poor execution decisions like:
• using chat UX when a structured inline assistant is better
• using GenAI where rules are enough
• collecting the wrong data
• not planning for review or fallback
• measuring the wrong outcomes
Day 2 execution principle
Problem framing is not a discovery exercise only.
It is the foundation for:
• solution architecture
• rollout strategy
• risk management
• metrics design
7. Risk / Trust / Safety Lens
How framing affects risk
The way you frame the problem determines the risk category of the product.
Safer framing
“Draft a summary for human review.”
Riskier framing
“Automatically decide and submit.”
Safer framing
“Suggest likely next-best actions.”
Riskier framing
“Take final action autonomously.”
Healthcare risk thinking
When framing a healthcare AI problem, ask:
• Could this create unsafe clinical misunderstanding?
• Will PHI be exposed?
• Is there a chance the user overtrusts the AI?
• Can the AI fabricate facts?
• Is human sign-off needed?
BFSI risk thinking
When framing a BFSI AI problem, ask:
• Could this influence financial decisions unfairly?
• Is there compliance exposure?
• Is explainability required?
• Is customer data protected?
• Is there a clear audit trail?
Bias and governance angle
If the problem involves prioritization, recommendation, or decision support,
framing must include:
• what decisions are influenced
• how bias could show up
• how outcomes are reviewed
• how exceptions are handled
Day 2 trust principle
A strong AI PM frames the problem in a way that limits uncontrolled risk from
the start.
8. Case Study / Scenario
Scenario: Building an AI-native Underwriting Assistant
Let’s walk through a realistic BFSI case.
Initial bad framing
“We want an AI underwriting product.”
Problems:
• too broad
• unclear user
• unclear workflow step
• no defined business metric
• unclear whether AI is actually needed
Improved framing
“Commercial underwriting analysts spend excessive time reviewing application
documents, financial statements, broker submissions, and prior notes to
prepare an initial underwriting case summary. This increases turnaround time
and creates inconsistency in early-stage review. We want to reduce initial
review preparation time by 30–40% while preserving underwriter control,
evidence visibility, and auditability.”
Why this is strong
• clear user: underwriting analysts
• clear task: initial review preparation
• clear pain: document-heavy prep
• clear value: faster turnaround and consistency
• clear guardrail: preserve human control
AI decomposition
Good AI tasks:
• summarize submissions
• extract financial indicators
• identify missing documents
• produce a case brief
• flag conflicting information
Non-AI / more controlled tasks:
• policy rule checks
• pricing calculations
• mandatory disclosures
• final underwriting decision
Stakeholder conflict
Business may say:
“Can we automate approvals?”
Compliance may say:
“Not without transparency, controls, and governance.”
A strong PM response:
“We should first target analyst productivity and consistency, prove quality, and
keep decisions human-controlled. Then we can evaluate where safe automation
is appropriate.”
Post-launch learning
Possible findings:
• summaries are useful but too long
• analysts want evidence links
• missing-document detection creates more value than full narrative
generation
• certain lines of business need custom templates
This is why strong framing matters.
It guides the initial scope and keeps iteration grounded.
⸻
9. Artifacts / Deliverables
For Day 2, create these practical PM artifacts.
Artifact 1: AI Problem Framing Template
Use this format:
• Problem title:
• User persona:
• Workflow step:
• Current behavior:
• Pain point:
• Why it matters:
• Frequency:
• Current workaround:
• Cost of current state:
• Candidate AI role:
• Candidate non-AI role:
• Risks:
• Human review needed:
• Success metrics:
• Recommendation:
Artifact 2: AI Suitability Checklist
For each problem, answer:
• Is the pain point real and frequent?
• Is the work unstructured or cognitively heavy?
• Is AI materially better than software/rules?
• Can the output be reviewed or constrained?
• Is there data/context available?
• Can success be measured?
• Is the risk manageable?
• Will users adopt it?
Artifact 3: Problem Decomposition Table
Workflow step Pain today AI fit Better alternative Risk level
Recommended approach
Use this for one Healthcare and one BFSI scenario.
10. Interview Preparation
Interview Question 1
How do you frame a problem for an AI product?
Strong sample answer
I frame AI problems by starting with the workflow, not the model. I identify the
user, the exact job they are trying to complete, where friction happens, and
what operational or business cost that friction creates. Then I assess whether
the pain is actually suitable for AI or better solved through rules, software
automation, or process redesign. Finally, I define measurable success, likely
risks, and what level of human oversight is needed. In regulated domains like
Healthcare and BFSI, that last part is critical because not every high-value
problem should be directly automated.
Interview Question 2
What makes a weak AI problem statement?
Strong sample answer
A weak AI problem statement is solution-first, too broad, and not tied to a
specific workflow or measurable outcome. Statements like “build an AI claims
bot” or “use GenAI for underwriting” are weak because they do not clarify who
the user is, what exact pain exists, where it happens in the workflow, why AI is
the right mechanism, or how success will be measured. Strong framing is user-
centered, specific, and operational.
Interview Question 3
How do you know when not to use AI?
Strong sample answer
I avoid AI as the primary solution when the workflow is highly deterministic,
when the logic is stable and explicit, when exactness is required every time, or
when the error cost is too high and review is not possible. I also challenge AI
usage when the real issue is poor process design rather than lack of
intelligence. A strong AI PM is willing to say no to AI when rules or software
automation are more reliable and cost-effective.
Interview Question 4
Can you give an example of reframing a broad AI idea into a strong product
problem?
Strong sample answer
Instead of saying “Let’s build AI for fraud,” I would narrow it to something like:
fraud analysts spend too much time manually reviewing fragmented alert
context before deciding whether to escalate a case. That reframing gives me a
clear user, workflow moment, pain point, and target value. It also helps define
which parts should use AI, such as summarization and evidence synthesis,
versus which parts should stay rule-based or analyst-controlled.
Interview Question 5
Why is problem framing especially important in AI products?
Strong sample answer
Because AI systems are expensive, probabilistic, and risk-sensitive. Weak
framing leads to the wrong model choice, poor UX, unclear evaluation, and
adoption failure. Good framing helps define whether AI is even needed, what
part of the workflow it should support, what data is required, how trust will be
designed, and what the real success metrics are.
11. Common Failure Patterns
1. Solution-first thinking
“Let’s use GenAI” is not product strategy.
2. Framing the domain instead of the workflow
“AI for Healthcare claims” is too broad.
“Summarize claims packages for adjuster review” is stronger.
3. Ignoring alternatives
Sometimes the right answer is rules, workflow redesign, or better search.
4. Treating one big workflow as one AI problem
Most enterprise workflows must be decomposed.
5. Missing business consequence
If the problem does not connect to time, money, risk, or quality, it may not
justify investment.
6. Not defining reviewability
In regulated environments, outputs often must be reviewable, evidence-
backed, and auditable.
7. Poor measurement planning
If success is vague, teams optimize for demo quality instead of workflow value.
12. Key Takeaways
• Strong AI PMs frame the problem before discussing the model.
• Good framing is specific to a user, workflow step, pain point, and
measurable outcome.
• Not every enterprise pain point should use AI.
• The best AI opportunities often involve unstructured, repetitive,
cognitively heavy work.
• Most enterprise AI products are hybrid systems, not pure GenAI
products.
• Problem framing shapes architecture, risk, trust design, evaluation,
and rollout.
• In Healthcare and BFSI, the framing must include governance, review,
and auditability from the start.
Day 2 Practice Work
Exercise 1
Take these vague ideas and reframe them properly:
• AI for claims
• AI for patient operations
• AI for underwriting
• AI for customer support
Turn each into:
• user
• workflow step
• pain point
• why it matters
• target metric
Exercise 2
Pick one Healthcare and one BFSI use case.
For each, fill out:
• what should use AI
• what should use rules
• what should use software automation
• what should remain human-controlled
Exercise 3
Answer in your own words:
“How do you decide whether a problem is suitable for AI?”
Mini Homework Case
Choose one:
Healthcare option
Care gap detection assistant
BFSI option
Collections intelligence assistant
Write a 1-page framing note:
• user
• workflow
• problem
• why now
• AI fit
• non-AI fit
• key risks
• metrics
• recommendation
Next is Day 3 — When to Use AI vs Rules vs Software Automation, where
we’ll go deeper into mechanism selection and product judgment.