Pain Mapping: the starting point of strategy with AI
Before any AI tool, there's a question almost nobody answers properly: where does it actually hurt, and how much does that cost? This lesson teaches the pain-mapping workshop, in three blocks, with a result metric across four categories, so you open the Strategy track with data, not guesswork.
You sit down to do your pain mapping and the first idea that comes up is "I want a dashboard." Stop. Before any solution, the right question is different: which activity eats too much of your time, how often, and how much would it cost to measure that improvement six months from now? That's where the mapping actually begins.
You quickly list three HR pains in a planning meeting: "slow process," "too much manual work," "people complain." None of them has a number attached, and that's exactly why none of them becomes a priority when budget gets contested. Real mapping asks for something else: which process exactly, how many hours it consumes per hiring cycle, how often it repeats, and what would happen if you cut that time in half. Only once you have that number does the pain become something defensible in a meeting, not just a hallway complaint.
You write "confusing prioritization" as the product pain and already want to jump straight to the solution: "I need an AI that prioritizes for me." Hold that thought a second. First, measure: how many hours the team spends in meetings deciding what goes into the next sprint, and how often that decision changes its mind halfway through, forcing the whole board to be redesigned. Without that number, you're trading a real pain for a shiny tool that might not even fix what's actually stuck.
You point to "I lose too many leads" as a sales pain, with no number behind it. Mapping asks for the data: how many leads go cold per week waiting for a reply in the CRM, and how much that, in lost opportunity, already cost in revenue last quarter. Only with that number in hand does the problem leave hallway conversation and land on the agenda the board actually decides to prioritize.
You write "SLA blows up constantly" on the board and move straight to the next line, no detail. But pain mapping demands the number behind the sentence: how often the SLA blows up per month, how many hours the team spends firefighting after each blowup, and what that actually costs in rework or contractual penalties. Without that data, "blows up constantly" is a complaint, not a priority.
You jot down "audits are painful" and move on without detail. Real mapping asks: how many controls you review manually per cycle, how much time that eats out of your month, and what risk goes uncovered today simply because there's no time left to check everything. It's that risk, discovered, named, and measured, that justifies investing in automating the review.
You write "too much repetitive code" and already jump straight to thinking about a new tool. Before that, mapping asks for the number: how many hours per sprint go into this kind of mechanical task, and what's the rework rate when someone gets that piece of code wrong by hand. Only with that number is it clear whether automating is worth it, or whether the lost time wasn't as big as it felt from your chair.
You jot down "research takes too long to become insight" without detail. Mapping demands: how many hours it takes today from interview to finished report, and how many design decisions sit stalled in the meantime waiting for that report to come out. It's that stalled decision queue that shows the real cost of the delay, not the vague feeling that it takes too long.
Yeah, let me ask you one thing before any conversation about an AI tool: where does it actually hurt, and how much does that cost? It sounds obvious, but almost nobody answers it properly. The answer most people give is vague: "we lose time," "it's kind of manual," "it could be faster." That's not a mapped pain, that's venting. And venting doesn't become priority, doesn't become budget, doesn't become a project. This lesson is the first step of the Strategy track: the workshop that turns venting into data.
The core idea of this lesson. Before choosing where AI fits in, you map the pain with precision: in three blocks (yours, your department's, and the most tedious and operational one), each with a result metric in one of four categories, time, cost, quality, or risk avoided. Without a number, the pain isn't mapped, it's an opinion. And that map, with numbers, is what becomes the starting point for everything the Strategy track teaches after this.
01Why map the pain before thinking solution
There's an almost automatic reflex when someone brings up AI: jump straight to the solution. "I want an agent that...," "I need a dashboard that...," "couldn't we have an AI that...." The problem is a solution without a mapped pain is a blind bet. You might end up building something pretty for a problem that isn't, not even close, what actually hurts most in your day-to-day or your department.
Mapping before ideating solves two problems at once. First, it forces you to name the real pain, not the first tool idea that crossed your mind. Second, it gives you a baseline: if you don't know how much time, money, or risk the pain costs today, you'll never be able to prove, later, that the solution worked. No number at the start, no "before and after" to show at the end.
02The three blocks
The mapping is organized into three blocks, each with a different question behind it.
Block A, yours. Three pains from your own activities: what eats too much time, what frustrates you often, what you keep putting off. Start here because it's the ground you know best, and it's where it's easiest to be honest about the number.
Block B, your department's. Three pains from people who work with you or depend on you, without repeating anything that already went into Block A. If the department pain is literally the same as a personal one, look for another one: the goal is to map the problem, not fill in a line.
Block C, the most tedious one. Just one activity, the most mechanical and operational one you do today, repetitive, with no real decision involved. And the question that goes with it: why does it still exist the way it does? Sometimes the answer is "because nobody ever stopped to question it," and that's already a valuable signal.
03The 4 metric categories
Every mapped pain needs a result metric, something you could measure again six months from now to prove it improved. There are only four accepted categories, and that's on purpose: it keeps the metric from turning into hand-waving.
- Time. How many hours per cycle (day, week, month) this pain costs today, and how much that could drop. Format example: "44 hours per month reduced to 12 hours per month."
- Cost. How much money is recovered or stops being lost per month, if the pain gets solved. Format example: "$X recovered per month."
- Quality or error. The rework, error, or complaint rate today, and where it could drop to. Format example: "5% rework dropping to under 1%."
- Risk avoided. For compliance, data-protection, information security, or regulatory pains. Don't force a dollar conversion when the risk is diffuse, measure the risk as risk. Departments like legal and data tend to have more pains of this type than the other three.
Go deeper: the anti-patterns that make the mapping worthless
Four common mistakes invalidate a pain mapping, even when it looks complete on paper.
The first is listing three pains in under two minutes, with no detail at all. That tends to be whatever comes to mind first, not the real pain. If that happened to you, try another question: which day of the week do you open your computer and think "ugh, this again"?
The second is skidding straight into the solution, like "I wish I had a dashboard" or "I needed an AI that...." Write the idea down, but come back: before the solution, what's the pain behind it?
The third is using a vague metric, "faster," "more agile," "better." That's not a metric, it's an adjective. Demand a number, even if it's an honest estimate.
The fourth is listing a pain you'd have no way to measure again six months from now. If you can't prove afterward that it improved, the pain isn't ready to go on the map, it needs one more question first.
04What comes after this map
This map isn't the end, it's the front door. With the pains named and each one carrying its metric, you have the raw material the next lessons in this track will use to decide where AI actually helps, what's just simple automation dressed up as an AI project, and where to start when several pains compete for your attention at once. Without this map, every following decision turns into a guess. With it, it turns into reading data.
Do it now
Grab a sheet of paper, or open a new document, and do your pain mapping right now, your real task or any other real context from your day.
- Block A, 3 personal pains: list the three activities that eat the most of your time, frustrate you, or that you put off the most. For each one, write the result metric (time, cost, quality, or risk) you could measure again in six months.
- Block B, 3 department pains: same structure, without repeating anything from Block A. Think about who depends on your work and where that person's pain shows up.
- Block C, 1 most tedious activity: the most mechanical, repetitive, decision-free thing you do today. Write down why it still exists that way.
- For each of the seven pains, write a first idea for a solution, and be honest about its nature: is it classification, text generation, calculation, or system automation? And, most important, say out loud whether this is really a generative AI problem, or whether it's ETL, a business rule, or simple automation. Both answers are valid, what's not valid is pretending it's AI when it isn't.
When you finish this map with a number on every line, you go from "we lose time on this" to "this costs 20 hours a month, and it can be measured again in six months." That shift is what opens the Strategy track.
Practice
1. Why does pain mapping ask you to name and measure the pain before thinking about a solution?
2. Which of the options below is a valid result metric, from the four accepted categories in the mapping?
3. A compliance pain is hard to convert into dollars, because the risk is diffuse. What does the mapping recommend in that case?
For the board
On ventingwe waste time is not a mapped pain. Venting does not become a priority, a budget, or a project.
On the ordername it and measure it before thinking about a solution. With no baseline there is no before and after.
On what you do not forcediffuse compliance risk does not become currency by guesswork. There is a metric category of its own for that.
Thanks for the feedback. It helps sharpen the next lesson.