Identify the Problem to Be Solved

Task 1 of the Joint-Largest Domain

Domain II, Identify Business Needs and Solutions, carries 26% of the PMI-CPMAI exam — tied with Domain III as the joint-largest domain — and its first task is identify problem to be solved (e.g., needs, persona). This is CPMAI Phase 1, Business Understanding, and the certification treats it, not technology selection, as the genuine starting line of an artificial intelligence (AI) project. Exam items in this area usually open with a sponsor who has already named a technology: "we want a chatbot," "we need a large language model." The credited answer walks the project back to the problem.

Conduct Stakeholder Interviews to Understand Business Pain Points

Interview at three levels, and ask each level for numbers:

• Executive sponsor — why now, what business outcome is being bought, what happens if nothing changes.
• Process owner — how the work flows today, where it breaks, what the exceptions are.
• Frontline operator — what actually happens, including the workarounds nobody documented.

Structure the conversation so you hear the pain rather than a pre-selected solution. Useful moves: ban the word "AI" for the first fifteen minutes; ask for the last three times the process went wrong and what each cost; ask what people do when the system is unavailable; ask for volume, cycle time, and error rate at every step. When a stakeholder opens with a solution, ladder down — "if the chatbot existed, what would stop happening?" — until you reach a measurable business consequence. A pain point you cannot attach a number to is not yet a problem statement; it is an opinion.

Analyze Existing Processes to Identify Automation Opportunities

Walk the current process end to end and record, for every step: monthly volume, average handling time, error and rework rate, unit cost, and who performs it. Then look for the three places AI opportunity concentrates:

1. Where a human judgment is made — a triage, a classification, a prioritization, an approval. Judgments are what models learn; keystrokes are what robotic process automation handles.
2. Where volume concentrates — a two-point accuracy gain on 40,000 claims a month is worth funding; on 40 claims a month it is not.
3. Where errors, rework, and queueing concentrate — cost and delay almost always cluster in one or two steps rather than spreading evenly.

One manager-level insight settles many of these candidates: a judgment is a realistic AI opportunity only if past decisions were recorded. Historical decisions are your labeled training data. If underwriters have decided by phone for ten years and nothing was captured, the opportunity may be real but the project begins with a data-creation effort. Flag that in Phase 1, because otherwise you discover it in Phase 2, Data Understanding, after the budget is committed.

Define Target User Personas and Use Cases for AI Solutions

A persona here is not a demographic sketch. It is who acts on the output. Specify the role, the decision that person makes, the system and workflow where the output appears, the latency they can tolerate, their AI literacy, and — critically — what they do when the model is uncertain or wrong.

The same fraud model serves two entirely different personas. A fraud analyst receiving a ranked review queue tolerates false positives and wants high recall. An automatic decline inside the payment flow has no human in the loop, so precision and customer harm dominate. Identical model, different persona, different success criteria, different risk profile — in practice, different projects. Write the use case as one sentence: when [trigger] occurs, [persona] receives [output] inside [system] within [latency] so they can [action].

Map Business Problems to Appropriate AI Patterns and Approaches

Before any algorithm discussion, map the pain to one of the Seven Patterns of AI: Hyperpersonalization; Autonomous Systems; Predictive Analytics and Decision Support; Conversational and Human Interaction; Pattern and Anomaly Detection; Recognition; Goal-Driven Systems. Pattern mapping is a scoping and communication device — it tells stakeholders what kind of data will be needed and how success will be measured long before anyone picks a model. A problem that maps cleanly to two patterns is usually two projects that should be sequenced, not one project with double the risk.

Validate Problem Statements with Subject Matter Experts

Reduce everything to a one-sentence problem statement with a measurable outcome: [Persona] handles [volume] of [work] and currently [failure], costing [baseline]; we need to move [metric] from [baseline] to [target] by [date]. Then take that sentence back to the subject matter experts (SMEs) — the people who do the work and the people who own the data — before scope, feasibility, or budget work proceeds.

SMEs catch the four things that kill AI projects later: a baseline that was measured the wrong way, exceptions that break the framing, a pain that another program is already fixing, and a prior attempt whose failure nobody mentioned in the executive interview. Capture that validation as a dated artifact with named reviewers; it becomes the reference the scope statement, the success criteria, and the business case are all built on.

The Traps This Task Punishes

The dominant exam trap is the solution in search of a problem — a technology chosen first, with business justification reverse-engineered around it. Its relatives are just as costly: a problem statement with no baseline number, so success can never be demonstrated; a persona nobody named, so the output lands in no one's workflow; and "the model will be accurate" written where a business outcome belongs. Accuracy is a model metric. It is not a business result, and on this exam it is never an acceptable problem statement.