1
00:00:00,920 --> 00:00:03,200
Let me tell you something I've 
learned the hard way. 

2
00:00:04,200 --> 00:00:09,600
Just because someone's yelling 
doesn't mean you're hearing the 

3
00:00:09,600 --> 00:00:12,720
real issue. 
We've all been there. 

4
00:00:12,720 --> 00:00:16,720
A stakeholder storms into a 
room, waves their arms red in 

5
00:00:16,720 --> 00:00:19,400
the face, or sends them 
ministerial. 

6
00:00:20,520 --> 00:00:23,360
The system is broken. 
My team hates using it. 

7
00:00:23,840 --> 00:00:29,280
This needs fixing. 
Now that's pain, and pain is 

8
00:00:29,280 --> 00:00:31,880
loud. 
But here's the thing. 

9
00:00:32,400 --> 00:00:37,080
Pain isn't the problem, It's the
symptom. 

10
00:00:38,160 --> 00:00:43,120
It's the warning light on the 
dashboard, not the busted engine

11
00:00:43,120 --> 00:00:48,120
underneath. 
As business analysts, our job is

12
00:00:48,120 --> 00:00:53,080
not to hand out painkillers. 
We are not a pharmaceutical 

13
00:00:53,080 --> 00:00:56,800
company. 
It is to diagnose the condition 

14
00:00:56,800 --> 00:01:01,280
where doctors and if you don't 
know the difference between the 

15
00:01:01,280 --> 00:01:05,480
pain someone is feeling and the 
problem that's causing it, 

16
00:01:06,360 --> 00:01:08,560
you're going to build the wrong 
solution. 

17
00:01:09,240 --> 00:01:14,360
You'll waste time, you'll waste 
money, you'll look busy, and 

18
00:01:14,360 --> 00:01:16,600
you'll leave the real issue 
untouched. 

19
00:01:18,080 --> 00:01:22,800
In today's episode, I'm giving 
you 10 practical examples, real 

20
00:01:23,440 --> 00:01:27,360
stories from the field. 
We're getting this distinction 

21
00:01:27,360 --> 00:01:29,240
right. 
Change the outcome. 

22
00:01:31,040 --> 00:01:35,080
The Better Business Analysis 
Institute presence, the Better 

23
00:01:35,080 --> 00:01:38,400
Business Analysis podcast with 
Kenzerman Walsh. 

24
00:01:42,880 --> 00:01:45,760
Welcome back to the Better 
Business Analysis podcast with 

25
00:01:45,760 --> 00:01:48,760
your host, Benjamin Walsh. 
Will we cut through the noise 

26
00:01:49,240 --> 00:01:52,960
and talk straight about what 
actually works in modern Better 

27
00:01:52,960 --> 00:01:57,760
Business Analysis? 
Today we're diving into a 

28
00:01:57,760 --> 00:02:03,640
deceptively simple concept that,
frankly, can make or break your 

29
00:02:03,640 --> 00:02:06,640
project's success. 
And it's pain points versus 

30
00:02:06,640 --> 00:02:09,400
problems. 
They're not the same, and I use 

31
00:02:09,400 --> 00:02:12,760
the term liberally, and I 
shouldn't. 

32
00:02:14,040 --> 00:02:17,960
If you're treating them the 
same, which I don't, you might 

33
00:02:17,960 --> 00:02:21,360
be solving the wrong thing. 
So today I'm going to walk you 

34
00:02:21,360 --> 00:02:28,000
through 10 examples about pain 
points and problems and the 

35
00:02:28,000 --> 00:02:32,040
differences here so you can spot
the difference, OK? 

36
00:02:32,040 --> 00:02:34,040
And you'll know what to do about
it. 

37
00:02:35,080 --> 00:02:42,640
So #1 pain hurts, problems cost.
So pain point equals emotion, 

38
00:02:43,040 --> 00:02:45,520
whereas problem equals 
structure. 

39
00:02:46,080 --> 00:02:48,480
And if you're just talking about
pain points, people get very 

40
00:02:48,480 --> 00:02:52,320
emotive about it, but they never
really get to the structured 

41
00:02:52,920 --> 00:02:55,120
problem. 
And we have talked about problem

42
00:02:55,120 --> 00:02:57,160
statements. 
We'll get there again today. 

43
00:02:57,160 --> 00:03:02,120
They're so important. 
The sparks from this episode was

44
00:03:02,120 --> 00:03:05,440
sparked from a conversation I 
had this week with a colleague. 

45
00:03:06,360 --> 00:03:08,880
Imagine a customer saying, I 
hate this app. 

46
00:03:08,880 --> 00:03:12,360
It's clunky and confusing. 
That's a pain point. 

47
00:03:12,360 --> 00:03:16,040
It's not a problem. 
But the problem might be that 

48
00:03:16,040 --> 00:03:21,240
the navigation structure was 
never really usability tested or

49
00:03:21,560 --> 00:03:26,840
isn't very good. the BA lesson 
here is always to separate the 

50
00:03:26,840 --> 00:03:29,960
emotional response from the root
cause. 

51
00:03:29,960 --> 00:03:33,760
OK, it's the top. 
The top of the iceberg is the 

52
00:03:33,760 --> 00:03:40,400
pain point. 
Let's take an example here. 

53
00:03:40,400 --> 00:03:44,520
Broken form. 
It takes too long to fill out 

54
00:03:44,520 --> 00:03:48,000
the form, so the business 
analyst removes a bunch of 

55
00:03:48,000 --> 00:03:50,480
fields, making it shorter. 
I had something similar about a 

56
00:03:50,480 --> 00:03:53,200
dashboard. 
It's it's there's too many 

57
00:03:53,200 --> 00:03:56,680
options so we'll just remove 
fields. 

58
00:03:57,880 --> 00:04:01,720
Users are briefly happy but a 
month later customer onboarding 

59
00:04:01,720 --> 00:04:04,280
drops because compliance checks 
now fail. 

60
00:04:04,280 --> 00:04:08,400
And in my example more options 
were asked for ones who went to 

61
00:04:08,400 --> 00:04:12,880
the public. 
The pain point was time. 

62
00:04:14,040 --> 00:04:15,840
Too many fields to fill in takes
time. 

63
00:04:16,279 --> 00:04:22,480
The problem was a lack of auto 
generated or integrated field 

64
00:04:22,480 --> 00:04:25,200
options with the existing 
systems which already had some 

65
00:04:25,200 --> 00:04:32,680
of that information. 
So don't amputate when a splint 

66
00:04:32,680 --> 00:04:35,960
would do. 
OK, so that example being don't 

67
00:04:35,960 --> 00:04:38,680
start chopping things off where 
you might just need to put some 

68
00:04:38,680 --> 00:04:41,600
reinforcements behind what 
you're doing. 

69
00:04:43,080 --> 00:04:46,040
The five whys will save you. 
I talk about this often. 

70
00:04:46,480 --> 00:04:51,000
Pain is what you're told. 
Problem is what you find after 

71
00:04:51,000 --> 00:04:56,160
elicitation, after 5 layers of 
why I'm sick of all these 

72
00:04:56,160 --> 00:05:00,080
emails, why they're asking for 
updates. 

73
00:05:00,440 --> 00:05:02,840
Why? 
Because no one knows the 

74
00:05:02,840 --> 00:05:05,080
project's status. 
Why? 

75
00:05:05,840 --> 00:05:07,680
Because we're not updating the 
dashboard. 

76
00:05:08,000 --> 00:05:10,680
Why? 
Because no one owns it. 

77
00:05:11,280 --> 00:05:15,040
The problem is there's no clear 
rescue for project reporting. 

78
00:05:15,360 --> 00:05:18,880
Not that they're getting all 
these emails asking for project 

79
00:05:18,920 --> 00:05:21,400
updates. 
Keep asking. 

80
00:05:22,120 --> 00:05:24,000
You're not annoying. 
You're being effective. 

81
00:05:24,000 --> 00:05:26,600
OK? 
And you need to probably let 

82
00:05:26,600 --> 00:05:29,360
people know you are using the 
five wives so they don't think 

83
00:05:29,360 --> 00:05:32,560
you're a small child who do the 
five wives very well. 

84
00:05:35,320 --> 00:05:42,960
Paine prioritizes emotion, and 
problems prioritize impact. 

85
00:05:44,000 --> 00:05:47,320
A sales manager might say 
Asserium sucks, Salesforce 

86
00:05:47,400 --> 00:05:50,880
sucks. 
But if you dig deeper you find 

87
00:05:51,160 --> 00:05:55,160
out that the actual issue is 
data entry takes too long. 

88
00:05:55,360 --> 00:05:59,840
Reps don't log calls, leads are 
followed up, revenue suffers. 

89
00:06:00,840 --> 00:06:05,600
Don't design the solution around
the loudest complaint design. 

90
00:06:05,760 --> 00:06:09,920
Design your solution around the 
biggest consequence, and there's

91
00:06:09,920 --> 00:06:12,480
a lot there. 
Just replay that message. 

92
00:06:12,720 --> 00:06:16,680
Don't design the solution around
the loudest complaint. 

93
00:06:17,240 --> 00:06:20,520
Design it around the biggest 
consequence where you're going 

94
00:06:20,520 --> 00:06:24,640
to have the biggest impact. 
I see people getting down and 

95
00:06:24,640 --> 00:06:26,720
just collecting pain points as 
requirements. 

96
00:06:27,000 --> 00:06:33,560
They're not requirements. 
We take another example here. 

97
00:06:33,920 --> 00:06:38,720
You might, for example, in a gym
situation, I use Fitnation as my

98
00:06:39,400 --> 00:06:45,200
example gym, There might be a 
bit of a situation where maybe 

99
00:06:45,200 --> 00:06:47,560
the manager or the owner walks 
through and they go, the too 

100
00:06:47,560 --> 00:06:50,920
many staff are just standing 
around, like the gym trainers 

101
00:06:50,920 --> 00:06:55,600
are just standing around and 
they might react by slashing 

102
00:06:55,600 --> 00:06:58,120
rosters. 
But what's the real problem? 

103
00:06:58,880 --> 00:07:01,680
There's no alignment between 
customer booking and staff 

104
00:07:01,680 --> 00:07:04,960
schedulings. 
So in personal trainers are in 

105
00:07:05,240 --> 00:07:09,280
when you don't have staff who 
want them or it's part of their 

106
00:07:09,280 --> 00:07:11,240
account management. 
They're wanting to see stuff, 

107
00:07:11,600 --> 00:07:13,480
they're wanting to see their 
clients who are in the gym and 

108
00:07:13,480 --> 00:07:17,560
it's part of retention. 
So the fix might be a scheduling

109
00:07:17,560 --> 00:07:22,000
system, not cutting headcount. 
Listen to the complaint, but 

110
00:07:22,000 --> 00:07:26,640
diagnose the cause. 
The real solution is really the 

111
00:07:26,640 --> 00:07:29,480
knee jerk one. 
Really. 

112
00:07:30,640 --> 00:07:33,800
Now what can we do? 
We can use process models to 

113
00:07:33,800 --> 00:07:38,160
isolate the problem. 
One of the most underrated or 

114
00:07:38,160 --> 00:07:41,120
unused BA skills is a simple 
process map. 

115
00:07:41,640 --> 00:07:44,160
And I saw something posted on 
LinkedIn today, it got me a 

116
00:07:44,160 --> 00:07:46,920
little bit heated. 
I was going to reply around 

117
00:07:46,920 --> 00:07:48,080
that. 
You know, process models are 

118
00:07:48,080 --> 00:07:50,400
going to die. 
It is an analysis technique. 

119
00:07:50,400 --> 00:07:53,760
Yes, process models in the 
business to capture a a process 

120
00:07:53,760 --> 00:07:56,360
or a procedure that it might be 
out of date after 5 minutes is 

121
00:07:56,360 --> 00:07:58,480
true. 
But that doesn't mean that 

122
00:07:58,480 --> 00:08:01,840
process models and business 
analysis are something we're 

123
00:08:01,840 --> 00:08:04,440
going to throw away. 
And they're really, really 

124
00:08:04,440 --> 00:08:07,520
important even with AI, because 
it helps visualize where some 

125
00:08:07,520 --> 00:08:10,840
holes are. 
Let's say the scenario here is 

126
00:08:10,840 --> 00:08:14,200
that the OPS team says 
everything grinds to a halt when

127
00:08:14,200 --> 00:08:18,040
the customer wants to change in 
order throughout the process, 

128
00:08:18,600 --> 00:08:21,880
you'll often find that there are
three manual approvals. 

129
00:08:22,240 --> 00:08:26,600
There's a lack of system 
visibility and that there's a 

130
00:08:26,600 --> 00:08:30,440
inconsistent definition of 
change order versus you know, 

131
00:08:30,440 --> 00:08:33,400
they want new stuff as opposed 
to they got the wrong stuff. 

132
00:08:33,880 --> 00:08:41,080
Pane tells us where to look. 
Mapping tells you what to fix. 

133
00:08:41,440 --> 00:08:44,920
Remember that pane tells you 
where to look in your domain, 

134
00:08:45,520 --> 00:08:49,480
Mapping tells you what to fix 
and might identify help you 

135
00:08:49,480 --> 00:08:52,800
identify through the five ways 
and cross mapping with process 

136
00:08:52,800 --> 00:08:58,040
mapping exactly what your 
problem is now. 

137
00:08:58,960 --> 00:09:02,880
Just be aware that a pain point 
does not equal a problem 

138
00:09:02,880 --> 00:09:05,360
statement. 
I've I've I don't make this 

139
00:09:05,360 --> 00:09:07,240
clear enough with, hence this 
episode. 

140
00:09:08,000 --> 00:09:11,880
The trappers for junior BAS is a
user might say I need a new 

141
00:09:11,880 --> 00:09:16,400
screen BA got it. 
Let's spec the new screen. 

142
00:09:16,720 --> 00:09:20,800
No BA Lesson here is to 
translate the pain into the 

143
00:09:20,800 --> 00:09:23,960
problem statement. 
Customer service reps struggle 

144
00:09:23,960 --> 00:09:28,280
to find customer records during 
calls impacting resolution times

145
00:09:28,280 --> 00:09:32,040
and satisfaction. 
They've they're struggling to 

146
00:09:32,040 --> 00:09:35,000
find the information, not they 
need a new screen. 

147
00:09:36,640 --> 00:09:39,880
Now you're solving something 
measurable, not just building 

148
00:09:39,880 --> 00:09:41,840
what they want. 
And one of the solutions might 

149
00:09:41,840 --> 00:09:45,640
be get them a new string screen,
but it also might be the focus 

150
00:09:45,640 --> 00:09:47,960
of the windows. 
They're playing in all sorts of 

151
00:09:47,960 --> 00:09:49,480
bits and pieces, but they will 
jump. 

152
00:09:49,600 --> 00:09:52,240
Humans jump to solutions. 
We get it all the time. 

153
00:09:52,680 --> 00:09:54,560
The more they move into 
management, the more they move 

154
00:09:54,560 --> 00:09:57,480
into politics, the more that 
they talk to solutions because 

155
00:09:57,480 --> 00:09:59,640
that's what people want to 
ultimately hear. 

156
00:10:00,680 --> 00:10:03,960
But ultimately, those solutions 
never get delivered because 

157
00:10:03,960 --> 00:10:06,440
people are not focusing on the 
problem. 

158
00:10:09,120 --> 00:10:11,960
Let's look at a case study here 
with automation going roll. 

159
00:10:13,720 --> 00:10:17,120
The pain is that reporting takes
hours every Friday. 

160
00:10:17,480 --> 00:10:20,080
So the team automates the Excel 
report. 

161
00:10:20,560 --> 00:10:24,840
No, Why? 
The problem was inconsistent 

162
00:10:24,840 --> 00:10:27,840
data definitions from different 
business units. 

163
00:10:28,520 --> 00:10:32,960
If you automate a broken 
process, it only creates garbage

164
00:10:32,960 --> 00:10:35,200
faster. 
And this is the same lesson with

165
00:10:35,200 --> 00:10:36,920
AI. 
If you have garbage data, you're

166
00:10:36,920 --> 00:10:40,480
only going to create garbage AI 
output faster. 

167
00:10:42,000 --> 00:10:45,160
So just be aware of that. 
It's really important that we 

168
00:10:45,160 --> 00:10:47,160
need to make sure we just don't 
just automate it. 

169
00:10:47,160 --> 00:10:49,560
That's not our job. 
It's just to automate something 

170
00:10:49,560 --> 00:10:54,480
that's wrong. 
Empathy mapping actually 

171
00:10:54,520 --> 00:10:58,920
uncovers deeper paint, so if you
use empathy maps to surface 

172
00:10:58,920 --> 00:11:00,800
hidden human factors, it's a 
good thing. 

173
00:11:00,800 --> 00:11:03,680
So you're not avoiding the 
painful conversation or the 

174
00:11:03,680 --> 00:11:07,040
emotion. 
But you might get an example 

175
00:11:07,040 --> 00:11:10,320
where users are consistently 
complaining about password 

176
00:11:10,320 --> 00:11:12,920
resets. 
It happens often, probably. 

177
00:11:13,240 --> 00:11:16,000
And your organization. 
And the real issue is that 

178
00:11:16,000 --> 00:11:20,120
they're logging in from kiosis 
and they can't remember long 

179
00:11:20,120 --> 00:11:25,040
passwords under pressure. 
So sometimes the problem is 

180
00:11:25,040 --> 00:11:28,320
environmental or cultural, not 
technical. 

181
00:11:28,720 --> 00:11:30,680
It's about what they're doing in
their environment. 

182
00:11:30,680 --> 00:11:33,280
So if you use empathy mapping, 
you might be able to meet them 

183
00:11:33,280 --> 00:11:36,200
halfway and figure out why 
they're feeling that way and 

184
00:11:36,200 --> 00:11:38,480
what needs to change in the 
environment, not jump to 

185
00:11:38,480 --> 00:11:40,600
solutions. 
Again, it's another way of 

186
00:11:40,600 --> 00:11:43,040
tackling it. 
It's a really good idea, and 

187
00:11:43,040 --> 00:11:45,960
empathy mapping should become 
part of your toolkit, if it 

188
00:11:45,960 --> 00:11:49,560
isn't already. 
And #10 you can actually do 

189
00:11:49,560 --> 00:11:52,880
this. 
The practical step is before 

190
00:11:52,880 --> 00:11:56,600
jumping to requirements, build a
simple table, maybe 3 columns, 

191
00:11:57,080 --> 00:11:58,640
lists the pain point you're 
hearing. 

192
00:11:58,800 --> 00:12:03,520
Form is too long, too many 
emails, hard to use the app in 

193
00:12:03,520 --> 00:12:07,240
the middle after the five wires.
Put in your root cause and your 

194
00:12:07,240 --> 00:12:11,160
problem and you might you might 
find this by doing a process 

195
00:12:11,160 --> 00:12:13,640
map. 
So in the middle column for form

196
00:12:13,640 --> 00:12:17,200
is too long, you might find that
manual re entry across three 

197
00:12:17,200 --> 00:12:20,880
different systems. 
And then for too many emails, 

198
00:12:20,880 --> 00:12:24,720
you might find there's no shared
task view or unclear ownership. 

199
00:12:25,280 --> 00:12:28,800
And for hard to use app, it 
could be that there's poor UX 

200
00:12:28,800 --> 00:12:32,760
design or inconsistent labels. 
So they're your first two 

201
00:12:32,760 --> 00:12:36,160
columns and then list potential 
solutions. 

202
00:12:37,040 --> 00:12:40,480
So after you've done those two 
steps, which is why I haven't 

203
00:12:40,480 --> 00:12:43,920
given you that just yet. 
So for our pain point form is 

204
00:12:43,920 --> 00:12:46,880
too long and we've heard about 
the root cause manual entry. 

205
00:12:47,600 --> 00:12:50,640
The potential solution could be 
pre filled from the CRM and 

206
00:12:50,640 --> 00:12:54,000
integration. 
For too many emails where there 

207
00:12:54,000 --> 00:12:56,240
are no shared view and unclear 
ownership. 

208
00:12:56,240 --> 00:12:58,920
It could be a racy model and a 
shared board. 

209
00:12:59,680 --> 00:13:03,920
And for when we had the pain 
point of hard to use app which 

210
00:13:03,920 --> 00:13:08,040
was really because of poor UI 
design and UX design and 

211
00:13:08,040 --> 00:13:12,600
inconsistent labels, we could 
potentially solve that by doing 

212
00:13:12,600 --> 00:13:17,240
usability testing and making 
sure it has a design pass or 

213
00:13:17,240 --> 00:13:20,920
redesign. 
This keeps stakeholders focused 

214
00:13:21,080 --> 00:13:23,160
and avoids silver bullet 
thinking. 

215
00:13:23,160 --> 00:13:26,360
So you can show them this table 
and say this is your pain point.

216
00:13:26,360 --> 00:13:29,200
Here's the solution you came up 
with, but what we need is a root

217
00:13:29,200 --> 00:13:31,160
cause or a problem in the 
middle, because that's what BAS 

218
00:13:31,640 --> 00:13:35,120
deal with. 
Pain points are your early 

219
00:13:35,160 --> 00:13:37,400
warning system. 
They're important. 

220
00:13:38,200 --> 00:13:39,880
They're how the business cries 
out. 

221
00:13:40,760 --> 00:13:44,400
But problems are your mission. 
That's what you're here to 

222
00:13:44,400 --> 00:13:46,640
solve. 
If you want to be a Better 

223
00:13:46,640 --> 00:13:49,560
Business analyst and not a 
glorified note taker. 

224
00:13:49,840 --> 00:13:54,200
Learn to love the gap between 
what people say it and what's 

225
00:13:54,200 --> 00:13:57,880
really broken. 
Go back to your current project.

226
00:13:58,200 --> 00:14:01,640
Ask yourself, am I solving the 
pain or the problem? 

227
00:14:01,920 --> 00:14:04,880
And if you don't know, it's time
to dig deeper. 

228
00:14:05,200 --> 00:14:06,240
I'll see you next week.