1
Pain Points
What hurts today?
1. Introduction: start with the pain, not the model
If the first question is, “Can we use AI here?”, I slow the room down. I want the friction first, because that is where the useful ideas come from. The better question is, “What is painful, repetitive, slow, risky, or unclear?” That tells us whether we need automation, AI, a dashboard, or a process change.
“A small automation that is used every day is more valuable than a large AI idea that never reaches production.” That is the standard I use when a team wants to improve fast without overengineering.
2. Build a free-flow feedback culture
Most of the useful ideas show up when the room feels safe enough for people to think out loud. If someone has to calculate how a comment will land, the conversation already slowed down. I want people to challenge, question, and improve ideas without worrying about hierarchy. That is how teams move for the right reasons, not out of fear.
What a healthy team does
- Lets people name pain points without being blamed for them.
- Encourages small, practical ideas instead of perfect ones.
- Lets feedback move up, down, and across the team.
- Makes it normal to question ideas without taking it personally.
- Uses review to improve the idea, not to silence the person.
- Treats feedback as a delivery tool, not a threat.
- Keeps brainstorming open so the best idea can come from anywhere.
What fear does to delivery
- People hide issues until they become expensive.
- Teams stop challenging weak assumptions.
- Brainstorming becomes performative instead of useful.
- The project moves slowly because nobody trusts the conversation.
- Good ideas die early because people are more worried about hierarchy than improvement.
- People do the work to avoid blame instead of doing it because they care about the outcome.
A fear-driven culture does not improve delivery. It only makes the pain quieter. Open discussion at every level is what lets teams improve without overengineering.
3. Start with pain point gathering
Before I reach for any tool, I ask the people who live with the pain every day. Developers, testers, support teams, release managers, and stakeholders often describe the same issue in different ways. That is helpful because it shows the real friction instead of the symptom someone sees on the surface.
↓
2
Categorise
Type of problem
↓
3
Data
Do we have enough?
↓
4
Clean
Fix the source first
↓
5
Pilot and Scale
Prove value, then expand safely
What I look for
- Repeated manual steps that burn time every week.
- Questions that keep coming back in support or release calls.
- Work that depends on a person remembering a step instead of a system enforcing it.
- Places where people are guessing because the data is not easy to see.
If the pain point cannot be described clearly, it is usually not ready for a solution yet. The conversation needs to get simpler before the solution gets bigger.
4. Categorise the pain points
The same complaint can belong to different categories. “It takes too long” might be an automation problem, a data quality problem, or a broken process. Categorising the pain point stops us from reaching for the wrong fix.
Pain point map
A quick way to separate the complaint from the kind of fix it needs.
Delivery
Support
Operations
| Category | What it usually sounds like | Likely fix |
|---|---|---|
| Repeated manual work | “We keep doing the same checks, copy-paste, or status updates.” | Automation first |
| Messy input or wording | “The request comes in different forms every time.” | AI or AI + automation |
| Lack of visibility | “Nobody can see the current state quickly enough.” | Dashboard |
| Ownership or discipline issue | “The step exists, but people skip it or do it late.” | Process change |
5. Decide whether the solution is automation, AI, both, dashboard, or process change
This is the point where teams are often tempted to jump straight to AI. I try to slow that down and ask what shape the problem actually has. The wrong tool can make a small pain more complicated than it needs to be.
Open the decision tree
Simple guide: repeated and exact means automation; messy and language-heavy means AI; missing visibility means dashboard; unclear ownership means process change.
Interactive
A
Automation
Use it when the steps are clear and repeatable.
B
AI
Use it when the input is messy and judgement is involved.
C
Dashboard
Use it when visibility is the real problem.
D
Process change
Use it when ownership or discipline is unclear.
Use it when the steps are clear and repeatable
If I can describe the rule in plain if/then language, automation is usually the first choice. It is easier to test, easier to trust, and easier to support.
Use it when the input is messy and judgement is involved
AI helps when people write things differently every time, or when the system has to interpret text, tone, or a rough document.
Use it when visibility is the real problem
Sometimes nobody needs a new decision engine. They just need the current state on one screen so the right question can be answered quickly.
Use it when ownership or discipline is unclear
If the step exists but keeps getting skipped, the fix may be accountability, ownership, or a clearer operating rhythm instead of code.
6. Check whether the right data exists
Good automation and good AI both need reliable input. If the data is missing, inconsistent, or untrusted, the project will spend its first weeks fixing symptoms instead of delivering value. I would rather see that early than find it after the build is already in motion.
Data readiness
The questions I ask before I let a feature move into build mode.
Source
Quality
Trust
| Question | Why it matters | If the answer is no |
|---|---|---|
| What pain point are we solving? | Prevents a vague solution looking busy but doing nothing useful. | Revisit the problem statement. |
| Who feels this pain? | Shows which team owns the benefit and who will judge success. | Talk to the people closest to the work. |
| Do we have the required data? | Without data, the feature becomes guesswork. | Collect, surface, or generate the missing source. |
| Is the data trusted? | A bad source produces bad automation and bad AI output. | Fix the source or expose the missing trust signal. |
7. Clean the data before expecting good results
What cleaning usually means
- Remove duplicates and stale records.
- Normalise names, states, dates, and identifiers.
- Separate raw source data from the cleaned view.
- Track where the data came from and when it changed.
What I do not do
- I do not hide a dirty source under a clever prompt.
- I do not assume the model will fix broken input.
- I do not skip validation just because the output looks neat.
Clean data is not a cosmetic step. It is the point where the idea stops being theory and starts becoming something a team can trust.
8. Build AI and automation awareness inside the team
Adoption breaks down quickly when only one person understands the solution. If the team will use it, test it, support it, or explain it, they need enough context to do that without guessing.
Need to know what is deterministic, what is probabilistic, and what must be validated before release.
Need clear positive and negative cases, especially for fuzzy inputs and model-assisted paths.
Need to know what the solution can answer, what it cannot, and when to step in manually.
9. Start small and prove value
I would rather prove one small improvement than pitch one big promise. A narrow pilot gives the team evidence, feedback, and confidence without forcing a big architecture decision up front.
1
Pick one pain point
Choose a problem that happens often enough to matter and small enough to fix safely.
2
Build the smallest useful version
Start with the minimum flow that makes a visible improvement for the team.
3
Measure before and after
Track time saved, mistakes reduced, or questions answered faster.
4
Expand only after trust
Grow the scope once the team sees the result and the risk stays under control.
10. Keep human review where it matters
Human review is not a sign that the solution failed. It is a control point. I keep humans in the loop wherever a bad answer could affect customers, money, security, or trust.
Review stays in place when
- The output is customer-facing.
- The action changes state or sends something externally.
- The input is ambiguous enough that mistakes are expensive.
Review can be lighter when
- The output is internal and reversible.
- The workflow has a clear fallback path.
- The team already trusts the data and the rule set.
11. Give access carefully and expand gradually
When a team trusts the first version, I still do not open everything at once. I widen access in steps so the change stays controllable.
Open the access ladder
Read only first, then shadow mode, then limited write, then wider rollout.
Progressive
1. Read only
The system shows suggestions or visibility only. Nobody depends on it yet.
2. Shadow mode
The system runs in the background and compares output with the human or current process.
3. Limited write
The feature can act, but only in a narrow case with review or approval.
4. Wider rollout
Expand after the team has seen stable behaviour and the risk is understood.
12. Practical adoption checklist
This is the checklist I wish more teams used before starting a new improvement effort. The point is not to block work. The point is to make sure we understand the problem, the people, the data, and the expected outcome before we spend time building anything. If too many answers are unclear, the work is probably not ready yet.
Adoption checklist
Use this as a quick yes/no filter before committing time or money. Each question is there to expose a gap early, before the team builds around a vague idea.
Yes / No
Practical
| Question | Good sign | Warning sign |
|---|---|---|
| What pain point are we solving? | Everyone can say it in one sentence. | The project sounds exciting but fuzzy. |
| Who feels this pain? | The people closest to the work confirm it. | Only managers can describe the issue. |
| Is the task repeated often? | The step happens every day or every week. | It is a one-off problem disguised as a pattern. |
| Is it rule-based? | The decision can be written as a clear rule. | The team cannot agree on the rule. |
| Does it involve language or judgement? | There is real text, interpretation, or summary work. | It is just structured data and thresholds. |
| Do we have the required data? | The source exists and can be accessed reliably. | We would need to invent the input. |
| Is the data trusted? | People already use it for decisions. | Everyone double-checks it manually. |
| Can a human review the result? | There is a clear reviewer or fallback. | The output would act on its own. |
| Can we start small? | There is one narrow use case to pilot. | The scope is broad and hard to measure. |
| How will we measure success? | Time, accuracy, fewer escalations, or better visibility. | Success is only “it feels smarter”. |
If most answers lean toward warning signs, I would pause and sharpen the problem statement first. A clean problem is much easier to solve than a fuzzy solution that already has momentum.
13. Final thought
The best AI strategy is not to use AI everywhere. It is to understand the work well enough to know where AI should not be used. Before starting the next AI idea, gather the team and ask: What pain are we actually trying to remove?