SOPD – Second Order Problem Distraction
I came across a company today that reminded me of a problem solving trap that I call “Second Order Problem Distraction” (SOPD). SOPD happens when you are trying to solve a problem but get distracted by another problem that is related, but serves only to distract you from the root cause. This is a very common trap for a team to fall into and I believe it is responsible for a lot of product failures.
Avid cyclists know how much of a hassle flats are, especially when you are using your bike to commute and you don’t have a lot of time to be fooling around on the side of the road with a flat repair. Let’s take a look at some of the solutions in this problem space to see what we can learn about SOPD.
When I was a kid the solution to the flat tire problem came in a little green box. It contained a miniature tube of cement, a couple of rubber patches, and a piece of sandpaper. With the contents of that box, a tire lever or two, and a pump, a careful and mechanically minded individual had a chance of repairing a flat in 30 minutes. If you asked 10 people who had repaired flats with the traditional little green box, they would tell you that the biggest problem was that the cement was almost always dried up when you needed it. If you stopped your investigation there and tried to innovate on that traditional solution, you would be looking for ways to get ride of the dry cement problem.
Several companies came up with solutions to the dry cement problem. Some had better packaging for the cement, some eliminated the cement all together by using a “peel and stick” patch. The latter, peel and stick patch kit was considered pretty innovative. It solved the dry cement problem and had the added bonus of no waiting for the cement to dry. I remember thinking that was a really cool solution when I first saw it. Those companies solved a significant problem in the traditional patching solution. However, they did not solve the real problem (the wasted time), they got distracted by the second order problem of the dry cement (SOPD).
Did you notice how the real problem got lost in the context of the traditional solution? When you ask people “what is wrong with the process of patching a tire“, they tell you exactly that. You must be very careful about what question you ask. There are lots of techniques in problem analysis to help you avoid this trap, the simplest of which is asking “why is that a problem?”. If you pursue a more rigorous problem analysis of the flat tire problem, you end up with several ways you can create value. One of those is by reducing the time it takes to restore the bike to normal operating condition.
Now I am hoping that many of you are jumping up and down about how the real root cause is the flat itself, and that the best solution would be to eliminate the flat altogether. Of course, you are right about that and a “flat proof” design for the bicycle tire would be a better solution to the first order problem. Interestingly enough, flat tires didn’t happen on bicycles for the first 80 years they existed because they didn’t have pneumatic tires! Air filled tires were part of the solution to the rough ride problem that the early “bone shaker” bicycles had. This example illustrates a truism in problem solving and innovation; The solution to the problem, creates the next problem.
Slime is another innovative solution to the flat tire problem. Slime is a sealant that you put into a tire before you ever have a flat. You might think of this as a proactive or preventative approach to the flat tire problem. Essentially slime sits inside your tube waiting for a puncture and then it squeezes out to plug the hole. So the makers of Slime obviously thought about the root cause problem and went about trying to solve the flat tire problem, instead of the dry cement problem. It creates substantial value for the user because it many cases it completely eliminates the time that would be lost to repairing a flat. No SOPD in this example.
Why wouldn’t everyone use Slime rather than spending all that time on the side of the road replacing or patching a tube? Slime is great when it works, but it has issues which some people feel make it less desirable than pulling everything apart and replacing the tube; it adds weight, it doesn’t work on sidewall punctures, and it doesn’t last a long time. This brings us to another truism; if the new problems that your solution creates cost more than the original problem did, your solution is doomed.
Patchnride took a different approach. Their focus was clearly on eliminating time wasted in flat repair like Slime did, except their solution only eliminates 90% of it. Their solution also doesn’t add any tire weight before the repair. Essentially they created a way to install a traditional patch on the tube very quickly without all of the disassembly of the traditional approach. This approach had the effectiveness of a traditional patch with most of the efficiency of Slime. But even Patchnride made design trade-offs that create new problems i.e., you have to carry the tool with you. The market will eventually tell us whether the design trade-offs that Patchnride made created more value than replacing a tube. They may have a good run in front of them, at least until someone perfects the flat-proof tire that doesn’t ride like a steel wheel Full disclosure, I have never used Patchnride and it’s not even available yet, so it is quite possible the technology doesn’t even work reliably, caveat emptor.
In all these examples the companies were trying to solve a real problem. Some of them solved what I call second order problems that created value but left a lot of value on the table because they only solved part of the first order problem. Sometimes this is a result of SOPD and other times even when the first order problem is well understood, the technology is not available to solve it yet. In those cases sometimes the best we can do is chip away at it one second order problem at a time. The trick is to make those choices consciously, keep pursuing the first order problem with fresh eyes, and be wary of SOPD.
What do you think?
Is SOPD a problem in your team?
Do you have any examples of SOPD that help to illustrate the problem?