People, Stakeholders and Targets: Whose Problem Are You Solving?
PathPatron Use-Case Canvas series — 1 of 7
Procurement wants the supplier activated this week. Legal will not accept an incomplete contract. Finance cannot create the vendor record without verified bank data. The business owner assumes somebody else is holding things up.
Nobody in that situation has an “AI problem.” They have different targets, different evidence and different exposure when the decision goes wrong.
AI projects rarely fail because nobody can name a tool. They fail because the team solves the loudest person’s request while overlooking the people who provide information, approve an exception, carry the operational risk, or live with the result.
The first move in a credible AI use case is therefore not selecting technology. It is identifying whose pain matters, whose target must be protected, and whose authority changes if the work changes.
Start with one person and one concrete moment
Take supplier onboarding. A procurement manager says, “We need AI to speed this up.” That is an ambition, not yet a use case. Start with a recent supplier request. The manager is chasing missing documentation, manually updating a spreadsheet and explaining another delay to the business requester. Her immediate pain is not “lack of AI.” It is repeated status chasing, incomplete context and no reliable view of ownership.
Put that person in the Persona field of the PathPatron Use-Case Canvas. Then record the strongest Pain Point / Opportunity in plain language: A supplier cannot be activated until several teams complete checks, but nobody can see what is missing or who owns the next move.
Specificity matters. “Improve onboarding” hides the decision. A person, a moment and a consequence make it discussable.
Add the people the first story leaves out
The stakeholder list is not a list of meeting invitees. It is a map of different stakes.
In the same supplier case:
- Procurement needs speed, a reliable status and fewer chaser emails.
- Legal needs the right contractual evidence before accepting risk.
- Finance needs validated bank and tax data before creating a vendor record.
- The business requester needs a supplier ready in time to deliver work.
- The supplier needs a clear request and a predictable route to resolution.
- IT or data owners may need to approve access to the systems that hold the relevant information.
Each person may describe a different pain. That is useful evidence, not scope creep. The aim is to reveal where targets conflict: a faster route is not automatically a safer one; a clean legal review can still create avoidable waiting time.
Separate user, beneficiary, decider and owner
Four roles are frequently collapsed into one:
| Role | Question to answer |
|---|---|
| User | Who does the work or receives the output? |
| Beneficiary | Who gains time, quality, revenue or reduced risk? |
| Decider | Who can approve the change, budget or exception? |
| Owner | Who remains accountable once it is live? |
In supplier onboarding, Procurement may be the daily user, the business unit the beneficiary, Finance a key control decider and Operations the long-term owner. If those roles remain unnamed, an attractive pilot can later fail on permissions, support or adoption.
Use the stakeholder-pain map
Before mapping a process, make a one-page stakeholder-pain map. For each material participant, capture:
- Their job in the case.
- Their pain, need or target.
- The evidence that the pain is real: an example, wait time, error, rework loop or complaint.
- The authority they hold: input, approval, override or ownership.
- What would make the proposed change unacceptable to them.
This makes a critical distinction visible: a stakeholder can be supportive and still be unable to approve access; a decider can support the outcome and still need evidence before funding it.
Keep this first map deliberately light. Its job is to ensure that the team has not mistaken one person’s request for the whole problem. It is not yet a stakeholder-management plan or a full power analysis.
When the first map needs to go deeper
Some cases need more than a first-pass map: the people affected hold competing goals, informal influence matters, or a decision will cross departmental authority. In those cases, use the PathPatron Stakeholder-Pain Map companion method. It makes six things visible for every material participant:
person → role in the case → pain or target → evidence → authority → non-negotiable.
Its visual is not a generic power–interest quadrant. It places the people around one concrete use case, then shows where pain, targets and decision rights meet or conflict. That detail is useful once the team has selected a real case; it would distract from the starting question here: whose problem are we trying to solve?
What a useful map produces
The output is not a stakeholder list. It is three operational choices:
- Named conflict: speed versus control. Procurement needs movement; Legal and Finance need evidence before the organisation accepts risk.
- Clear boundary: no vendor activation without verified evidence. This is the rule an assistant, automation or human cannot route around.
- Decision owner: Finance Operations owns the activation decision and its exception route—not simply “the team.”
That is the moment the map becomes useful. A proposed workflow can optimise for speed, but it cannot quietly weaken a non-negotiable. A design choice can be debated, but someone is visibly accountable for the final call.
How to make the first map in 20 minutes
Use one recent, real case. Do not begin with a generic future process.
- Put the person with the clearest pain in the centre: what were they trying to get done, and what happened instead?
- Add every person who supplies critical information, receives the impact, approves an exception or can block the workflow.
- For each, write one pain or target and one piece of evidence—not an assumed motivation.
- Ask the uncomfortable question: If this person could stop, override or quietly work around the new workflow tomorrow, have we included them?
- Name the one conflict the proposed change must resolve, the non-negotiable boundary it must not cross, and the decision owner who can settle an exception.
The result is a shared starting position for the process map. It does not yet decide the tool. It prevents the team from building around an incomplete view of the work.
Use AI for a first pass—not for the answer
An AI assistant can help a team structure the first map and spot questions it has not yet asked. It cannot tell you what a stakeholder actually believes, needs or will accept. Treat its output as a hypothesis to validate with the people involved.
Use anonymised, non-sensitive case details only. Then copy this prompt into an approved AI tool:
I’m mapping a real workflow case. Help me produce a first stakeholder-pain map.
Do not invent motivations or facts. Label each point as Evidence, Hypothesis, or Information Gap.
First, ask me up to five clarifying questions. Then identify: 1. the person with the clearest pain; 2. other people who provide critical information, receive impact, approve exceptions, or could block or work around the workflow; 3. each person’s likely pain or target; 4. the evidence needed to validate it; 5. the central conflict, non-negotiable boundary, and likely decision owner.
Present the result as a table. Do not recommend an AI tool or solution yet.
The useful outcome is not an AI-generated stakeholder list. It is a better set of questions for the people who know the work. Check every hypothesis with them before using the map to design a process, assign authority or choose technology.
Do not mistake a loud request for a shared problem
The most common early error is treating a senior sponsor’s solution request as the problem statement. “Build an agent” may be an invitation to investigate, not the answer. The Canvas asks the team to hold that request lightly until the actual people, work and constraints are visible.
For the supplier case, the right outcome might be a clearer intake standard, a shared status view and a fixed exception owner. That may come before any AI assistance. If an AI tool later helps classify documents or draft a supplier follow-up, it should serve a designed workflow—not substitute for one.
The next decision
Once you can state whose pain matters, move to The Stakeholder-Pain Map. It turns the first story into evidence, targets, authority and a named conflict before the team decides whether the case is worth pursuing. Then continue to From Pain Point to a Real Use Case, where the team separates a symptom from a need, a want and an opportunity.
The PathPatron principle is simple: start with people, but do not stop at opinions. Turn lived experience into evidence, decision rights and a shared target for the work that follows.
An AI use case is never only task design. It redistributes context, authority and consequence. That is why the stakeholder question comes first.
Continue the PathPatron Use-Case Canvas
- 1/7: People, Stakeholders and Targets: Whose Problem Are You Solving? — you are here.
- 2/7: Map Power, Interest and Pain Before You Pitch AI: The Stakeholder-Pain Map
- 3/7: From Pain Point to a Real Use Case
- 4/7: Map the Work Before You Automate It
- 5/7: The Cost of Not Solving: Making Process Pain Visible
- 6/7: From Current State to a Credible Future State: Cost, Control & Change
- 7/7: Requirements Engineering for AI-Enabled Work