We define the problems from episode 14's operational learning session and discuss what goes into properly crafting problem statements.
(Transcript Start)
[00:00:00] spk_0: This is Andy and this is Matt and you're listening to
[00:00:03] spk_1: the Hop podcast with no name.
[00:00:06] spk_0: What a dumb name. So stupid.
[00:00:23] spk_1: And we're off episode 15, which I just looked up and much to your chagrin is our, our crystal episode because your 15 year anniversary,
[00:00:33] spk_0: so the 15 year anniversary of each episode
[00:00:37] spk_1: of episodes and that's where we're at. All right. And here we are. Don't
[00:00:44] spk_0: play. I'm sorry, I did not get you a gift. I, I'm very sorry. I
[00:00:49] spk_1: didn't know my presence is your gift every time, every time we do one of these that that's what you get. Um But yeah, so we're, we are episode 15, it's going to be all about problem statements, correct,
[00:01:04] spk_0: all about them, all about them. Um Which homework last week? Right? Was to listen to our operational learning discussion around um the ins and outs of actually booking flights and travel and hotel and what that actually is like in
[00:01:24] spk_1: our world. I think it was more about the ins and outs of what it's like working with you.
[00:01:29] spk_0: All right. Ok. Oh, yeah. Fair enough. Yeah. Yeah, we focused on the process and then you also got a lot of insight as to what it would be like to have to deal with me on a regular
[00:01:39] spk_1: basis for everyone to
[00:01:41] spk_0: see. Um And then, so we used that as just an example of what operational learning is. Um so that we had something to then try to wrap some problem statements around. Um So folks might want to listen to that if they haven't, it just, I mean, the problem statement, we'll talk to it. But the problem statements, obviously, the specificity of them comes from what we talked about on the last episode.
[00:02:05] spk_1: Yeah, I mean, it generally it's a very good practice to tell people who listen to the show that you can't listen to this episode if you haven't listened to the last one. But that being said, if you have not listened to episode 14, uh episode 15, this episode will make slightly less sense. I think you'll still get something from it. Um But yeah, we would recommend listening to episode 14 because we go through all of the operational learning. And it was a good example of you doing operational learning for everyone to listen to which some people, some people I guess might find valuable
[00:02:38] spk_0: I was attempting to operationally learn. Um Even about something that uh many of the problem statements revolve around my existence, which is actually kind of hard to do, right? Because as you are learning, you are learning about your own actions and how your actions impact other people. Um And so to stay in the learning space and not in the defensive space can be difficult to do. But that ability is actually incredibly useful in your personal life. Sometimes it comes up in the work world. Like if you happen to be the person who is responsible for a process or a task and you help design it and then people are just telling you your baby's ugly over and over again. Um That does come up but many times the way that it at least manifests in my life is in my personal life when I'm learning about other people's reality and how I act or decisions I make, how it affects them.
[00:03:29] spk_1: We also learned that I have no problem telling you all of your problems.
[00:03:33] spk_0: We had, we had the conditions for candor in this circumstance um which is uh with a little bit of practice is a little bit easier to create than at least my initial assumptions on how hard it would be to get people to talk. So what we learned, it's quite a bit about the ins and outs and the difficulties of booking travel and the fact that in our lives, Matt has taken on that responsibility and yet it is quite difficult for him to execute it based in our current system and the conditions
[00:04:05] spk_1: that we have, I didn't say this last time, but just thank you for giving me that responsibility. I, I really, I really appreciate it and no, I have no problems with it as, as everyone knows.
[00:04:16] spk_0: Um, and so what we would want to do, like if this was, uh, any sort of operational learning learning team or otherwise, after we've done some learning, which we would do over multiple sessions, not just one session, um, we would then try to wrap some words around the problems that we're facing and the way that we would do this like in a work setting. Um What I tend to do if I'm facilitating any sort of operational learning is I actually try to take the first pass at wording what the problem statements are knowing that I'm probably gonna get them wrong, but I do that to cut down some of the amount of time just in the word smithing piece of it because we don't really want to get caught up on the words that we're using. We just wanna make sure that the words are adequately describing the problems that we're facing in any sort of operational learning. We're gonna have multiple problem statements. So we're not just looking for one thing and the scope of how we're defining the problem becomes pretty important. And it's almost like it's a, it's a bit of a, a goldilocks sit situation
[00:05:16] spk_1: come up so often in my life or something. But yes, it
[00:05:18] spk_0: is. Um We don't want the problem statement to be super super general and we also don't want it to be so specific that it is accidentally giving you a solution rather than a problem. So example, based on the process that we learned about of the the booking process, a super general problem statement that would not be very useful is that Andy's life makes it really difficult to book flights,
[00:05:46] spk_1: which is, which is actually interesting because you could even shorten that to Andy's life, makes it difficult
[00:05:53] spk_0: period, period.
[00:05:56] spk_1: But, but yes, that would be entirely too broad to say that you
[00:06:00] spk_0: my, my my main exist, right? So, so that is not a great problem statement because um anyone who wasn't part of the conversation, like there's not, there's not enough words or context to even start to form a mental picture of what it actually means what the problem is. It's not that it's terribly inaccurate, right? It's just that it's too general. I feel it's very
[00:06:20] spk_1: accurate
[00:06:23] spk_0: and then the other side, right? So that the the too specific is oftentimes um we actually skip to a solution and we don't even define the problem, like basically in, in this circumstance, you know, we would have to say uh that like Matt needs his own credit card to make booking flights easier. That's actually not a problem statement that that is a solution disguised as a problem statement. And so we would call that too specific because actually it's not even a problem statement. We've just
[00:06:56] spk_1: determined what the answer is. And we just said it like, yeah, it could be a problem. So they said we're gonna solve it.
[00:07:00] spk_0: Why it is so helpful to have problem statements is then it allows you multiple different ways to uh address the problem. So you don't pigeonhole yourself into one solution, especially because oftentimes when we're doing operational learning, we don't necessarily know all of the constraints that we will be under Meaning we don't have a full mental picture of all of the resourcing difficulties or how um we might have one group of people interact with a solution set. And so until we start to try out solutions, Tr Storm solutions, we won't know all of those constraints. So it behooves us to have multiple ways to try to address the problem and to do that. Well, we actually have to articulate the problem. So should we take a stab at actually articulating some of the problems that this booking process has in it, Matt,
[00:07:50] spk_1: yes. And we can also show that we, we do our own homework sometimes. Yes. And we define our own problems.
[00:07:56] spk_0: We did. So we went through and we listened to our own difficulties,
[00:08:01] spk_1: which is if you, if you ever recorded yourself and then heard yourself speak, it is never what you expect, but we did it
[00:08:09] spk_0: and then tried to wrap some words around the problems and what do we got, Matt? You want to throw one of them out there. I will, I
[00:08:15] spk_1: will. We said it's difficult for Matt to book flights without Andy's repeated input because family related restraints that only Andy knows pop up and cause some disruption.
[00:08:34] spk_0: So the reason why that might be a problem statement that could be helpful is that it has enough information in it that we know that there's um what we might decide is an opaque part of the system, meaning my knowledge of my world is not transparent to that. And he needs that information in order to be able to make a good decision. And so you could actually use those words if you want to get fancy about transparency or opaque parts of your system. But in this case, that's what it's describing is that there is something, some information that is not transparent to matt that he would need in order to make a good decision. And the way that we are trying to solve that problem in our current process is that he has to call me over and over again while trying to book this. And that's not a great way of solving the problem because it actually is taking up a lot of time.
[00:09:23] spk_1: And then we don't often have time where we can just wait to be together and do it next to each other. Um But also this is an example, but at the time we were doing this most recent booking, your both your kids were sick. Correct. So I wasn't even, I wasn't gonna be there no matter what we were gonna spend any time together. So I had to call you, call you, call you as you're juggling two sick kids. I
[00:09:43] spk_0: was like, why is he calling me again? This is
[00:09:45] spk_1: crazy. And I was like, what time does jeez, when can we leave? We leave this time and then we hang up and like, when, when do we get back?
[00:09:56] spk_0: Is James leaving? When is Yeah. So, um so that might be one problem and, and in real life, like if you're trying to define this problem and you have multiple people in a room, if you're facilitating the discussion, you would just throw some wording out there and be like, hey, what I thought I heard last time is it's actually really difficult for Matt to, to actually book this without having to talk to Andy multiple times because she has a bunch of information that he doesn't have at the time that he's trying to book it and it has to do with her family and the constraints. And then I would say, does that sound right? And to that you would Matt, what would you say in the circumstance? Does that sound right?
[00:10:30] spk_1: Right. That is. Exactly. And we've done operational learning together where we've thrown in a problem problem statement and they've been like, no, that's, that's actually not it.
[00:10:39] spk_0: Absolutely. Yeah. I would say a significant portion of the time, my first attempt personally as the facilitator to articulate the problem is wrong. Um But people are more than willing sort of at this phase of operational learning to be like, no, that's not quite it. Um And sometimes I pick out a thing that is, it is a constraint, it is a difficulty, but in terms of scale of difficulty, it is not high on the list. And so I'll say it and people will be like, yeah, yeah, I guess, but that's not really all that important. It's
[00:11:13] spk_1: also important to recognize that you don't lose credibility when you try it. If what you've shown is your genuine curiosity the whole time you've done operational learning and then you try to summarize the problems, I mean, and get it wrong. That's not, that's actually not bad. You just sparked conversation to further clarify and improve upon. So if you're nervous to go and try it, I can't tell you don't be because I can't control you don't be. But just know that if you, it's not gonna make it any worse, right? So long as you're not wildly wildly
[00:11:43] spk_0: inaccurate. So what I heard, Matt is you're not taking responsibility for booking things, right? If, if that's what if that's what I said, I wish that was an option. Um All right. So that was one of the, one of the problem statements that we came up with. What, what was another one?
[00:12:00] spk_1: And this actually we worked backwards from, but uh it's about expenses. So it's difficult to keep track of expenses with multiple cards, which we didn't really explain last time as sort of a barrier that we had. But that's, and we sat back and talked about it. That is definitely why we have the one card.
[00:12:19] spk_0: Yeah, so one of the things that we talked
[00:12:20] spk_1: about, I weirdly Lord of the Rings,
[00:12:22] spk_0: one card, the one true card. Uh One of the things that we mentioned, right, as a difficulty in booking is the fact that that Matt is using my card. And so when we said, wait, why is that a difficulty? There's a couple reasons, right? So uh let's operationally learn about that, right? So apart from the parent child dynamic of you must use my credit card, um we mentioned in sort of in passing and now if we're operationally learning in multiple uh multiple rounds, multiple opportunities, that would be something that you'd key in on a facilitator to have more conversation about which we did actually by accident in preparation for doing this this episode. We're like, wait a minute. So what I think I just asked, so what is it, why is using my card a problem? Is it, is it have anything to do with like you just feeling uncomfortable using my card and like it's not yours and maybe that's fraudulent. I don't know what the rules are. And you said what
[00:13:19] spk_1: I mean? Actually what I do, what I always do, which is I, you ask me something and then I'm looking at you as you're asking me and then I look away. So I'm like I need a minute. So sorry, I repeat the question. So
[00:13:33] spk_0: the question was um in using my card, like what difficulties is that actually creating? I
[00:13:39] spk_1: mean, one we in person kind of have to be tied at the hip for a lot of things, right? So if we're going to check in at a hotel and they want the card on file, you know, there has been times where we've traveled and we had to stay at two different hotels for whatever reason, each one only had one room. And so I'd have to like bring you in with me and say this is the person with the car and then get checked in and then drive you to your hotel and then,
[00:14:06] spk_0: and then you drive
[00:14:07] spk_1: back. It's fun for me.
[00:14:09] spk_0: Yeah. And then when we get the, yeah, we kind of have to be, you're stuck with me whether you like it or not, even in times where you could be independent because you're using my card and, and usually in person, they ask for ID to verify that you're the cardholder. So, so that brings up a host of problems in using the card. And so the way that we then sort of defined that is that what you just said? Right. It's the problem that we're trying to solve by using the same card is the fact that it's difficult to track expenses on multiple cards. And that's why we're using one card is to make it easier to track expenses. But our solution set of using one card clearly has created a whole other host of problems. And so it's time to go back to the drawing table on how to address that problem I
[00:14:59] spk_1: saw was drawing board. But OK.
[00:15:01] spk_0: Yeah, it was probably right. So I am sure there are more problem statements that we can pull out of the operational learning. But for us as the end users of this process, those are kind of the two big ones of hey, hard for you to make decisions without knowledge that's living inside of my brain. We've got an opaque part of the process and the transparency. The way we're trying to solve it is through multiple phone calls, which isn't optimal in many circumstances. And then also using one card is not an optimal solution for the fact that we're trying to just track expenses because it creates a whole other host of problems. And so those would be the two that we would go after and in operational learning once we've defined those problems, this is the fun part because now you know whether you're just one on one with somebody or you've got multiple people in a room or even if you want a crowd source solution sets. You're just trying to come up with, with possible ways to address a well defined problem. And my guess is one of these, we could crowd source and most likely we're gonna get some suggestions on how to fix it. And that's the, one of it's hard to keep track of expenses on multiple cards. My guess is that, that's actually not true if you have the right cards and the right technology and the right software and the right any of
[00:16:14] spk_1: those things problem. For sure. Sure. There's immediate solutions we can
[00:16:18] spk_0: find. Um And for others. Right. Uh let's just toss around some crazy ideas for that first pro statement of like it's hard for you to have the information that's living inside of my brain. When you're trying to book things, we could go with the extreme of, well, Matt shouldn't be booking it. Right. And he's the one with the constraints, right. That's one possible option. What's another option? I mean, we,
[00:16:41] spk_1: we use the calendar for a lot. So the week before any travel is gonna be booked, you can put out on the calendar, what your constraints are for the days we have to leave and the days we have to return
[00:16:51] spk_0: or even the opposite of the constraints of like these are the open windows where it would make sense to be doing the travel. Right? I could put that on the calendar. That's an option. Um I don't know crazy. Uh, we could do a weird flow chart of like, if, then statements of how I'm making those decisions,
[00:17:13] spk_1: we could, we could, the flights themselves tend not to change. So, like if we looked for a flight right now in two months, we'd see all the available flights, we could just write them down as soon as we book them, as soon as we, uh, schedule a training and then you now know what to pick from. You
[00:17:29] spk_0: can have like a multiple choice, multiple choice option. Yeah. Anyway, and if you're doing any sort of everyone um listening right now is like, here's 20 other ways you could solve that problem.
[00:17:41] spk_1: Also, we get it. You all are bad at bookings.
[00:17:45] spk_0: But if you are in a mode of being able to do this operational learning, especially if you have multiple people in a room, like if you're doing a learning team, um this is the part where you can pull in things like lien tools or problem solving tools to help you. Like I used to use seven ways. So seven ways as far as I know what I've been taught is a lien originally a lien tool. Um And basically, if you have a well defined problem, each person who's sitting around tries to think of seven ways to address that problem. And usually you can only come up with like one or two or maybe three seemingly practical ways to solve it. And then you really have to push your thought process to get to 456 and seven. And so it just helps people push beyond like their original solution sets. When you have a whole bunch of people doing it, you end up with a laundry list of possible things to try. And it's usually kind of the, the solution that people like the most is oftentimes just a combination of a bunch of pieces of different peoples solutions. Um So that's a way of doing it. Um And then, you know, I in cases where it is a fairly common problem, it is fantastic to be able to actually crowd source solution sets. So if you can define the problem with words really well and back it up with some pictures. If you're dealing with things in the physical world, you can send that out into your internet within your own organization. Some folks like have gone on message boards and anonymously posted things to the to the internet to be like, hey, has anyone ever seen a tool that has the guarding that allows you to do XY and Z in this circumstance to try to solve a problem that they found in a learning team. So there's lots of ways to, to gather potential solutions as long as we're pretty comfortable being able to articulate what the
[00:19:29] spk_1: problem is. Yeah. And the, and the best uh problem statements that require the least amount of context on top of them. So they should just almost speak for themselves and you can, you can drop them in front of someone and they just take it and say I have an answer or I can go, go talk to this person, they know about this and it should be that that simple.
[00:19:46] spk_0: Yeah, if we have a really well defined problem, even if it has to be paired with some amount of pictures to help visualize something it can live by itself, right? So you can just take that little nugget of a problem and then allow other people to try to come up with ways to address it. And
[00:20:03] spk_1: when I say context, I mean, it wouldn't require them to have listened to the to the hours of learning that went into getting that that problem. They can, they can understand it with minimal
[00:20:12] spk_0: and actually that becomes an incredibly important piece of like the output of operational learning. People often say like the question they have is like, what, what do we produce? Like what report do we produce? What are we supposed to do after a learning team? Like how do we share information and a chunk of that? A big chunk of that is the problem statements and the ones that we have ideas for and also the ones we don't have ideas for. Um and some of the the corresponding ideas that is a piece of that and we'll talk more about the other outputs of operational learning probably next
[00:20:42] spk_1: time. Yeah, I guess, I think we should spend some time on what to do after you've operational learned too. Spend some time there. But we have homework. We do, we do have homework. We
[00:20:51] spk_0: have, if you want to try this out suggestion action, that's what we're calling it. Right.
[00:20:57] spk_1: It's called homework and you have to do
[00:20:59] spk_0: it. Um, our, our suggestion, our homework is that some, at some point over the next couple of weeks when you're in a meeting and somebody proposes a solution to something that you either are asking yourself or sometimes asking out loud to the folks in the meeting. What problem are we trying to solve? Because oftentimes when we get wrapped around the axle of like how to solve a problem and there's a lot of disagreement. It has very little to do with the actual solutions. It's the fact that we all think we're solving different problems. So the solutions sound different because actually the problem statements are all different. So sometimes taking that step of going backwards to be like, oh, ok, I hear this solution but tell me the corresponding problem, what are we trying to address with it? Um That can go a large way to help us make improvements. And it is a really, really, really important skill in operational learning is to be able to articulate a problem statement. And also acknowledge when we haven't said one, right? When we have when we don't know, collectively don't know what the problem is. That's it. That's
[00:22:10] spk_1: it. My, my boss used to do that to me all the time. One of my very first jobs I could be complaining about something and he would say, hey, so, wait, wait, just Matt help me understand what are we trying to solve here? And then I would just pause and I would just walk out of the room like he's right. I'm just complaining and that's, that's totally separate. But, uh, that's it. Thank you for listening and we'll talk to you again soon. Thanks so much.
[00:22:41] spk_0: Well, that's it. Yep.
[00:22:44] spk_1: Another one in the books we did it.
[00:22:48] spk_0: If you, uh, wanna send us any of your thoughts, actually fling us any of your thoughts you can do. So at the website www dot hop podcast dot com.
[00:23:00] spk_1: That's Hoppo DC A ST dot com. It's still
[00:23:07] spk_0: such a stupid name. A
[00:23:08] spk_1: stupid name. We look forward to hearing from you. Thanks for listening.