From Pain Point to a Real Use Case: Needs, Wants and Opportunities
PathPatron Use-Case Canvas series — 3 of 7
“We should use AI for supplier onboarding” is not a use case. It is a direction of travel.
A use case becomes worth pursuing only when a team can explain whose problem is recurring, what proof exists, what outcome matters, and what must not be weakened to achieve it. That is the bridge between the first People map and the Stakeholder-Pain Map: first see who carries the work; then turn what you learn into a decision that can be tested.
This is not bureaucracy before innovation. It is how leaders stop a loud complaint, a senior request or a shiny tool from becoming the organisation’s default problem statement.
The first 20–30 minute map is a People practice: start with the people who carry the work, their evidence and their decision rights. This article turns that map into a candidate use case. The next stage is a Process practice: map the work before you automate it and test where an intervention could genuinely help. These are not separate frameworks; they are connected decisions in the People Pillar and Process Pillar.
Continue the supplier-onboarding case
The opening two articles established the same case: a supplier cannot be activated because documents, contract evidence and bank data move unevenly across Procurement, Legal, Finance, the business owner and the supplier. Everyone experiences a genuine problem. They are not all asking for the same thing.
That distinction matters. A team that frames the case only as “Procurement needs AI to speed onboarding” can easily build a faster chase mechanism while leaving the actual controls, gaps and ownership confusion untouched.
Separate pain, need, want, opportunity and outcome
Use these five labels before discussing a solution:
| Label | What it means | Supplier-onboarding example |
|---|---|---|
| Pain | A negative experience happening now. | Procurement chases status in email and a spreadsheet. |
| Need | A condition that must be true for the work to succeed safely. | Legal needs the required clause and Finance needs validated bank data. |
| Want | A preferred improvement; valuable, but not automatically essential. | A business requester wants a live progress view; a supplier wants fewer follow-ups. |
| Opportunity | A credible chance to create value, capacity or better service. | A complete request reaches the correct reviewer once, with a visible next owner. |
| Outcome | The observable change that would tell you the intervention worked. | Fewer incomplete submissions, less manual chasing and a predictable activation route—without bypassing controls. |
The labels stop one familiar failure mode: treating a want (“automate the whole thing”) as if it were the need (“complete, validated evidence reaches the accountable reviewer”).
When interviewing each stakeholder, do not ask only “what do you want?” Ask: What is the most costly frustration today? What is tolerable for the moment but must be fixed in the next 6–12 months? What would a genuinely better day look like? Those questions reveal the difference between a pain, a structural need and a preferred future state.
This is the discovery-side companion to the established 4C conversation structure: establish the context, name the concern, make the consequences concrete, then check what the person needs to move forward. PathPatron does not own this practice; it applies it here to stakeholder discovery. The three questions turn that dialogue into usable evidence for a case—not a promise that every preference becomes a requirement. The 4C guide is still in editorial development; this article will link to its public Technique page when it is live.
The Canvas continues: the evidence and stakeholder tensions from Articles 1–2 are not repeated; they are sorted into what hurts now, what must be true and what a better future could look like before the team writes one bounded candidate use case.
Turn five perspectives into testable problem statements
Do not write one generic statement for a cross-functional case. Write a short testable statement for every material participant. The same event will reveal different pains, needs and non-negotiables.
Use this structure:
For [person / role], when [specific moment], [current condition] causes [consequence]. We need [observable outcome] without violating [non-negotiable].
Here is the supplier-onboarding case in full.
| Stakeholder | Testable problem statement | What to validate |
|---|---|---|
| Procurement | For the procurement manager, when a supplier is needed for a project, incomplete inputs and unclear hand-offs create repeated status chasing and delayed activation. We need a visible, predictable route to the next owner without asking Procurement to approve controls it does not own. | How many chaser emails occur per case? Where does a case wait? |
| Legal | For Legal, when a contract packet reaches review without the required clause or evidence, the reviewer must stop the case or accept unbounded risk. We need complete evidence before review without turning Legal into the data-collection team. | Which items are most often missing? What is the rework loop? |
| Finance | For Finance, when bank or tax data fails validation after the business expects activation, the team must reopen the case and explain a late control failure. We need valid data before activation without creating a second, hidden intake process. | What fails most often and how late is it discovered? |
| Business owner | For the business requester, when no one can explain the supplier’s status or expected timing, project planning becomes unreliable and work starts late. We need a trustworthy status and escalation route without promising a date the controls cannot support. | How often is delivery delayed? Which status information is actually useful? |
| Supplier | For the supplier, when requests arrive piecemeal with no named owner or next step, documents are resubmitted and activation stalls. We need one clear request and a predictable route to resolution without exposing internal approval details. | Which requests are duplicated? How long do suppliers wait for an answer? |
Only after those statements exist can the team name the shared use-case candidate:
Candidate use case: create a complete, traceable supplier-intake and case-visibility flow that routes validated evidence to the accountable reviewer, makes the next action visible to Procurement and the supplier, and preserves Legal and Finance controls.
That is a far better starting point than “automate supplier onboarding.” It describes a real outcome and leaves the solution genuinely open: clearer standards, shared case management, rules-based routing, document extraction, AI drafting assistance—or a combination.
Keep a running evidence log — yes, boring, but maintainable
You do not need a polished workshop or a new platform to get started. In fact, when information arrives over days or weeks from several people, a simple shared list is often the most honest tool.
An Excel sheet, shared table or maintained intake list works well if it captures one observation at a time:
| Date / source | Role | What happened | Pain, need or want? | Evidence or hypothesis? | Consequence | Non-negotiable / open question | Owner of follow-up |
|---|---|---|---|---|---|---|---|
| 30 Jul / Procurement call | Procurement | Chased Legal twice for a status | Pain | Evidence | Supplier start delayed | Who owns the next update? | Procurement lead |
| 31 Jul / Legal review | Legal | Required clause absent from packet | Need | Evidence | Review cannot start | Must evidence be complete before routing? | Legal owner |
| 1 Aug / supplier email | Supplier | Received three separate document requests | Pain | Evidence | Duplicate submissions | Can one request be sent externally? | Supplier manager |
The point is not the spreadsheet. The point is a shared record that separates what the team knows from what it merely assumes. It makes patterns visible without pretending the first workshop captured the truth.
Choose the work mode that fits the organisation
| Work mode | Best when | What it produces |
|---|---|---|
| Running list / Excel | Evidence arrives over time from different people. | A maintainable evidence log and a shortlist of recurring patterns. |
| Facilitated 45-minute session | The relevant people can look at one recent case together. | Aligned problem statements, missing evidence and one candidate outcome. |
| AI first pass | The team has anonymised notes but needs help structuring questions. | A labelled draft: Evidence / Hypothesis / Information Gap—not a final answer. |
| Reusable AI project or skill | The organisation handles many requests and wants consistency. | A governed intake routine with a maintained template, owner and review cycle. |
Use AI for a first pass—not for the answer
An approved AI tool can help turn a messy collection of notes into a question set, reveal contradictions and maintain the evidence log. It cannot determine what Legal will accept, what Finance can own or what the supplier actually experienced. Those remain human validations.
Use anonymised, non-sensitive information only. Then use a prompt such as:
I am assessing a possible AI-enabled workflow use case. Using only the notes below, create a working table with these columns: stakeholder role; observation; pain, need or want; evidence, hypothesis or information gap; consequence; non-negotiable; follow-up owner.
Do not invent motivations, metrics or controls. Flag contradictory observations. Ask up to five clarifying questions before proposing a candidate problem statement. Then draft one testable statement for each material stakeholder and one shared candidate use case. Do not recommend a technology or tool.
The model’s output belongs in the log as a hypothesis, until the relevant person confirms it.
Make this an organisational practice, not a heroic habit
Leaders should not rely on someone remembering to ask better questions on a good day. Put a lightweight gate before teams pitch an AI solution:
- Require a one-page problem record for every material AI or automation proposal: five stakeholder statements, current evidence, intended outcome, non-negotiables and a named decision owner.
- Provide one maintained template—a shared sheet plus the approved AI prompt/project—not five competing versions in individual chat histories.
- Set data boundaries: what can be copied into the approved AI tool, what must be anonymised, and what must remain in internal systems.
- Name an owner for the template and the portfolio view. They keep the fields useful, not ornamental.
- Review when conditions change: a new system, regulation, stakeholder, decision right or control may invalidate an old problem statement.
That is the PathPatron difference: the method does not just help one team articulate a use case. It gives leaders a repeatable way to improve the quality of requests entering the organisation.
Prioritise without pretending every case has one number
Once a candidate has evidence, compare it to other candidates using a simple qualitative lens:
| Lens | Question it answers |
|---|---|
| Pain and affected volume | Is this recurring and materially felt by more than one person? |
| Cost of not solving | What is lost through delay, rework, risk or missed opportunity? |
| Outcome value | What measurable improvement becomes possible if the case works? |
| Readiness | Is there usable evidence, a bounded first step and a named owner? |
| Control burden | What data, authority, regulation and exception handling would be required? |
This is not a generic ROI calculator. A high-value case with no acceptable control path may need redesign first. A modest case with evidence, ownership and a reversible test may be the better place to learn.
Devil’s advocate: what this step does—and does not—prove
This step is deliberately more rigorous than a complaint list, but it is not yet a business case, process map, data assessment or solution design. It cannot prove feasibility, calculate savings or decide whether AI is appropriate. Those questions follow.
Its job is narrower and more important: make the next decision defensible. If the team cannot state the recurring problem from several perspectives, show the evidence, name the boundary and identify who can decide, it is not ready to automate anything.
The next article follows the same supplier-onboarding case into the current workflow: actual hand-offs, workarounds, waiting time and the place where an intervention might help—or should not be attempted.
PathPatron’s rule: do not prioritise the most exciting technology. Prioritise the most defensible next decision.
Continue the PathPatron Use-Case Canvas
- 1/7: People, Stakeholders and Targets: Whose Problem Are You Solving?
- 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 — you are here.
- 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