Problem Solving is Iterative

Last week I gave a five minute talk on problem solving at an event called “Ignite Denver.” Ignite has an interesting format (You get 20 slides which automatically advance every 15 seconds) and the people who speak and show up to these events is a pretty diverse bunch. I welcome you to watch the recording. I have also already used a couple of the slides in a work context to emphasize how what I am saying is different.

Usually, people describe problem solving linearly. You write the problem down, and then solve it. However, there are plenty of cases we can all point to where we defined the problem, and later updated it. In those cases, you could be left wondering “What did I do wrong during the problem definition phase such that I got the wrong problem.” You could also say “eh, things change, this is just an unfortunate thing that sometimes happens.”

Neither of those interpretations are particularly helpful though. In one case we somehow assume we could theoretically avoid this thing that always seems to happen. In the other we have given up on avoiding this thing that can be quite expensive (changing direction). I choose a third path: Viewing problem solving as iterative. If you know you may have to update your problem statement, you can define and solve your problem differently. You can schedule in revisions at the appropriate times to course correct.

Assuming problem solving is iterative, we have some ideas of what we might do differently. But why can’t we just get the problem right the first time? My take is it all comes down to uncertainty. If you have uncertainty in what you know (information wise) or uncertainty in what you want, learning more about those things will change the problem to solve.

• In work, estimating the effort to do something can be difficult. If we are considering two technical solutions to a problem and one seems like it will be much easier, we’ll pick that. As the team gets to work, we may discover that the easier solution does not work at all or that it is not in fact easy. Depending on how much uncertainty you have about the other technical solution, it might make sense to jump ship.

• Often, we need to decide on tradeoffs between different priorities. Even for the example above: typically, we are choosing between the effort of a particular approach, and exactly how well it solves the problem. Work in the field of Decision Analysis addresses how to infer people’s preferences. People can choose between two alternatives pretty well though. So rather than framing it as choosing a problem, I think of understanding uncertainty in what you want as choosing a solution. (I have written about this idea before. This link is one example).

In either of these cases, we could learn things either during or after we have solved our first version of the problem. If things we learn do not change which problem we set out to solve, great! One shot works.

The rest of the time though, or when you are specifying your problem statement and you have some uncertainties, plan for iteration.