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. This needs fixing. Now that's pain, and pain is loud. But here's the thing. Pain isn't the problem, It's the symptom. It's the warning light on the dashboard, not the busted engine
underneath. As business analysts, our job is 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. 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. 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 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. 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 spot the difference, OK? And you'll know what to do about it. So #1 pain hurts, problems cost. So pain point equals emotion, whereas problem equals structure.
And if you're just talking about pain points, people get very emotive about it, but they never really get to the structured problem. And we have talked about problem 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 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 root cause. OK, it's the top. The top of the iceberg is the pain point. Let's take an example here. 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 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 takes time. The problem was a lack of auto generated or integrated field 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. 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?
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 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 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 around the loudest complaint design. Design your solution around the biggest consequence, and there's a lot there. Just replay that message. Don't design the solution around the 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. You might, for example, in a gym situation, 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
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 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 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 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, you'll often find that there are three 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. 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 statement. I've I've I don't make this clear enough with, hence this episode. The trappers for junior BAS is a user 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 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 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. Let's look at a case study here with automation going roll. The pain is that reporting takes hours 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 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 uncovers deeper paint, so if you use 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 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 in their 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 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 a simple table, maybe 3 columns, 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 that manual re entry across three
different systems. And then for too many emails, you might find there's no shared task 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 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 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. 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 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 time to dig deeper. I'll see you next week.