May 19, 2025 • 14 mins
Pain Points vs. Problems – Why Getting This Right is Everything
🧠 In this episode of The Better Business Analyst, I’m pulling back the curtain on one of the biggest mistakes I see across projects – confusing pain points with actual problems.
Too often we get caught reacting to symptoms instead of diagnosing the root cause. The result? Misguided priorities, wasted effort, and “solutions” that don’t actually solve anything.
In this practical, no-fluff episode, I walk through:
✅ 10 real-world examples of pain vs. problem
✅ Case studies like FitNation and reporting automation failures
✅ Techniques like the 5 Whys, empathy mapping, and process modelling
✅ A simple framework to trace pain points back to root causes
✅ The difference between being a busy BA… and a better one
If you want to sharpen your analysis, deliver more value, and stop building bandaids—this one’s for you.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Let me tell you something I've learned the hard way.
Just because someone's yelling doesn't mean you're hearing the
real issue. We've all been there.
A stakeholder storms into a room, waves their arms red in
the face, or sends them ministerial.
The system is broken. My team hates using it.
(00:23):
This needs fixing. Now that's pain, and pain is
loud. But here's the thing.
Pain isn't the problem, It's thesymptom.
It's the warning light on the dashboard, not the busted engine
underneath. As business analysts, our job is
(00:48):
not to hand out painkillers. We are not a pharmaceutical
company. It is to diagnose the condition
where doctors and if you don't know the difference between the
pain someone is feeling and the problem that's causing it,
you're going to build the wrong solution.
(01:09):
You'll waste time, you'll waste money, you'll look busy, and
you'll leave the real issue untouched.
In today's episode, I'm giving you 10 practical examples, real
stories from the field. We're getting this distinction
right. Change the outcome.
(01:31):
The Better Business Analysis Institute presence, the Better
Business Analysis podcast with Kenzerman Walsh.
Welcome back to the Better Business Analysis podcast with
your host, Benjamin Walsh. Will we cut through the noise
and talk straight about what actually works in modern Better
(01:52):
Business Analysis? Today we're diving into a
deceptively simple concept that,frankly, can make or break your
project's success. And it's pain points versus
problems. They're not the same, and I use
the term liberally, and I shouldn't.
(02:14):
If you're treating them the same, which I don't, you might
be solving the wrong thing. So today I'm going to walk you
through 10 examples about pain points and problems and the
differences here so you can spotthe difference, OK?
And you'll know what to do aboutit.
(02:35):
So #1 pain hurts, problems cost.So pain point equals emotion,
whereas problem equals structure.
And if you're just talking aboutpain points, people get very
emotive about it, but they neverreally get to the structured
problem. And we have talked about problem
(02:55):
statements. We'll get there again today.
They're so important. The sparks from this episode was
sparked from a conversation I had this week with a colleague.
Imagine a customer saying, I hate this app.
It's clunky and confusing. That's a pain point.
It's not a problem. But the problem might be that
(03:16):
the navigation structure was never really usability tested or
isn't very good. the BA lesson here is always to separate the
emotional response from the rootcause.
OK, it's the top. The top of the iceberg is the
pain point. Let's take an example here.
(03:40):
Broken form. It takes too long to fill out
the form, so the business analyst removes a bunch of
fields, making it shorter. I had something similar about a
dashboard. It's it's there's too many
options so we'll just remove fields.
Users are briefly happy but a month later customer onboarding
(04:01):
drops because compliance checks now fail.
And in my example more options were asked for ones who went to
the public. The pain point was time.
Too many fields to fill in takestime.
The problem was a lack of auto generated or integrated field
(04:22):
options with the existing systems which already had some
of that information. So don't amputate when a splint
would do. OK, so that example being don't
start chopping things off where you might just need to put some
reinforcements behind what you're doing.
(04:43):
The five whys will save you. I talk about this often.
Pain is what you're told. Problem is what you find after
elicitation, after 5 layers of why I'm sick of all these
emails, why they're asking for updates.
Why? Because no one knows the
project's status. Why?
(05:05):
Because we're not updating the dashboard.
Why? Because no one owns it.
The problem is there's no clear rescue for project reporting.
Not that they're getting all these emails asking for project
updates. Keep asking.
You're not annoying. You're being effective.
OK? And you need to probably let
(05:26):
people know you are using the five wives so they don't think
you're a small child who do the five wives very well.
Paine prioritizes emotion, and problems prioritize impact.
A sales manager might say Asserium sucks, Salesforce
(05:47):
sucks. But if you dig deeper you find
out that the actual issue is data entry takes too long.
Reps don't log calls, leads are followed up, revenue suffers.
Don't design the solution aroundthe loudest complaint design.
Design your solution around the biggest consequence, and there's
(06:09):
a lot there. Just replay that message.
Don't design the solution aroundthe loudest complaint.
Design it around the biggest consequence where you're going
to have the biggest impact. I see people getting down and
just collecting pain points as requirements.
They're not requirements. We take another example here.
(06:33):
You might, for example, in a gymsituation, I use Fitnation as my
example gym, There might be a bit of a situation where maybe
the manager or the owner walks through and they go, the too
many staff are just standing around, like the gym trainers
are just standing around and they might react by slashing
(06:55):
rosters. But what's the real problem?
There's no alignment between customer booking and staff
schedulings. So in personal trainers are in
when you don't have staff who want them or it's part of their
account management. They're wanting to see stuff,
they're wanting to see their clients who are in the gym and
it's part of retention. So the fix might be a scheduling
(07:17):
system, not cutting headcount. Listen to the complaint, but
diagnose the cause. The real solution is really the
knee jerk one. Really.
Now what can we do? We can use process models to
isolate the problem. One of the most underrated or
(07:38):
unused BA skills is a simple process map.
And I saw something posted on LinkedIn today, it got me a
little bit heated. I was going to reply around
that. You know, process models are
going to die. It is an analysis technique.
Yes, process models in the business to capture a a process
or a procedure that it might be out of date after 5 minutes is
true. But that doesn't mean that
(07:58):
process models and business analysis are something we're
going to throw away. And they're really, really
important even with AI, because it helps visualize where some
holes are. Let's say the scenario here is
that the OPS team says everything grinds to a halt when
the customer wants to change in order throughout the process,
(08:18):
you'll often find that there arethree manual approvals.
There's a lack of system visibility and that there's a
inconsistent definition of change order versus you know,
they want new stuff as opposed to they got the wrong stuff.
Pane tells us where to look. Mapping tells you what to fix.
(08:41):
Remember that pane tells you where to look in your domain,
Mapping tells you what to fix and might identify help you
identify through the five ways and cross mapping with process
mapping exactly what your problem is now.
Just be aware that a pain point does not equal a problem
(09:02):
statement. I've I've I don't make this
clear enough with, hence this episode.
The trappers for junior BAS is auser might say I need a new
screen BA got it. Let's spec the new screen.
No BA Lesson here is to translate the pain into the
problem statement. Customer service reps struggle
(09:23):
to find customer records during calls impacting resolution times
and satisfaction. They've they're struggling to
find the information, not they need a new screen.
Now you're solving something measurable, not just building
what they want. And one of the solutions might
be get them a new string screen,but it also might be the focus
(09:45):
of the windows. They're playing in all sorts of
bits and pieces, but they will jump.
Humans jump to solutions. We get it all the time.
The more they move into management, the more they move
into politics, the more that they talk to solutions because
that's what people want to ultimately hear.
But ultimately, those solutions never get delivered because
people are not focusing on the problem.
(10:09):
Let's look at a case study here with automation going roll.
The pain is that reporting takeshours every Friday.
So the team automates the Excel report.
No, Why? The problem was inconsistent
data definitions from different business units.
If you automate a broken process, it only creates garbage
(10:32):
faster. And this is the same lesson with
AI. If you have garbage data, you're
only going to create garbage AI output faster.
So just be aware of that. It's really important that we
need to make sure we just don't just automate it.
That's not our job. It's just to automate something
that's wrong. Empathy mapping actually
(10:54):
uncovers deeper paint, so if youuse empathy maps to surface
hidden human factors, it's a good thing.
So you're not avoiding the painful conversation or the
emotion. But you might get an example
where users are consistently complaining about password
resets. It happens often, probably.
And your organization. And the real issue is that
(11:16):
they're logging in from kiosis and they can't remember long
passwords under pressure. So sometimes the problem is
environmental or cultural, not technical.
It's about what they're doing intheir environment.
So if you use empathy mapping, you might be able to meet them
halfway and figure out why they're feeling that way and
(11:36):
what needs to change in the environment, not jump to
solutions. Again, it's another way of
tackling it. It's a really good idea, and
empathy mapping should become part of your toolkit, if it
isn't already. And #10 you can actually do
this. The practical step is before
jumping to requirements, build asimple table, maybe 3 columns,
(11:57):
lists the pain point you're hearing.
Form is too long, too many emails, hard to use the app in
the middle after the five wires.Put in your root cause and your
problem and you might you might find this by doing a process
map. So in the middle column for form
is too long, you might find thatmanual re entry across three
(12:17):
different systems. And then for too many emails,
you might find there's no sharedtask view or unclear ownership.
And for hard to use app, it could be that there's poor UX
design or inconsistent labels. So they're your first two
columns and then list potential solutions.
So after you've done those two steps, which is why I haven't
(12:40):
given you that just yet. So for our pain point form is
too long and we've heard about the root cause manual entry.
The potential solution could be pre filled from the CRM and
integration. For too many emails where there
are no shared view and unclear ownership.
It could be a racy model and a shared board.
And for when we had the pain point of hard to use app which
(13:03):
was really because of poor UI design and UX design and
inconsistent labels, we could potentially solve that by doing
usability testing and making sure it has a design pass or
redesign. This keeps stakeholders focused
and avoids silver bullet thinking.
So you can show them this table and say this is your pain point.
(13:26):
Here's the solution you came up with, but what we need is a root
cause or a problem in the middle, because that's what BAS
deal with. Pain points are your early
warning system. They're important.
They're how the business cries out.
But problems are your mission. That's what you're here to
solve. If you want to be a Better
(13:46):
Business analyst and not a glorified note taker.
Learn to love the gap between what people say it and what's
really broken. Go back to your current project.
Ask yourself, am I solving the pain or the problem?
And if you don't know, it's timeto dig deeper.
I'll see you next week.
Let me tell you something I've learned the hard way.
Just because someone's yelling doesn't mean you're hearing the
real issue. We've all been there.
A stakeholder storms into a room, waves their arms red in
the face, or sends them ministerial.
The system is broken. My team hates using it.
(00:23):
This needs fixing. Now that's pain, and pain is
loud. But here's the thing.
Pain isn't the problem, It's thesymptom.
It's the warning light on the dashboard, not the busted engine
underneath. As business analysts, our job is
(00:48):
not to hand out painkillers. We are not a pharmaceutical
company. It is to diagnose the condition
where doctors and if you don't know the difference between the
pain someone is feeling and the problem that's causing it,
you're going to build the wrong solution.
(01:09):
You'll waste time, you'll waste money, you'll look busy, and
you'll leave the real issue untouched.
In today's episode, I'm giving you 10 practical examples, real
stories from the field. We're getting this distinction
right. Change the outcome.
(01:31):
The Better Business Analysis Institute presence, the Better
Business Analysis podcast with Kenzerman Walsh.
Welcome back to the Better Business Analysis podcast with
your host, Benjamin Walsh. Will we cut through the noise
and talk straight about what actually works in modern Better
(01:52):
Business Analysis? Today we're diving into a
deceptively simple concept that,frankly, can make or break your
project's success. And it's pain points versus
problems. They're not the same, and I use
the term liberally, and I shouldn't.
(02:14):
If you're treating them the same, which I don't, you might
be solving the wrong thing. So today I'm going to walk you
through 10 examples about pain points and problems and the
differences here so you can spotthe difference, OK?
And you'll know what to do aboutit.
(02:35):
So #1 pain hurts, problems cost.So pain point equals emotion,
whereas problem equals structure.
And if you're just talking aboutpain points, people get very
emotive about it, but they neverreally get to the structured
problem. And we have talked about problem
(02:55):
statements. We'll get there again today.
They're so important. The sparks from this episode was
sparked from a conversation I had this week with a colleague.
Imagine a customer saying, I hate this app.
It's clunky and confusing. That's a pain point.
It's not a problem. But the problem might be that
(03:16):
the navigation structure was never really usability tested or
isn't very good. the BA lesson here is always to separate the
emotional response from the rootcause.
OK, it's the top. The top of the iceberg is the
pain point. Let's take an example here.
(03:40):
Broken form. It takes too long to fill out
the form, so the business analyst removes a bunch of
fields, making it shorter. I had something similar about a
dashboard. It's it's there's too many
options so we'll just remove fields.
Users are briefly happy but a month later customer onboarding
(04:01):
drops because compliance checks now fail.
And in my example more options were asked for ones who went to
the public. The pain point was time.
Too many fields to fill in takestime.
The problem was a lack of auto generated or integrated field
(04:22):
options with the existing systems which already had some
of that information. So don't amputate when a splint
would do. OK, so that example being don't
start chopping things off where you might just need to put some
reinforcements behind what you're doing.
(04:43):
The five whys will save you. I talk about this often.
Pain is what you're told. Problem is what you find after
elicitation, after 5 layers of why I'm sick of all these
emails, why they're asking for updates.
Why? Because no one knows the
project's status. Why?
(05:05):
Because we're not updating the dashboard.
Why? Because no one owns it.
The problem is there's no clear rescue for project reporting.
Not that they're getting all these emails asking for project
updates. Keep asking.
You're not annoying. You're being effective.
OK? And you need to probably let
(05:26):
people know you are using the five wives so they don't think
you're a small child who do the five wives very well.
Paine prioritizes emotion, and problems prioritize impact.
A sales manager might say Asserium sucks, Salesforce
(05:47):
sucks. But if you dig deeper you find
out that the actual issue is data entry takes too long.
Reps don't log calls, leads are followed up, revenue suffers.
Don't design the solution aroundthe loudest complaint design.
Design your solution around the biggest consequence, and there's
(06:09):
a lot there. Just replay that message.
Don't design the solution aroundthe loudest complaint.
Design it around the biggest consequence where you're going
to have the biggest impact. I see people getting down and
just collecting pain points as requirements.
They're not requirements. We take another example here.
(06:33):
You might, for example, in a gymsituation, I use Fitnation as my
example gym, There might be a bit of a situation where maybe
the manager or the owner walks through and they go, the too
many staff are just standing around, like the gym trainers
are just standing around and they might react by slashing
(06:55):
rosters. But what's the real problem?
There's no alignment between customer booking and staff
schedulings. So in personal trainers are in
when you don't have staff who want them or it's part of their
account management. They're wanting to see stuff,
they're wanting to see their clients who are in the gym and
it's part of retention. So the fix might be a scheduling
(07:17):
system, not cutting headcount. Listen to the complaint, but
diagnose the cause. The real solution is really the
knee jerk one. Really.
Now what can we do? We can use process models to
isolate the problem. One of the most underrated or
(07:38):
unused BA skills is a simple process map.
And I saw something posted on LinkedIn today, it got me a
little bit heated. I was going to reply around
that. You know, process models are
going to die. It is an analysis technique.
Yes, process models in the business to capture a a process
or a procedure that it might be out of date after 5 minutes is
true. But that doesn't mean that
(07:58):
process models and business analysis are something we're
going to throw away. And they're really, really
important even with AI, because it helps visualize where some
holes are. Let's say the scenario here is
that the OPS team says everything grinds to a halt when
the customer wants to change in order throughout the process,
(08:18):
you'll often find that there arethree manual approvals.
There's a lack of system visibility and that there's a
inconsistent definition of change order versus you know,
they want new stuff as opposed to they got the wrong stuff.
Pane tells us where to look. Mapping tells you what to fix.
(08:41):
Remember that pane tells you where to look in your domain,
Mapping tells you what to fix and might identify help you
identify through the five ways and cross mapping with process
mapping exactly what your problem is now.
Just be aware that a pain point does not equal a problem
(09:02):
statement. I've I've I don't make this
clear enough with, hence this episode.
The trappers for junior BAS is auser might say I need a new
screen BA got it. Let's spec the new screen.
No BA Lesson here is to translate the pain into the
problem statement. Customer service reps struggle
(09:23):
to find customer records during calls impacting resolution times
and satisfaction. They've they're struggling to
find the information, not they need a new screen.
Now you're solving something measurable, not just building
what they want. And one of the solutions might
be get them a new string screen,but it also might be the focus
(09:45):
of the windows. They're playing in all sorts of
bits and pieces, but they will jump.
Humans jump to solutions. We get it all the time.
The more they move into management, the more they move
into politics, the more that they talk to solutions because
that's what people want to ultimately hear.
But ultimately, those solutions never get delivered because
people are not focusing on the problem.
(10:09):
Let's look at a case study here with automation going roll.
The pain is that reporting takeshours every Friday.
So the team automates the Excel report.
No, Why? The problem was inconsistent
data definitions from different business units.
If you automate a broken process, it only creates garbage
(10:32):
faster. And this is the same lesson with
AI. If you have garbage data, you're
only going to create garbage AI output faster.
So just be aware of that. It's really important that we
need to make sure we just don't just automate it.
That's not our job. It's just to automate something
that's wrong. Empathy mapping actually
(10:54):
uncovers deeper paint, so if youuse empathy maps to surface
hidden human factors, it's a good thing.
So you're not avoiding the painful conversation or the
emotion. But you might get an example
where users are consistently complaining about password
resets. It happens often, probably.
And your organization. And the real issue is that
(11:16):
they're logging in from kiosis and they can't remember long
passwords under pressure. So sometimes the problem is
environmental or cultural, not technical.
It's about what they're doing intheir environment.
So if you use empathy mapping, you might be able to meet them
halfway and figure out why they're feeling that way and
(11:36):
what needs to change in the environment, not jump to
solutions. Again, it's another way of
tackling it. It's a really good idea, and
empathy mapping should become part of your toolkit, if it
isn't already. And #10 you can actually do
this. The practical step is before
jumping to requirements, build asimple table, maybe 3 columns,
(11:57):
lists the pain point you're hearing.
Form is too long, too many emails, hard to use the app in
the middle after the five wires.Put in your root cause and your
problem and you might you might find this by doing a process
map. So in the middle column for form
is too long, you might find thatmanual re entry across three
(12:17):
different systems. And then for too many emails,
you might find there's no sharedtask view or unclear ownership.
And for hard to use app, it could be that there's poor UX
design or inconsistent labels. So they're your first two
columns and then list potential solutions.
So after you've done those two steps, which is why I haven't
(12:40):
given you that just yet. So for our pain point form is
too long and we've heard about the root cause manual entry.
The potential solution could be pre filled from the CRM and
integration. For too many emails where there
are no shared view and unclear ownership.
It could be a racy model and a shared board.
And for when we had the pain point of hard to use app which
(13:03):
was really because of poor UI design and UX design and
inconsistent labels, we could potentially solve that by doing
usability testing and making sure it has a design pass or
redesign. This keeps stakeholders focused
and avoids silver bullet thinking.
So you can show them this table and say this is your pain point.
(13:26):
Here's the solution you came up with, but what we need is a root
cause or a problem in the middle, because that's what BAS
deal with. Pain points are your early
warning system. They're important.
They're how the business cries out.
But problems are your mission. That's what you're here to
solve. If you want to be a Better
(13:46):
Business analyst and not a glorified note taker.
Learn to love the gap between what people say it and what's
really broken. Go back to your current project.
Ask yourself, am I solving the pain or the problem?
And if you don't know, it's timeto dig deeper.
I'll see you next week.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.