# Defining a problem space

I expect that I will probably post more on this topic but wanted to get the ball rolling. Based on my experience, an area that seems to be a near universal weak spot is defining a problem space. Defining a problem space as I use it has to do with identifying the most basic or overarching item it is that you are trying to solve. It could probably be as easily referred to as good problem definition. I prefer the problem space terminology because it makes me think of a collection of items or interlocking pieces that I am dropping in to a bag or a box. I can keep adding to or removing pieces as I like to improve how well they represent the problem.

A simple illustration of what I am going on about: I might say my problem is that I need a calculator. This isn’t really correct. A calculator is more likely a solution. So what is the problem? Well, maybe I need to solve a math problem (as opposed to needing a paperweight) , so that goes in to the problem space. How often do I need to solve this particular math problem? Let’s say reasonably frequently. That goes in to the problem space. Is this math problem kind of the same each time or does it vary a lot? Let’s say kind of the same. Into the problem space. How fast do I need to solve the problem? Let’s say really quickly. Into the problem space. This can go on and on. Only after taking a good pass at defining the problem space do I want to take a cut at the solution. I may need to revisit the problem space (I may need to iterate), as I try to solve the problem. Given the above example, a calculator is one solution. A second solution might be a spreadsheet. A third solution might be a pre-solved table. A fourth solution might be to do it by hand or in my head.

You might question whether this is important; I know I do. The reasons it has moved up for me are twofold. One, I see folks doing the equivalent of banging away on the calculator all day when 30 minutes of effort might produce a solution that drastically reduces the effort or cost in solving the problem. (I think there is another interesting thought in why folks might not want to reduce the effort) Second, scaling up beyond the simple example given, not defining the problem space or not keeping the problem space in mind run rampant across so many different people, organizations, processes, products, and functions at least in my experience. There seems to be an inverse correlation between ambiguity/problem difficulty, and whether a good job has been done in defining the problem space.

I am of the opinion that this is really just a skill that improves with practice and applying it whenever possible. This leads me to wonder why I notice so many examples where it isn’t applied. Have I just been exposed to a really bad sample? Are my perceptions inaccurate?

That’s why you make the Big Bucks. I think often people aren’t interested in solving or even finding the real problem, especially when it’s not in their immediate financial interest to do so. (Speaking from a work POV.) I also think a lot of it comes from the basic fear of change. Learning a new process is scarier than the several hours it takes me to do it this way. Finally and sadly, a lot of it comes from pure stupidity. (I’ll let people’s imaginations come up with examples of that…)